Analysis, measured from primary sources

WRITEUP 001 · THREAT INTELLIGENCE

26 crews, five days: the infostealer-to-extortion pipeline in primary leak-site data

Ransomware crews publish their victims on Tor-hosted data-leak sites (DLS) to apply pressure. That publication is also, unintentionally, one of the earliest public signals available to defenders, typically landing hours to days before press coverage. I pulled the 100 most recent DLS postings and counted what was actually in them.

The concentration finding

Twenty-six distinct crews appeared, but the distribution had a long tail and a heavy head: qilin (16), CRPxO (13), thegentlemen (10), safepay (9), and incransom (8) together produced 56 of 100 postings. Sixteen crews posted twice or fewer.

The defensive implication is a prioritization argument. A small team cannot build detection coverage against twenty-six adversaries, and this data says it does not need to. Emulating the top five operators' known TTP sets addresses the majority of realistic exposure, which is a defensible way to spend a limited detection-engineering budget.

The pipeline finding, and why it matters more

The more interesting number is 58%: the share of postings carrying an infostealer association. That points at a supply chain rather than a single actor. Commodity infostealers harvest credentials and session cookies at scale, those land in marketplaces, initial-access brokers resell them, and extortion crews buy access already authenticated.

This lines up with what vendor telemetry has been reporting from the other end of the funnel, that the large majority of detections now involve no malware at the intrusion point at all, because the operator simply logs in. If most extortion begins with valid credentials (T1078), then perimeter and payload controls are guarding a door the adversary is not using.

What this changes in a SOC

Reproducing this

The aggregate view is live on the dossier's Extortion Economy board, refreshed hourly from the same source. That board and this writeup both withhold victim names and .onion addresses by design: naming targets serves the crews' pressure campaign and adds nothing the counts do not already carry.

FILE 04b · VULNERABILITY DISCLOSURE

How I handle a vulnerability, mine or yours

If you found something in my systems

Report it to sergio.w.rdz@gmail.com, or use the contacts in my security.txt. I will acknowledge within 72 hours, keep you updated, credit you publicly if you want credit, and I will not pursue legal action against good-faith research that stays within the boundaries below. In scope: sergrdz.pages.dev and its subpaths. Out of scope: denial of service, social engineering, physical attacks, and anything touching third-party services I do not control.

My process when I find something in someone else's

1. Authorization first. I test only what I own, what a published bug-bounty or VDP scope permits, or what I have written permission for. No exceptions, and no "it was only a scan."
2. Minimum necessary proof. Establish the finding is real, then stop. No pivoting, no data exfiltration, no persistence. If I can prove it with a read, I do not attempt a write.
3. Private report to the vendor. Root cause, reproduction steps, affected versions, assessed impact with a CVSS vector, and a suggested remediation. Sent through their VDP, security.txt contact, or CERT/CC if no channel exists.
4. Coordinated timeline. Standard 90 days to patch, flexible when a vendor is engaging in good faith, shortened only if the flaw is already being exploited in the wild.
5. Publish after the fix. Writeup goes public once a patch ships or the coordinated window closes, with the CVE identifier and vendor acknowledgment. Exploit code stays unpublished unless releasing it clearly serves defenders more than attackers.