Breach Attack Simulation (BAS)

• BAS is a controlled adversary emulation framework that simulates multi-stage attack flows (reconnaissance, lateral movement, and exfiltration) to assess security defenses.
• It integrates techniques such as syscall-level simulation, probabilistic attack graphs, and LLM-driven planning to measure attack success and detection performance.
• BAS informs iterative security hardening by linking simulation findings to SIEM rule synthesis and defense engineering across IT and cyber-physical systems.

Searching arXiv for recent and foundational papers on Breach Attack Simulation (BAS) and related attack-simulation frameworks. Breach Attack Simulation (BAS), also written “Breach-and-Attack-Simulation” in recent detection-engineering work, denotes automated frameworks that emulate realistic adversary behaviors against an organization’s infrastructure in a fully controlled environment. In the literature, its core objectives are repeatable and scalable emulation of multi-stage attack flows, evaluation and hardening of security controls, identification of overlooked attack vectors, and provision of measurable metrics such as success or failure of each simulated step and time-to-detection (Sánchez-Matas et al., 5 Aug 2025, Maiorano, 3 Jun 2026). BAS has been instantiated as lightweight syscall-level network simulators, probabilistic attack-graph engines, multi-agent LLM systems for assumed-breach testing, cyber-physical co-simulation environments, and pipelines that translate simulation findings into SIEM rules (Futoransky et al., 2010, Sarraute et al., 2010, Happe et al., 6 Feb 2025, Bel et al., 2023, Maiorano, 3 Jun 2026).

1. Definition, scope, and terminological boundaries

In the BAS literature, the defining feature is controlled adversary emulation rather than generic vulnerability scanning. The objective is not merely to enumerate weaknesses, but to execute or simulate multi-stage attack flows such as reconnaissance, initial access, lateral movement, and exfiltration, then measure how defensive controls respond under those conditions (Sánchez-Matas et al., 5 Aug 2025). This distinguishes BAS from static asset inventory or one-shot exploit validation.

The scope of BAS in published work is broader than penetration testing narrowly construed. Insight was introduced as a platform for pentesting training, study of the impact of 0-days vulnerabilities, evaluation of security countermeasures, and risk assessment (Futoransky et al., 2010). Later work extends BAS toward hypothesis-driven experimentation through Security Chaos Engineering (SCE), toward autonomous assumed-breach operations in Active Directory, and toward downstream detection engineering in SIEMs (Sánchez-Matas et al., 5 Aug 2025, Happe et al., 6 Feb 2025, Maiorano, 3 Jun 2026). A plausible implication is that BAS is increasingly treated as an operational evaluation loop rather than a single red-team exercise.

A recurrent terminological ambiguity is that the acronym “BAS” is also used in another cybersecurity literature to mean “building automation system.” The KNX false-data-injection study, for example, analyzes attacks against a KNX based BAS in the building-control sense, not breach-and-attack-simulation (Cash et al., 2022). For technical readers, disambiguation depends on context: adversary emulation platforms on the one hand, and instrumented control infrastructures on the other.

2. Formal representations of attack simulation

Early BAS work established a formal vocabulary centered on theater of operations, targets, missions, actions, plans, assets, and agents. In this model, the theater of operations is the computer network under test; a target may be a host, service, file, or person; an action carries preconditions, success probability, stealthiness, runtime estimates, a zero-day flag, and a traceability penalty; and a plan is a totally ordered sequence of actions chosen to maximize utility under operational constraints (Futoransky et al., 2010). Assets are typed statements of knowledge such as BannerAsset, OSAsset, TCPConnectivityAsset, or AgentAsset, and goals are expressed as completion of an asset, optionally quantified by Any, All, or AllPossible (Futoransky et al., 2010).

A closely related formalization models vulnerabilities and exploits as channels. In that framework, each vulnerability $v$ is represented as

$$C_v=\bigl(\mathit{Req}(v),\;\mathit{Env}(v),\;\mathit{Res}(v),\;p_v,\;T_v,\;\mathit{Noise}_v\bigr),$$

