LetsDefend — LockBit Challenge Walkthrough

A Memory Forensic Investigation with Volatility3, Volatility2, and VirusTotal

Image Credit: https://letsdefend.io/

Introduction:

Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the LockBit Challenge from LetsDefend, you’re in the right place. Prepare to be thrown right into the world of digital forensics and incident response (DFIR).

A victim’s device has been compromised with ransomware and all their files have been encrypted — now the attacker is demanding payment! Our objective is to dissect a memory dump of the infected device, provide an analysis of the attack, and understand our options. To accomplish this mission, we’ll leverage Volatility3, Volatility2, and VirusTotal to hunt for the malware process, determine what ransomware family it’s part of, scour VirusTotal to detail its behavior, and uncover how the malware elevates privileges and stays persistent on the system.

Sounds like fun, right? Let’s get into it!

And hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!

Thanks for reading and going on this investigation with me!

Challenge Link: https://app.letsdefend.io/challenge/lockbit

Challenge Scenario:

You are a Digital Forensics and Incident Response (DFIR) analyst tasked with investigating a ransomware attack that has affected a company’s system. The attack has resulted in file encryption, and the attackers are demanding payment for the decryption of the affected files. You have been given a memory dump of the affected system to analyze and provide answers to specific questions related to the attack.

Question 1: Can you determine the date and time that the device was infected with the malware? (UTC, format: YYYY-MM-DD hh:mm:ss)

Let’s kick off this investigation by extracting the ChallengeFile containing the memory dump of the victim’s system, Lockbit.vmem.

To analyze the contents of this file we’ll use Volatility, a popular memory forensics tool. There are a couple of versions of Volatility: Volatility 2.6 (the original, no longer in active development) and the latest, Volatility3 (in active development.) They are a little different but for this challenge, we’ll start with Volatility3 but (spoilers) we will also have to use Volatility2 to solve Question 4. Don’t worry, I’ll note which version to use since the commands will change, too.

Finally, before we dive into Volatility3, let’s get familiar with the command to show the Volatility3 manual pages. This is handy way to see what plugins are available for use:

vol -h

Now, let’s get started hunting for the malware process. To identify the malicious process, the first step is to understand what processes were running on the victim’s system during the incident when the dump was taken. We’ll accomplish this by leveraging Volatility’s windows.pslist plugin to scan the image and list the running processes on the system using the syntax below:

vol -f Lockbit.vmem windows.pslist

Let’s go out on a limb and assume that the obvious one called mal.exe is the process we are looking for. From there, we just need to grab the timestamp from the CreateTime column to determine when the device was infected.

Question 2: What is the name of the ransomware family responsible for the attack?

To identify the ransomware family, we first need to obtain the file hash of the malware’s executable by first extracting the process from the memory dump. We can do this by using Volatility3’s windows.dumpfiles plugin to dump file contents from the image. Use the syntax below, specifying an output directory for the dump, and the process ID (PID) of the mal.exe process we found in Question 1.

vol -f Lockbit.vmem -o <YOUR OUTPUT DIRECTORY> windows.dumpfiles --pid 900

This will give us two separate output files: a .dat and a .img. I’ll put the results for both below, but for this example let’s run a SHA256 hash calculation on the extracted .img file right from the terminal. Then, we’ll submit the hashes to VirusTotal to check if there are any hits.

sha256sum file.0xfa801bfe5320.0xfa801c116990.ImageSectionObject.mal.exe.img

IMG File — VirusTotal Report: https://www.virustotal.com/gui/file/5988e75518b2f365671dc49da18b5a70274351721f1f3a8f8f7bf32984e4024c

sha256sum file.0xfa801bfe5320.0xfa801bde2b10.DataSectionObject.mal.exe.dat

DAT File — VirusTotal Report: https://www.virustotal.com/gui/file/cea3e8a3e541ae4c928c3cd33f6772f1a69746393ac1a5c4575379a09a92d1e1

After receiving the report for the .img file, the sample has previously been analyzed by VirusTotal and is detected as malicious by most scanning engines on the platform. What we are most interested in is the Family labels tag where we’ll see that the malware is part of the Lockbit ransomware family.

Question 3: What file extension is appended to the encrypted files by the ransomware?

Let’s continue using the VirusTotal report to see what else we can learn about the malware. The next stop is to check the Behavior > File System Action tab.

In this area, we can check the Files Written by the malware to determine what extension it’s adding to the files it encrypts. For this sample, we can see that the ransomware appends the .lockbit extension to the encrypted files:

