Adversary Simulation

Adversary Simulation: a practical guide to scenario-driven security validation for OT and critical infrastructure

Adversary simulation is a way to validate security posture by emulating how real attackers move through an environment, end to end, against specific objectives. It is often confused with red teaming or breach and attack simulation (BAS). The difference is focus and fidelity: adversary simulation is scenario-driven and attack-path oriented, designed to test whether an attacker can actually achieve an outcome (for example, deploy ransomware, disrupt operations, access safety systems, or exfiltrate sensitive process data) rather than only whether individual controls or techniques fire.

For critical infrastructure and OT environments, this distinction matters. Traditional testing can be incomplete because production constraints limit what can be exercised safely. Meanwhile, control-check automation can miss the systemic reality of industrial networks: legacy protocols, segmented and partially documented architectures, brittle engineering workstations, vendor remote access, and the operational impact of even minor disruptions.

This guide explains what adversary simulation is, where it fits alongside BAS and red teaming, and how to plan and execute simulations that are safe for OT while still being realistic. It also covers how digital twins enable full-scope testing without touching production systems, and what outcomes you should expect at the end of an engagement.

What is adversary simulation (and why it exists)

Adversary simulation is the practice of emulating realistic attacker behavior against your environment to answer outcome-based questions such as:

• Can an attacker pivot from an initial foothold to our highest-risk OT assets?
• Which specific misconfigurations, trust relationships, and segmentation gaps create the shortest attack paths?
• Would our detections and response actions actually stop the intrusion before the attacker achieves their objective?

Unlike tests that focus on isolated technique execution, adversary simulation is built around complete attack paths. It begins with an attacker objective, then chains together the tactics, techniques, and environmental dependencies required to reach that objective.

In practice, adversary simulation sits between two common approaches:

• BAS and other automated validation tools, which provide repeatable checks but often struggle with environment-specific dependencies and complex lateral movement.
• Red teaming, which can be highly realistic but is typically time-bounded, not continuous, and in OT is often constrained by safety and production limitations.

Adversary simulation exists because many organizations need both realism and repeatability. They need a way to simulate “what would really happen here” while keeping the exercise scoped, measurable, and safe.

For OT and critical infrastructure, adversary simulation is especially useful when you cannot safely execute disruptive actions in production but still need high-confidence answers about exposure, segmentation, and likely blast radius.

A concise definition for security teams

If you need a working definition for internal alignment:

Adversary simulation is a scenario-driven security validation method that emulates real attacker behavior across an environment to validate end-to-end attack paths, detection coverage, and response effectiveness against defined objectives.

Key elements embedded in that definition:

• Scenario-driven: based on credible threat scenarios, business and operational context, and relevant threat actor behaviors.
• End-to-end: covers reconnaissance, initial access, privilege escalation, lateral movement, persistence, and actions on objectives.
• Environment-aware: accounts for your network architecture, identity systems, remote access patterns, and OT constraints.
• Measurable: produces evidence of what was possible, where it was stopped, and what gaps enabled progression.

A good adversary simulation program yields more than “you have X vulnerabilities.” It shows which weaknesses combine into viable paths to the assets that matter.

Adversary simulation vs red teaming vs penetration testing vs BAS

Many security programs use all of these methods. The value comes from understanding where each fits, especially in environments that combine IT and OT.

Penetration testing

• Primary goal: find and prove exploitable vulnerabilities in a defined scope.
• Strengths: depth on specific systems; clear remediation items; often compliance-aligned.
• Limitations: typically not designed to model the full attacker journey or test blue team response; in OT, scope is often narrowed to avoid production disruption.

Red teaming

• Primary goal: emulate a capable adversary to test detection and response, often with stealth and minimal constraints.
• Strengths: realism, pressure-testing people and processes, strong learning value.
• Limitations: time-bounded; may not be repeatable; can be difficult or unsafe to execute fully in production OT; results can be hard to compare over time.

Breach and attack simulation (BAS)

• Primary goal: validate security controls with automated, repeatable tests mapped to known techniques.
• Strengths: automation and repeatability; good for continuous validation of certain detections and controls.
• Limitations: can drift into “checkbox validation” if it does not incorporate environment-specific dependencies; may not model complete attack paths; may underrepresent OT realities.

Adversary simulation

