Breach and Attack Simulation (BAS): What It is and How It Works

Quick Overview: Breach and attack simulation (BAS) is automated security testing that runs real attacker techniques against your live environment to verify whether deployed controls actually detect and block them. This guide covers how BAS works, what it validates, and where it stops.

Your EDR dashboard is green. Your SIEM has detection rules for credential dumping. Your email gateway quarantined forty thousand messages last month. None of that tells you whether an attacker executing a real credential-dumping technique on a production endpoint right now would actually be caught.

That distance between controls that are deployed and controls that work is where most breaches live. Security tools ship with default configurations, get tuned down to reduce alert noise, drift after version upgrades, and quietly stop covering the techniques they were purchased to stop. Nobody notices, because nothing fails loudly. A control that silently allows an attack looks identical to a control that never saw one.

The first honest test of a security stack is usually an incident. By then the results are expensive. IBM puts the global average cost of a data breach at USD 4.99 million in its 2026 Cost of a Data Breach report, and Verizon's 2026 Data Breach Investigations Report finds vulnerability exploitation now sits among the leading initial access vectors, accounting for roughly 31% of breaches.

Breach and attack simulation exists to run that test on purpose, on a schedule, under controlled conditions, before an adversary runs it for free. This guide covers what BAS is, how it works, which controls and techniques it exercises, how it uses MITRE ATT&CK, how it differs from vulnerability scanning and penetration testing, and what it does not cover.

See what your security controls might be missing before attackers do. Start Testing Before They Do

What is Breach and Attack Simulation?

Breach and attack simulation (BAS) is an automated, continuous security testing method that executes real-world adversary tactics, techniques, and procedures against a live environment to measure whether deployed security controls detect, block, or miss them.

The distinction that matters most is what BAS points at. A vulnerability scanner examines your assets and reports what is weak about them. BAS examines your defenses and reports on what they failed to stop. The target of the test is the control stack itself: the firewall rule, the endpoint agent, the detection logic, and the mail filter.

That reframing changes the question a security team can answer. Instead of asking how many critical findings are open, a team running BAS can answer whether a specific technique, executed against a specific segment, was prevented, detected and alerted, logged but ignored, or allowed to complete without any record at all. Those four outcomes are the actual output of a BAS assessment.

BAS is built to be automated and repeatable, which is the second defining property. Simulations run on a schedule rather than a one-off engagement, so a control that regresses after a policy change or a product upgrade surfaces in the next run instead of during the next incident. This is why BAS is usually described as continuous security validation rather than as an assessment.

How Does Breach and Attack Simulation Work?

Breach and attack simulation works by selecting an attack scenario, discovering the in-scope environment, executing that scenario's techniques under controlled conditions, recording how each security control responds, and scoring the gaps where prevention or detection failed.

1) Attack Scenario Selection

A run begins with the choice of what to simulate. Most BAS platforms ship a library of prebuilt scenarios: atomic techniques, campaigns modeled on named threat groups, ransomware behavior chains, and templates built around recently exploited CVEs. Teams can also author custom scenarios reflecting threats specific to their sector.

2) Environment and Asset Discovery

The platform establishes what is in scope and what defensive technology sits in front of it. That means identifying endpoints, network segments, cloud workloads, identity boundaries, and the security controls covering each. Without this step, a failed simulation cannot be attributed to the control that should have caught it.

3) Controlled Attack Execution

The scenario runs. Simulators perform the actual behaviors an attacker would: writing a known malicious file to disk, attempting a credential dump, beaconing to a controlled endpoint, moving between segments, staging data for exfiltration. Behavior is real. The payloads and destinations are not.

One property separates BAS from an external penetration test. BAS agents can be given credentials and internal knowledge an outside attacker would have to earn. That makes BAS closer to a purple team's exercise than to black box testing, and it is deliberate: the goal is to test the control, not to prove reconnaissance is possible.

4) Security Control Monitoring

While the scenario executes, the platform observes what each control did. Did the endpoint agent quarantine the file or ignore it? Did the firewall drop the connection? Did the SIEM alert, and did that alert reach an analyst's queue?

5) Detection and Prevention Validation

Results are scored per technique across two axes: prevention, meaning the action was blocked, and detection, meaning the action was recorded and alerted even if it succeeded. A technique that is neither prevented nor detected is a silent gap, and those are the findings that matter most.

6) Remediation and Retesting

Findings come with mitigation guidance, often vendor-specific: a signature to enable, a policy to tighten, a detection rule to author. Once applied, the same scenario is re-run to confirm the fix actually closed the gap. This is the step that turns BAS from reporting into improvement.

Why is Breach and Attack Simulation Important?

Breach and attack simulation is important because it establishes which exposures are actually reachable in your environment, correcting a prioritization problem that severity scores alone cannot solve.

Consider a vulnerability rated CVSS 9.8. On paper it is critical and demands immediate patching. In your environment, the preconditions for exploitation may not exist, or a next-generation firewall may block the attack at its first stage. The theoretical maximum severity and the real risk are different numbers, and only one of them should drive an emergency change window.

This is the gap that BAS closes. CVSS describes how bad a vulnerability could be in the worst case. EPSS estimates how likely it is to be exploited somewhere in the world. Neither account for the compensating controls you have already paid for and deployed. BAS factors those controls in, which converts a list of hundreds of theoretical exposures into a much smaller set that survives in contact with your actual defenses.

