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.
| Phase | Profiling Activity |
|---|---|
| Planning / Direction | Define the intelligence requirement: “Which APT threatens our sector, and can we detect its TTPs?” |
| Collection | Gather vendor reports, advisories, passive DNS, malware samples |
| Processing | Normalize raw reports; extract candidate TTPs and IOCs |
| Analysis | Map to ATT&CK, assess confidence, resolve naming conflicts |
| Dissemination | Publish as STIX bundle, Navigator layer, and emulation plan |
| Feedback | Refine the profile as new reporting and red-team results arrive |
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.
| Framework | Role in APT Profiling |
|---|---|
| MITRE ATT&CK | Maps observed TTPs to a standardized taxonomy for comparison and emulation |
| Cyber Kill Chain (Lockheed Martin) | Sequences behaviors across reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objectives |
| Diamond Model | Relates the four core intrusion elements: Adversary, Infrastructure, Capability, Victim |
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.
| Source Type | Description |
|---|---|
| Vendor threat reports | Mandiant, CrowdStrike Intelligence, Microsoft MSTIC, Secureworks CTU, Elastic Security Labs, SpecterOps |
| Government advisories | CISA advisories (often with embedded ATT&CK mappings), NSA/CISA joint advisories, FBI Flash |
| MITRE ATT&CK Groups | Curated, attributed group profiles at attack.mitre.org/groups/ |
| Malware repositories | VirusTotal, MalwareBazaar, Hybrid Analysis for tooling attribution |
| Infrastructure / passive DNS | Shodan, Censys, DomainTools, WHOIS/RDAP, certificate transparency logs |
| Code repositories | GitHub/GitLab for leaked tooling and infrastructure-as-code patterns |
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.
| Field | Content |
|---|---|
Actor ID | Canonical tracker (e.g., ATT&CK G0016) |
Aliases | Associated group names and vendor designations |
Nexus | Suspected country of origin / state sponsorship |
Motivation | Espionage, financial, ideological, destructive |
Active Since | First reported activity date |
Targeting | Sectors, geographies, victim profile |
Tooling | Malware families and offensive tools |
Infrastructure Patterns | Registrar habits, ASN clusters, cert reuse, C2 conventions |
ATT&CK Techniques | Normalized technique-ID list with frequency |
IOCs | Hashes, domains, IPs (with confidence and decay date) |
Confidence | Admiralty rating per claim |
Sources | Cited reports with retrieval dates |
ATT&CK’s Group object aligns directly with several of these fields, so anchor your dossier to it.
| Field | Description |
|---|---|
Group ID | Unique identifier (e.g., G0016 for APT29) |
Associated Groups | Publicly reported overlapping names (formerly “Aliases”) |
Description | Activity dates, suspected attribution, targeted industries |
Techniques Used | Techniques with a note on how the group used each |
Software | Malware and tool families attributed to the group |
Campaigns | Named, time-bounded intrusion clusters |
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.
| STIX SDO | Maps To |
|---|---|
threat-actor | Actor identity, aliases, motivation, sophistication |
intrusion-set | Named activity cluster (e.g., “APT29”) |
attack-pattern | An ATT&CK technique via external_references |
malware | Family with malware_types, is_family |
tool | Legitimate software used offensively |
campaign | A time-bounded activity cluster |
indicator | A STIX pattern, e.g. [file:hashes.'SHA-256' = '...'] |
relationship | Links SDOs (uses, attributed-to) |
{
"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.
| Technique | Description |
|---|---|
| Gather identity information | Harvest credentials, emails, employee names (T1589) |
| Gather network information | Enumerate DNS, IP ranges, topology (T1590) |
| Gather org information | Identify roles, business tempo, relationships (T1591) |
| Gather host information | Fingerprint software, hardware, configs (T1592) |
| Search open websites | Social media, search engines, code repos (T1593) |
| Active scanning | Port, vulnerability, wordlist scanning (T1595) |
| Acquire / develop capabilities | Register infra, build or buy tooling (T1583, T1587, T1588) |
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.
| Detection Area | Specifics |
|---|---|
| Web server logs | Scanner user-agents (Masscan, ZGrab); sequential 404 bursts (T1595.003) |
| DNS monitoring | AXFR zone-transfer attempts; unusual PTR sweeps (T1590.002) |
| Honeytokens | Planted career-page emails that fire on first contact (T1589.002) |
| Cert Transparency | Alerts on lookalike-domain issuance (T1583/T1584) |
| Identity logs | Event ID 4624 correlated with 4662 for LDAP/AD enumeration |
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: mediumCentralize 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
| Tool | Description | Link |
|---|---|---|
| MITRE ATT&CK Navigator | Technique heatmaps and layer arithmetic | mitre-attack.github.io |
mitreattack-python | Programmatic ATT&CK STIX queries | github.com |
| MISP | Threat-intel platform, STIX/TAXII ingestion | misp-project.org |
| OpenCTI | Knowledge graph for actors and TTPs | opencti.io |
| Shodan / Censys | Passive internet asset discovery | shodan.io |
| DomainTools / RDAP | WHOIS and passive DNS pivoting | domaintools.com |
| VirusTotal / MalwareBazaar | Tooling attribution from samples | virustotal.com |
15. MITRE ATT&CK Mapping
| Technique | MITRE ID | Detection |
|---|---|---|
| Gather Victim Identity Information | T1589 | Honeytoken email triggers; phishing telemetry |
| Email Addresses | T1589.002 | Planted-address alerting |
| Gather Victim Network Information | T1590 | AXFR / PTR sweep monitoring |
| DNS | T1590.002 | Microsoft-Windows-DNS-Client ETW |
| Gather Victim Org Information | T1591 | LinkedIn exposure review |
| Gather Victim Host Information | T1592 | Web fingerprinting in server logs |
| Search Open Websites/Domains | T1593 | Code-repo secret scanning |
| Search Victim-Owned Websites | T1594 | Anomalous crawl patterns |
| Active Scanning | T1595 | Perimeter scan / 404 burst detection |
| Acquire Infrastructure | T1583 | Cert Transparency lookalike alerts |
| Compromise Infrastructure | T1584 | Passive DNS pivoting |
| Develop / Obtain Capabilities | T1587 / T1588 | Malware-repo attribution |
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
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.
| Type | Audience | Focus | Lifespan |
|---|---|---|---|
| Strategic | C-Suite, Board | Geopolitical risk, sector trends, long-term threat developments; guides policy and investment | Months–years |
| Operational | IR teams, SOC managers | Ongoing or emerging campaigns targeting the org/industry; attacker tools, timelines, objectives | Days–weeks |
| Tactical | SOC analysts, detection engineers | Adversary tactics, techniques, and procedures (TTPs) usable as detection logic | Hours–days |
| Technical | SIEM/EDR feeds, tooling | Atomic indicators: C2 domains, malware hashes, attacker assets, exploited vulnerabilities | Minutes–hours |
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.
| Source Discipline | Abbreviation | Example in CTI Context |
|---|---|---|
| Open-Source Intelligence | OSINT | Vendor blogs, Shodan, VirusTotal, paste sites |
| Human Intelligence | HUMINT | Analyst trust networks, dark-web source engagement |
| Technical Intelligence | TECHINT | Malware sandbox outputs, PCAP analysis |
| Signals Intelligence | SIGINT | Network telemetry, DNS traffic |
| Finished Intelligence | — | Mandiant/CrowdStrike reports, CISA advisories |
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.
| Phase | Key Activity |
|---|---|
| 1. Planning & Direction | Set goals; prioritize intelligence requirements (IRs); define collection scope and process metrics against the org’s threat landscape and resources |
| 2. Collection | Gather data mapped to IRs from public/proprietary feeds, security logs, and network traffic |
| 3. Processing | Normalize and structure raw data — parse logs, deduplicate IOCs, tag STIX objects |
| 4. Analysis | Transform processed data into actionable intelligence; identify patterns, motivations, and impact; produce reports |
| 5. Dissemination | Deliver tailored intelligence to stakeholders — leadership, IT, end-users |
| 6. Feedback | Capture stakeholder input to refine Planning & Direction, closing the cycle |
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.
| Standard | Role |
|---|---|
| STIX 2.1 | Structured Threat Information Expression — how to represent threat data |
| TAXII 2.1 | Trusted Automated Exchange of Intelligence Information — how to exchange it |
| TLP | Traffic Light Protocol — sharing boundaries: TLP:CLEAR, TLP:GREEN, TLP:AMBER, TLP:RED |
| ISO/IEC 27001:2022 Control 5.7 | Mandates a formal threat-intelligence process |
STIX models intelligence as graph objects. STIX Domain Objects (SDOs) are the nodes; STIX Relationship Objects (SROs) are the edges.
| SDO Type | ATT&CK ID Prefix | Description |
|---|---|---|
intrusion-set | G#### | Activity group / threat actor |
attack-pattern | T#### / T####.### | Technique or sub-technique |
malware / tool | S#### | Software used by a group |
campaign | C#### | Time-bounded set of intrusions |
indicator | — | Wraps an IOC with a STIX pattern |
relationship | — | Links SDOs (e.g., uses, targets) |
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.
| Vertex | Worked Example (fictitious “Operation Tidefall”) |
|---|---|
| Adversary | Espionage group “Fictitious Bear” |
| Capability | Macro-laden document → PowerShell stager (T1566.001, T1059.001) |
| Infrastructure | C2 domain cdn-update.example, fronted via web protocols (T1071.001) |
| Victim | Regional energy utility, OT-procurement staff |
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.001Every 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.
| Technique | Description |
|---|---|
| Victim org profiling | Adversary harvests org structure, vendors, and tech stack to tailor lures |
| Identity reconnaissance | Collection of employee emails/roles for spearphishing target lists |
| Phishing for information | Pretext outreach to elicit defensive posture or credentials |
| Feed poisoning | Submitting false IOCs to public feeds to induce defender false positives |
| Infrastructure rotation | Cycling domains/IPs faster than IOC feeds decay, defeating base-tier detection |
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:
| Event ID | Description |
|---|---|
| 1 | Process Create — match against known-bad process names/hashes |
| 3 | Network Connection — match against C2 IP/domain IOCs |
| 7 | Image Loaded — match against malicious DLL hashes |
| 22 | DNS Query — match against malicious domain IOCs |
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.001Program 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
| Tool | Description | Link |
|---|---|---|
| MITRE ATT&CK Navigator | Heat-map technique coverage and group TTPs | attack.mitre.org |
| MISP | Open-source threat-intelligence platform (STIX/TAXII) | misp-project.org |
| OpenCTI | Knowledge-graph TIP for SDO/SRO modeling | opencti.io |
mitreattack-python | Programmatic ATT&CK STIX consumption | github.com |
Sigma / sigma-cli | Generic detection rule format and converter | sigmahq.io |
| STIX 2 (python-stix2) | Build/parse STIX 2.1 bundles | oasis-open.org |
| VirusTotal | Multi-engine IOC enrichment | virustotal.com |
13. MITRE ATT&CK Mapping
| Technique | MITRE ID | Detection |
|---|---|---|
| Phishing | T1566 | Mail gateway logs; attachment detonation |
| Spearphishing Attachment | T1566.001 | Sysmon EventID 1 child of Office app; macro telemetry |
| Web Protocols (C2) | T1071.001 | Sysmon EventID 3/22; proxy/DNS IOC matching |
| OS Credential Dumping | T1003 | LSASS access (EventID 10); EDR memory hooks |
| PowerShell | T1059.001 | Script Block Logging EventID 4104; Sigma attack.t1059.001 |
| Gather Victim Identity Info | T1589 | External recon monitoring; brand exposure alerts |
| Gather Victim Org Info | T1591 | OSINT footprint review |
| Phishing for Information | T1598 | Pretext/elicitation reporting; mail telemetry |
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:REDnever 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