• Primary goal: validate end-to-end attack paths for defined scenarios and objectives, with measurable outcomes.
• Strengths: balances realism and repeatability; focuses on what actually matters (path to impact); can integrate ATT&CK-based technique mapping while staying scenario-first.
• Limitations: requires good scenario design, environment data, and a safe execution model, particularly for OT.

In OT, the key question is not “can technique X run?” but “can an attacker traverse the real boundaries between zones, identity tiers, and engineering systems to reach the process?” That is why adversary simulation emphasizes attack paths and operationally safe execution.

If your team is specifically exploring OT-focused realism, the guide OT Red Teaming: Complete Guide to Adversary Simulation for ICS [2025] provides additional depth on aligning simulations to industrial constraints and adversary behaviors.

Where adversary simulation fits in OT and critical infrastructure

Industrial environments are not just “IT with different devices.” Several characteristics make adversary simulation both more necessary and harder to execute:

• Safety and uptime constraints: You often cannot run disruptive payloads, scans, or configuration changes against production PLCs, HMIs, and historians.
• Legacy and heterogeneity: Older OS versions, unsupported firmware, proprietary protocols, and vendor appliances complicate both defense and testing.
• Segmentation that is partial in practice: OT segmentation is frequently a combination of firewalls, VLANs, jump hosts, vendor access paths, and informal exceptions that create unexpected routes.
• Identity and access complexity: Shared accounts, local admin on engineering workstations, service accounts, and flat domains can turn a minor foothold into broad access.
• Detection gaps: OT telemetry is often incomplete; passive monitoring may be present but not tuned to adversary behavior; incident response in OT can be cautious and slow.

Adversary simulation helps answer OT-specific questions that other methods often miss:

• Which pathways exist between IT and OT, including remote access and “temporary” exceptions?
• What is the shortest practical route to the engineering workstation tier?
• Can ransomware-style actions reach systems that would impact production or recovery?
• Which mitigations reduce risk fastest: segmentation changes, identity hardening, access workflow changes, or monitoring improvements?

The goal is not to generate the most findings. The goal is to identify the most realistic routes to operational impact and validate what actually breaks the chain.

What “realistic attacker behavior” means in practice

Realism in adversary simulation is not about running the most malware-like payload. It is about representing how attackers operate under constraints: imperfect knowledge, opportunistic discovery, and pragmatic trade-offs.

A realistic simulation typically includes:

• Discovery driven by what the attacker can actually see: domain enumeration from a compromised host, mapping reachable subnets, identifying jump hosts and remote access portals.
• Credential-centric progression: targeting weak credential hygiene, cached credentials on engineering workstations, service accounts, and mis-scoped privileges.
• Pivoting based on trust and connectivity, not on an assumed network diagram.
• Living-off-the-land behaviors where appropriate, because many attackers avoid noisy binaries until necessary.
• Objective-based actions, such as gaining access to a historian to exfiltrate process data, reaching an HMI network segment, or deploying ransomware-like behaviors in a way that tests recoverability.

For OT, realistic behavior also includes respecting operational guardrails:

• Avoiding actions that could change controller state or disrupt communications.
• Using replicas, test benches, or digital twins for high-risk steps.
• Coordinating with operations for timing and safety, even when not touching production.

This is where many “simulation” approaches fall short: they focus on technique execution rather than on attacker decision-making across your unique environment.

The core methodology: scenario-first, attack-path validation

A practical adversary simulation methodology can be structured into seven phases. The emphasis is on outcomes, evidence, and repeatability.

1. Define objectives and guardrails

Start with a clear objective statement:

• What outcome are we testing? Examples: “access the engineering workstation tier,” “reach the historian and extract batch records,” “simulate ransomware propagation to determine blast radius and recovery constraints.”
• What are the safety constraints? For OT, define prohibited actions (for example, modifying PLC logic, active scanning on sensitive segments) and where simulations must occur (digital twin versus production).

2. Select credible threat scenarios

Scenarios should be credible for your industry and architecture:

• Initial access via vendor remote access, compromised IT workstation, VPN credential theft, exposed services, or supply chain paths.
• Lateral movement via AD misconfigurations, local admin reuse, weak segmentation, remote management tools.
• Actions on objectives aligned to operational impact.

3. Build the environment model and identify attack paths

Attack paths are not just network routes. They are combinations of:

