Adversary Emulation Explained: TTPs, Purple Teaming and MITRE ATT&CK

Adversary emulation is the practice of imitating a specific, known threat actor — using their tools, their techniques and their sequence of operations — to find out whether your defences would actually catch them.

That last part is the point. A penetration test asks whether an attacker could get in. Adversary emulation asks whether your detection and response would notice a particular attacker while they did it. The deliverable is different, and CompTIA tests that difference.

How it differs from the neighbouring activities

Activity	Question it answers
Vulnerability scan	What weaknesses exist?
Penetration test	Can those weaknesses be exploited to reach something valuable?
Red team engagement	Can we reach a specific objective without being stopped?
Adversary emulation	Would we detect and respond to this particular actor's methods?

A penetration test is scoped by systems. Adversary emulation is scoped by behaviour. You start by choosing a threat actor who plausibly targets your sector, then reproduce the way that actor works rather than reaching for whatever exploit is easiest.

TTPs: the unit of work

Everything in adversary emulation is built on TTPs — tactics, techniques and procedures. The three levels are not interchangeable, and exam questions lean on the distinction.

Tactics are the adversary's goals at each stage: initial access, persistence, privilege escalation, lateral movement, exfiltration. The why.

Techniques are the general methods used to achieve a tactic: spear-phishing with an attachment, abusing a scheduled task, dumping credentials from memory. The how.

Procedures are the specific implementations a given actor uses: a particular loader, a specific registry key, a distinctive command-line pattern. The exactly how, by whom.

Tactics change slowly, techniques change moderately, procedures change often. This is why detections built on behaviour outlive detections built on file hashes — and why emulation targets techniques rather than indicators.

MITRE ATT&CK as the common language

ATT&CK is the knowledge base that makes emulation repeatable. It catalogues adversary tactics and techniques observed in real intrusions, organised into a matrix where columns are tactics and cells are techniques, each with an identifier such as T1059 for command and scripting interpreter.

Three uses come up on the exams.

Scoping. Pick a threat group profile and take its documented techniques as your test plan.

Coverage mapping. Chart which techniques your tooling can detect. The resulting heat map shows gaps far more honestly than a count of installed products.

Communication. "We were blind to T1003 credential dumping" is a more actionable finding than "EDR needs tuning".

Related frameworks worth recognising: the Cyber Kill Chain, which models an intrusion as seven sequential stages, and the Diamond Model, which analyses an intrusion through adversary, capability, infrastructure and victim. ATT&CK is a catalogue of behaviour, the Kill Chain is a sequence, and the Diamond Model is an analytic frame. Do not mix them up.

How an engagement runs

Select the adversary. Use threat intelligence to choose a group that realistically targets your industry. Emulating a state actor when your risk is commodity ransomware wastes the exercise.

Gather the intelligence. Collect reporting on that group and extract its TTPs into a concrete plan.

Build the emulation plan. Convert the TTPs into executable steps with defined start and end states, and with safety rails. Emulation reproduces behaviour, not damage — you do not detonate real ransomware on production.

Execute. Run the plan, logging precisely what you did and when. That timeline is what you compare detections against.

Compare and report. For each technique: was it prevented, detected but not alerted, alerted, or missed entirely? That four-way outcome is the real product of the exercise.

Purple teaming

Adversary emulation is most often run as a purple team exercise. Red operates, blue defends, and both sides share information as it happens rather than after the fact.

The value is speed of feedback. When an operator runs a technique and the SOC sees nothing, the detection engineer can write a rule and have it retested within the hour. A conventional red team engagement surfaces that gap weeks later in a report.

Breach and attack simulation tooling automates the same idea continuously, running a library of techniques on a schedule so that coverage is verified constantly rather than annually.

Rules of engagement

Whatever the framing, the authorisation requirements are the same as for any offensive testing, and the exam does ask. Get written authorisation from someone empowered to give it. Define scope, timing and prohibited actions. Agree the escalation path and a stop condition. Decide in advance whether the SOC is told — an unannounced exercise tests detection realistically, but it consumes real incident-response effort.

Cloud-hosted targets often need provider notification, and third-party systems need their own authorisation. Your contract with a customer does not authorise you to test their supplier.

Where it appears on the exams

PenTest+ (PT0-003) covers scoping, rules of engagement and TTP-driven planning.

CySA+ (CS0-003) approaches it from the defensive side: using ATT&CK for detection coverage and threat-informed defence.

SecurityX (CAS-005) treats it as a programme, including purple teaming and continuous validation.

What to remember

Adversary emulation imitates a specific known actor to test detection and response, not just whether entry is possible. TTPs run from tactics (goal) to techniques (method) to procedures (specific implementation). MITRE ATT&CK supplies the shared vocabulary and the coverage map. Purple teaming shortens the feedback loop. And nothing starts without written authorisation.

Related reading: TAXII · STIX objects · Insider threats