Amadey Trojan Stealer — Memory Forensics

Scenario

After an after-hours EDR alert flagged suspicious activity on a Windows workstation, we suspected the Amadey Trojan Stealer. A memory dump (Windows 7 x64-Snapshot4.vmem) was handed to us for analysis. Using Volatility 3 inside an Ubuntu VM, I worked through the dump to uncover the malicious process, its location, C2 activity, downloaded plugins, and persistence mechanisms.

---

Environment Setup — defining $VOL and $MEM

Before diving in, I set two variables to avoid rewriting long file paths with spaces:

VOL="/home/ubuntu/Desktop/Start here/Tools/volatility3/vol.py"
MEM="/home/ubuntu/Desktop/Start here/Artifacts/Windows 7 x64-Snapshot4.vmem"

ls -l "$MEM"

Setting $VOL and $MEM makes the commands cleaner and prevents errors with paths. This way, every Volatility command is shorter and repeatable.

---

Q1 — Parent Process Triggering Malicious Behavior

Command:

python3 "$VOL" -f "$MEM" windows.pstree | tee ~/allprocs.txt

Answer:

lssass.exe

The process tree revealed a fake lssass.exe (extra “s”), masquerading as the real lsass.exe. It spawned a child rundll32.exe, which is exactly how Amadey executes malicious DLLs.

---

Q2 — Location of the Rogue Process

Command:

python3 "$VOL" -f "$MEM" windows.filescan | grep -i "lssass"

Answer:

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

The binary was executed from a user’s Temp directory, not from System32 where a legitimate lsass.exe belongs. This confirms it’s malicious staging.

---

Q3 — C2 Server IP

Command:

strings -a -n 6 "$MEM" | grep -A3 -B3 "GET /rock/Plugins/"

Answer:

41.75.84.12

Carving strings exposed the malware’s C2 server: 41.75.84.12. It communicated over port 80, blending malicious traffic with normal web browsing.

---

Q4 — Distinct Files Fetched

Command:

grep -n "GET /" ~/allstrings.txt | sed -n '1,80p'

Answer:

2

The malware attempted to fetch two DLLs — cred64.dll and clip64.dll. These are modular plugins: one to steal credentials and another to capture clipboard data.

---

Q5 — Full Path of Downloaded File

Command:

python3 "$VOL" -f "$MEM" windows.filescan | egrep -i "cred64|clip64"

Answer:

C:\Users\0xSh3rl0ck\AppData\Roaming\116711e5a2ab05\clip64.dll

One of the plugins, clip64.dll, was stored in AppData\Roaming under a randomly named folder. This location is stealthy and often overlooked by defenders.

---

Q6 — Child Process Used to Execute the DLLs

Command:

python3 "$VOL" -f "$MEM" windows.pstree | egrep -i "lssass|rundll32"

Answer:

rundll32.exe

The malware used rundll32.exe — a trusted Windows utility — to load and execute its malicious DLLs. This is a common “living off the land” tactic that helps malware avoid detection.

---

Q7 — Additional Persistence Location

Command:

python3 "$VOL" -f "$MEM" windows.filescan | grep -i "Tasks\\lssass.exe"

Answer:

\Windows\System32\Tasks\lssass.exe

The malware registered itself as a Scheduled Task, ensuring it restarts after reboots. This persistence method uses a trusted Windows feature, making it harder to spot.

---

Final Wrap-Up

Through careful memory forensics, I was able to fully reconstruct the chain of activity tied to the Amadey trojan. The investigation began by identifying a masquerading process, lssass.exe, which was pretending to be the legitimate Windows security process lsass.exe. This rogue binary was executed from a user’s Temp folder, confirming it was not a system file. Analysis of the process tree showed that lssass.exe spawned rundll32.exe, a legitimate Windows utility that attackers commonly abuse to execute malicious DLLs. By carving network artifacts from memory, I discovered the malware had connected to its command-and-control server at 41.75.84.12, using port 80 to disguise its traffic as normal web browsing. Further analysis of HTTP requests revealed that Amadey attempted to fetch two plugin DLLs — cred64.dll and clip64.dll. One of these, clip64.dll, was located in the user’s AppData\Roaming directory, hidden under a randomly generated folder to evade detection. Finally, persistence was confirmed through the presence of a copy of lssass.exe in the System32\Tasks directory, showing the malware registered itself as a scheduled task to ensure it would survive reboots. Overall, this case highlights how Amadey leverages process masquerading, modular plugin downloads, living-off-the-land techniques, and scheduled tasks to establish long-term control of a system.