01 / THREAT INTELLIGENCE
100 extortion claims, five days
2026-07-31
· Sergio Rodriguez
· ATT&CK: T1078, T1567, T1486
I pulled 100 recent victim records from ransomware.live to see how extortion claims clustered over five days. The records describe postings on crews’ data-leak sites.
100claimed postings
26distinct crews
56%from top 5 crews
58%infostealer association
FINDINGS
- Five crews accounted for 56% of claimed postings in this sample. That concentration belongs to this five-day window.
- 58% of sampled postings carried an infostealer association. The field does not identify how an intrusion began.
- 13% of records quantified claimed data volume. Missing quantities leave incident scope unknown; the aggregator field alone cannot settle it.
- The sample averaged 20 postings per day. The aggregator placed 45% of listed victims in the U.S.
METHOD & LIMITS
Method: one pull of the 100 most recent victim records from ransomware.live on 31 July 2026. Posting dates ran from 27–31 July. I counted that record set and did not visit leak sites.
Limits: one aggregator, 100 records, five days. Crawler gaps and repeated or fabricated claims affect the counts. They measure claimed activity; compromise and a wider trend remain unverified.
Five crews, 56 claims
Of 26 crews, qilin (16), CRPxO (13), thegentlemen (10), safepay (9), and incransom (8) accounted for 56 records. Sixteen crews appeared twice or fewer.
I would use these counts to select claims for closer review. Defensive priorities need the organization’s assets, verified behavior, and a longer observation period.
An association to investigate
The aggregator marked 58 records as infostealer-associated. Did credential theft precede the claimed intrusion, follow it, or have no connection? This snapshot has no incident timeline to answer that.
MITRE ATT&CK T1078 describes adversary use of valid accounts. It gives this inquiry a behavior to look for. Attributing access still needs identity, endpoint, and network records.
Questions for a SOC
The historical sample
The Extortion Economy board requests the same aggregator and may serve a cached snapshot. It shows a separate aggregate view. The original 100-record set is not included here, so these historical totals cannot be independently recomputed from this page. Both views omit victim names and .onion addresses.
02 / LAYOUT DEBUGGING
390 pixels on screen, 780 in the document
2026-08-03
· Sergio Rodriguez
· Target: this site
At a 390px viewport, this site’s document measured 780px wide. It scrolled sideways even though nothing visible crossed the edge. Three elements were contributing to the width.
780pxscrollWidth at 390
3independent causes
1fix that broke sticky nav
0overflow after patch
FINDINGS
- The menu and overlay were invisible contributors. The closed menu used
position:fixed and translateX(100%). The CRT overlay spanned the viewport. Both widened the document without visible pixels outside it.
- The ticker could not shrink. Its flex item inherited
min-width:auto and kept the width of a 628px track. Setting min-width:0 let it fit.
- The first patch broke the nav. Applying
overflow-x:clip to html removed the extra width but broke position:sticky in Chromium. The next assertion caught it. I moved clipping to the elements causing the overflow.
METHOD & LIMITS
Method: a headless Chromium script loaded 390, 768, and 1280px viewports. It compared each element’s scrollWidth and clientWidth, skipping elements inside clipped ancestors. After each patch it checked overflow, sticky navigation, the open menu, and console errors.
Limits: the root-level overflow-x:clip failure was recorded on this site in Chromium. Gecko and WebKit were not checked for that behavior.
The second check mattered
The width check passed while the sticky-nav check failed. Keeping both caught a patch that solved one problem by creating another. The final check covered the menu and console errors too.
03 / PAYMENT VERIFICATION
Check the webhook before it reaches the ledger
2026-08-02
· Sergio Rodriguez
· Cloudflare Workers + Postgres
For a personal project, I built a payment webhook that verifies the request before changing the ledger. A database trigger checks the corresponding verification record before accepting posted revenue.
HMAC-SHA256raw-body signature
300stimestamp tolerance
2enforcement layers
fail-closedunconfigured = 503
FINDINGS
- Keep the raw bytes for verification. The HMAC covers
timestamp.rawBody as received. Parsing follows a successful constant-time comparison.
- Check age and identity separately. A five-minute tolerance rejects stale timestamps. A uniqueness key on the provider’s event ID keeps repeated deliveries to one row.
- Check the posted state in the database. A trigger makes posted revenue immutable and requires a matching signature-verified, live-mode webhook record.
- Missing configuration returns 503. No event is processed without the required secret. Unknown event types are ignored and acknowledged with 200.
METHOD & LIMITS
Method: the recorded unit suite covered invalid and stale signatures, duplicate event IDs, sandbox/live separation, and oversized-payload handling. A deployed-endpoint probe confirmed the 503 path before secrets were installed. The design follows the processor’s signature scheme.
Limits: Stripe’s v1 scheme and a Postgres-specific trigger. Production load and retry behavior were not measured.
Where each check lives
The worker verifies the signature. Postgres enforces the row constraints through a SECURITY DEFINER trigger with a pinned search path and execution revoked from client roles. The design still relies on the permissions used to write the verification record.
DISCLOSURE
Report a problem.
Coordinate a finding.
No coordinated advisories have been published here yet. Assigned identifiers and vendor acknowledgments will accompany a published advisory when available.
Report a problem with this site
Email sergio.w.rdz@gmail.com or use security.txt. I aim to acknowledge within 72 hours, keep you updated, and credit you if requested. I will not pursue legal action for good-faith research within this scope: sergrdz.pages.dev and its subpaths. Denial of service, social engineering, physical attacks, and third-party services are excluded.
When I report a finding
- Authorized scope. I test my own systems, a published bug-bounty or VDP scope, or systems covered by written permission.
- Minimal proof. Confirm the finding and stop. No pivoting, exfiltration, or persistence. Use a read when it is sufficient.
- Private report. Send the root cause, reproduction, affected versions, impact and CVSS assessment, and a proposed fix through the vendor’s VDP or security.txt contact. Use CERT/CC if no channel exists.
- Coordinated timeline. Allow 90 days for a patch, with flexibility for good-faith coordination. Shorten the window only for active exploitation.
- Publication. Publish after a patch or the coordinated window, with a CVE if assigned and vendor acknowledgment if available. Exploit code stays private unless release clearly serves defenders.
SOURCE AND CREDIT
Published studies link to their sources and credit the original work. Private findings stay private through the disclosure process.