Back to Services
Adversary Simulation

Validate Your Defences
Against Real Threat Actors

Continuous Breach & Attack Simulation mapped to the techniques of named threat actors. Validate SOC, SIEM and EDR coverage technique-by-technique, then walk away with detection content written against your own telemetry.

20–30 atomics
per monthly cadence
Named-actor TTPs
APT29 · FIN7 · Lazarus
Sigma / KQL / SPL
detection content you keep
Trended heat-map
coverage drift over time

Service overview

Detection coverage is not a yes/no property. It is a per-technique, per-data-source, per-rule property that drifts as your environment changes — agents get redeployed, log pipelines get reshaped, EDR vendors push silent rule updates, threat actors evolve. Adversary simulation is the discipline of measuring that coverage on a defined cadence so the drift is visible before an incident exposes it.

An AxVeil engagement runs a defined ATT&CK technique inventory against your production estate, scored against your existing detection stack. The unit of measurement is the technique-detection pair: did EID 4769 with weak encryption fire when we kerberoasted, did the EDR raise an alert when we dumped LSASS via comsvcs.dll, did the SIEM correlate the OAuth consent grant against the new-application-registration baseline. The output is a heat-map across the ATT&CK Enterprise matrix and a tuning backlog the SOC can work down over the following quarter.

The IBM Cost of a Data Breach Report 2024 measures the global average breach lifecycle (time to identify plus time to contain) at 258 days. Compressing that number is mostly a detection-engineering problem, not a tooling problem — the controls already exist in most organisations; what is missing is the rule, the data source or the analyst playbook that turns telemetry into an alert. Continuous adversary simulation is the feedback loop that closes the gap.

Scope

BAS & purple teaming

  • Continuous ATT&CK technique rotation
  • Threat-actor scenario design
  • Detection rule tuning
  • SOC analyst training exercises
  • Tabletop exercises for the executive team

SOC & SIEM validation

  • Alert fatigue analysis
  • Detection gap mapping
  • MTTD / MTTR benchmarking
  • False-positive reduction
  • Threat-hunting playbooks

EDR / XDR testing

  • Endpoint detection coverage
  • EDR bypass assessment for documented gaps
  • Lateral movement detection
  • Privilege escalation detection
  • Cloud workload protection coverage

Methodology

Five phases mapped to the MITRE ATT&CK Enterprise matrix. The cadence below describes a one-off engagement; the continuous model repeats phases 02–05 monthly with quarterly executive readouts.

01
Threat intelligence & scenario design
Identify the threat actors that materially target your sector. Pull the actor's public TTP profile from the ATT&CK Groups database, Mandiant / CrowdStrike / Microsoft / government CERT advisories. Convert into a campaign brief: techniques, data sources, expected detections, success criteria.
02
Pre-flight & SOC notification
Issue the technique inventory, source IPs, time windows and canary identifiers to the SOC lead. Confirm out-of-band escalation channel. Take baseline telemetry snapshot so technique-fired-and-detected events can be reconciled against the alert log.
03
Simulated execution
Run the campaign through MITRE Caldera, Atomic Red Team, and custom payloads where coverage is thin. Every operator command timestamped and tagged with the ATT&CK technique ID. Where in scope, real C2 frameworks (Sliver, Mythic) used so EDR sees production-grade traffic.
04
Detection reconciliation
Per-technique matrix: fired in environment / alert generated / alert routed / analyst triaged / time-to-detect / time-to-respond. Every miss categorised — telemetry gap, rule gap, routing gap, analyst training gap. Output is a tuning backlog ranked by exploitability and effort.
05
Purple team replay & detection-content hand-over
Joint session with the SOC. Refire each missed technique in the lab, build the Sigma / KQL / SPL / EQL / CQL rule with the analyst, validate it fires, ship it into the production rule pack. Versioned detection-content repository handed back to the customer.

Deliverables

A single PDF report (typically 50–90 pages) plus a versioned detection-content repository. Every claim in the report is backed by a timestamped operator-action log and the corresponding alert (or alert absence) from your SIEM.

