July 22, 2024
For this challenge, we’re tasked with finding the malicious process running on the endpoint and which user was responsible.
This write-up includes instructions for Volatility 2.6.1 and the corresponding commands for Volatility 3. (Please see the Volatility 2 section for explanations.)
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.
What was the date and time when Memory from the compromised endpoint was acquired?
To get the time we’ll run the imageinfo command with Volatility2.
imageinfo documentation: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#imageinfo
In the output, we can see the suggested profiles and the creation time of the memory dump.
What was the suspicious process running on the system? (Format : name.extension)
To get an idea of what processes were running on the system, and in what context, we’ll run the pstree command. Pstree lists process found in memory, their Process IDs (PIDs), and their Parent Process IDs (PPIDs).
pstree documentation: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#pstree
It also formats the output so that it is easy to see relationships without referencing (P)PIDs.
Although there are no processes with obviously suspicious names, there is a process that should draw your attention.
In Windows, certain system processes should only have a single instance, and often times have a specific parent process. If either of these characteristics isn’t found, the process should be marked as requiring further investigation.
In our case, we can see that there are two lsass.exe processes running on the host.
LSASS should be initialized by the Wininit process. We can see that the two lsass.exe processes were started by different parent processes. Let’s filter our results to see the respective parent processes.
We can see that one lsass process was started by Wininit, as we would expect. The other, however, was started by explorer.exe, which also spawned a command shell.
Analyze and find the malicious tool running on the system by the attacker (Format name.extension)
We’ve discovered that the lsass process running under pid 7592 is extremely suspicious, so we’ll start by dumping the process.
We can dump the process with volatility’s procdump command
procdump documentation: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#procdump
With the process dumped, we can generate a hash and search for it on VirusTotal).
Note: VirusTotal will automatically switch the search to the sha256 hash if it finds a match.
With that, we’ve discovered that the suspicious lsass process is actually winPEAS (Windows Privilege Escalation Awesome Scripts).
Which User Account was compromised? Format (DomainName/USERNAME)
We can start by double-checking what time the malicious “lsass” (winPEAS) process was executed.
Referring back to our pstree output, we can see the process was executed at 2022-07-26 18:09:33 UTC. Looking back on the process' parents, we see userinit.exe and explorer.exe processes occurring at 2022-07-26 18:01:50 UTC.
These processes and timestamps indicate the logon time of the user that ran winPEAS.
With that information, we can refer to registry entries to determine which account logged in at that time.
There are a few registry keys we can check for this information.
First, we’ll check the SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI key and its SessionData subkey.
We’ll use the printkey command in Volatility to retrieve the data.
Note: I forgot to screenshot the hivelist command/output. Hivelist outputs addresses to reference various registry hives. Using these addresses we can craft our printkey commands as shown below. The -o 0x is the virtual address of the relevant hive.
hivelist documentation: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#hivelist
printkey documentation: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#printkey
As we can see in the output, CyberJunkie was the last user to logon to the device, and this registry key was last updated at 18:09:01, shortly after the malicious process was executed.
Checking the SessionData subkey shows that the last logon occurred at 18:01:45. Comparing this timestamp with the logon processes we discovered within pstree’s output, we can determine that CyberJunkie was the compromised user.
The output of the LogonUI registry key also included CyberJunkie’s SID. We can use this to check the SAM\Domains\Account\Users registry key.
The registry key’s subkeys are hex-encoded representations of each user’s RID.
Referencing the output from LogonUI, we know that CyberJunkie’s RID is 1003 which, when encoded into hex, is 3EB.
With that, we can reference the subkey for our suspected user with the path SAM\Domains\Account\Users\000003EB.
To determine the hostname we will reference the SYSTEM\ControlSet002\Control\ComputerName\ComputerName and SYSTEM\ControlSet001\Services\Tcpip\Parameters.
ComputerName registry keyTcpip\Parameters registry key
With these values, we can see that the hostname for the device is MSEDGEWIN10.
The Tcpip\Parameters key has an empty value for Domain, which indicates that the host may not be joined to a domain, which is true in our case.
What is the compromised user password?
For this, we can use the volatility hashdump command. Once we have the output we can crack the hash with hashcat, johntheripper, or an online tool like CrackStation.net.
vol2 hashdump resultsvol3 hashdump results
As seen in the screenshots, the results for Volatility 2 and 3 differ. Hashcat, johntheripper, and crackstation were unable to crack the output from Vol2. The output from Vol3, however, was quickly cracked.
We can get the timestamp of the memory dump in Volatility3 by using the windows.info command.
This output also contains other useful information such as the Major and Minor versions of the Windows OS.
What was the suspicious process running on the system? (Format : name.extension)A
We’ll use Volatility3’s version of the pstree command to find the suspicious process. One notable difference between Vol2 and Vol3’s output is that in Volatility3 we can also see the executable path. We see that the suspicious one is executing from Windows\System whereas the real lsass process executed from Windows\System32.
We can dump processes in Volatility3 straight from the pslist command. We’ll do this by supplying the –pid and –dump switches.
With the file, we can calculate the hash and look it up on VirusTotal as we did with Volatility2.
This question has an easier solution in Volatility 3.
By using the sessions command, we can see the user that ran the malicious process was the CyberJunkie user as we discovered previously with Volatility2.
This output also gives us the domain, which confirms our previous findings.
We resorted to using Volatility3 for this task previously, so there is nothing new here.
Previous post
Next post