Correlating Threat Campaigns

When to Use

Use this skill when:

• Multiple unrelated-appearing incidents share IOCs (same C2 IP, same malware hash, similar TTPs)
• An ISAC partner shares indicators from an incident that match your own historical events
• Building a campaign report linking adversary activity over weeks or months to a single operation

Do not use this skill to force correlation based on weak signals — false campaign attribution misleads defenders and wastes resources on incorrect threat models.

Prerequisites

• TIP or SIEM with historical indicator and event data (90+ days recommended)
• MISP correlation engine enabled with event sharing configured
• Graph analysis tool (Maltego, Neo4j, or OpenCTI) for relationship visualization
• Reference to MITRE ATT&CK intrusion set and campaign objects for structuring output

Workflow

Step 1: Collect and Normalize Events

Gather all candidate events for correlation from:

• Internal SIEM (raw events, alert history)
• TIP (historical indicators and events)
• ISAC sharing (partner-submitted events in MISP or TAXII)
• Commercial intelligence (Recorded Future, Mandiant, CrowdStrike reports)

Normalize all events to STIX 2.1 schema with consistent timestamp (UTC), indicator types, and confidence scores. Ensure all indicators have source attribution and collection date.

Step 2: Identify Correlation Pivot Points

Apply systematic pivot analysis across four dimensions:

Infrastructure pivots:

• Same IP address or /24 subnet across events
• Same domain registrant email or WHOIS organization
• Same ASN or hosting provider with same account fingerprint
• Same SSL certificate fingerprint or serial number across C2 domains

Capability pivots:

• Same malware hash or YARA signature match
• Same C2 communication protocol (Cobalt Strike beacon config, Sliver implant parameters)
• Same exploit code or weaponized document template
• Same obfuscation method or packer fingerprint

Temporal pivots:

• Events occurring within same time window (operational hours suggesting same timezone)
• Sequential events with logical kill chain progression
• Malware compilation timestamps clustering in same date range

Victimology pivots:

• Same target sector (healthcare, energy, financial)
• Same target geography
• Same targeted technology (specific ERP vendor, VPN appliance brand)

Step 3: Calculate Correlation Confidence

Apply weighted scoring for campaign attribution:

def calculate_campaign_confidence(events: list) -> float:
    scores = []

    # Infrastructure overlap (highest weight — most discriminating)
    infra_overlap = count_shared_infra(events) / len(events)
    scores.append(infra_overlap * 40)

    # Capability overlap (high weight — TTPs are durable)
    capability_overlap = count_shared_ttps(events) / len(events)
    scores.append(capability_overlap * 35)

    # Temporal proximity (moderate weight)
    temporal_score = assess_temporal_clustering(events)
    scores.append(temporal_score * 15)

    # Victimology alignment (lower weight — many actors target same sector)
    victim_score = assess_victim_pattern(events)
    scores.append(victim_score * 10)

    total = sum(scores)
    if total >= 70: return "HIGH"
    elif total >= 45: return "MEDIUM"
    else: return "LOW"

Step 4: Build Campaign Graph

In OpenCTI or Maltego, construct campaign graph:

• Campaign object (STIX) as central node
• Intrusion Set → uses → Malware objects
• Intrusion Set → uses → Infrastructure objects
• Intrusion Set → targets → Identity objects (victim organizations/sectors)
• Campaign → attributed-to → Threat Actor (if attribution achieved)
• Indicators → indicates → Malware (linking technical observables to capabilities)

Label each relationship with evidence reference and confidence.

Step 5: Produce Campaign Intelligence Report

Structure the campaign report:

1. Campaign name: Assign descriptive codename based on targeting theme or tooling
2. Timeline: First/last observed dates with activity phases
3. Attribution: Suspected threat actor with confidence level
4. Target profile: Industry verticals, geographies, organization sizes
5. TTPs summary: ATT&CK Navigator heatmap for campaign-specific techniques
6. Shared indicators: IOCs that span multiple incidents (highest confidence for blocking)
7. Detection guidance: Sigma/YARA rules specific to this campaign

Key Concepts

Term	Definition
Campaign	STIX object representing a grouping of adversarial behaviors with common objectives over a defined time period
Intrusion Set	STIX object grouping related intrusion activity by common objectives, even when actor identity is uncertain
Pivot	Using a single data point (IOC, infrastructure, TTP) to discover related events or adversary artifacts
Clustering	Machine learning or manual grouping of incidents based on feature similarity to identify campaign boundaries
False Correlation	Incorrect linking of unrelated incidents due to shared infrastructure (CDNs, shared hosting) or common tools

Tools & Systems

• MISP Correlation Engine: Automatic correlation of events sharing attribute values across the MISP instance and federated instances
• OpenCTI Graph: Interactive relationship graph for visualizing campaign linkages with STIX object types
• Maltego: Link analysis for infrastructure and capability pivoting across multiple data sources
• Neo4j: Graph database with Cypher queries for large-scale campaign correlation (millions of events)

Common Pitfalls

• CDN/Shared hosting false positives: Cloudflare, AWS CloudFront, and bulletproof hosters serve multiple threat actors. Shared IP alone does not establish campaign linkage.
• Common malware conflation: Multiple threat actors use Cobalt Strike. Shared capability does not indicate same actor without additional corroboration.
• Premature attribution: Forcing campaign-to-actor attribution before evidence threshold is reached produces incorrect intelligence that persists in reports.
• Missing temporal analysis: Events from different years may share infrastructure that was recycled by a different actor, not the same campaign.

Verification Criteria

Confirm successful execution by validating:

• [ ] All prerequisite tools and access requirements are satisfied
• [ ] Each workflow step completed without errors
• [ ] Output matches expected format and contains expected data
• [ ] No security warnings or misconfigurations detected
• [ ] Results are documented and evidence is preserved for audit

Compliance Framework Mapping

This skill supports compliance evidence collection across multiple frameworks:

• SOC 2: CC7.1 (Monitoring), CC7.2 (Anomaly Detection)
• ISO 27001: A.6.1 (Threat Intelligence), A.16.1 (Security Incident Management)
• NIST 800-53: PM-16 (Threat Awareness), RA-3 (Risk Assessment), SI-5 (Security Alerts)
• NIST CSF: ID.RA (Risk Assessment), DE.AE (Anomalies & Events)

Claw GRC Tip: When this skill is executed by a registered agent, compliance evidence is automatically captured and mapped to the relevant controls in your active frameworks.

Deploying This Skill with Claw GRC

Agent Execution

Register this skill with your Claw GRC agent for automated execution:

# Install via CLI
npx claw-grc skills add correlating-threat-campaigns

# Or load dynamically via MCP
grc.load_skill("correlating-threat-campaigns")

Audit Trail Integration

When executed through Claw GRC, every step of this skill generates tamper-evident audit records:

• SHA-256 chain hashing ensures no step can be modified after execution
• Evidence artifacts (configs, scan results, logs) are automatically attached to relevant controls
• Trust score impact — successful execution increases your agent's trust score

Continuous Compliance

Schedule this skill for recurring execution to maintain continuous compliance posture. Claw GRC monitors for drift and alerts when re-execution is needed.