# 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.

![](https://cdn.hashnode.com/uploads/covers/69441e0da418bf1fc22446c0/77788b74-9c3d-411c-ba98-682eea5ab98f.png align="center")

*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.

![](https://cdn.hashnode.com/uploads/covers/69441e0da418bf1fc22446c0/9bca68aa-ed80-4a19-85b8-eb58261ac50f.png align="center")

*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

![](https://cdn.hashnode.com/uploads/covers/69441e0da418bf1fc22446c0/4142cd9a-0fe9-491b-85b8-64f73652260e.png align="center")

*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 ?**

![](https://cdn.hashnode.com/uploads/covers/69441e0da418bf1fc22446c0/28f1f322-fae3-4295-9bde-1fee2d579308.png align="center")

*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.