To confirm we see the same behavior, let’s jump back into Volatility3 and search the victim’s image for anything similar with the windows.filescan plugin which can search for file objects. To make this easier, we can grep “.lockbit” to narrow down the results.

vol -f Lockbit.vmem windows.filescan | grep -i ".lockbit"

While this is just a small sampling of the files with this extension, it’s enough to confirm that we have found the correct answer to Question 3!

Question 4: What is the TLSH (Trend Micro Locality Sensitive Hash) of the ransomware?

To answer Question 4, we need to find the Trend Micro Locality Sensitive Hash (TLSH) of the ransomware binary. TLSH is not a term I’m familiar with, so let’s do some Google research. We’ll find that according to Trend Micro, a TLSH is:

a kind of fuzzy hashing that can be employed in machine learning extensions of whitelisting. TLSH can generate hash values which can then be analyzed for similarities. TLSH helps determine if the file is safe to be run on the system based on its similarity to known, legitimate files.

Put another way a TLSH can be used to detect similarities between objects in data even if the content is not identical. So similar pieces of malware would have similar a TLSH. But how do we determine the TLSH of the .img file we submitted to VirusTotal?

Handily, VirusTotal already calculates the TLSH upon submission so we can simply refer back to the Details > Basic Properties tab on the VirusTotal report. Easy enough!

Or so I thought…

We’ve run into a problem: the TLSH reported from the two files (.img & .dat) that we dumped in Question 2 do not work to solve the question.

For some hindsight: Next, I tried dumping the process by using the windows.memmap and windows.dlllist plugins, and while I got some different SHA256 hashes to submit, none matched what the question was looking for. So, after stumbling around researching on Google, I finally found the following issue on the Volatility3 GitHub with this comment:

procdump produced files have different checksums from volatility 2 · Issue #160 ·…

