Triage of a Ransomware Affiliate Indicator Dump
At 09:10 on a Monday, an analyst receives a 4,800-indicator dump from a ransomware affiliate leak: 2,100 domains, 1,600 IPv4 addresses, 900 file hashes, and 200 email addresses. Initial enrichment shows 62% of the domains are already sinkholed by a public resolver, 410 IPs belong to two content-delivery networks, and 280 hashes match unsigned commodity utilities. The team has three days and one junior analyst; leadership tolerates no more than 20% false positives in the blocklist. Two vendor reports attribute the campaign to different affiliates, one citing shared encryptor code and the other citing a unique Tor payment portal. The SOC asks for a blocklist by Wednesday; the incident-response lead wants hunting guidance; the CISO wants to know whether the organization is a target.
1. Design a triage workflow for the 4,800 indicators over three days, including what to discard and what to prioritize.
Read the worked answer
Day one is automated enrichment and deduplication, not manual review. I would normalize the four indicator types, remove exact duplicates and known sinkholes, and tag CDN and shared-hosting IPs. The 410 CDN IPs are unsafe for blocking unless a specific malicious path or domain is identified. The 280 commodity hashes are low priority unless we have a unique compile path or a loader association. The 200 email addresses are not blocklist material; they are fraud-monitoring leads. That leaves a smaller set of domains and IPs for deeper enrichment: passive DNS, WHOIS age, certificate history, sandbox behavior, and internal telemetry.
Prioritization should be by decision utility. Highest priority: domains resolving to actor-controlled infrastructure and IPs with observed C2 ports or beacon patterns. Next: hashes tied to a loader or unique packing, and email addresses used in payment-fraud attempts. Medium: unclassified domains with recent registration. Low: sinkholed domains, CDN IPs, and commodity hashes. Day two focuses on hunting and validation against logs; day three produces a tiered blocklist with confidence and expiration. With a 20% false-positive ceiling, only high-confidence items should be automatically blocked; medium items should alert.
2. How would you assess the competing attribution claims and express confidence?
Read the worked answer
Shared encryptor code is weak attribution evidence because ransomware-as-a-service encryptors are reused across affiliates. A unique Tor payment portal is stronger, but it still may be operated by an affiliate rather than the core group, or reused. I would map the campaign using the diamond model: adversary, capability, infrastructure, and victim. I would compare the two reports' evidence, source access, timestamps, and whether they describe the same victim set and infrastructure. I would then use analysis of competing hypotheses, listing at least three possibilities: affiliate A, affiliate B, or an unattributed affiliate using shared tooling.
My confidence statement would be explicit: 'Low-to-moderate confidence that the campaign is affiliated with the actor cited in report two; the payment portal is distinctive, but shared encryptor code is not diagnostic and we lack independent victimology.' I would avoid naming an actor in the blocklist. I would state what evidence would raise confidence: unique cryptocurrency clustering, reused private infrastructure, operator handles, or independent incident-response corroboration. I would also note the collection cutoff and set a review date. This satisfies the CISO's question without overclaiming.
3. What should the Wednesday blocklist and incident-response hunting guidance contain?
Read the worked answer
The blocklist should be tiered, not a single flat file. Tier 1: high-confidence domains and IPs with observed malicious resolution or C2 behavior; automatic block with a 30-day expiry and an owner. Tier 2: medium-confidence indicators that alert only. Tier 3: context-only items, such as sinkholed domains, CDN IPs, and commodity hashes. Each entry should include indicator type, confidence, first seen, source, and expiration. Email addresses should go to the fraud team for monitoring, not to a network blocklist.
The hunting guidance should focus on behaviors, because the indicator list is incomplete. It should include loader execution patterns, scheduled-task or service creation, beacon jitter, archive creation before encryption, and credential-access attempts. I would give the IR lead prioritized hunts against endpoint and proxy telemetry, with expected false-positive sources. The package should also answer the CISO's question directly: 'We have no current evidence of targeting, but the actor uses commodity tools and our exposure is plausible.' The deliverable is decision support, not just a list.