Adversary Emulation with MITRE ATT&CK: Testing Detections You Assume Work

Most organizations do not know which attacks they would actually detect. Tools are deployed, rules are enabled, dashboards look healthy — and nobody has confirmed that a given technique produces an alert. Adversary emulation answers that question by executing known techniques deliberately and checking whether anything fired.

The gap it exposes

Detection coverage is usually assumed rather than measured. A vendor claims a product detects credential dumping, so the technique is marked covered. In practice the rule may be disabled by default, the relevant log source may not be forwarded, an exclusion added a year ago may suppress it, or the alert may fire into a queue nobody reads.

Every one of those failures is invisible until a real incident, which is the worst possible time to discover it. Running the technique yourself turns an assumption into a measured result: either the alert appeared or it did not.

How ATT&CK structures the problem

MITRE ATT&CK catalogs observed adversary behavior as tactics and techniques. Tactics are goals — initial access, persistence, privilege escalation, defense evasion, credential access, lateral movement, exfiltration. Techniques are the specific ways each goal is achieved, with sub-techniques for variants.

The framework matters because it gives detection engineering a vocabulary and a checklist. Instead of "are we secure," the question becomes "which of these several hundred techniques would we see, and which are we blind to." That is answerable, and it produces a coverage map you can argue about with evidence.

The honest caveat: coverage against the catalog is not the same as coverage against your adversary. Prioritize by which techniques are actually used against organizations like yours, using threat intelligence delivered over TAXII feeds and described with STIX objects so the mapping to ATT&CK comes with the data.

How emulation is run

Atomic testing executes one technique at a time as a small, documented, reversible action — a single command or script that produces the same telemetry the real technique would. Each test names the ATT&CK technique it covers, the prerequisites, the command, and the cleanup.

The workflow is deliberately narrow. Pick a technique, note the exact time, run the test on a chosen host, then check whether the expected telemetry reached your SIEM and whether a detection fired. Record one of three outcomes: detected and alerted, telemetry present but no rule, or no telemetry at all.

That third outcome is the important one. A missing log source is a bigger problem than a missing rule, because no amount of detection engineering fixes data you are not collecting.

Full-chain emulation goes further, stringing techniques together to imitate a specific threat actor's sequence. It tests correlation rather than individual rules, which is where cross-domain platforms such as XDR are supposed to earn their cost.

Doing it safely

These are real attack techniques, so the rules of engagement matter as much as in a penetration test. Get written authorization before running anything, and make sure the security operations team knows — unless the test is specifically designed to measure their unaided response, in which case a small number of people know and the timeline is recorded for the debrief afterward.

Start in a lab or a dedicated test host rather than production. Read every test before running it and understand exactly what it does; some create accounts, modify registry keys, or disable protections, and the cleanup step is not optional. Avoid destructive techniques and anything touching critical systems entirely.

Expect some tests to be blocked, which is a good result — but note that a blocked technique should still generate an alert. Prevention without visibility means you learn nothing about the attempt.

Turning results into improvement

The output is a prioritized gap list. For missing telemetry, add the log source. For present telemetry with no rule, write the detection. For rules that fired but were ignored, fix the triage process rather than the rule.

Re-test after each change and re-test periodically regardless, because coverage decays: agents get uninstalled, log forwarding breaks, exclusions accumulate, and a platform upgrade quietly changes an event format. A technique detected last quarter is not necessarily detected today.

Where response is automated, emulation also validates the playbook end to end — whether the SOAR workflow actually isolated the host rather than erroring out on a stale API token.

Exam angles

Know adversary emulation as a form of security control validation distinct from vulnerability scanning and from a full penetration test: it tests detection, not exploitability. Recognize MITRE ATT&CK as a knowledge base of tactics and techniques used to map coverage. Understand that the three outcomes are detection, telemetry without detection, and no telemetry, and that missing data sources are the highest priority gap. And remember purple teaming — offense and defense working together to improve detection — as the collaborative model this work sits inside.