LetsDefend — Memory Analysis Challenge Walkthrough
Endpoint Investigation with Volatility 3
Introduction:
Hello!
It’s another week, another challenge. This time I’m continuing with my write-ups of the practice challenges over at LetsDefend and will be tackling the Memory Analysis room. This room is rated medium difficulty and notes that we can use Volatility, a memory forensics tool to complete it. As always, I want to take the opportunity to give back to the community and do some write-ups as I go through the challenges to help anyone who stumbles across this post to level-up their analysis. I am new to using Volatility and excited to stumble through this challenge while getting some hands-on time with the tool. To keep this blog focused, I am not going to cover the setup for Volatility3 but I will point you to the readme over on their GitHub: https://github.com/volatilityfoundation/volatility3
Thanks for reading!
Challenge Link: https://app.letsdefend.io/challenge/memory-analysis
Challenge Scenario:
A Windows Endpoint was recently compromised. Thanks to our cutting-edge EDR/IDS solution we immediately noticed it. The alert was escalated to Tier 2 (Incident Responders) for further investigation. As our Forensics guy, you were given the memory dump of the compromised host. You should continue to investigate.
NOTE: You can use the Volatility for analysis.
This challenge prepared by 0xCyberJunkie.sh
Question 1: What was the date and time when Memory from the compromised endpoint was acquired?
Since we’re going into this one blindly, let’s start to get more familiar with Volatility3 by taking a look at the quick start guide on the GitHub page. It looks like there is a command used to check out what help options we have available within the application. This will help us to tackle the challenge moving forward.
python3 vol.py -hNow, the scenario says we are analyzing a memory dump from a Windows endpoint so let’s just scroll through the Windows modules to see if there is anything that might help us to get some general information about the memory dump. After scrolling through the list, we stumble across this module:
This plugin might be a good starting point for our investigation so that we can get some high-level details from the dump file and better understand our victim environment.
For context, I had previously downloaded and extracted the challenge file to my Kali Linux environment for analysis. When we run Volatility we will point to the challenge file path with the -f parameter and have it use the windows.info plugin.
After running the command, we get the above output. I think the SystemTime might answer the question — let’s confirm that we have the right answer:
Question 2: What was the suspicious process running on the system? (Format : name.extension)
Let’s leverage Volatility to dig a bit deeper and understand the running processes at the time the memory dump was taken. If we refer to the help again we have several process options. We’ll try the pslist module first to see if we can find anything suspicious. To make this a little easier to read, we’ll output this to a text file.
If we scroll through our evidence file, nothing initially sticks out as looking too suspicious. There are a few processes that I’m unfamiliar with but a quick Google refresher confirms that everything appears legitimate. Maybe we need some more detail? Let’s pivot and try something else process related — the pstree module could be interesting.
After looking over the output a few times, I still don’t see anything obvious (like evil.exe or something) sticking out. We are definitely missing something. Let’s brush up on normal Windows processes behavior using the excellent SANS Hunt Evil reference graphic.
After looking this over, I think I see something. Let’s revisit the pstree output and dial-in on the lsass.exe (PID 7592) processes.
Let’s compare the artifacts from the victim system to the SANS reference. Look closely at the below instance of lsass.exe (PID 7592) from the pstree output. There are a couple of red flags that we notice if we compare to the normal behavior documented above:
- The first red flag is the parent process ID (PPID) of this lsass.exe process. According to the SANS reference, this should be wininit.exe (PID 500) but the parent process for this lsass.exe is actually 3996 (explorer.exe) — That seems suspicious and definitely requires some further investigation…
- The second red flag is the image path of the executable. Take a close look and notice that the image path is %SystemRoot%\System\lsass.exe and NOT the expected path %SystemRoot%\System32\lsass.exe — this is a subtle evasion technique.
- Earlier, I mentioned lsass.exe processes — this is the third red flag, there are two instances of this process. This is something that should have tipped us off after running the pslist command (whoops!) If we search for lsass.exe and grep the output to the terminal we now see clearly that there are two different instances…
After focusing the analysis and comparing the known process behavior for lsass.exe (PID 7592), I think we can be pretty confident that we have identified the suspicious process. Let’s submit the answer and confirm.
Question 3: Analyze and find the malicious tool running on the system by the attacker (Format name.extension)
Now that we have uncovered the suspicious process, we will need to perform further analysis on the tool. Let’s circle back to the Volatility3 help command. In addition to the general help file, Volatility also offers help for the individual plugins options:
Since we know what process ID we want to analyze, maybe we can use pslist again to dump the running process from the memory dump file? Let’s try the help command for that specific plugin.
Awesome! There is a dump option. Once we feed Volatility the PID, we should get a file output to analyze.
Great, it worked! Let’s get to work on gathering some intelligence and see if we get any hits on VirusTotal or Hybrid Analysis. First we’ll grab a hash of the file which will help us document our indicators of compromise; we can do this right from the terminal:
Then, let’s search VirusTotal for any hits…
Okay — We’ve got a lot of detection and additional analysis for this tool now and we can confirm that it is malicious. For our challenge, we are looking for the name of the malware. VirusTotal has the filename listed as winPEAS.exe — let’s submit our finding and see if we are on the right track.
Question 4: Which User Account was compromised? Format (DomainName/USERNAME)
We’re going to jump back into Volatility to try and scope the impact of this malware and look for which user on the system was compromised. All of our previous process analysis has not given us much user information yet. Once again, we’ll turn to the Volatility command reference for a starting point:
To view the SIDs (Security Identifiers) associated with a process, use the getsids command. Among other things, this can help you identify processes which have maliciously escalated privileges and which processes belong to specific users.
This plugin sounds like it could be what we are looking for to uncover additional information. Since we know the PID (7592) of the malicious executable, let’s also see if we can get any info about the user account that ran it. We can run the getsids plugin and grep the malicious PID to the output. Hopefully, this will list out the security identifier (SID) of the user.
There we go! It looks like the top result is the user account, CyberJunkie. Even though we have the domain identifier in the SID, we still need to find the domain name to complete the question.
If we go back to search the built-in help and the command line reference, we don’t see anything that references a domain specifically. We will have to get creative and go a little deeper. Let’s give the command line reference one more look for anything that could give us more information generally. What about the envars plugin? This sounds like it could reveal some new, relevant artifacts.
To display a process’s environment variables, use the envars plugin. Typically this will show the number of CPUs installed and the hardware architecture (though the kdbgscan output is a much more reliable source), the process’s current directory, temporary directory, session name, computer name, user name, and various other interesting artifacts.
In a Windows domain, the USERDOMAIN environment variable contains the workgroup or domain that a user belongs to. I’m thinking that we can try the same method that we did to get the account SID and grep the malicious PID?
It looks like this worked. Now we have the domain name and the username of the victim. This plugin actually gave us both parts of the answer, too. Now we have two methods to discover usernames.
Question 5: What is the compromised user password?
For the last task, we need to get the password for CyberJunkie. I’m not sure where this fits into the investigation narrative, but it will be fun to keep exploring Volatility and practice some password cracking while we’re at it. Let’s go back one last time to the Volatility help and see what we plugin might help us.
It seems like the hashdump plugin might be able to dump the user’s password hashes for us. We’ll get a little more context from the command reference again:
To extract and decrypt cached domain credentials stored in the registry, use the hashdump command
Hashes can now be cracked using John the Ripper, rainbow tables, etc.
Let’s try it out. Again, we will output the results to a text file for easier analysis.
After reviewing the output, we now have the NTHash of the user password from cached credentials in the registry! Now we need to crack the password to solve the challenge.
The Volatility docs suggest that we can throw the hash into John the Ripper, or something similar. I prefer John the Ripper but you could also use hashcat or even CrackStation if you want to do a quick check. For illustrative purposes, I will show all three here and use the classic rockyou.txt wordlist.
There we have it! Using Volatility we were able to dump the user hashes and crack them to discover the password. Let’s submit the answer and wrap this challenge up.
Conclusion:
Great job! We got to explore Volatility3 and made it through the challenge. This challenge really got me interested in utilizing Volatility and was a great introduction to the tool. Thank you to LetsDefend.io for the awesome lab and thank you for checking out this walkthrough and stumbling through the challenge with me. Stay curious!