where $\mathit{Req}(v)$ denotes prerequisite assets, $\mathit{Env}(v)$ soft environment conditions, $\mathit{Res}(v)$ the resulting asset, $p_v$ the probability of successful covert use of the channel, $T_v$ syscall-count or time cost estimates, and $\mathit{Noise}_v$ expected IDS or noise contributions (Sarraute et al., 2010). This representation supports attack-graph construction, best-first plan search, and cost-based ranking of partial plans.

Plan evaluation in these models is explicitly multi-objective. One formulation defines success probability, stealthiness, runtime, and traceability over a plan $P=\langle a_1,\dots,a_n\rangle$ by products or sums over the constituent actions, and minimizes a weighted objective

$$F(P)=\alpha[1-p(P)] + \beta[1-s(P)] + \gamma t_{\mathrm{avg}}(P) + \delta \tau(P) + \epsilon z_{\mathrm{sum}}(P)$$

subject to operational constraints such as time budget, zero-day budget, or minimum stealthiness (Futoransky et al., 2010). A second formulation combines success probability, expected time, and detection risk as

$$C_v=\bigl(\mathit{Req}(v),\;\mathit{Env}(v),\;\mathit{Res}(v),\;p_v,\;T_v,\;\mathit{Noise}_v\bigr),$$0

for a plan $$C_v=\bigl(\mathit{Req}(v),\;\mathit{Env}(v),\;\mathit{Res}(v),\;p_v,\;T_v,\;\mathit{Noise}_v\bigr),$$1 (Sarraute et al., 2010). These formulations make BAS amenable to shortest-path, best-first, or hierarchical planning methods rather than ad hoc exploit sequencing.

Probabilistic attack graphs extend BAS toward inference under uncertainty. In Bayesian attack graphs, each node is a Boolean random variable indicating whether the attacker reaches a condition or goal; conditional probability tables are constructed differently for leaf, AND, and OR nodes; and evidence from IDS or host activity updates posterior compromise probabilities (Matthews et al., 2021). Because exact inference becomes intractable on large graphs, stochastic simulation is used. The comparison of Probabilistic Logic Sampling, Likelihood Weighting, and Backward Simulation concludes that Likelihood Weighting is most efficient for most uses, including dynamic updating and sensitivity analysis of large Bayesian attack graphs (Matthews et al., 2021).

3. Execution substrates: syscall-level simulation, exploit outcomes, and pivoting

Insight exemplifies a BAS architecture that trades full fidelity for scalability by modeling only the attacker’s point of view. Its architecture comprises a Simulator Monitor, distributed Simulator subsystems, XML configuration files, and a Penetration Testing Framework such as Core Impact’s API and Python modules, used unmodified through real or simulated sockets (Futoransky et al., 2010). Each virtual machine implements only a small common subset of POSIX or Win32 syscalls mapped to a unified “insight syscall” interface; there is no full CPU emulation or detailed heap state, only enough context to answer read, write, open, and exec queries (Futoransky et al., 2010). The network is similarly minimal: packets are generated and forwarded on demand, with SocketDirect for in-host fast paths and SocketReal only when external connectivity is required (Futoransky et al., 2010).

In Insight, vulnerabilities are stored in an XML exploits database with <requirement> clauses for host properties and <results> clauses for outcome tags such as <agent>, <crash>, <reset>, and <alarm>, each carrying a probability in $$C_v=\bigl(\mathit{Req}(v),\;\mathit{Env}(v),\;\mathit{Res}(v),\;p_v,\;T_v,\;\mathit{Noise}_v\bigr),$$2 (Futoransky et al., 2010). Delivery is triggered by sending a “magic string” over an existing TCP channel to the simulated service. On each intercepted read, the simulator checks host predicates and evaluates outcomes through a small probabilistic finite-state-machine. If $$C_v=\bigl(\mathit{Req}(v),\;\mathit{Env}(v),\;\mathit{Res}(v),\;p_v,\;T_v,\;\mathit{Noise}_v\bigr),$$3 is the ordered result list with probabilities $$C_v=\bigl(\mathit{Req}(v),\;\mathit{Env}(v),\;\mathit{Res}(v),\;p_v,\;T_v,\;\mathit{Noise}_v\bigr),$$4, the outcome is

$$C_v=\bigl(\mathit{Req}(v),\;\mathit{Env}(v),\;\mathit{Res}(v),\;p_v,\;T_v,\;\mathit{Noise}_v\bigr),$$5

