Reconstruct Amadey Trojan behavior by analyzing memory dumps with Volatility3 to identify malicious processes, C2 communications, payload delivery, and persistence mechanisms.
An after-hours alert from the Endpoint Detection and Response (EDR) system flags suspicious activity on a Windows workstation. The flagged malware aligns with the Amadey Trojan Stealer. Your job is to analyze the presented memory dump and create a detailed report for actions taken by the malware.
Medium - Endpoint Forensics | Completion Achievement
- In the memory dump analysis, determining the root of the malicious activity is essential for comprehending the extent of the intrusion. What is the name of the parent process that triggered this malicious behavior?
This is the command I will be using to run Volatility based on this cheatsheet:
$ ./Tools/volatility3/vol.py -f ./Artifacts/Windows\ 7\ x64-Snapshot4.vmem ...Since we need to look at parent processes, let's get a list of all process running with windows.pstree:
The most interesting processes are usually at the end of the process list. Should lssass.exe have rundll32.exe as a child? I did some research and found this report about rundll32.exe: Rundll32. The following is relevant for our investigation:
Similar to `minidump`, we commonly see adversaries injecting `rundll32.exe` into `lsass.exe` to gain access to the memory contents of LSASS.Another relevant detail to notice: lssass.exe != lsass.exe ! There’s a typo here, which makes this process more suspicious.
- Once the rogue process is identified, its exact location on the device can reveal more about its nature and source. Where is this process housed on the workstation?
Great, we have process lssass.exe (PID: 2748) as our starting point in this investigation. Let's read some information about where this process was started based on cmdline information through windows.cmdline. We can narrow the output using grep 2748:
ubuntu@ip-172-31-26-152:~/Desktop/Start here$ ./Tools/volatility3/vol.py -f ./Artifacts/Windows\ 7\ x64-Snapshot4.vmem windows.cmdline | grep 2748
2748 lssass.exe "C:\Users\0XSH3R~1\AppData\Local\Temp\925e7e99c5\lssass.exe"The answer is located in the command line arguments.
- Persistent external communications suggest the malware's attempts to reach out C2C server. Can you identify the Command and Control (C2C) server IP that the process interacts with?
Now, we need to read network information related to this memory dump, which can be easily done with windows.netscan.:
The first connection appears to be closed, while the second one is more interesting with a local address and port and the foreign address we needed to find.
- Following the malware link with the C2C, the malware is likely fetching additional tools or modules. How many distinct files is it trying to bring onto the compromised workstation?
Let's analyze the PID 2748 process deeply by creating a memdump off of it:
./Tools/volatility3/vol.py -f ./Artifacts/Windows\ 7\ x64-Snapshot4.vmem -o output-mem-2748/ windows.memmap --dump --pid 2748Inside the output directory, we will find a pid.2748.dmp file which contains a memdump of our suspicious process. We know that the machine established a connection with a suspicious IP address over port 80, which is used for HTTP communications. Knowing that, let's try filtering the ASCII strings based on GET requests which are typical for HTTP traffic:
ubuntu@ip-172-31-26-152:~/Desktop/Start here/output-mem-2748$ strings pid.2748.dmp | grep "GET /"
GET /rock/Plugins/cred64.dll HTTP/1.1
GET /rock/Plugins/clip64.dll HTTP/1.1We have 2 GET requests here!
- Identifying the storage points of these additional components is critical for containment and cleanup. What is the full path of the file downloaded and used by the malware in its malicious activity?
Knowing the names of the files downloaded from the C2 IP address, let's try looking for their path with windows.cmdline:
ubuntu@ip-172-31-26-152:~/Desktop/Start here$ ./Tools/volatility3/vol.py -f ./Artifacts/Windows\ 7\ x64-Snapshot4.vmem windows.cmdline | grep cred64
ubuntu@ip-172-31-26-152:~/Desktop/Start here$ ./Tools/volatility3/vol.py -f ./Artifacts/Windows\ 7\ x64-Snapshot4.vmem windows.cmdline | grep clip64
3064ressrundll32.exe "C:\Windows\System32\rundll32.exe" C:\Users\0xSh3rl0ck\AppData\Roaming\116711e5a2ab05\clip64.dll, Mainclip64.dll returns a valid path.
- Once retrieved, the malware aims to activate its additional components. Which child process is initiated by the malware to execute these files?
The PID corresponding to the process using clip64.dll is 3064. Let's go back to the windows.pstree output to find the child processes of this specific PID:
ubuntu@ip-172-31-26-152:~/Desktop/Start here$ ./Tools/volatility3/vol.py -f ./Artifacts/Windows\ 7\ x64-Snapshot4.vmem windows.pstree
PID PPID ImageFileName Offset(V) Threads Handles SessionId Wow64 CreateTime ExitTime
...
2748 2524 lssass.exe 0xfa800300a750 7 254 1 True 2023-08-09 21:33:04.000000 N/A
* 3064 2748 rundll32.exe 0xfa8003042b30 1 64 1 True 2023-08-09 21:33:56.000000 N/AWe are back at the initial lssass.exe process. Now, we can observe that the malicious process lssass.exe called a child process with PID 3064, which is our answer.
- Understanding the full range of Amadey's persistence mechanisms can help in an effective mitigation. Apart from the locations already spotlighted, where else might the malware be ensuring its consistent presence?
This malware might be on other locations in the filesystem. Let's use windows.filescan to retrieve any other locations where lssass.exe might be stored:
ubuntu@ip-172-31-26-152:~/Desktop/Start here$ ./Tools/volatility3/vol.py -f ./Artifacts/Windows\ 7\ x64-Snapshot4.vmem windows.filescan | grep lssass
0x517b290 100.0\Users\0XSH3R~1\AppData\Local\Temp\925e7e99c5\lssass.exe 216
0x1dad11e0 \Windows\System32\Tasks\lssass.exe 216
0x1e994b20 \Users\0XSH3R~1\AppData\Local\Temp\925e7e99c5\lssass.exe 216The C:\Windows\System32\Tasks\ directory in Windows is used to store files related to the Task Scheduler (source: here). Placing a file here is a common method to obtain Persistence.