What Is an Attack Simulation?

An attack simulation is an automated, software-based offensive security process that tests an organization's defenses by safely mimicking real-world threat behaviors and adversary tactics against its production environment. Instead of reporting that a weakness exists, it runs the attack and records how security controls, attack paths, and exposures actually respond.

Where attack simulation fits in Gartner's CTEM model

• In Gartner's model, attack simulation is how the Validation stage of the Continuous Threat Exposure Management (CTEM) framework gets done.

• Gartner separates the tooling into two platforms: exposure assessment platforms discover and prioritize exposures, and adversarial exposure validation (AEV) proves which of them matter by testing them.

• AEV covers breach and attack simulation and automated penetration testing, and Gartner's Continuous Offensive Security Testing research adds that this validation must be continuous and trigger-driven rather than scheduled.

The three disciplines of attack simulation

In practice, attack simulation is three disciplines, each answering a different question.

• Breach and attack simulation proves which security controls stop adversary behavior.

• Autonomous penetration testing proves how far an attacker gets once inside.

• Exposure validation proves whether a specific CVE is exploitable against your controls today, including CVEs with no public PoC and assets an autonomous pentest cannot safely touch, such as restricted or air-gapped systems.

Not every exposure needs all three. A signal, whether from outside (a new CVE, a new campaign, a new public exploit) or inside (a new asset, a policy change, control drift), determines which question is being asked, and the question selects the discipline. In a mature program that selection runs autonomously: agents pick the test, execute it, and route the fix, with humans approving at decision gates.

All three disciplines run in production, map to MITRE ATT&CK, and end with a fix and a re-test.

Why is attack simulation important?

Attack simulation is important because neither a CVSS score nor a control inventory can tell you whether an attack would succeed against your environment today. It is the only method that runs the attack and records what happened. Four shifts have made that answer unavoidable.

Deployed controls are not working controls

For years the question was "Do we have a security control for this?" A deployed firewall, EDR, or gateway was read as a working one. Picus’ Blue Report 2026 data says otherwise: organizations running the same class of product score anywhere from near 100% prevention to near zero.

A lab benchmark is a ceiling; configuration drift, exclusions added to silence false positives, agents missing from hosts, and detections left in alert-only mode decide what happens in production.

Figure 1: Real-world performance of cybersecurity products, Blue Report 2026

Detection tells the same story from the other side.

Across 338 million simulations performed by Picus customers in 2026H1, attacker behavior was logged in 58% of cases, the highest in four years of Blue Report data, but only 14% produced an alert, unchanged from last year. Fewer than one in seven simulated attacks reaches a human as an alert. The telemetry is being collected; it is not being turned into detections that fire. Neither gap is visible from a control inventory, and both are visible the moment the attack is run.

AI-speed attacks leave no time to guess

Writing a working exploit used to be the slow, skilled part of an attack. Anthropic reports that Claude Mythos Preview found vulnerabilities and developed working exploits autonomously. In the meantime, the window between disclosure and exploitation has collapsed to roughly eight hours. The assumption that defenders have time to investigate, prioritize, and act no longer holds.

The numbers compound the problem. 35,853 CVEs were published in the first half of 2026, about 49% more than a year earlier; only 495 were exploited in the wild, and 116 were under attack the day they were published. Patching cannot keep pace either: in Anthropic's August 26 update, only 421 of 2,300 disclosed vulnerabilities had known patches, with human triage as the bottleneck.

So a CVE drops, it is rated 9.8, and leadership asks "Are we exposed?" Most teams cannot say whether the attack would even work against their controls.

The calendar-based security testing model is officially retired

The old calendar-based security testing model had three habits: score the vulnerability, wait for a safe exploit, assume control coverage. Each is now a liability.

• In June 2026, CISA's BOD 26-04 replaced CVSS-led patching with evidence-based prioritization, citing AI shortening the gap between disclosure and weaponization.
• In March 2026, Gartner's Continuous Offensive Security Testing research retired fixed-interval pentesting in favor of continuous, trigger-driven validation, with a planning assumption that more than 60% of enterprise pentest programs run as continuous validation by 2028.

The new requirements map directly to the three disciplines: prove exploitability, validate the required techniques, prove control effectiveness.

Mythos-ready means being able to prove it