with $$C_v=\bigl(\mathit{Req}(v),\;\mathit{Env}(v),\;\mathit{Res}(v),\;p_v,\;T_v,\;\mathit{Noise}_v\bigr),$$6, or “no visible effect” if none fire (Futoransky et al., 2010).

Successful exploitation installs a small “agent” process on the compromised VM, after which the host becomes a pivot for further remote or local exploits. The agent acts as a stub syscall server, while the penetration-testing framework marshals Python syscall requests through the newly provisioned TCP channel (Futoransky et al., 2010). Network segmentation is represented by routers, ACLs, or stateless firewall objects placed in scenario XML; if the pivot host lacks the required trust or ACL path, later stages cannot traverse (Futoransky et al., 2010). For a $$C_v=\bigl(\mathit{Req}(v),\;\mathit{Env}(v),\;\mathit{Res}(v),\;p_v,\;T_v,\;\mathit{Noise}_v\bigr),$$7-hop lateral move, the end-to-end success probability is naturally the product $$C_v=\bigl(\mathit{Req}(v),\;\mathit{Env}(v),\;\mathit{Res}(v),\;p_v,\;T_v,\;\mathit{Noise}_v\bigr),$$8 of stagewise compromise probabilities (Futoransky et al., 2010).

Insight’s scenario specification is deliberately lightweight. A scenario is defined by XML files such as machines.xml, network.xml, vuln.xml, and users.xml, optionally augmented with Python scripts for topology generation or imports (Futoransky et al., 2010). This architecture was designed to scale: a single modern desktop such as an Intel Pentium D 2.67 GHz with 1.4 GB RAM can simulate approximately 1,000 hosts, and the published performance table reports the following discovery throughput for an unmodified network-discovery module scanning port 80 on every host (Futoransky et al., 2010).

Configuration	Elapsed (s)	Syscalls/s
1 LAN / 250 hosts	80	356
2 LANs / 500 hosts	173	236
3 LANs / 750 hosts	305	175
4 LANs / 1000 hosts	479	139

These design choices establish a canonical BAS trade-off: reduced fidelity at the host and packet level in exchange for tractable large-scenario multistage attack emulation (Futoransky et al., 2010).

4. LLM-native BAS and autonomous assumed-breach systems

Recent BAS systems move from predefined exploit engines toward LLM-mediated planning and execution. In the Active Directory setting, the cochise prototype introduces a high-level Planner that maintains a Pentest-Task-Tree and a low-level Executor that runs a ReAct-style loop over Linux commands on a Kali VM; self-correction emerges both within the executor through error-and-retry cycles and across Planner→Executor hand-offs (Happe et al., 6 Feb 2025). Five LLM configurations were evaluated, spanning reasoning and non-reasoning models. In two-hour runs, reasoning models compromised approximately twice as many accounts and produced approximately twice as many actionable leads as non-reasoning models, while costs ranged from about \$C_v=\bigl(\mathit{Req}(v),\;\mathit{Env}(v),\;\mathit{Res}(v),\;p_v,\;T_v,\;\mathit{Noise}_v\bigr),$911.6/hr for the hybrid o1+GPT-4o configuration, compared with \$180/hr for human pen-testers (Happe et al., 6 Feb 2025). The system also performed inter-context attacks such as web-app audits, phishing with gophish or SET, and extraction of credentials or hints from unstructured files (Happe et al., 6 Feb 2025).

BreachSeek adopts a graph of LLM-powered agents communicating via LangGraph, with a Supervisor for orchestration, specialized Reconnaissance and Exploitation agents, a Recorder, and an Evaluator that scores outputs as Success, Failure, or Partial and flags hallucinations (Alshehri et al., 2024). The workflow decomposes a user goal into sub-tasks, invokes tools such as nmap, Nikto, enum4linux, and Metasploit, and terminates when a root shell is detected, at which point a PDF report is generated (Alshehri et al., 2024). In a preliminary evaluation on Dockerized Metasploitable 2, the system used about 150k tokens, required about eight minutes end-to-end, and succeeded in all five repeated trials by exploiting vsftpd 2.3.4-backdoor to obtain a root TTY shell (Alshehri et al., 2024).

