We Claimed a Two-Month Lead. Our Own Timestamp Says We Were One Day Late.
- Patrick Duggan
- 18 hours ago
- 4 min read
On July 16 we published a post with this headline: the FamousSparrow command-and-control server was in our feed since May 14, two months before the report named it.
That is wrong, and the evidence that proves it wrong is our own database record.
What the record actually says
The indicator is a typosquatted SentinelOne domain used as a hard-coded Deed RAT C2 in the FamousSparrow intrusion into Azerbaijani oil and gas. Our record for it carries three fields that settle the question.
The timestamp reads May 14, 2026. The source reads STIX-Ingest. And the description, written at ingest time, reads: FamousSparrow slash UAT-9244 attribution, source bitdefender-azerbaijan-2026-05-13.
Bitdefender published on May 13. We ingested their indicators on May 14.
We were one day behind them, and our own record says so in plain text. We then cited that ingest timestamp as a two-month lead over the vendor whose research produced it.
The post also described Bitdefender as having published "this week." They had published nine weeks earlier.
The second one
On July 14 we ran a post arguing that a warning we issued about UniFi had aged into a receipt within twenty-four hours, because Ubiquiti then disclosed twenty-five more vulnerabilities.
Ubiquiti's Security Advisory Bulletin 066 published on July 2. Our warning was July 13. The disclosure we claimed to have anticipated already existed when we wrote the warning, eleven days earlier.
Same error, different layer. The first is a data problem. The second is an editorial one.
The audit that found them
We ran every falsifiable claim we published over fourteen days against external reality: CISA KEV dates, vendor publication bylines, third-party feed corroboration.
Thirty-one claims that reality can adjudicate. Twenty confirmed. Eight refuted. Three unverifiable.
Seventy-one percent.
Six of the eight refutations are the same mistake: treating an ingest timestamp or a publication date as a detection timestamp without checking what the external comparator actually said.
Four smaller ones are worth naming rather than burying. We said a ColdFusion CVE was the ninth on KEV; it is the sixteenth, and we missed seven older entries. We said CISA added the FortiSandbox vulnerabilities on July 15; the date is July 16, so it was three days to the deadline rather than four. We called a Kaspersky-reported loader "a Russian APT's," when Kaspersky attributed it only at medium confidence with no nation-state origin and victims in Russia, Kazakhstan and Brazil. And we said Everest hit Coca-Cola twice, when the earlier incident hit a Dubai bottling partner rather than Coca-Cola itself.
Two more were factually true but stale in a way that read as current. A Splunk post described exploitation "days after disclosure" without anchoring that the timeline was five weeks old. A UniFi post presented KEV additions from June 23 as happening right now, and re-ran our own June 27 coverage as if it were new.
What held up, since a scorecard needs both columns
The claims that survived are the ones where the receipts were independent of the vendor we were measuring against.
Our strongest was a Lineage infostealer C2 that Arctic Wolf reported on July 13. Our records show it flagged by SSLBL on May 20 at confidence 90, corroborated by ThreatFox on May 26, by community feeds on May 23, and its enclosing network range covered by a Spamhaus listing back in February. Four independent sources, all genuinely preceding the vendor report. That post explicitly declined to claim a scoop, which in hindsight was the correct instinct.
A ColdFusion post beat the KEV listing by five days and openly disclaimed predicting the specific CVE. Typosquats tied to Brass Typhoon were in the feed roughly three months before the July 18 advisory, and that post correctly refused to conflate Brass Typhoon with Salt Typhoon. Our medical-device sector map named its own two misses accurately.
The pattern is clear enough. Every claim that held was one where independent parties had dated the indicator before the comparator existed. Every claim that failed was one where we measured ourselves against a document we had ingested.
The actual defect
Our indicator database has no field distinguishing when we detected something from when we ingested somebody else's detection.
Both land in the same timestamp. A record sourced from our own GitHub hunting looks identical, structurally, to one imported from a vendor PDF. When you then ask "how long has this been in our feed," the answer is technically accurate and completely misleading.
That is not a writing problem that better editing fixes. It is a schema problem that produced a writing problem, and it will keep producing them until the schema changes.
The fix is a detection-type field separating first-party observation from third-party ingest, and a rule that no lead claim ships unless the receipt is first-party or independently corroborated with dates preceding the comparator. The Arctic Wolf post already demonstrates what that looks like when it works.
Why publish this
We measure ourselves on five axes. Novelty, currently 88 percent of sampled indicators absent from ThreatFox. Timeliness, a median 27-day lead on the 30 percent of recent KEV additions we had any receipt for at all. Accuracy, 51 percent of our Spamhaus submissions independently confirmed. Precision, handled by an internal false-positive gate. Liveness, which is currently zero, because no consumer has ever reported one of our indicators firing and we are not going to pretend otherwise.
A vendor who publishes those numbers and then quietly leaves a false lead claim standing has not measured accuracy. They have measured the things that were flattering.
We would rather be the outfit whose corrections you can find. The two-month lead was never real. The one-day lag is in our own record, and it was there the entire time we were claiming otherwise.
Our confidence caps at ninety-five percent as a standing rule, which means something is always wrong. This week it was these eight things.
To err is human. Divinity is neither accepted nor acknowledged.
Free STIX 2.1 threat feed: analytics.dugganusa.com slash stix slash pricing
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.