Reading the Metadata, Not the Dump: How CTI Analysts Correlate Leak-Forum Posts

A listing appears in your threat-intel feed: “FRESH 2026 — [your company] customer database, 1.2M records, serious buyers only.” The instinct is to find the data and assess the damage. More often than not, the higher-value first move is the opposite: ignore the data entirely and correlate the post metadata. The forum, the handle, the date, the claimed count and the artifacts the seller advertises will usually tell you — in minutes, and without touching a single leaked record — whether this deserves an incident or a shrug.

A defensive, vendor-neutral methodology explainer for security & IT leaders. It describes how CTI analysts triage leak-forum metadata to prioritise threats. It is not an endorsement of accessing leaked data and contains no instructions for finding, downloading or operating on leaks. Examples are illustrative and synthetic.

What “post metadata” actually is

You do not need the dump to triage the claim. A single listing surfaces a predictable set of fields:

• Forum — which marketplace it was posted on.
• Thread title — the seller’s marketing copy (“FRESH”, “MEGA”, “private”).
• Handle — the author’s username.
• Post date — when it was listed.
• Claimed victim and claimed record count — both seller-asserted, both routinely exaggerated.
• Advertised artifacts — the proof-of-life a seller offers: a file hash, a sample-column header (the field names of a few rows, e.g. cust_id,email,pw_md5,city), a PGP key fragment, a contact or an escrow/payment tag.

The artifacts are the load-bearing part. A hash and a sample header are properties of the actual file; a handle and a title are just words. Correlation is the practice of comparing these fields across posts — and against an index of past posts — to establish relationships. Four techniques cover most of the value.

1. Recycled: an old leak sold as new

The highest-frequency trick on leak forums is re-listing old data with a fresh coat of paint. A dump from 2024 reappears in 2026 titled “FRESH,” sometimes with an inflated count (“now 5M!”) to look bigger. The tell is definitive and cheap to check: if the advertised file hash, sample-column header or exact record count is identical to a thread posted long before, the data is not new — a hash cannot change if the file did not.

Why it matters to a defender: the default response to “fresh breach of our company” is an incident-response cycle — team convened, scope assessed, customer notifications drafted, credit monitoring considered, regulators potentially notified. Recognising a two-year-old dump re-listed turns all of that into “this is the 2024 data again, close at low priority.” Recycled-leak detection is the single correlation that most often saves a CISO a wasted, expensive cycle — and it catches the inflated-count variant too, because the hash exposes the real (smaller, older) file under the marketing number.

2. Duplicate: the same dump on two forums

Sellers cross-post to widen their audience. The same file shows up on Forum A and Forum B, often under two different handles and with slightly reworded titles or a “cleaned” lower count. The tell is a matching artifact across forums within a short window: the same file hash and the same sample rows (and sometimes the same magnet/torrent identifier) appearing twice.

Why it matters to a defender: if you count a cross-posted dump as two breaches, your metrics lie. You inflate breach counts, double-book notification work, and can make one seller look like a wave of activity. Merging duplicates on the artifact — not on the differing handles or titles — keeps the record honest and surfaces that both threads trace back to one seller, which feeds the next technique.

3. Alias linkage: two handles, one actor

Actors rotate handles and even change the kind of data they sell to look like several unrelated people. What they reuse — because it is inconvenient to vary — is infrastructure and habit: a PGP key fingerprint, a payment or escrow address/tag, a Tox/Jabber/onion contact, or an ingrained verbal tic or sign-off. A shared selector across two differently-named handles is a strong one-actor link, and it beats soft signals like writing style, which an actor can fake on purpose (formal under one handle, slang under another, both resolving to the same onion mirror and PGP tail).

Why it matters to a defender: correct attribution turns three disconnected ghosts into one tracked profile. You see the actor’s true tempo, their preferred sectors, and the moment they escalate — and you can pivot on a selector (an escrow tag, a fingerprint) to surface the rest of their inventory, including listings that name your vendors.

4. Campaign: a cluster over time

Individually minor listings can add up to a coordinated push. Several victims in one sector posted inside a tight date window — especially with sequential internal batch IDs (CU-001, CU-002, …) or a shared broker/escrow tag across otherwise unrelated-looking posts — is a campaign, not a coincidence. The spread across forums and handles is often deliberate, to hide the pattern from a single-forum view.

Why it matters to a defender: spotting the cluster early — rather than triaging four isolated small listings — lets you raise a sector advisory and warn peers and your ISAC before the campaign’s later batches are posted. For supply-chain cases (a run of managed-service-provider listings, say), the downstream risk to every customer behind each provider makes early recognition the difference between a timely warning and finding out after the access is used.

The discipline that makes it work: don’t over-link

Correlation is as much about refusing false links as finding real ones. Three traps recur:

• A round record count. “1,000,000” is a rounded sales figure, not an artifact. Two dumps that share only a tidy number — but differ in hash, sample schema, sector and handle — are unrelated.
• The same victim named twice. This can be two separate incidents, even a re-breach, when the hashes and sample schemas differ and the posts are months apart. Collapsing them into one hides an active, ongoing exposure.
• The same sector in the same week. Common noise in a busy feed. Without a shared broker, selector or sequential batch IDs, it is coincidence, not coordination — and raising a false campaign advisory erodes trust in your real ones.

The rule underneath all three: link on hard, verifiable artifacts — hash, sample header, selectors — never on a headline or a surface overlap. Do that and the queue stops being noise.

Real-world prior art — credited, and a responsible-use note

This correlation mindset is not ours to claim. The real-world inspiration is security researcher Iván Castañeda (@ivancastl) and his open-source project darkforums-ip-intel, which demonstrates correlating leak-forum activity for CTI. We credit that work and reproduce none of it. Responsible-use note: his dataset contains leak-derived PII and is for authorized CTI research only. Nothing in this article or our lab reproduces real leak data, and this is not an endorsement of accessing leaked data — only of triaging the metadata a sanctioned feed already provides, under your own authorization and legal guidance.

Practise it on synthetic data

We built a free, in-browser Leak-Forum CTI Correlation Lab to drill exactly these four techniques plus the don’t-over-link discipline. You work a queue of cases — each a small set of 100% synthetic post-metadata records (fabricated handles, titles, dates, companies, placeholder hashes, and IPs from the RFC 5737 TEST-NET / RFC 3849 documentation ranges) — and for each you call the verdict (recycled, duplicate, same actor, campaign, or no correlation) and name the selector that decides it. It is graded S–D with a per-case debrief explaining why each call matters to a defender. No real usernames, people, breached company, leaked data, download links or forum URLs appear anywhere; it is a training simulation, not a window onto real forums. Learn to read the metadata, and most “fresh breach” panics resolve before they start.