Deconstructing Multi-Stage Malware: A Practical Workflow for Analysts

TLDR: This post breaks down a multi-stage malware infection chain involving a fake game cheat that uses obfuscated PowerShell and scheduled tasks for persistence. By leveraging standard tools like Ghidra, dnSpy, and Procmon, analysts can quickly deconstruct these samples without needing advanced reverse engineering skills. The key takeaway is that even heavily obfuscated, multi-stage malware often relies on simple, predictable execution patterns that are easily exposed through dynamic analysis and logging.

Malware analysis often feels like an exercise in frustration, especially when you are staring at a heavily obfuscated binary that seems designed to waste your time. Many researchers get stuck trying to reverse engineer every single function, but the reality is that most commodity malware follows a standard, predictable playbook. If you can identify the core execution flow, you can often bypass the noise and get straight to the malicious payload.

The Anatomy of a Fake Cheat Infection

The sample in question arrived as a fake game cheat, a common delivery vector for credential stealers and remote access trojans. The attacker mass-messaged users on Telegram, directing them to a landing page that promised "undetected" cheats. Every download button on the site pointed to the same archive, which contained a small, 9KB C# binary.

At first glance, the binary looks like a simple wrapper. However, its primary function is to act as a downloader and executor for subsequent stages. It does not contain complex anti-analysis techniques, but it does use base64-encoded PowerShell commands to hide its true intent. When you drag this binary into dnSpy, you can see the C# source code directly, provided there is no packing. The code reveals a hardcoded, base64-encoded string that, once decoded, executes a PowerShell command to download and run additional binaries from the internet.

Exposing the Execution Flow

Static analysis is only the first step. To see what the malware is actually doing, you need to run it in a controlled environment. FLARE-VM is the industry standard for this, providing a pre-configured Windows environment with all the necessary tools.

When you execute the sample, Procmon becomes your most valuable asset. By filtering for process activity, you can watch the malware spawn child processes, modify registry keys, and create files on disk. In this case, the binary dropped several files into the AppData directory and set up scheduled tasks to ensure persistence.

One of the most effective ways to capture these malicious commands is by using PowerShell's built-in Start-Transcript feature. This logs every command executed in a session to a text file. Even if the malware uses obfuscation to hide its commands, the transcript will show the de-obfuscated version as it is passed to the PowerShell engine. This is a massive time-saver, as it allows you to see the exact URLs and file paths the malware is interacting with, without having to manually decode every layer of obfuscation.

Persistence and Evasion

The malware demonstrated a clear focus on persistence. It dropped multiple binaries, including a VBE script and a batch file, which worked in concert to execute the final payload. The VBE script, which is often used to hide malicious code, can be easily decoded using John Hammond’s VBE Decoder.

Once the VBE script executes, it triggers a batch file that runs the final binary, which is a known stealer-as-a-service. This final stage is often obfuscated with tools like .NET Reactor, which can make static analysis difficult. However, because the malware needs to execute on the host, it must eventually de-obfuscate itself in memory. This is where dynamic analysis shines. By monitoring the process in Process Hacker or System Informer, you can often dump the memory of the running process to recover the original, de-obfuscated code.

Practical Application for Pentesters

During a red team engagement or a penetration test, you will frequently encounter similar techniques. Understanding how to quickly triage these samples is essential. You do not need to be a master of assembly to be effective. By focusing on the "what" rather than the "how," you can quickly determine the impact of a sample and provide actionable intelligence to your client.

If you are performing a test, look for these common indicators:

• Unexpected PowerShell execution: Any binary that spawns powershell.exe with encoded commands should be treated as highly suspicious.
• Persistence in AppData: Malware frequently uses the AppData directory to hide its files, as it is a writable location that does not require administrative privileges.
• Scheduled Tasks: Check the Task Scheduler for any tasks that run on login or at regular intervals, especially those pointing to files in user-writable directories.

Defensive Considerations

Defenders should focus on visibility. Implementing robust logging for PowerShell, specifically enabling Script Block Logging, is one of the most effective ways to detect and respond to these types of attacks. When combined with an EDR solution that monitors for suspicious process creation and file modifications, you can significantly reduce the dwell time of an attacker.

Stop trying to analyze every line of code. Start by observing the behavior, capturing the commands, and identifying the persistence mechanisms. Most of the time, the malware will tell you exactly what it is doing if you just give it a place to run.