CyberExplorer reframes BAS evaluation as an open-environment benchmark rather than a closed-world single-target exploit task. It places forty real-world CTF-style web services into one Linux VM, with all containers sharing the same IP address but listening on unique TCP ports, and drives a reactive multi-agent framework through reconnaissance, target selection, and exploitation without exposing vulnerability locations in advance (Rani et al., 8 Feb 2026). Its evaluation suite measures not only true positives, false positives, and false negatives, but also rounds per challenge, time-to-first-flag, average number of executor agents spawned per entrypoint, budget exhaustion rate, agent inflation factor, and persistence ratios for rounds and cost on dead ends (Rani et al., 8 Feb 2026). This shifts BAS benchmarking toward the geometry of exploration: how early correct hypotheses are formed, how often agents escalate on uncertainty, and how much budget is burned on dead ends.

Across these LLM systems, the literature identifies common operational gains and failure modes. Gains include dynamic adaptation of attack strategy, automatic tool installation, command self-correction, and context partitioning across specialized agents (Happe et al., 6 Feb 2025, Alshehri et al., 2024). Failure modes include “rabbit holes,” brittle context transfer between planning and execution, hallucinated goals, and safety violations such as ignoring exclusion rules or proposing social engineering against real victims (Happe et al., 6 Feb 2025). The consensus in this line of work is that human oversight and sandboxing remain mandatory (Happe et al., 6 Feb 2025).

5. BAS as an integrated experimentation and defense-engineering pipeline

One strand of work integrates BAS with Security Chaos Engineering. In the proposed three-layer architecture, the SCE Orchestrator translates user inputs $\mathit{Req}(v)$0 into structured chaos experiments; the Connector standardizes communication with the BAS API; and the BAS layer, implemented with MITRE Caldera, executes atomic abilities through agents such as sandcat RAT (Sánchez-Matas et al., 5 Aug 2025). Attack sequences are not fixed playbooks: the system constructs inferred attack trees from adversary profiles, where each profile is an ordered sequence of abilities and each branch receives a probability score derived from threat-intelligence confidence metrics (Sánchez-Matas et al., 5 Aug 2025). In the reported evaluation on four VMs in a closed LAN, the attack tree contained four lateral-movement branches, producing a Branch Success Rate of $\mathit{Req}(v)$1 and an Attack Surface Coverage of $\mathit{Req}(v)$2; a baseline fixed-profile Caldera run would have covered only 25% of the lateral movement TTPs because it would have stopped at the first failure (Sánchez-Matas et al., 5 Aug 2025).

A second strand closes the loop from BAS findings to deployable detections. The deterministic synthesis pipeline for SIEM rules assumes locked probe corpora, stable probe_id values, and a template library with $\mathit{Req}(v)$3 Sigma skeletons indexed by OWASP LLM and Web Top 10 categories (Maiorano, 3 Jun 2026). A pure function

$\mathit{Req}(v)$4

maps each BAS finding to a starter Sigma rule, with deterministic UUID generation from a SHA256 hash and a bas://finding/<finding_id> back-reference to the originating probe (Maiorano, 3 Jun 2026). On the locked corpora, every bypassed-probe finding yielded a starter rule, and all emitted rules parsed and converted to Splunk and Elasticsearch backends; replay on a live OpenSearch SIEM produced 30% true positives on a held-out AdvBench subset and 14% on HarmBench, with 7.7% false positives on a benign LLM baseline (Maiorano, 3 Jun 2026). This suggests a BAS workflow in which attack simulation is directly coupled to rule authoring and traceable alert provenance.

Cyber-physical BAS extends these ideas beyond enterprise IT. NATI[P]G couples GridLAB-D, NS-3, and HELICS into a containerized co-simulation environment for power-grid cyberattacks, with HELICS federates for the physical layer, communication layer, control center, and optional attacker node (Bel et al., 2023). The framework supports DNP3 message tampering, packet interception and replay, and MITM intrusion, all parameterized through JSON snippets, while collecting packet captures, physical-layer deviations, and threshold-based detection metrics (Bel et al., 2023). In a representative evaluation across $\mathit{Req}(v)$5 independent runs, a simple threshold-based detector achieved approximately $\mathit{Req}(v)$6 and $\mathit{Req}(v)$7 (Bel et al., 2023).