"Mythos-ready" is now shorthand for that boardroom question: can we withstand AI-powered attacks, and can we prove it? A CVSS score describes how dangerous a flaw is in theory. A control inventory describes what was bought. Attack simulation answers the question because it runs the attack and records what happened.

How does an attack simulation work?

Every attack simulation follows the same five-step loop: choose what to test, execute it safely against production, measure what defenses did, fix what failed, and re-test to prove the fix. What changes across the three disciplines is the object under test and therefore what each step looks like.

Because the loop is shared, findings from one discipline feed the next: an exploitable CVE triggers the path test, a reached asset triggers the control fix, and BAS confirms the fix holds across the stack.

What are the types of attack simulation?

Attack simulation is often equated with BAS. BAS is one discipline of three, and the three test different things.

Breach and attack simulation: testing security controls

BAS sends known malicious payloads and adversary techniques through each layer of defense and scores the integrated security control, per technique, on prevention, logging, and alerting. The Blue Report measures five vectors.

Two results deserve a sentence each.

Network attack simulation prevention has slid 21 points in two years because indicator-based inspection cannot keep pace with the nearly two million new files VirusTotal receives daily; the Blue Report's conclusion is that IOC-based prevention must be reinforced with TTP-based prevention targeting the behaviors beneath the indicators.

A data exfiltration prevention score of 7% means more than nine in ten simulated data theft attempts succeed, and the Red Report 2026 explains why that matters: ransomware encryption fell 38% year over year, while roughly 80% of the most prevalent techniques serve evasion and persistence.

Autonomous penetration testing: simulating the attack path

Autonomous penetration testing measures something the boundary prevention score cannot: what an adversary accomplishes once already operating inside the environment as an authenticated user. AI agents reason, adapt, and chain real exposures into attack paths toward crown-jewel assets, executing discovery, credential access, lateral movement, and privilege escalation safely in production within guardrails you control, and reporting which actions defenses stopped and which assets were reached. It requires no red-team resources and runs continuously.

The Blue Report measured this for the first time in 2026, and the result describes a soft interior: only 37% of attacker actions were blocked.

Loud actions were caught. Lateral movement via service execution was prevented around 90% of the time, UAC-bypass privilege escalation around 85%, Active Directory abuse such as Pass-the-Ticket around 63%. Quiet actions were not. Discovery and collection were blocked in roughly 10% of attempts, and passive credential reads from memory and the registry about 22% of the time, with some variants blocked in well under 1%.

One illustration captures the mechanism. The same credential-theft tool was blocked in the large majority of attempts when it dumped LSASS memory, the heavily signatured path, and rarely or never when quieter variants read credentials from the registry or other memory locations.

Controls are tuned to the well-known indicator, not the underlying behavior, and an adversary who picks the less famous variant walks past them. It is the credential-access counterpart to the malware download finding: indicator-based prevention is losing ground to behavior that stays just off the signatured path.

Exposure validation: simulating CVEs without a safe exploit

Exposure validation answers the question the first two cannot always reach: is this specific vulnerability exploitable in this environment, today? Many newly disclosed CVEs have no public or safe exploit, and many sit on restricted assets an autonomous pentest cannot touch.

Exposure validation decomposes each vulnerability into the exploit primitives an attacker would have to execute, then validates that chain against the real control stack, per asset, to show whether the path executes and which control stops it. Because the same primitives recur across CVEs, hardening one step blocks a whole family.

The cost of guessing is visible in the Blue Report's vulnerability spotlight.

Every one of the ten least prevented CVEs was blocked in fewer than 25% of simulated exploit attempts, led by Linux libblockdev CVE-2025-6019 at 8%, Windows Notepad CVE-2026-20841 at 9%, and OpenSSL CMS CVE-2025-15467 at 11%. A browser, two archive utilities, a text editor, and core OS libraries: the everyday software surface, with compensating controls not picking up the slack.

When a patch is weeks away, exposure validation tells you which control to tune in the meantime and confirms it worked.

Attack simulation vs. penetration testing vs. vulnerability scanning

The five methods are often bought as substitutes for one another, and they are not. A scanner tells you a CVE exists; a manual pentest tells you whether a skilled human could reach one target during one engagement; neither tells you whether your controls would stop the attack today.

The table shows where each method's answer stops, so you can see which gaps a program built on scanning and annual pentests leaves open, and which of the three attack simulation disciplines closes each one.