Adversary emulation

Adversary emulation starts from intelligence: a named actor, or a profile relevant to the sector, whose behaviour is documented as a set of techniques in MITRE ATT&CK. The team selects the techniques that matter for the target, builds a plan that chains them into a plausible operation (initial access, execution, persistence, lateral movement, exfiltration), and runs it against the live estate. The point is not to find every hole. It is to walk one credible path the way the emulated actor would, using the same categories of tooling and the same tradecraft, so the client can see which steps their controls caught and which they missed.

Two things trip organisations up. The first is confusing emulation with a generic penetration test: a pentest asks “what is exploitable here?”, emulation asks “would we see this actor if they were already inside?”. The second is measuring the wrong outcome. On these engagements the interesting result is rarely that a technique worked, because most will. It is where the telemetry existed but no alert fired, where an alert fired but nobody acted, and where the response playbook assumed a step the attacker skipped. An attacker does not need novel malware to succeed. They need the defender’s detection to have a gap on the one path that reaches the objective.

The deliverable is an ATT&CK-mapped narrative: each technique attempted, whether it succeeded, and whether it was detected, prevented or missed. We hand over the reproduction and the timestamps so the blue team can line up their own logs against ours, which is the value of running this alongside a purple team. The finding is written against the detection gap, not the technique. This is the core of how we plan an intelligence-led engagement under agreed rules of engagement.