Amadey — APT-C-36 Lab

Windows Memory Forensics Walkthrough — Amadey (CyberDefenders Lab)

https://cyberdefenders.org/blueteam-ctf-challenges/amadey-apt-c-36/

Scenario: 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.

Before starting the memory analysis, it is important to understand what we are dealing with.

The malware in this case is Amadey, which is commonly classified as an information stealer. However, it is more than just a simple credential harvester. Amadey is often used as a loader, meaning its primary job is to establish communication with a Command and Control (C2) server and download additional malicious payloads. These secondary modules may perform credential theft, reconnaissance, or deploy other malware families.

Because of this modular behavior, I expected to observe:

• Outbound C2 communication
• Downloaded DLL modules
• Execution through legitimate Windows binaries (like rundll32.exe)
• Persistence mechanisms to survive reboot
• Possible interaction with sensitive processes such as lsass.exe

If I did not understand these behavior patterns beforehand, I would not know what artifacts to focus on inside memory.

Windows Memory Forensics Fundamentals:

1. Process Analysis

Every Windows process has:

• PID and PPID
• Command-line arguments
• Creation and exit time

By reviewing these details, we can detect suspicious parent-child relationships, process masquerading (such as lssass.exe pretending to be lsass.exe), and unusual execution paths like Temp or AppData directories. Most malware reveals itself through process anomalies.

2. Process Injection Awareness

Many malware families hide by injecting into legitimate processes. In memory, this may appear as:

• RWX memory regions
• Unusual or unlinked modules
• Threads running inside unexpected processes

If injection is not checked, stealth behavior can be completely missed.

3. Persistence Mechanisms

To survive reboot, malware often uses:

• Registry Run keys
• Scheduled Tasks
• Services
• Startup folders

Artifacts related to these locations are strong indicators of long-term compromise.

4. LSASS and Credential Access

If malware interacts with lsass.exe, it is serious. This can indicate credential dumping or privilege abuse. Evidence may include open handles to LSASS or suspicious memory artifacts. This is always a high-priority check.

Lab Navigation and Setup

First, go to the Start here folder on the Desktop. Open the Tools folder, then open the volatility3 directory. Right-click inside that folder and select Open Terminal Here so the terminal starts in the correct location.

Next, minimize the terminal and go back to Start here → Artifacts. Locate the memory file (for example, Windows 7 x64-Snapshot4.vmem) and copy its full file path.

Return to the terminal to begin analysis.

Running Volatility 3

The basic command format is:

vol.py -f <file_path> <plugin>

Example:

vol.py -f “/home/ubuntu/Desktop/Start here/Artifacts/Windows 7 x64-Snapshot4.vmem” windows.pslist

Here, -f specifies the memory image and the plugin determines what artifact you want to examine.

Q.1 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 first step in any memory investigation is to look at running processes.

I used windows.pslist because it shows all active processes along with their PID and PPID. This helps identify suspicious names and relationships.

While reviewing the process list, I noticed: lssass.exe

This immediately stood out because the legitimate Windows process is: lsass.exe

The extra “s” suggests process masquerading — a common malware technique.

From the process list, I identified its parent process (PID: 2748), confirming that lssass.exe is the malicious parent triggering the activity.

Answer (Q1): lssass.exe

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?

After identifying the suspicious process, the next logical step is to find where it is running from.

For this

I used windows.cmdline because it shows the full execution path and command-line arguments of processes.

From the output, I located the execution path of lssass.exe:

C:\Users\0XSH3R~1\AppData\Local\Temp\925e7e99c5\lssass.exe

This confirms it is not a legitimate system process, since real lsass.exe runs from: C:\Windows\System32\

Running from a Temp directory strongly indicates malicious behavior.

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?

Malware usually communicates with a Command and Control server. To check network activity,

I used windows.netscan because it lists active and closed network connections along with the associated PID 2748.

By reviewing the output and correlating it with lssass.exe, I found that it was communicating with: 41.75.84.12 .This external IP… is the Command and Control server.

Q4.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?

Since the malware is communicating with a C2 server, the next step is to check if it downloaded additional components.

To inspect its memory, I dumped the process memory:

This created a dump file (pid2748.dmp).

To search for HTTP download requests inside memory, I ran:

I used this because HTTP GET requests in memory indicate files being retrieved from a server.

From the output the malware attempted to download two distinct files:

1. cred64.dll
2. clip64.dll

Answer (Q4): 2 files

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?

After identifying clip64.dll, I needed to determine where it was stored on the system.

For this,

I used windows.filescan because it scans memory for file objects, even if they are not currently open.

The output revealed: location in AppData\Roaming with a random folder name confirms malicious staging.

Answer (Q5): C:\Users\0xSh3rl0ck\AppData\Roaming\116711e5a2ab05\clip64.dll

Q6.Once retrieved, the malware aims to activate its additional components. Which child process is initiated by the malware to execute these files?

Malware often uses legitimate Windows utilities to execute malicious DLLs.

To check process hierarchy,

I used windows.pstree because it shows parent-child relationships clearly.

From the tree, I observed that lssass.exe (PID 2748) spawned:

rundll32.exe is commonly abused to execute DLL payloads.

Answer (Q6): 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?

To check for additional instances or persistence artifacts, I searched for references to lssass.exe:

The Tasks directory is associated with Scheduled Tasks in Windows.

This indicates the malware created a scheduled task to maintain persistence after reboot.

If malware interacts with lsass.exe, it is serious. This can indicate credential dumping or privilege abuse. Evidence may include open handles to LSASS or suspicious memory artifacts. This is always a high-priority check.

Conclusion:

Through this memory analysis, I was able to trace the full behavior of the Amadey infection. Starting from the masqueraded process (lssass.exe), I identified its execution path, C2 communication, downloaded DLL modules, execution via rundll32.exe, and persistence through Scheduled Tasks.

This lab reinforced how powerful memory forensics can be in reconstructing an attack chain and understanding what actually happened on a compromised system.