Ransomware investigation: notes from the digital forensics front line

Laptop, tablet and computer screens on a desk

OLYMPUS DIGITAL CAMERA

I have always had a big interest in digital forensics; it’s why I chose to pursue this career path. This post documents my first official forensics case involving ransomware: in other words, I got paid to root through someone else’s computer.

Although my role is not limited to digital forensics, I enjoy when these cases come in. I want to start documenting my journey at BH Consulting and sharing what I am learning and the great experiences so far.

For this case, a client had ransomware on one of its laptops and needed to know how this occurred and what information it had encrypted. The investigation involved tracing how the infection happened, and what occurred when the ransomware launched. I was excited about what I would learn and the challenges I would face.

Until that point, my understanding of ransomware came from experiments on my own virtual machine and through college assignments. I had thought that most ransomware would encrypt anything and everything it could access. In fact, the variant on this client’s machine was very specific on what it wanted to encrypt. Just three folders: the favourites, links and another folder with the client’s name. Each folder had a text file within it, with instructions on how to pay the ransom to decrypt the files.

Ransomware design

Wondering why it only chose these particular folders to encrypt, I posed the question to my colleague. She replied that it really depends on the ransomware’s design and its purpose. Some ransomware, like WannaCry, or wiperware like Petya, can be way more malicious and have a larger impact surface.

Our client wanted us to find the initial attack vector the infection came from. During the investigation, I started researching what other variants did and where the initial vector of attack was. Some variants came through via email with an attachment or a URL redirection, but I noticed a lot of talk about how the most widespread method was via malvertising. Behind fake ad banners would be code to exploit and infect users with vulnerable machines who simply happened to visit a popular website without actually clicking on any ad.

Starting point

So for the investigation at hand, we had an idea on where to start looking for the initial infection: all users’ emails, their browser history and cookie information. This machine had had a few users so there were lots of areas to check. Thankfully, the research paid off and gave me an idea of exactly where to look. I looked within each user’s AppData, Roaming, Local and Locallow folders until I eventually spotted a suspicious looking .exe file within one users Locallow folder.

Bingo: we knew the name of patient zero.

Using our tools and manually checking the HEX timestamps, we could see the initial time of the file’s creation. This correlated to when the client first detected it. From there, we calculated the hash of the suspicious .exe file, inputted that hash to VirusTotal and checked some reputable AV solutions for their findings.

Success: VirusTotal identified it as a variant of the CryptoMix family of ransomware, which is known to several AV solutions. CryptoMix spreads via exploit kits, malicious attachments and malicious links spread across the internet on hacked domains.

Now we needed to find how the infection occurred in our case. We used our tools to check the victim’s emails, manually inspecting messages that had attachments or suspicious URLs. We looked for keywords and known subject lines of ransomware email attacks, but no luck.

Alarm bells

Could we find evidence of malvertising as the culprit instead? This CryptoMix variant exploited devices that still used out-of-date or deprecated versions of Flash, so we checked the version of Flash on this machine. Sure enough, the last Flash update was at the end of 2015 – leaving the machine vulnerable to numerous exploit kits. This particular variant used the Astrum Exploit kit which takes advantage of vulnerabilities within Adobe Flash Player.

We had a solid lead. Next, we investigated the victim’s internet traffic, basing our searching start time just prior to the known infection time. We saw the user read some articles on a news portal which loaded advertisements. Checking each of the URLs, we could not directly link the infection to the Astrum exploit kit, but we found that a domain related to the kit in the browser history around the time the initial infection took place. Moreover, the timeline of activity for the user suggested that the source of infection was most likely a malicious ad on a website that user had browsed.

I thoroughly enjoyed working on this case and I’m also grateful to my more experienced colleague for her guidance.

Other achievements

In my first six months at BH Consulting, I also had the pleasure of writing a white paper on how to prevent ransomware which was published by Help Net Security after the initial spread of WannaCry (shameless plug 1). Then I was part of an expert panel discussing the aftermath and lessons learned of WannaCry in a webinar hosted by Infosecurity Magazine (shameless plug 2).

In future blog posts, I will share my experience of performing vulnerability assessments and penetration testing of clients’ applications; certifications achieved so far along with my journey to CISSP and CEH; ISO27001 auditing; and the differences of a client-facing security role compared to desk-based security.

1 Comment

  1. Out of date software is a common problem for many companies, especially when talking about such kind of attacks. Company technical staff need to pay more attention about security issues & recommendations.

Leave a Reply

Your email address will not be published. Required fields are marked *