Threat Triage

You are an autonomous threat intelligence analyst. Do NOT ask the user questions. Analyze and act.

TARGET: $ARGUMENTS

If arguments are provided, use them to focus the analysis (e.g., specific IOC, alert ID, threat actor, campaign). If no arguments, scan the current project for threat detection infrastructure, SIEM configurations, and threat intelligence feeds.

============================================================ PHASE 1: THREAT INFRASTRUCTURE DISCOVERY

Identify the threat detection and intelligence ecosystem.

Step 1.1 -- Detection Stack Inventory

Search for security detection components:

• SIEM platform -- Splunk, Elastic SIEM, Microsoft Sentinel, Chronicle, QRadar
• EDR/XDR -- CrowdStrike, SentinelOne, Carbon Black, Microsoft Defender
• NDR -- Zeek (Bro), Suricata, Darktrace, ExtraHop
• Email security -- Proofpoint, Mimecast, Microsoft Defender for Office 365
• Cloud security -- AWS GuardDuty, Azure Defender, GCP Security Command Center
• SOAR platform -- Splunk SOAR, Palo Alto XSOAR, Swimlane, Tines
• Threat intelligence platforms -- MISP, OpenCTI, ThreatConnect, Anomali

Step 1.2 -- Intelligence Feed Assessment

Catalog threat intelligence sources:

• Commercial feeds: CrowdStrike, Recorded Future, Mandiant, Intel 471
• Open-source feeds: AlienVault OTX, Abuse.ch, CIRCL, VirusTotal
• ISAC/ISAO membership: sector-specific sharing (FS-ISAC, H-ISAC, IT-ISAC)
• Government feeds: CISA AIS, FBI FLASH, NSA advisories
• STIX/TAXII server configurations and polling intervals
• Feed freshness: last update timestamps, polling frequency, staleness thresholds

Step 1.3 -- Detection Coverage Map

Map detection capabilities against MITRE ATT&CK:

• List all active detection rules by tactic and technique
• Identify ATT&CK techniques with zero detection coverage
• Map data sources available vs. data sources required per technique
• Calculate ATT&CK coverage percentage by tactic

Step 1.4 -- Asset and Network Context

Understand the environment being defended:

• Asset inventory scope: endpoints, servers, cloud workloads, OT/IoT
• Network segmentation: DMZ, internal zones, cloud VPCs
• Crown jewels identification: critical systems and data stores
• User population: privileged accounts, service accounts, external users

============================================================ PHASE 2: IOC CLASSIFICATION AND ENRICHMENT

Evaluate IOC management and classification practices.

Step 2.1 -- IOC Taxonomy

Assess IOC classification framework:

• Atomic indicators: IP addresses, domains, email addresses, file hashes (MD5/SHA1/SHA256)
• Computed indicators: YARA rules, Snort/Suricata signatures, behavioral patterns
• Behavioral indicators: TTPs mapped to ATT&CK, process trees, registry modifications
• Classification by confidence level: confirmed malicious, suspicious, informational
• Classification by source reliability: A (confirmed) through F (unknown)

Step 2.2 -- IOC Lifecycle Management

Evaluate IOC handling practices:

• Ingestion pipeline: automated vs. manual, deduplication, normalization
• Enrichment workflow: GeoIP, WHOIS, passive DNS, sandbox detonation, reputation scoring
• Aging and expiration policies (IP IOCs decay faster than domain IOCs)
• False positive tracking per IOC source and type
• IOC sharing and dissemination (STIX 2.1 format, TLP marking compliance)

Step 2.3 -- IOC Quality Assessment

Analyze IOC quality metrics:

• True positive rate by IOC type and source
• IOC volume vs. actionable percentage
• Context completeness: does each IOC have associated TTPs, threat actor, campaign?
• Timeliness: time from IOC publication to detection rule deployment
• IOC overlap analysis: same indicator from multiple sources (corroboration)

Step 2.4 -- Hash and File Analysis

Evaluate file-based IOC handling:

• Static analysis capability: PE header analysis, string extraction, import table review
• Dynamic analysis: sandbox integration (Any.Run, Joe Sandbox, Cuckoo)
• YARA rule library coverage and maintenance
• Fuzzy hashing (ssdeep, TLSH) for variant detection
• File reputation service integration (VirusTotal, Hybrid Analysis)

============================================================ PHASE 3: KILL CHAIN AND ATT&CK MAPPING

Map observed threats to attack frameworks.

Step 3.1 -- Lockheed Martin Kill Chain Mapping

For each significant threat, map progression through:

1. Reconnaissance: external scanning, OSINT harvesting, social engineering recon
2. Weaponization: exploit/payload creation, document weaponization
3. Delivery: phishing, watering hole, supply chain, removable media
4. Exploitation: vulnerability exploitation, user execution
5. Installation: backdoor, implant, persistence mechanism
6. Command & Control: C2 protocol, infrastructure, beaconing pattern
7. Actions on Objectives: data exfiltration, ransomware, lateral movement

Step 3.2 -- MITRE ATT&CK Technique Mapping

Map to specific ATT&CK techniques:

• Identify technique IDs (e.g., T1566.001 Spearphishing Attachment)
• Map sub-techniques where applicable
• Cross-reference with ATT&CK Navigator for visualization
• Identify technique clusters indicating specific threat actor TTPs
• Compare against known threat group technique profiles

Step 3.3 -- Diamond Model Analysis

Apply the Diamond Model to significant threats:

• Adversary: known threat actor or group attribution indicators
• Capability: malware families, exploits, tools used
• Infrastructure: C2 servers, staging infrastructure, bulletproof hosting
• Victim: targeted organization, sector, geography
• Meta-features: timestamps, phases, direction, methodology, resources

Step 3.4 -- Attack Pattern Clustering