• Network connectivity and segmentation rules
• Identity relationships and privilege tiers
• Host configurations and exposed services
• Trust relationships (domains, one-way trusts, shared admin accounts)
• Remote access patterns and workflows

The output should be a set of hypothesized paths from initial footholds to high-value assets.

4. Create an emulation plan mapped to ATT&CK where useful

MITRE ATT&CK is valuable for standardization, but it should support the scenario, not replace it. A good plan includes:

• Technique selection that matches the scenario and environment
• Success criteria per step (what evidence proves the step succeeded)
• Expected detections (what should alert, where, and with what context)
• Stop conditions and safety checks

5. Execute safely with instrumentation

Execution should collect evidence to support decisions:

• What was reachable and why
• What credentials were obtained and how (in a safe, authorized manner)
• Which controls blocked movement (network rules, EDR, application allowlisting, MFA)
• Which detections fired and what the SOC saw

6. Analyze outcomes and root causes

Move from “we got in” to “here is why this path existed.” Root-cause analysis should link outcomes to:

• Specific trust misconfigurations
• Identity and privilege design issues
• Segmentation gaps and rule exceptions
• Monitoring and response deficiencies

7. Convert results into a prioritized remediation plan and retest loop

Adversary simulation is most valuable when it becomes a validation loop:

• Fix the highest-leverage gaps
• Re-run the scenario or the critical path segments
• Measure whether the path is broken and whether detections improved

If your organization is looking to scale attack-path work, the concepts in Smarter OT Attack Path Simulation with AI/ML can help frame how to prioritize paths and reduce analysis time without turning the process into generic automation.

MITRE ATT&CK adversary simulation: how to use it without turning it into a checklist

ATT&CK is widely used to structure adversary emulation. The common failure mode is treating it as a menu of techniques to execute.

A more effective approach:

• Start with the scenario and objective.
• Identify the likely sequence of tactics for that objective in your environment.
• Map the sequence to ATT&CK techniques for standard language and coverage tracking.
• Use the map to evaluate detection and response, not as the definition of success.

For example, an OT-relevant scenario might involve:

• Initial access in IT via credential compromise
• Discovery and enumeration of OT-adjacent assets
• Privilege escalation to obtain domain or local admin on a jump host
• Lateral movement to an engineering workstation segment
• Collection from historians or engineering projects
• Ransomware-like encryption simulation in a lab or twin environment to test recovery assumptions

ATT&CK mapping helps you communicate and measure. The simulation still must reflect your actual segmentation, identity tiers, and operational workflows.

FAQs

Is adversary simulation the same as threat emulation?

They are closely related. Threat emulation usually refers to mimicking a specific threat actor’s behaviors and techniques. Adversary simulation is broader: it can emulate specific actors, but it is often framed around scenario-driven objectives and validating complete attack paths, including the environmental conditions that enable them.

How is adversary simulation different from BAS tools?

BAS tools are typically designed for automated, repeatable checks that validate whether specific controls or detections respond to certain techniques. Adversary simulation focuses on whether an attacker can achieve an objective across your environment by chaining steps into an end-to-end path. BAS can support adversary simulation, but a path-focused approach is required to avoid isolated control checking.

Can we do adversary simulation in OT without touching production systems?

Yes, if you use a safe execution model such as a digital twin that represents the OT environment and supports full attack-path testing. This allows you to emulate high-risk steps, including ransomware-like impact and complex lateral movement, without operational risk to production assets.

What should we measure to know if adversary simulation improved our security posture?

Measure outcomes tied to attack paths: which paths to high-risk assets were possible before and after remediation, how many steps were blocked earlier in the chain, whether detections produced actionable alerts with the right context, and whether response actions would have prevented the objective. Improvement is demonstrated when the path is broken or becomes significantly harder, not when a ticket count increases.

Do we need a complete asset inventory and perfect diagrams to start?

No. You need enough data to model and validate the highest-risk paths. Most organizations start with partial inventories, firewall rules, and identity data, then refine the model iteratively. The goal is to produce decision-grade results quickly and improve fidelity over time.

Call to Action

Adversary simulation is most valuable when it validates what matters: whether real attack paths exist to your highest-risk OT assets, and which changes will actually stop an attacker. If you need a safe way to test full-scope scenarios without impacting production, request an OT Security Assessment with Frenos.