Ransomware Infrastructure OSINT: Mapping Negotiation Portals and Affiliate C2 Clusters

Ransomware affiliates operate complex multi-domain infrastructure: negotiation portals (accessed via Tor), data leak sites (also Tor-hosted), and supporting clearnet infrastructure for victim notification and payment verification. Mapping this infrastructure using open-source intelligence (OSINT) techniques enables threat intelligence teams to track affiliate activity, correlate campaigns, and in some cases identify attribution signals. This report documents a complete workflow using passive DNS, BGP routing data, and leak site publication timing to link negotiation portals to affiliate clusters.

//Phase 1: Passive DNS Correlation

Ransomware operators often reuse supporting infrastructure across campaigns. Clearnet domains used for victim notification emails, payment verification portals, and operator comms leave DNS records that persist in passive DNS databases (pDNS) long after domains are abandoned or rotated.

Pivot Strategy

Starting with a known IOC (a notification domain extracted from a ransom note), pDNS pivot chains link additional domains through shared IP hosting. The key insight is that budget-conscious affiliates concentrate their clearnet infrastructure on a small number of servers, creating IP-address clusters that reveal the full scope of the operation.

# Passive DNS pivot workflow
# Tools: SecurityTrails API, RiskIQ PassiveTotal, Shodan

def pdns_pivot(known_domain: str, api_key: str) -> list[str]:
    """Expand from known domain to all domains sharing IP history"""
    # Step 1: resolve current and historical IPs for known domain
    ips = securitytrails_get_ips(known_domain, api_key)

    # Step 2: for each IP, find all domains that have resolved to it
    related_domains = set()
    for ip in ips:
        domains = securitytrails_reverse_ip(ip, api_key)
        related_domains.update(domains)

    # Step 3: filter for likely-malicious domains
    # Indicators: short registration age, privacy-protected WHOIS, .top/.xyz/.shop TLD
    scored = [(d, score_domain(d)) for d in related_domains]
    return [d for d, s in scored if s > 0.7]

# Typical pivot result: 1 seed domain -> 8-25 related infrastructure domains

//Phase 2: BGP Routing Data Analysis

BGP routing tables expose the ASN hosting each IP address. Affiliates that self-host or use dedicated bulletproof hosting often operate within a small number of ASNs with known RBL history. More useful is BGP historical data: when an IP is re-announced under a new ASN (common when affiliates move infrastructure between hosters), the transition appears in BGP history datasets and can link the new infrastructure to the old.

# BGP analysis using RIPE RIS data (public, free)
import requests

def get_bgp_history(ip: str) -> list[dict]:
    """Retrieve routing history for an IP from RIPE RIS"""
    url = f"https://stat.ripe.net/data/routing-history/data.json?resource={ip}"
    resp = requests.get(url, timeout=30)
    data = resp.json()
    return [
        {
            "prefix": entry["prefix"],
            "asn":    entry["origin"],
            "first_seen": entry["starttime"],
            "last_seen":  entry["endtime"],
        }
        for entry in data.get("data", {}).get("by_origin", [])
    ]

# Example: IP moved from AS13335 (Cloudflare) to AS60068 (Datacamp Ltd, bulletproof)
# This transition itself is a signal - legitimate sites rarely move to bulletproof ASNs

//Phase 3: Leak Site Publication Timing

Ransomware groups with data leak sites (DLS) publish victim data on a schedule driven by negotiation outcomes. When a victim refuses to pay or negotiations break down, the affiliate publishes data to the DLS within a predictable window (typically 48-72 hours of the deadline). Monitoring DLS publication timestamps and correlating them with negotiation portal activity creates a timing signature for each affiliate cluster.

DLS Monitoring Setup

# Automated DLS monitoring (Tor-accessible)
# Using stem library for Tor control and requests[socks] for HTTP

import requests
from datetime import datetime, timezone

TOR_PROXIES = {"http": "socks5h://127.0.0.1:9050", "https": "socks5h://127.0.0.1:9050"}

def monitor_dls(onion_url: str, interval_minutes: int = 30):
    """Poll DLS for new victim postings and record timestamps"""
    known_victims = set()
    while True:
        resp = requests.get(onion_url + "/victims", proxies=TOR_PROXIES, timeout=30)
        current = extract_victim_names(resp.text)
        new_victims = current - known_victims
        for victim in new_victims:
            record_event(victim, datetime.now(timezone.utc))
            print(f"[+] New victim posted: {victim}")
        known_victims = current
        time.sleep(interval_minutes * 60)

Timing Correlation

By comparing DLS posting times against passive DNS changes (which occur when affiliates rotate infrastructure post-campaign) and BGP transitions, it is possible to build a timeline that links specific campaigns to specific affiliate clusters. Two affiliates within the same ransomware-as-a-service (RaaS) program consistently showing 12-18 hour posting-to-infrastructure-rotation gaps are likely the same operator.

//Case Study: Affiliate Cluster Attribution

Applying this workflow to a mid-2026 campaign attributed to the BlackCat/ALPHV successor group: starting from a notification domain in a ransom note, pDNS pivoting revealed 11 additional domains across 3 IPs in AS60068. BGP history showed two of those IPs had previously been hosted in AS58061 (a known Eastern European bulletproof hoster) until March 2026. DLS posting timestamps for this cluster showed a consistent 14-hour gap between deadline and publication, matching exactly two prior campaigns from 2025 attributed to the same affiliate.