Adversary Simulation: Testing the Controls You Think You Have

Most organisations have invested substantially in security controls. Endpoint detection, email security, network monitoring, identity protection, privileged access management: the stack is broad and the licensing costs are significant. What most organisations have not done is verify that those controls work under realistic attack conditions. The assumption that a deployed control is an effective control is one of the most expensive assumptions in security.

Adversary simulation is the practice of running structured attack scenarios against a live environment to test whether deployed controls detect, block, or alert on the behaviour they are supposed to. It sits at the intersection of penetration testing and red teaming, and it is distinct from both. Where a pen test looks for vulnerabilities and a red team tests the whole defensive programme, adversary simulation tests specific control categories against specific attack technique categories. The output is a gap map: which techniques your controls catch, which they miss, and why.

Why Deployed Controls Are Not Automatically Effective Controls

A control is effective only if it is correctly configured, correctly integrated, and actually processing the telemetry it needs to produce alerts. Each of those conditions fails in practice more often than security teams acknowledge. An endpoint detection product installed with default configuration may not generate alerts for the most common post-exploitation techniques. An email security gateway correctly blocking commodity phishing may not inspect the attachment types used in targeted attacks. A network detection product with no visibility into encrypted east-west traffic is producing a false picture of its own coverage.

Configuration drift is a persistent problem. Controls are tuned at deployment, often with aggressive settings that generate alert noise, and then quietly adjusted to reduce volume. By the time an adversary simulation is run, the deployed configuration may bear little resemblance to the configuration the vendor demonstrated during the sales process. Testers regularly find endpoint controls with core features disabled, logging agents that stopped reporting weeks ago, and detection rules that were written to fire on signatures from two years prior.

What Adversary Simulation Tests

Adversary simulation tests specific attack techniques against the controls that are supposed to address them. Initial access techniques, including credential phishing, payload delivery, and exploitation of exposed services, are tested against the controls that claim to prevent or detect initial access. Post-exploitation techniques, including credential dumping, lateral movement, command and control communication, and data staging, are tested against the controls that claim to detect those activities. Each test produces a binary or partial result: detected, not detected, or detected but not alerted.

The technique mapping is typically drawn from a structured framework of adversary behaviour. This allows simulation results to be expressed in terms of which technique categories your controls address and which they do not, producing a coverage map rather than a simple pass or fail. The coverage map identifies both the specific gaps to address and the vendor claims that do not survive contact with a real attack scenario.

The Difference Between Simulation and Validation

Adversary simulation should be distinguished from automated control validation, which is a related but different activity. Automated validation tools run large libraries of pre-built attack scenarios continuously against controls and report coverage percentages. This is useful for ongoing monitoring of control effectiveness and for regression testing after configuration changes. It is not the same as an adversary simulation run by practitioners who chain techniques together, adapt to what they find, and test the integrated defence stack rather than individual controls in isolation.

A practitioner-run adversary simulation will find gaps that automated validation misses because it tests the combination of controls rather than each control individually. A technique that is blocked by the endpoint control but not by the network monitoring control leaves a detection gap when the attacker operates entirely in memory and generates no endpoint artifacts. Automated tools test individual controls against individual techniques; practitioners test whether the whole picture holds when techniques are chained in realistic sequences.

What Organisations Get From the Exercise

The primary output of an adversary simulation is a prioritised control improvement list, not just a finding list. For each detected gap, the engagement identifies whether the issue is a configuration problem, a coverage problem, or a visibility problem. Configuration problems are fixed in the existing tool. Coverage problems may require additional tooling or tuning. Visibility problems mean the control does not have access to the telemetry it would need to detect the technique, which may require architectural change.

Organisations also get an honest assessment of what their controls actually cost them in effectiveness terms versus what the vendor claimed they would deliver. This has direct implications for renewal decisions, for conversations with vendors about configuration support, and for prioritising investment in the areas where current controls provide no meaningful coverage.

• Treat control validation as an ongoing programme, not a one-time exercise.
• Test controls under realistic conditions, not in isolated sandbox environments.
• Require technique-level granularity in simulation results, not just aggregate scores.
• Include post-exploitation techniques, not just initial access scenarios.
• Use simulation output to hold vendor configuration support accountable.

To discuss adversary simulation and control validation for your organisation, contact Cyberlinx at info@cyberlinx.com.au.