Amadey Malware - Investigation Walkthrough
- Jv Cyberguard
- Apr 2
- 7 min read
I have recently been doing Cyber Defenders labs in their Blue Yard Cyber range to get more reps in from a DFIR perspective. This week we are going to create a walkthrough for the Amadey Malware Endpoint Forensics lab. It can be found at the link below.
We are going to perform an investigation where the scenario goes as follows:
The first thing I want to do is get a quick background on the malware.
A quick google search reveals that , "Amadey’s primary function is to steal information and further distribute malware. It aims to extract a variety of information from infected devices and attempts to evade the detection of security measures by reducing the volume of data exfiltration compared to that seen in other malicious instances."
So we have a memory dump of the compromised workstation and are tasked with creating a report detailing the attack.
The tool we will use to analyze the memory dump is Volatility. This a standard tool used for memory analysis. In investigations, we do not always have access to the physical workstation to perform live host-based forensics. Volatility allows us to analyze the device's memory dump for the details that we would have had if we had the physical machine.
The format of these will be as follows: Q1 - Answer with screenshot and explanation.
Q1 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?
The process chain for any known malicious file matters as it helps us to deduce the origin and also identify other IoCs that we can use to drive our investigation forward. Volatility has plugins that allow us to extracts and parse data from memory. For example, for us to identify the parent process that triggered the malicious process will require us to use the windows.pstree.PsTree and windows.pslist.PsList plugin. PsTree would show us the parent child relationships. PsList plugin just lists the processes.
Below are the key headers.
PID - Process ID number
PPID - Parent process ID number
ImageFileName - Name of the running process
Offset - Hexadecimal value representing the location in memory the process is running
CreateTime - Time process started
ExitTime - Time process ended
The commands I used to generate the files are below.
Now analyzing the process tree, I quickly noted a process called lssass.exe. This is suspicious because the process lssass process and the legitimate lsass process is spelled differently. (An extra 'S')
However, if we want to be sure if anything stands out as malicious we can identify the cmdline of these processes by examining and running Volatility again with plugin windows.cmdline.CmdLine
Do you note there is a lsass.exe below?
However, remember we also see an lsass.exe process with an additional 's' in our pslist further down to the end of the the output. Look at where it is located below. It's in the temp folder.
This is one takeaway we want to have, one of the ways we can identify suspicious processes is looking for processes that are not located in directories where their legitimate counterparts are normally found or naming them closely to the name of legitimate processes. This is a Defensive Evasion Technique called Masquerading.
T1036.005 - Masquerading: Match Legitimate Name or Location
Tactic: Defense Evasion
Technique: Masquerading
Sub-Technique: Match Legitimate Name or Location
Description
This sub-technique involves adversaries renaming files or processes to resemble legitimate ones. In this case, the attacker creates a process named lssass.exe instead of lsass.exe. The goal is to fool defenders or automated detection systems by exploiting common mistakes made during monitoring or analysis.
Learn more here: https://attack.mitre.org/techniques/T1036/005/
Future detection opportunities for this include:
Creating a detection rule that looks for Legitimate Windows Executable names such as svchost.exe, smss.exe,winit.exe,taskhost.exe, and lsass.exe and the process path is not C:\Windows\System\32 or C:\Windows\SysWow64.
Check the parent process (e.g., if it was launched by explorer.exe instead of winlogon.exe or services.exe).
Look for unusual command-line arguments or indicators of credential dumping.
That solves question 1 and we gained some applicable tips along the way.
Q2 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?
So the lssass.exe which is our malicious executable was found in the temp folder. WE had the answer to this questions already from our analysis above. Therefore, we submit the full path as the answer.
Q3 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?
Remember in the brief snippet of the Amadey malware we read that it drops additional malicious files. The way this happens is that the malware pulls them down from the command and control server. The way we would analyze this activity on a live host is by running Get-NetTCPConnection in PS which will show us the process ID associated with the network connection. For eg:
Get-NetTcpConnection | Select-object -First 1 -Property LocalPort,RemoteAddress,RemotePort,OwningProcess
Since, we have a memory dump, we can get this same information with the help of a volatility plugin called windows.netscan.NetScan
To show you how similar the output of the netscan is to the powershell output, look at the below screenshot for the output from the memory analysis on network connections.
Rather than looking at the whole file, we can quickly look for network connections related to the process by using grep on the file. I am choosing to use the process ID for lssass.exe which is 2748, we could have also used lssass[.]exe
I am leaning towards 41[.]75[.]84[.]12 being the C2 as the 56.x.x.x. ip does not have a local port or local address nor ports it communicates over. If anything, maybe a failed attempt. Plus, the connection the the 41.x.x.x ip happened more than once.
We were correct.
Q4 Following the malware link with the C2 server, the malware is likely fetching additional tools or modules. How many distinct files is it trying to bring onto the compromised workstation?
I tried to use the windows.filescan.FileScan plugin to see if any additional files were written to the temp folder where the malicious executable resides. I found nothing. I then decided to search for strings that may be in the memory dump.
Strings utility is really useful as it searches memory or even malware and can extract ASCII text from memory or binaries.
When using strings it is best to search for ASCII strings, little endian Unicode strings, and big endian Unicode strings since all these strings could be encoded differently. Using all options is the safest approach to ensure you don't miss potential evidence. Also, always extract ASCII strings as a baseline.
We can then grep across the three files we just created. We see that it attempted to bring 3 files on to the workstation. index[.]php and clip64[.]dll and cred64[.]dll
We use the -h option with grep to hide the relative file path from our output.
Without it, our output looks like below. That is why we use the -h option with grep to hide it.
I noticed that answer 3 was not accepted. However, 2 was correct. I think the reason two was accepted as the answer was that I was looking for all possible string output that matches the malicious IP. It is possible that they may not have extracted all strings in their walkthrough. That is why it is important to look for all possible strings.
However, in taking another look this. I noticed if I used 'GET /' in my grep search it returned only these two files.
So I guess 2 may be correct, since 2 files were explicitly requested as far as we can see.
Q5 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?
This question positions us to be able to surgically eradicate the malware. A skilled analyst must work towards getting to a point where they can identify all IoCs from the malware and clean up accordingly.
To answer this we can use the plugin windows.filescan.FileScan. This plugin list scans for files in memory. We then grep for the malicious dll files that the lssass[.] executable retrieved from the C2 . Doing this we were able to find one of the malicious files clip64[.]dll located in the AppData roaming folder.
We also could have checked for this via the cmdline if it had been executed.
Q6 - Once retrieved, the malware aims to activate its additional components. Which child process is initiated by the malware to execute these files?
The PsTree volatility plugin shows us parent child relationship across processes.
Our malicious file lssass[.]exe spawned a child process rundll32.exe and we saw in the screenshot above that is what was used to execute the malicious DLL.
This technique aligns with System Binary Proxy Execution: Rundll32 in our MITRE ATT&CK FRAMEWORK under the tactic Defense Evasion.
According to MITRE:
Adversaries may abuse rundll32.exe to proxy execution of malicious code. Using rundll32.exe, vice executing directly (i.e. Shared Modules), may avoid triggering security tools that may not monitor execution of the rundll32.exe process because of allowlists or false positives from normal operations. Rundll32.exe is commonly associated with executing DLL payloads (ex: rundll32.exe {DLLname, DLLfunction})
Some opportunities for detection here based on the information provided by MITRE include:
Command Execution (DS0017)
Look for unusual command-line arguments with rundll32.exe.
Common abuse techniques:
Loading remote DLLs: rundll32.exe \\<IP_ADDRESS>\<SHARE>\malicious.dll,EntryPoint
Executing JavaScript: rundll32.exe javascript:<code_block>
Opportunity: Check for remote file execution or execution of unexpected DLLs.
File Metadata (DS0022)
Analyze metadata of DLL files loaded by rundll32.exe.
Includes details like:
Signature verification
File creation/modification dates
Permissions
Opportunity: Compare with known-good DLLs and expected signing authorities.
Process Creation (DS0009)
Monitor new process creation events.
Event IDs to monitor:
Sysmon Event ID 1: Process creation.
Windows Security Event ID 4688: Process creation (useful for tracking parent-child relationships).
Opportunity: Detect anomalies by inspecting the command-line arguments and parent process.
For example:
(source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode="1") OR (source="WinEventLog:Security" EventCode="4688") Image= "rundll32.exe"
So the answer for Q6 is rundll32.exe
Q7 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?
We are limited to volatility 3. However, autoruns would be my go to in vol2. Since, it prints all AutoStart Extensibility Points(ASEPs) where malware can persist. In this case, we can check the filescan.txt that we made previously. Using grep to list all file paths that contain lssass.exe, we would see if a scheduled task was created for persistence, since scheduled tasks are stored in \Windows\Systems32\Tasks\ folder.
Therefore we have our answer. The malware persists because a scheduled task was created.
That's the end of our investigation. I hope you this jumpstarted your ability to use volatility during investigations. We were also able to spend some time looking at techniques attackers use more deeply by referencing the MITRE ATT&CK framework and identifying detection opportunities.
Comments