Unmasking Amadey: How Forensic Artifacts Expose Silent Infection Chains

TLDR: Amadey malware frequently evades standard security tools by killing monitoring processes upon execution, but it leaves a trail of breadcrumbs in Windows forensic artifacts. By analyzing Prefetch, SRUM, and USN Journal data, researchers can reconstruct the entire infection chain, including C2 communication and persistence mechanisms. This methodology allows incident responders to track malicious activity even when traditional EDR solutions are blinded or disabled.

Modern malware authors prioritize stealth above all else. They know that if they can kill your monitoring tools, they can operate in the dark. Amadey is a prime example of this philosophy. When it hits a system, it immediately targets common analysis utilities like Process Monitor and Process Explorer. For a standard incident responder relying solely on these tools, the infection appears to vanish, leaving behind a clean system that is actually compromised.

However, the operating system never forgets. Windows maintains a persistent record of execution, network usage, and file system changes that malware cannot easily scrub. By shifting focus from real-time monitoring to post-mortem forensic analysis, we can turn the tables on these attackers.

Reconstructing the Infection Chain

Amadey typically arrives via phishing, often disguised as a legitimate document or installer. Once the user executes the payload, the malware initiates a multi-stage process designed to establish persistence and escalate privileges. The key to understanding this behavior lies in the artifacts generated by the Windows kernel and system services.

Prefetch and Execution History

Every time an application runs, Windows creates a Prefetch file in C:\Windows\Prefetch. These files are gold mines for investigators. They contain metadata about the executable, including the timestamp of the first and last run, the number of times it was executed, and the files it accessed.

When analyzing an Amadey infection, you will often see multiple executables spawned in rapid succession. For instance, the primary dropper might launch a secondary process, such as 1q37l5.exe or 2e2941.exe. By using Eric Zimmerman’s PECmd, you can parse these files to build a timeline of the attack. If you see an unknown binary executing immediately after a suspicious document, you have found your entry point.

Tracking Network Activity with SRUM

The System Resource Usage Monitor (SRUM) is another critical, often overlooked source of intelligence. Located in C:\Windows\System32\SRU\SRUDB.dat, this database tracks per-application network usage, energy consumption, and execution time for up to 30 days.

Amadey needs to communicate with its Command and Control (C2) server to receive instructions or exfiltrate data. SRUM records the bytes sent and received by every process on the system. If you suspect a machine is beaconing, you do not need to capture live traffic to prove it. You can query the SRUM database to identify which process is responsible for the outbound traffic and the specific IP address it contacted. This is invaluable for identifying the C2 infrastructure without alerting the malware to your presence.

Persistence and Privilege Escalation

Amadey does not just run once; it ensures it survives a reboot. A common technique involves creating a scheduled task that triggers the malware at specific intervals. This aligns with MITRE ATT&CK T1053, which covers scheduled task creation for persistence.

Beyond simple persistence, Amadey often attempts to escalate privileges to gain full control over the system. It achieves this by modifying registry keys to manipulate system behavior. Once the malware gains administrative rights, it can dump credentials from the Local Security Authority Subsystem Service (LSASS) process. This is where Credential Dumping (T1003) becomes a major risk. By accessing lsass.exe, the malware can harvest cleartext passwords or NTLM hashes, allowing the attacker to move laterally through the network.

Practical Application for Pentesters

During a red team engagement or a penetration test, you should treat these forensic artifacts as part of your post-exploitation assessment. If you are simulating an Amadey-style attack, you need to understand what you are leaving behind.

When you drop a payload, do not assume that deleting the file is enough. Your execution will be recorded in the Prefetch files. Your network connections will be logged in the SRUM database. Your file system modifications will be tracked in the USN Journal. If you are testing a client's detection capabilities, ask their blue team if they are monitoring these specific artifacts. If they are not, you have identified a significant gap in their visibility.

Defensive Strategies

Defenders must move beyond signature-based detection. While EDR tools are essential, they are not infallible. A robust defense requires a layered approach that includes:

1. Endpoint Visibility: Ensure that logs from Windows Event Forwarding and Sysmon are being ingested into a SIEM. Focus on events related to process creation, scheduled task modification, and registry changes.
2. Artifact Monitoring: Periodically audit the Prefetch directory and SRUM database for anomalies. Tools like Wireshark are great for live analysis, but they cannot replace the historical context provided by forensic artifacts.
3. User Education: Since phishing remains the primary delivery vector, training employees to recognize suspicious email attachments is the most effective way to prevent the initial infection.

The next time you encounter a system that seems "clean" despite clear indicators of compromise, stop looking for the malware and start looking for the evidence it left behind. The OS is the ultimate witness, and it never lies.