This is because the volatility3 procdump plugin currently outputs files as if they had been dumped by volatility2 with --memory (ie, it's dumping the memory image, not the reconstructed PE file)

Ah-ha! Since there are differences in how the process dump works between the two versions of Volatility. Let’s switch to Volatility2, dump the process again, and compare the output.

In Volatility2, we first must determine what OS image profile is needed — notice that we are using vol.py now on the analysis environment to launch Volatility2.

vol.py -f Lockbit.vmem imageinfo

Once we find the correct profile, let’s try dumping the mal.exe process again using the procdump plugin:

vol.py -f Lockbit.vmem --profile=Win7SP1x64 procdump --pid=900 --dump-dir=YOUR-OUTPUT-DIRECTORY 

This time, Volatility2 dumps one reconstructed binary instead of the two separate .img and .dat files. Let’s submit the new file (executable.900.exe) to VirusTotal and see if this changes the resulting TLSH:

EXE File — VirusTotal Report: https://www.virustotal.com/gui/file/19ca5aa4cd62929afb255d2b38e70fd3143e3b181889e84348a5c896e577d708

VirusTotal

Bingo! By switching from Volatility3 to Volatility2 to run the process dump, we’ve located the correct VirusTotal report and corresponding TLSH!

Question 5: Which MITRE ATT&CK technique ID was used by the ransomware to perform privilege escalation?

Now that we have a new VirusTotal report to review, let’s analyze its behavior, focusing on the Behaviors > MITRE ATT&CK Tactics and Techniques section. We’re looking for privilege escalation techniques, so expand the privilege escalation header to see all the observed tactics and techniques used by the malware:

VirusTotal Behaviors > MITRE ATT&CK Tactics and Techniques

At this point in our analysis, we could be searching for any of the listed techniques to answer Question 5. To narrow it down further, check the next section, Malware Behavior Catalog Tree, focusing again on the Privilege Escalation behaviors.

VirusTotal Behaviors > Malware Behavior Catalog Tree

Comparing the two sections we do see some overlap in the listed techniques. Since the question is asking (and only has room for) the technique ID (T1543) and not the sub-technique, let’s check our work and see if we found the correct answer…

VirusTotal Behaviors > MITRE ATT&CK Tactics and Techniques > Create or Modify System Process (T1543)

Question 6: What is the SHA256 hash of the ransom note dropped by the malware?

Next, scroll down to the File system actions > Files Dropped section to see the observed file activity. We’re looking for anything dropped by the malware that resembles a ransom note. This will help identify the note’s name, which we can then search for in the memory dump using Volatility2. You’ll quickly notice that there are dozens of instances of a ransom note-y type files, Restore-My-Files.txt.

Dropped Files Summary from VirusTotal

In the same way that we handled Question 3, let’s jump back into Volatility2 and use the filescan plugin to search the file objects in the image for the ransom note. Again, we’ll use grep to filter the results matching the name of the ransom note:

vol.py -f Lockbit.vmem --profile=Win7SP1x64 filescan | grep -i "Restore"

Unfortunately, we don’t find anything that matches the string. So, let’s pivot to the mftparser plugin to scan the Master File Table (MFT) for the artifact:

vol.py -f Lockbit.vmem --profile=Win7SP1x64 mftparser | grep "Restore"

While this looks more promising and confirms the activity on the victim’s device, we have no way of extracting the files to calculate the SHA256 hash that is needed to answer the question.

Returning to VirusTotal; this becomes a process of elimination using the pre-existing analysis results. Starting at the top of the dropped files list, expand the first entry, “Restore-My-Files.txt,” to reveal the available SHA256 hashes. Let’s try each hash to see if any work.

Luckily, the first “dropped” ransom note in the list is the one we are looking for!

Question 7: What is the name of the registry key edited by the ransomware during the attack to apply persistence on the infected system?

Finally, let’s continue using the VirusTotal report and analyze the persistence mechanisms used by the malware. Looking at the MITRE ATT&CK Tactics and Techniques section again, we’ll find several observed techniques listed, but only one referencing the Windows Registry. This is a common persistence method where a threat actor might use a run key to execute an application when a user logs in (MITRE ATT&CK — T1547.001.)

Finding the relevant technique is a good start, but let’s see if VirusTotal can provide any more information about the created registry key. The next place to check is the Crowdsourced Sigma Rules section. These Sigma rules are open-source threat detection rules and can be extremely useful when applied to the VirusTotal analysis. For example, let’s open the rule hit for CurrentVersion Autorun Keys Modification:

The matching rule contains a TargetObject for the Autorun key modification. At the very end, we can see the very suspicious key object name — this could be what we’re looking for. Let’s double-confirm by scrolling down Registry Actions > Registry Keys Set section and see if this key appears again:

Since we’ve seen this key referenced twice and the location matches a known adversary technique, I think we’ve found our answer! Let’s submit the flag and wrap up our investigation!

Conclusion:

Mission accomplished! With the help of Volatility, we’ve successfully identified the malware process and found the file hash of the executable to determine its ransomware family. After that, we turned to VirusTotal to reveal more details about the malware including how it elevates privileges and stays persistent on the system. Now that we have scoped the attack and completed our objectives let’s close out this walkthrough of the LockBit Challenge!

A big thank you to LetsDefend, for another engaging and challenging lab scenario. This was a great learning opportunity because I hit a couple stumbling blocks particularly trying to uncover the TLSH of the malware binary. I was really interested in this question since I was unfamiliar with what a TLSH is and because the challenge didn’t specify any recommended tools, needing to pivot from Volatility3 to Volatility2 was an unexpected twist — I suspect this lab was designed with the older version in mind. But, this was a great example of the importance of staying flexible during an investigation — I’ve done a string of Volatility labs recently so I had gotten into a routine using Volatility3 and didn’t even consider choosing Volatility2 until a couple of hours of being stuck on that question — newer doesn’t always mean better and it’s a good reminder to check my own confirmation biases.

Thanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don’t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we’re in this together!

Until next week’s challenge — stay curious and be safe out there!

Tools & References:

VirusTotal (.img): https://www.virustotal.com/gui/file/5988e75518b2f365671dc49da18b5a70274351721f1f3a8f8f7bf32984e4024c

VirusTotal (.dat): https://www.virustotal.com/gui/file/cea3e8a3e541ae4c928c3cd33f6772f1a69746393ac1a5c4575379a09a92d1e1

Trend Micro: Smart Whitelisting Using Locality Sensitive Hashing | Trend Micro (US)

Volatility GitHub Issues: https://github.com/volatilityfoundation/volatility3/issues/160

VirusTotal (executable.900.exe): https://www.virustotal.com/gui/file/19ca5aa4cd62929afb255d2b38e70fd3143e3b181889e84348a5c896e577d708

MITRE ATT&CK — Create or Modify System Process (T1543): https://attack.mitre.org/techniques/T1543/

MITRE ATT&CK — Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder (T1547.001): https://attack.mitre.org/techniques/T1547/001/