How to Build Realistic Adversary Emulation Plans from Open Source Intel

TLDR: This post breaks down a structured methodology for turning raw threat intelligence into actionable adversary emulation plans. By mapping observed behaviors to the MITRE ATT&CK framework, red teams can move beyond generic testing and build scenarios that accurately reflect real-world threats. The approach emphasizes using open-source intelligence to identify specific TTPs, developing custom malware, and validating detections against a simulated environment.

Adversary emulation is often treated as a box-ticking exercise where teams run a few automated scripts and call it a day. That is not red teaming. That is noise. If you want to actually test a security program, you need to emulate the specific behaviors of real-world actors who are currently targeting your industry. The gap between a generic penetration test and a high-fidelity adversary emulation is the difference between finding low-hanging fruit and identifying systemic failures in your detection and response pipeline.

From CTI Reports to Actionable TTPs

The biggest mistake most teams make is trying to emulate an entire actor group at once. You cannot effectively test your defenses if you are trying to simulate every move a sophisticated threat actor makes over a six-month campaign. Instead, you need to scope your emulation down to specific, manageable techniques.

Start by selecting a target adversary and gathering recent, high-quality intelligence. Look for reports that provide granular technical details, such as file paths, registry keys, and specific API calls. When you find a report that includes a detailed infection flow, you have found gold. Use that flow to map out the adversary's lifecycle using the MITRE ATT&CK framework. This gives you a common language to discuss the attack with your blue team and ensures you are testing against reality, not a hypothetical threat model.

The Mechanics of Emulation

During a recent engagement, we focused on emulating AsyncRAT, a common remote access trojan. The goal was to replicate the infection chain from initial access to credential dumping. We didn't just run the binary; we deconstructed the infection flow to understand the "why" behind each step.

For example, many reports on AsyncRAT mention process hollowing. Instead of relying on a pre-compiled tool, we analyzed the behavior to understand the specific Windows API calls involved. The process typically looks like this:

// Simplified logic for process hollowing
CreateProcess(..., CREATE_SUSPENDED, ...);
ZwQueryInformationProcess(...);
ReadProcessMemory(...);
ZwUnmapViewOfSection(...);
VirtualAllocEx(...);
WriteProcessMemory(...);
SetThreadContext(...);
ResumeThread(...);

By understanding these mechanics, you can build a custom emulation that triggers the same alerts a real attacker would. If your EDR doesn't flag the combination of CreateProcess in a suspended state followed by WriteProcessMemory into a remote process, you have a visibility gap.

Managing the Development Lifecycle

Building custom malware for emulation is a resource-intensive process. You do not have the unlimited budget or the six-year development cycle of a nation-state actor. You have weeks, not months. This is where you need to be pragmatic.

Focus on the Minimum Viable Product (MVP) for your emulation. If the adversary uses a complex custom crypter, you don't necessarily need to build a perfect clone. You need to replicate the behavior that triggers the detection. If the goal is to test your EDR's ability to detect malicious file execution, a simple wrapper that performs the same file system operations is sufficient.

Use tools like Ghidra to analyze existing malware samples and extract the logic you need. When you encounter obfuscated code, don't waste days deobfuscating every single line. Identify the core logic, rewrite it in a clean, maintainable format, and focus your energy on the execution phase.

The Importance of Pivot Points

Every emulation plan will hit a wall. Your tool will crash, the environment will behave unexpectedly, or a security control will block your path. This is not a failure; this is the most valuable part of the exercise.

When you hit a roadblock, you need a pivot point. If your primary persistence mechanism—like a registry run key—is blocked, what is the adversary's fallback? Do they use a scheduled task? Do they modify a startup folder? By planning for these contingencies, you turn a dead-end into a deeper test of your detection capabilities.

Bridging the Gap with Blue Teams

The ultimate goal of this process is to create a transparent dialogue with your blue team. When you are building your emulation plan, share your findings early. If you are using a specific technique, tell them what to look for.

# Example of a simple persistence check
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"
schtasks /query /fo LIST /v | findstr "TaskName"

By providing the blue team with the exact commands and artifacts you are generating, you remove the guesswork from their investigation. You aren't just testing if they can catch you; you are testing if they can interpret the telemetry you generate.

Adversary emulation is not about winning; it is about learning. If you can successfully execute your plan without being detected, you have identified a critical gap. If you are caught, you have validated your controls. Either way, you have moved the needle. Stop running generic scans and start building scenarios that force your team to confront the reality of modern threats. Invest the time to understand the "how" behind the "what," and you will find that your testing becomes significantly more effective.