The practical benefit is better prioritization. Security teams can’t fix every finding, especially when some don’t pose a real threat. BAS helps confirm which issues are actually exploitable, and which are already protected by existing controls. This helps teams focus on the risks that matter most. That’s why BAS is becoming an important part of Continuous Threat Exposure Management (CTEM).

Don’t wait for production incidents to find out. Test it continuously with AI. Put Your App Under Attack

What Security Controls Does BAS Test?

BAS tests the prevention and detection layers of a security stack, covering network, endpoint, identity, email, data, and monitoring controls. Coverage varies by platform, but the following are standard.

What Attack Techniques Can BAS Simulate?

BAS simulates techniques across the full attack lifecycle, from initial access through to data exfiltration, rather than testing isolated actions. Running a complete chain matters because controls often catch a technique in the middle of a kill chain while missing the steps on either side.

How Does BAS Use the MITRE ATT&CK Framework?

BAS uses MITRE ATT&CK as the shared taxonomy that maps every simulated technique to a documented adversary behavior, turning individual test results into a measurable picture of defensive coverage.

In practice, mapping does three things. First, it makes coverage visible. When every simulation carries an ATT&CK technique identifier, results aggregate into a matrix showing which techniques your controls prevent, which they merely detect, and which pass through untouched. That matrix is a coverage map rather than a findings list.

Second, it makes gaps specific enough to act on. A result reading that credential dumping via LSASS memory was neither blocked nor alerted tells a detection engineer exactly which rule to write, which is materially more useful than a finding that endpoint security underperformed.

Third, it makes prioritization threat informed. Threat intelligence describes adversary groups in ATT&CK terms, so a team can identify the techniques used by actors targeting its sector and check its coverage against precisely those, rather than trying to cover the entire matrix at equal depth.

BAS vs Vulnerability Scanning vs Penetration Testing

BAS checks whether security controls can stop known attack techniques. Vulnerability scanning finds weaknesses without exploiting them, while penetration testing exploits those weaknesses to show their real-world impact. Each serves a different purpose, so they work together rather than replace one another.

The clearest way to separate them is by what each one points at. Vulnerability scanning points at assets and asks what is weak. Penetration testing points at those weaknesses and asks whether they can be exploited to reach something valuable. BAS points at defenses and asks whether they would notice. VAPT combines the first two into a single engagement model, which is why it is often confused with BAS despite testing something different.

None of these replaces another, and the industry consensus, including Gartner's own framing of the category, is that BAS complements red teaming and penetration testing without substituting for either. The practical combination most mature programs land on is continuous scanning for hygiene, BAS for control validation, automated penetration testing for continuous exploitability validation at the application layer, and periodic human-led red teaming for adversary creativity.

What are the Limitations of BAS?

The core limitation of BAS is that it validates defenses against known attacker techniques, which means its results are bounded by the contents of its simulation library. Understanding those bounds is what keeps a BAS program honest.

Scenario Coverage Dependency: BAS executes predetermined TTPs. A technique absent from the platform's library is a technique your controls are never tested against, and its absence will not appear as a gap in any report. Coverage looks complete because the untested space is invisible.

Threat Library Freshness: A BAS platform is only as current as the content behind it. If the vendor is slow to add newly observed techniques, simulations quietly drift toward testing last year's adversary behavior while reporting the same confident coverage scores.

Limited Representation of Human Adversaries: Automation runs known behavior consistently. It does not improvise, chain an unexpected misconfiguration into an unplanned path, or exercise the judgment a skilled operator brings. This is precisely the gap that red teaming fills.

Environment-specific Attack Paths: Simulations model general adversary behavior. The path unique to your architecture, a trust relationship between two systems that should not exist, may not correspond to any library scenario.

Operational and Resource Overhead: Results require tuning and interpretation. Poorly scoped simulations generate noise, and small teams frequently underestimate the ongoing effort of maintaining scenarios and acting on findings.

No Visibility into Your Own Application Code: BAS validates the controls surrounding your applications, not the vulnerabilities inside them. A broken authorization check in your own codebase is not an attacker technique and does not appear in any ATT&CK-mapped library.

See how ZeroThreat validates vulnerabilities, connects attack paths, and delivers proof-based results. Watch a Real Attack Demo

Conclusion

Deploying a security control and validating a security control are two different activities, and only one of them produces evidence. Breach and attack simulation exists to close that distance, replacing the assumption that defenses work with measured results per technique, continuously, in the environment that actually matters.

What BAS cannot do is look inside your applications. Its library is built from adversary techniques, and a broken object level authorization flaw in your own checkout flow is not one. That class of risk lives in code you wrote, and it is reached through your own endpoints and APIs rather than through a technique any framework has catalogued.

That is the layer ZeroThreat covers. Its engine runs continuous, attacker-style testing against web applications and APIs, navigating authenticated workflows, chaining weaknesses into multi-step attack paths, and validating exploitability through controlled execution so every finding arrives with proof rather than a severity score. Testing is production-safe and runs on every release, which means application-layer risk is validated on the same continuous basis as your control stack.

A complete validation program needs both halves: BAS proving that your controls hold, and automated penetration testing proving that your applications do. Sign up for free to see what an attacker would find in yours.