Adversary Simulation — Walking Through a Real Attack Chain, Stage by Stage
Let's break down what adversary simulation actually is, how a simulation team moves through an organization stage by stage, and how each of those stages maps to MITRE ATT&CK.
What Is Adversary Simulation ?
Adversary simulation is a security assessment where a team acts like a real-world attacker to test whether an organization can prevent, detect, and respond to a multi-stage attack.
Note the important word: multi-stage.
A vulnerability scan tells you a door is unlocked. A simulation walks through that door, moves across the house, finds the safe, and tries to carry it out — while you watch whether your alarms went off.
The output is not a list of CVEs. The output is a timeline.
A scan finds the unlocked door and stops. A simulation walks in, moves room to room, and reaches the data — the difference between a finding and a timeline.
Why Do Organizations Run These ?
Test detection and response — not just whether a flaw exists, but whether anyone notices it being used.
Expose blind spots — small misconfigurations look harmless alone. A simulation shows how three of them chain into a breach path.
Measure real resilience — can the ecosystem survive an adaptive attacker, or does it only pass compliance checks ?
Improve team readiness — the SOC gets live reps at triaging real alerts instead of tabletop theory.
Simulation vs Emulation — Not the Same Thing
People use these words interchangeably. They are not interchangeable.
| Feature | Adversary Simulation | Adversary Emulation |
|---|---|---|
| Core question | "What could an attacker do ?" | "What has this specific attacker already done ?" |
| Scope | Broad and flexible. Mixes tactics freely to test overall resilience. | Narrow and rigid. Mirrors one known group's exact playbook. |
| Threat intel | General recon and an adversarial mindset. | Precise, current intel on one actor's past campaigns. |
| Example goal | "Can we get to customer data at all ?" | "Can we survive FIN7's documented TTPs ?" |
Simple version: simulation is creative, emulation is a cover version.
Now the walkthrough. A simulation team is testing a financial institution. The objective is sensitive customer financial data. Each stage only exists because the previous one worked.
The whole engagement at a glance — initial access leads to C2, C2 to escalation, escalation to lateral movement, and only then to the objective.
Stage 1 — Initial Access
The team wants a foothold inside the corporate network.
What they do:
Send a spear-phishing email to a DevOps engineer, picked because that role usually holds keys to more than one system.
The email carries either a link to a convincing fake login portal, or a document with an embedded macro.
The engineer enters credentials. The team now holds a valid corporate account.
What this tests: did the mail filter catch it ? Did MFA stop the login with stolen credentials ? Did EDR flag the macro executing ?
| Technique | ID |
|---|---|
| Phishing: Spearphishing Link | T1566.002 |
| Phishing: Spearphishing Attachment | T1566.001 |
| User Execution: Malicious File | T1204.002 |
| Command and Scripting Interpreter: Visual Basic | T1059.005 |
| Valid Accounts | T1078 |
Tactics: Initial Access (TA0001), Execution (TA0002)
Stage 2 — Command and Control
A foothold that disappears on reboot is useless. The team needs a stable channel.
What they do:
Drop a quiet backdoor on the workstation.
Make it survive reboots — a run key, a scheduled task, or a service.
Have it call out over HTTPS, so the traffic looks like ordinary browsing.
What this tests: does network monitoring notice an internal host beaconing regularly to a newly registered, unknown domain ?
| Technique | ID |
|---|---|
| Application Layer Protocol: Web Protocols | T1071.001 |
| Encrypted Channel: Asymmetric Cryptography | T1573.002 |
| Fallback Channels | T1008 |
| Boot or Logon Autostart: Registry Run Keys | T1547.001 |
| Scheduled Task/Job: Scheduled Task | T1053.005 |
| Create or Modify System Process: Windows Service | T1543.003 |
Tactics: Command and Control (TA0011), Persistence (TA0003)
Stage 3 — Privilege Escalation
The team currently has the rights of one engineer. That is not enough.
What they do:
Enumerate the box — patch level, running security products, interesting files.
Hunt for passwords sitting in scripts, config files, and saved sessions.
Exploit a local kernel flaw to reach SYSTEM, or abuse tokens to inherit higher privilege.
What this tests: do host-based controls block the escalation attempt, or the suspicious memory activity around it ?
| Technique | ID |
|---|---|
| Exploitation for Privilege Escalation | T1068 |
| Unsecured Credentials: Credentials In Files | T1552.001 |
| Access Token Manipulation | T1134 |
| Abuse Elevation Control Mechanism: Bypass UAC | T1548.002 |
| Process Injection | T1055 |
| System Information Discovery | T1082 |
| Security Software Discovery | T1518.001 |
Tactics: Privilege Escalation (TA0004), Defense Evasion (TA0005), Discovery (TA0007)
Stage 4 — Lateral Movement
The data is not on the engineer's laptop. The team has to travel.
What they do:
Harvest credentials and tickets from memory on the compromised workstation.
Map out other hosts, accounts, and admin groups.
Reuse those credentials to reach internal database servers and cloud consoles that this workstation should never touch.
What this tests: is the internal network actually segmented ? Does the SOC alert when an engineering laptop suddenly authenticates to a production database ?
| Technique | ID |
|---|---|
| OS Credential Dumping: LSASS Memory | T1003.001 |
| Use Alternate Auth Material: Pass the Hash | T1550.002 |
| Use Alternate Auth Material: Pass the Ticket | T1550.003 |
| Remote Services: SMB/Windows Admin Shares | T1021.002 |
| Remote Services: Remote Desktop Protocol | T1021.001 |
| Valid Accounts: Cloud Accounts | T1078.004 |
| Remote System Discovery | T1018 |
| Permission Groups Discovery | T1069 |
Tactics: Credential Access (TA0006), Lateral Movement (TA0008), Discovery (TA0007)
Stage 5 — Action on Objectives
This is the point of everything before it.
What they do:
Locate the database holding customer records.
Collect it, compress it, encrypt it, and stage it in one place.
Send it out in small chunks over the existing encrypted channel — or over a side channel like DNS — so no single transfer looks large enough to trip an alert.
What this tests: does DLP block sensitive files moving ? Does anyone flag a slow, steady outbound flow that does not match normal behavior ?
| Technique | ID |
|---|---|
| Data from Information Repositories | T1213 |
| Data from Cloud Storage | T1530 |
| Archive Collected Data: Archive via Utility | T1560.001 |
| Data Staged: Remote Data Staging | T1074.002 |
| Exfiltration Over C2 Channel | T1041 |
| Exfiltration Over Alternative Protocol | T1048 |
| Data Transfer Size Limits (chunking) | T1030 |
| Scheduled Transfer | T1029 |
Tactics: Collection (TA0009), Exfiltration (TA0010)
The Chain at a Glance
Each stage of the story lines up with one or more ATT&CK tactics — this is what makes the engagement measurable.
| Stage | ATT&CK Tactics |
|---|---|
| 1. Initial Access | TA0001, TA0002 |
| 2. Command and Control | TA0011, TA0003 |
| 3. Privilege Escalation | TA0004, TA0005, TA0007 |
| 4. Lateral Movement | TA0006, TA0008 |
| 5. Action on Objectives | TA0009, TA0010 |
Why Map to ATT&CK at All ?
Because "we got domain admin" is a story, and a story cannot be measured.
Mapping does three useful things:
It gives the red team and the blue team one shared vocabulary. T1003.001 means the same thing to both sides.
It turns the report into coverage data — which techniques were blocked, which were detected, which went completely unseen.
It makes the next simulation comparable to this one.
The Debrief — Where the Value Actually Is
When the simulation ends, the team does not just hand over a "we won" slide.
They produce a timeline of every action taken, with timestamps, and place it side by side with the organization's own logs.
Then the honest question gets asked: at which stage were we caught ?
The attacker's timeline laid over the defender's logs. Where detection happened is the real score of the engagement.
Caught at Stage 1 — good. The phishing controls and EDR worked.
Caught at Stage 4 — late, but the segmentation and SOC alerting saved you.
Not caught at all — the gap is not one tool. It is the whole chain.
That gap is the deliverable. Everything else is context.
In Summary
Adversary simulation tests prevention, detection, and response across a full multi-stage attack, not isolated flaws.
Simulation asks what an attacker could do. Emulation reproduces what a specific actor already did.
The chain runs initial access → C2 → privilege escalation → lateral movement → exfiltration, and each stage depends on the one before it.
Mapping every action to MITRE ATT&CK turns a war story into measurable detection coverage.
The real product is the debrief — the point in the timeline where your defenders stopped seeing the attacker.
