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.

WRITEUP 002 · WEB FORENSICS

The invisible 780 pixels: hunting phantom width on this exact site

This site scrolled sideways on phones. Nothing visible crossed the edge, but at a 390px viewport the document measured exactly 780px wide — a suspiciously clean 2x. Since the target was my own production site, I treated it like any other incident: measure first, patch at the source, prove the fix, and write down what the tooling got wrong on the way.

Why this belongs on a security portfolio

The workflow is the point, not the CSS. An invisible fault, a measurement harness instead of guesswork, a plausible fix that failed under test, and a root-cause patch proven by re-running the whole suite — that is incident response, practiced somewhere cheap. The bug that teaches you to distrust "looks fixed" costs nothing here and everything in production forensics.

WRITEUP 003 · DEFENSIVE ENGINEERING

A webhook that assumes it is being lied to: payment-event ingestion under adversarial assumptions

A payment processor's webhook endpoint is an unauthenticated URL on the public internet that, if believed naively, writes revenue into your database. I built and shipped one for a personal project on the assumption that every request reaching it is hostile until proven otherwise, and then made the database enforce the same assumption independently, so that even a compromised application layer cannot post a lie as money.

The layering argument

Signature verification lives in the worker; integrity enforcement lives in the database as a SECURITY DEFINER trigger with a pinned search path and execute revoked from client roles. The two layers share no code and fail independently, which is the property that matters: the attacker who beats one control has learned nothing about the other. Defense in depth is usually a slogan; in a schema it can be a constraint.

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.