Emulating adversaries you actually have, not the ones in the brochure

There is a particular kind of red-team report that turns up at the end of a six-week engagement. It is colour-coded, it has flame graphics on the cover, and it concludes that the attacker reached domain admin in three hours by exploiting an unpatched piece of equipment that nobody has touched since 2009. The conclusion is presented as if it were profound. It is not profound. It is what happens when you give a competent attacker six weeks and no rules.

Adversary emulation is a different exercise, and the difference matters.

A specific adversary, a specific estate

The premise of emulation is that not all adversaries are interesting. The ones that should shape your defensive programme are the ones who are plausibly going to come for you, doing the things they have demonstrably done to others. A small UK-based law firm and a multinational shipping company face different adversaries with different goals using different toolkits, and an emulation that ignores that fact teaches them roughly the same lesson, which is that a determined attacker with no scope limits can win. We knew that already.

The way to make emulation useful is to begin with the threat profile. Who has compromised similar organisations in the last two years, what did they want, and what did they actually do once they were in? You read the public reports carefully, you talk to peers, you read sectoral threat intelligence, and you write down — in plain English — three to five adversary profiles. Each profile names the actor, the goal, and a short list of TTPs they consistently rely on.

What emulation looks like in practice

An emulation engagement is staged. You agree the profile, you agree the operational tempo (which usually means slowing down to mimic real-world dwell times rather than collapsing the kill chain into an afternoon), and you agree the rules of engagement that protect the production estate. You bring tooling that mimics the family of tooling the actor has been observed to use — not necessarily the exact malware, which is often encumbered for reasons that need not detain us here, but functional analogues that produce telemetry of similar shape.

Then you run the campaign with the discipline of a real operation. You stage your foothold. You move the way the actor moves. You exfiltrate the way the actor exfiltrates, against synthetic data, into infrastructure that mimics theirs. The defenders are notified that an emulation is running but, importantly, are not told what or when — that is the defenders' rehearsal, and protecting it is part of the contract.

The report nobody writes

The valuable report from an emulation does not say we got in. It says, step by step, what each defensive control did and did not do, and what would have been required to change the outcome. At T+0:14 we triggered detection rule R-1083 but the alert was not actioned because the analyst on call was already saturated; at T+1:22 we performed lateral movement that should have triggered R-2110, but R-2110 had been silently broken by a schema change in March; at T+3:40 we exfiltrated 14 GB of synthetic finance data through a path that no detection covered. That is the document the defensive programme can act on.

It is also, incidentally, the document that distinguishes a useful emulation programme from a vanity exercise. If the report cannot be reduced to a small number of concrete improvements, the engagement was not really an emulation; it was a generic offensive engagement with extra branding.

Purple is where the value compounds

An emulation in isolation is useful once. An emulation programme — in which the same scenarios are re-run quarterly against the same defensive function, with the gaps from the previous run remediated and tracked — is the thing that produces a measurable, durable lift in defensive capability. The first run is a baseline. The second run tells you whether the remediations actually worked. The third tells you whether they were worth the cost. By the fifth run, the function has detectably more capability than it had a year earlier, in language the executive can understand.

If you have a budget for one offensive engagement a year, you will probably get more value out of running the same emulation twice — once as a baseline, once after remediation — than out of two unrelated engagements. The compounding is the point.

A note on tooling

The temptation is to lean heavily on commercial breach-and-attack-simulation platforms. They have their place — particularly for testing that simple controls are still in place — but they are very rarely a substitute for an emulation. They emulate techniques in a sterile way; an emulation emulates an adversary on a real estate, with all the operational frictions that implies. The two are complementary, not interchangeable. If your offensive programme is exclusively automated, you have a coverage tool, not an emulation programme.

Where emulation lives in a defensive function

I think of emulation as the forcing function in the defensive cycle: it is what generates concrete, time-stamped evidence of what does and does not work. Detection engineering, threat hunting, and incident-response readiness all benefit from it, because all three feed off the same evidence. Without emulation, those functions tend to drift into self-assessment; with it, they have a regular external reality check.

And reality, in the end, is what the discipline is about.