Executive summary
Two-to-three pages. ATT&CK coverage heat-map, MTTD / MTTR for the campaign, three highest-leverage detection gaps and the cost-of-fix estimate. Designed for the board and the audit committee.
Per-technique reconciliation
Row-per-technique matrix — fired, alerted, routed, triaged, MTTD, MTTR, root-cause category. Sortable by ATT&CK tactic, by data source, by EDR / SIEM / SOAR layer.
Detection content pack
Versioned repository of Sigma rules, KQL queries (Sentinel / Defender XDR), Splunk SPL, Elastic EQL and CrowdStrike CQL written against your telemetry during the purple-team session and validated by re-firing the technique.
Tuning backlog
Prioritised list of detection gaps with named owners, target dates and effort estimates. Categorised by gap type — telemetry, rule, routing, analyst training. Drives the SOC roadmap.
Operator-action log
Timestamped, ATT&CK-tagged JSON log of every command run during the engagement. Imports cleanly into your SIEM for blue-team replay outside the purple-team session.
Tabletop exercise pack
Optional. Executive and SOC walkthrough of one realistic incident derived from the campaign — decision points, escalation paths, regulator-notification triggers, communications templates.
Sample reconciliation row
{
  "technique": "T1003.001 LSASS Memory",
  "actor_attribution": ["FIN7", "Lazarus"],
  "fired_at": "2026-04-18T09:14:22Z",
  "source_host": "WS-FIN-027",
  "data_source": "Sysmon EID 10",
  "alert_generated": false,
  "gap_category": "rule",
  "remediation": "Ship Sigma rule sysmon_lsass_access_susp; tune for legitimate AV processes.",
  "detection_content_id": "AXV-DET-2026-014"
}

Frameworks & standards

MITRE ATT&CK Enterprise + Cloud + ICSMITRE ATT&CK CalderaAtomic Red TeamSigma rule taxonomyLockheed Martin Cyber Kill ChainNIST SP 800-115CVSS v3.1 + v4.0

Frequently asked questions

How is adversary simulation different from a red team engagement?+

A red team operation is goal-driven and OPSEC-constrained — small white team, defenders blind, single objective. Adversary simulation is detection-driven and collaborative — the SOC knows the campaign is live, the operator runs a defined ATT&CK technique inventory against the environment, and every action is timestamped so the blue team can correlate it against their telemetry. Red team answers "could an attacker reach the objective". Adversary simulation answers "which techniques does our stack catch, which does it miss, and what does the missing detection content need to look like".

Which threat actors and frameworks do you simulate?+

Selection is driven by your sector and intelligence picture, not a generic top-ten list. Financial services typically asks for FIN7, FIN11 and the Lazarus group. SaaS and technology asks for APT29 (Cozy Bear), Scattered Spider and the LAPSUS$ playbook. Industrial environments add Volt Typhoon and Sandworm where ICS / OT is in scope. Every campaign is built from public ATT&CK group profiles plus open-source threat-intelligence reporting (Mandiant, CrowdStrike, Microsoft Threat Intelligence, government CERT advisories) so the techniques exercised are the ones the actor actually uses.

What tooling do you use to run the simulations?+

MITRE ATT&CK Caldera as the primary orchestration framework, Atomic Red Team for atomic-technique coverage, and custom payloads written for techniques where public coverage is thin or signature-burned. Where in scope, we use the same C2 frameworks an attacker would (Cobalt Strike, Sliver, Mythic) so the network and host telemetry your EDR sees matches what a real intrusion would generate. Operator commands are logged with timestamps and ATT&CK technique IDs so the purple-team replay session is line-by-line auditable.

How do you avoid generating false-positive alert storms in production?+

Each campaign opens with a pre-flight call to the SOC lead listing the techniques scheduled, the source hosts, the time windows and the canary identifiers we will embed in payloads. SOC analysts can then triage real-versus-simulated activity in a single query. We also issue a post-campaign reconciliation matrix listing every technique fired, every alert generated, every alert that should have generated and did not, and every false-positive cluster — so the SOC walks away with a tuning backlog rather than a ticket queue.

Do you hand over detection content we can keep?+

Yes. The purple-team phase produces Sigma rules, KQL queries (Microsoft Sentinel / Defender XDR), Splunk SPL, Elastic EQL and CrowdStrike CQL for the techniques the SOC missed or detected late — written against your actual telemetry sources during the joint session, validated by re-firing the technique, and shipped as a versioned detection pack. Those rules are yours to keep, version-control and extend after the engagement closes.

Can adversary simulation run continuously rather than as a one-off?+

Yes. The continuous model runs a rotating ATT&CK technique inventory on a monthly cadence — typically 20-30 atomics per month, prioritised by your threat profile and gap-map, with quarterly purple-team replay sessions. The output is a trended ATT&CK heat-map showing detection coverage drift over time, which is the metric most security leaders find easier to defend to the board than a one-time penetration test snapshot.

Ready to validate your SOC?

Send the threat actors that concern you, the EDR / SIEM stack you operate, and the cadence you want — one-off or continuous. We respond with a fixed-fee proposal and a sample technique-reconciliation matrix from a comparable engagement under NDA.

Request a scoping call →