Agent Skills: Executing Diamond Model Analysis

Executing Diamond Model Analysis

When to Use

Use this skill when:

• Analyzing a confirmed intrusion to understand the complete adversary-capability-infrastructure-victim relationship
• Attempting to link two or more incidents to a common threat actor using shared infrastructure or capability indicators
• Structuring a finished intelligence product that explains adversary behavior in a formal analytic framework

Do not use this skill during active incident containment — Diamond Model analysis is a post-event or concurrent intelligence activity, not a response procedure.

Prerequisites

• Completed incident investigation data: logs, forensic artifacts, malware samples, network captures
• Access to MITRE ATT&CK, VirusTotal, Shodan, and passive DNS databases for vertex enrichment
• Link analysis platform (Maltego, Analyst's Notebook, or graph database like Neo4j) for multi-event correlation
• Familiarity with the original Diamond Model paper: Caltagirone, Pendergast, Betz (2013)

Workflow

Step 1: Populate the Four Core Vertices

Adversary Vertex: Who conducted the activity?

• Operator (direct keyboard access) vs. Customer (who commissioned the attack) distinction
• Attribution confidence level (Low/Medium/High) with supporting evidence
• Known aliases, ATT&CK Group ID, sector targeting history

Capability Vertex: What tools and techniques were used?

• Malware families: names, YARA signatures, behavioral characteristics
• Exploits: CVEs exploited, exploit kit identifiers
• ATT&CK techniques employed (T-numbers)
• Capability sophistication: commodity (off-shelf) vs. custom-developed

Infrastructure Vertex: What systems were used to conduct the attack?

• C2 servers: IPs, domains, hosting providers, certificate fingerprints
• Delivery infrastructure: phishing domains, watering holes, compromised servers
• Operational relay boxes (ORBs): intermediate proxies obscuring true origin

Victim Vertex: Who/what was targeted?

• Organization profile: sector, size, geography, technology stack
• Personae: specific individuals targeted (CISO, finance team, executives)
• Assets targeted: intellectual property, financial systems, OT/ICS

Step 2: Identify Vertex Relationships (Edges)

Document relationships between vertices:

• Adversary → uses → Capability (malware development/deployment relationship)
• Adversary → uses → Infrastructure (operational relationship)
• Infrastructure → delivers → Capability (technical delivery mechanism)
• Capability → targets → Victim (attack surface relationship)
• Infrastructure → attacks → Victim (direct connection)

Each edge should be supported by at least two independent data points (evidence-backed, not inferred).

Step 3: Apply Meta-Features for Enrichment

Meta-features provide additional context beyond the four vertices:

Timestamp: When did each phase of the intrusion occur? Map to cyber kill chain phases.

Phase: Which kill chain phase does this activity represent?

• Reconnaissance → Weaponization → Delivery → Exploitation → Installation → C2 → Actions on Objectives

Direction: Attack direction (external-to-internal, internal-to-external for exfiltration)

Result: Outcome of each adversary action (success/failure/partial)

Resources: Adversary resources invested (time, money, infrastructure cost, zero-day usage)

Step 4: Cluster Events Using Vertex Pivoting

Apply Diamond Model pivoting logic to cluster related incidents:

• Infrastructure pivot: Same C2 IP across multiple incidents → same or related adversary
• Capability pivot: Same malware hash or YARA signature → same tool developer
• Adversary pivot: Same victimology pattern (sector + geography + asset type) → same targeting criteria
• Victim pivot: Same victim across multiple incidents → sustained campaign against organization

Incident A: IP 185.220.101.x, domain evil-redir[.]com, SUNBURST malware variant
Incident B: IP 185.220.101.y (same /24), domain redir-evil[.]com, modified SUNBURST
→ Infrastructure cluster (same /24 block) + Capability cluster (same malware family) = High confidence same actor

Step 5: Produce Structured Analytic Output

Document analysis in structured format:

• Diamond event diagram for each discrete intrusion event
• Activity thread connecting multiple events across time
• Activity group (cluster) with confidence assessment
• Competing hypotheses analysis: alternative attribution explanations with evidence weighting (ACH methodology)

Key Concepts

| Term | Definition | |------|-----------| | Diamond Model | Intrusion analysis framework with four vertices (adversary, capability, infrastructure, victim) connected by edges representing relationships | | Activity Thread | A time-ordered sequence of Diamond events representing a single adversary operation | | Activity Group | A cluster of Diamond events linked by shared vertex properties, suggesting a common adversary | | Adversary Operator vs. Customer | Diamond Model distinction: operator has keyboard access; customer directs/funds the operation | | Pivoting | Using a known vertex value to discover additional related events or infrastructure (e.g., one IP revealing 20 more C2 domains) | | ACH | Analysis of Competing Hypotheses — structured analytic technique for evaluating evidence against multiple attribution hypotheses |

Tools & Systems

• Maltego: Graph-based link analysis ideal for visualizing Diamond vertex relationships and infrastructure pivots
• Neo4j: Graph database for storing and querying complex Diamond event clusters at scale; supports Cypher query language
• MISP: Diamond Model meta-feature tagging supported via MISP galaxies and correlation engine
• Analyst's Notebook (IBM i2): Law enforcement/intelligence-grade link analysis for adversary relationship mapping

Common Pitfalls

• Conflating operator and customer: Not distinguishing between who conducted the attack and who directed it leads to incorrect attribution targeting.
• Infrastructure re-use assumption: Bulletproof hosting providers sell the same IP blocks to multiple criminal groups. Shared IP ≠ same actor without additional corroboration.
• Analysis without confidence levels: Diamond Model conclusions presented without confidence qualifiers appear more certain than the evidence supports.
• Ignoring the victim vertex: Analysis often over-focuses on adversary/capability and neglects victim characterization, which provides crucial context for predicting future targeting.
• Static diagrams: Diamond events should be time-stamped and evolve as new evidence emerges. Static diagrams without version history mask analytic evolution.