Back

Breach and attack simulation isn’t Purple Teaming

BAS can be useful for continuous validation. But a green heatmap doesn’t necessarily tell you how your security program will perform against a real attacker.
Authored by: Dominion Cyber

The pitch sounds great

BAS platforms make a seductive promise: push a button, emulate an adversary, and collect continuous proof that your security stack works. The MITRE ATT&CK heatmap turns green, the report lands in the board deck, and everyone exhales.

‍

There’s just one problem: a green heatmap doesn’t necessarily tell you how you’ll perform against a real attacker.

‍

And lately the pitch has escalated. BAS is marketed as “purple team automation” and a “virtual purple team” — the exercise without the humans who run one. Even Gartner cautions that BAS complements red teaming and penetration testing but cannot completely replace them.

‍

Before you let a report card retire your purple team, ask what that report card actually measures

The thing you are paying for is resilience. Not the number of tools you own or the compliance boxes you check, but what actually happens when a capable adversary shows up: how far they get, how fast you see them, how well your layers hold when the first one fails, and how expensive the ordeal is before you recover. Every dollar in your security budget is a bet on that outcome. If you cannot measure resilience, you are betting blind.

‍

The typical BAS platform is not built to measure all of it. The grade may be real, but the test can be rigged in your favor by architecture rather than malice. Here are six things to consider:

‍

1. The agent can taint the evidence

The standard BAS deployment model installs an agent on target systems, and that agent becomes the instantiating process for what the platform does. If the agent is BASSolution.exe, BASSolution.exe is the parent of every “attack” in the test.

‍

Modern EDR contextualizes the process tree when deciding whether behavior is malicious. When every test traces back to the same well-known process, detections can anchor on that lineage instead of the tradecraft. The same problem can show up on the wire: if “malicious” traffic always originates from the same IP space and ASN, reputation can do the work behavioral detection should be doing.

‍

That is vendor convenience, not true-to-form attacker behavior, and it can distort what you think you are detecting, preventing and, most importantly, missing.

‍

BAS content can also emphasize tool use over outcomes. If a credential-dumping test (ATT&CK T1003) uses a copy of Mimikatz that has been signatured for more than a decade, congratulations: you detected the tool. But did you prove resilience against credential theft?

‍

That distinction matters. CrowdStrike’s 2026 Global Threat Report found that 82 percent of detections in 2025 involved no malware at all, with adversaries increasingly leaning on valid accounts and tools already present on systems. A validation program centered on tool signatures is measuring a shrinking slice of attacker behavior.

‍

2. Whitelisting the agent doesn’t make the test neutral

The obvious fix is to whitelist the agent. Add an exclusion, tell the sensor to ignore it, and let the tradecraft stand on its own. Except that is not what an exclusion does.

‍

Modern EDR sensors collect context around process creation, thread creation, image and driver loads, registry writes, file operations and network connections. Those events carry information such as parent process, command line, signer, hash and integrity level. Behavioral logic evaluates the chain, not one process in isolation.

‍

An exclusion reaches into that machinery. It changes the trust boundary: rule evaluation can be skipped, telemetry can stop being scored, and activity beneath an excluded lineage can receive softer treatment.

‍

You did not make the test neutral. You reconfigured the instrument in the middle of the experiment.

‍

A real intruder never gets an exclusion. Microsoft’s own Defender documentation warns that creating an exclusion creates a protection gap. Building a validation program on top of one can bake that gap into the numbers you report.

‍

3. One detection is not the whole story

BAS validation logic can be one-dimensional: did a “block” land inside the window, yes or no? If the platform does not understand your data schema, it may not examine the events surrounding the test even when those events hold the real story.

‍

Say your endpoint tooling blocks a scheduled task (T1053.005). The BAS marks it green and moves on. But the left-of-bang events — what happened before the final malicious action — may matter more: creation of the scheduled task, a binary staged in a commonly abused path, or rare task parameters.

‍

Those are the signals that can catch an adversary while they are staging the environment. Breakout time, the gap between first access and lateral movement, averaged 29 minutes in 2025, with the fastest observed run at 27 seconds. If your validation platform cannot see the events that precede the boom, it cannot tell you whether you can.

‍

Moving the needle left of bang is the point of purple teaming.

‍

4. The first block is not the finish line

BAS platforms commonly leave the security stack inline and report on the first detection they hit. Test over. Cell turns green.

‍

But disabling or sidestepping EDR is established tradecraft. ESET researchers track close to 90 distinct EDR killers in active use and describe them as a near-standard fixture of modern ransomware intrusions (Impair Defenses, T1562.001). One campaign cycled through more than 2,500 signed variants of the vulnerable truesight.sys driver for one job: terminating security products.

‍

Treating the first detection as the final word assumes an attacker who politely leaves your defenses running. That is not the attacker you have.

‍

Purple team testing validates surrounding telemetry and downstream controls end to end. It also asks what happens when an attacker starts from an unmanaged or unenrolled asset your EDR never touched.

‍

5. Your BAS library may be testing yesterday’s attack surface

BAS content is built after tradecraft becomes public, documented and repeatable. Meanwhile, attackers keep moving toward the path of least resistance.

‍

Increasingly, that means identity and SaaS: session token theft, OAuth consent abuse, malicious app registrations, SaaS-to-SaaS integration abuse and valid-account activity inside sanctioned applications.

‍

Verizon’s 2026 Data Breach Investigations Report found credential abuse somewhere in the chain of 39 percent of breaches. CrowdStrike logged a 266 percent jump in cloud-conscious intrusions by state-nexus adversaries. Endpoint-only validation does not tell you how resilient you are when the attacker simply logs in.

‍

The frontier keeps moving. Anthropic has documented an espionage campaign that manipulated a coding agent into executing most of the attack chain. Agentic tooling abuse is live tradecraft before many standardized content libraries can cover it.

‍

Some of this requires bespoke testing by hand. That comes with the territory when you care about the attack surface adversaries actually use.

‍

6. A score is not resilience

Add it up: tainted telemetry, one-dimensional correlation, testing that stops at the first block, and blind spots across identity and SaaS. You can end up with a best-case health card built on use cases that do not fully emulate threat actor behavior.

‍

That does not make BAS useless.

‍

A report card has its place. Run BAS as a regression test — a scheduled check that controls you already validated are still standing — and it can earn its keep. What it cannot do is replace the validation itself.

‍

Purple teaming is where you generate visibility intelligence: what can my tooling actually see? It is where you quantify resilience against specific vectors and actor tradecraft, and where you build a defensible read on the ROI of your cybersecurity investment.

‍

A heatmap full of green will not save you in an incident review.

‍

Where does BAS belong?

Use automation for repeatability. Use BAS to rerun known scenarios, catch regression and monitor controls you have already validated. Then use adversary-led purple teaming to answer the questions automation cannot: what happens when the path changes, a control fails, the attacker pivots, the identity layer becomes the battlefield, or the telemetry tells a story the test was not designed to score?

‍

The question is not whether BAS works. It is whether you are asking it to prove something it cannot.

‍

Evaluating a BAS platform?

Read the 20 questions we think every buyer should ask before signing.