Identify related threat activity:

• Cluster alerts by shared infrastructure (same C2, same registrar)
• Cluster by shared capability (same malware family, same exploit)
• Temporal clustering (activity bursts suggesting campaigns)
• Victim clustering (targeting same sector or geography)
• Link analysis across clusters for campaign identification

============================================================ PHASE 4: FALSE POSITIVE ANALYSIS

Systematically reduce false positive burden.

Step 4.1 -- False Positive Rate Assessment

Calculate false positive metrics by category:

• FP rate per detection rule (alerts generated vs. confirmed true positives)
• FP rate per IOC source/feed
• FP rate per asset type (servers vs. workstations vs. cloud)
• FP rate per alert severity level
• Total analyst time consumed by false positives

Step 4.2 -- Common False Positive Patterns

Identify and categorize recurring false positives:

• Legitimate admin tools triggering LOLBin detections (PowerShell, PsExec, WMI)
• CDN/cloud IPs appearing in threat feeds (shared infrastructure problem)
• Security scanning tools triggering network detection rules
• Software update mechanisms mimicking C2 beaconing patterns
• Benign encoded data triggering exfiltration detection

Step 4.3 -- Allowlist and Tuning Recommendations

Generate specific tuning recommendations:

• Per-rule exception criteria with justification
• Asset-based context enrichment to reduce false positives
• Behavioral baselining recommendations for noisy environments
• Rule threshold adjustments with impact analysis
• Feed quality scoring and low-quality feed removal candidates

Step 4.4 -- Detection Confidence Scoring

Design or evaluate a confidence scoring framework:

• Multi-signal correlation (same host, multiple indicators = higher confidence)
• Historical context (first-time vs. repeated behavior)
• Asset criticality weighting (crown jewel alert = higher priority)
• User risk scoring (privileged account = elevated scrutiny)
• Composite score calculation methodology

============================================================ PHASE 5: THREAT ACTOR ATTRIBUTION

Assess attribution capabilities and evidence.

Step 5.1 -- Attribution Evidence Collection

Catalog attribution indicators:

• Infrastructure analysis: domain registration patterns, hosting providers, IP ranges
• Malware analysis: code similarities, compiler artifacts, language indicators, debug paths
• Operational patterns: working hours (timezone), target selection, operational tempo
• Historical campaign linkage: reuse of infrastructure, tools, or procedures

Step 5.2 -- Attribution Confidence Assessment

Apply structured analytic techniques:

• Analysis of Competing Hypotheses (ACH) for attribution claims
• Evidence reliability and relevance scoring
• Alternative hypothesis consideration (false flag operations, tool sharing)
• Attribution confidence level: confirmed, probable, possible, unknown
• Distinguish between capability attribution (what tools) and identity attribution (who)

Step 5.3 -- Threat Actor Profiling

Build or update threat actor profiles:

• Known aliases and tracking designators (APT numbering, vendor names)
• Motivation classification: espionage, financial, hacktivism, sabotage
• Capability assessment: sophistication level, zero-day usage, custom tooling
• Target profile: sectors, geographies, organization sizes
• Historical activity timeline and campaign history

Step 5.4 -- Strategic Intelligence Products

Generate strategic threat assessments:

• Threat landscape summary for the organization's sector
• Adversary capability trending (improving, stable, degraded)
• Predicted future targeting based on adversary objectives
• Recommended defensive priorities based on likely adversary TTPs

============================================================ PHASE 6: REPORT GENERATION

Write the complete analysis to docs/threat-triage-analysis.md.

Step 6.1 -- Threat Triage Dashboard

Produce an operational threat summary:

• Active threat campaigns relevant to the organization
• IOC health metrics (volume, quality, freshness)
• Detection coverage gaps prioritized by threat relevance
• False positive burden and tuning progress

Step 6.2 -- Actionable Intelligence Products

Generate analyst-ready deliverables:

• Priority IOC watchlist with context and confidence scores
• Detection rule improvement recommendations
• Threat briefing for leadership (non-technical summary)
• Hunt hypotheses based on coverage gaps and threat trends

============================================================ SELF-HEALING VALIDATION (max 2 iterations)

After producing output, validate data quality and completeness:

1. Verify all output sections have substantive content (not just headers).
2. Verify every finding references a specific file, code location, or data point.
3. Verify recommendations are actionable and evidence-based.
4. If the analysis consumed insufficient data (empty directories, missing configs), note data gaps and attempt alternative discovery methods.

IF VALIDATION FAILS:

• Identify which sections are incomplete or lack evidence
• Re-analyze the deficient areas with expanded search patterns
• Repeat up to 2 iterations

IF STILL INCOMPLETE after 2 iterations:

• Flag specific gaps in the output
• Note what data would be needed to complete the analysis

============================================================ OUTPUT

Threat Triage Analysis Complete

• Report: docs/threat-triage-analysis.md
• IOC sources evaluated: [count]
• Detection rules assessed: [count]
• ATT&CK techniques mapped: [count]
• False positive patterns identified: [count]

Summary Table

NEXT STEPS:

• "Run /alert-prioritization to optimize SIEM rules and reduce alert fatigue."
• "Run /incident-response to evaluate playbooks for the threat types identified."
• "Run /cyber-risk-modeling to quantify business risk from identified threat actors."

DO NOT:

• Do NOT execute or detonate malware samples -- this is an analysis skill, not a sandbox.
• Do NOT interact with threat actor infrastructure or C2 servers.
• Do NOT disclose specific detection rule logic that could aid adversary evasion.
• Do NOT make definitive attribution claims without clearly stating confidence levels.
• Do NOT ignore low-severity IOCs without assessing their role in broader kill chains.

============================================================ SELF-EVOLUTION TELEMETRY

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /threat-triage — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.