The KNX false-data-injection study occupies a related space at building-control level. It presents a real-world MITM attack on a KNX installation using two Raspberry Pis with KNX-Pi HATs, simulates the impact on HVAC energy consumption, and proposes JSD-based ML detection over telegram inter-arrival times (Cash et al., 2022). Attack-i, with a $\mathit{Req}(v)$8 bias, increased consumption by about 200 kWh or about 15%; Attack-ii, with a constant $\mathit{Req}(v)$9 spoofed temperature, increased consumption by about 150 kWh or about 11% (Cash et al., 2022). Although this work studies a building automation system rather than breach-and-attack-simulation by acronym, it functions as a protocol-specific blueprint for attack-and-detection simulation in operational technology.

6. Metrics, limitations, and recurrent controversies

BAS research employs heterogeneous metrics that reflect distinct underlying substrates. Insight defines AttackerCoverage as compromised hosts over reachable hosts and DetectionRate as expected alarms over expected exploit attempts, with optional virtual IDS modules logging alarms with probability $\mathit{Env}(v)$0 (Futoransky et al., 2010). The SCE-enabled Caldera framework reports Branch Success Rate, Attack Surface Coverage, and Time-to-Detection (Sánchez-Matas et al., 5 Aug 2025). CyberExplorer adds precision, recall, time-to-first-flag, agent inflation factor, and persistence ratios for rounds and cost (Rani et al., 8 Feb 2026). Cyber-physical co-simulation introduces latency, jitter, packet loss, reliability, and physical deviation metrics such as $\mathit{Env}(v)$1, along with $\mathit{Env}(v)$2 and $\mathit{Env}(v)$3 for detectors (Bel et al., 2023). The result is not a single BAS metric standard, but a family of measurement regimes matched to network simulation, autonomous offensive agents, or cyber-physical resilience.

A common misconception is that BAS realism necessarily increases with low-level fidelity. The foundational simulators explicitly reject that premise. Insight and related work focus on realism from the attacker’s standpoint while omitting full CPU emulation, detailed packet switching, and heap state, because their design objective is scalability to hundreds or thousands of hosts on commodity hardware (Futoransky et al., 2010, Sarraute et al., 2010). The debate is therefore not realism versus unreality, but which aspects of realism matter for the evaluation question at hand.

Another recurring tension concerns known exploit chains versus unknown or emerging behaviors. Insight permits simulation of 0-days by injecting them into the same exploit database and populating probabilities such as p_agent or p_crash from large-scale automated QA runs or public vulnerability timelines (Futoransky et al., 2010). By contrast, BreachSeek is limited to known exploit chains and explicitly does not cover zero-days, while the SCE-enabled Caldera architecture is limited to adversary profiles present in MITRE Caldera unless manual profile creation is performed (Alshehri et al., 2024, Sánchez-Matas et al., 5 Aug 2025). This suggests that BAS breadth is often constrained by the expressiveness of the exploit corpus or adversary-profile library.

Autonomous LLM-based BAS introduces a further controversy: whether cost-effective automation can be safely delegated. The published results show that reasoning-capable models can autonomously compromise accounts in a real Active Directory testbed and can do so at a fraction of human cost (Happe et al., 6 Feb 2025). At the same time, the same line of work documents rabbit holes, incomplete information transfer, model brittleness, arbitrary code installation, exclusion-rule violations, and dual-use social-engineering behavior, concluding that human oversight and sandboxing are mandatory (Happe et al., 6 Feb 2025). The issue is therefore not merely technical performance, but operational governance.

Finally, deterministic post-processing of BAS findings raises a trade-off between reproducibility and breadth. The Sigma synthesis pipeline provides exact reproducibility, byte-stable outputs, and typed traceback from alert to originating probe, but it does so by restricting itself to a locked corpus and a finite template library; unseen attack classes without a matching template return null and require manual handling (Maiorano, 3 Jun 2026). This is not a defect of implementation so much as an explicit design choice: governance and auditability are prioritized over unconstrained generative coverage.

Taken together, the literature presents BAS as a layered field: formal attack modeling, scalable simulation, autonomous adversary orchestration, cyber-physical experimentation, and detection engineering. Its unifying principle is controlled adversary emulation with measurable outcomes; its principal methodological divide is between open-ended exploratory systems and tightly governed reproducible pipelines.