Our Edge Sensor Logged SUCCESS Every Hour for 29 Days While Writing Timestamps in the Wrong Unit. Fixed, the Data Says 44% of Blocks Are Two AWS Singapore /24s. GRAYRABBIT's C2 Is Now in the Feed.
Monday morning we swept the headlines, pulled the traffic report, and then did the thing we keep telling you to do: we stopped trusting the green lights and went to look at the data underneath them. Three findings, one fix, one ingest. The order below is the order we found them in.
The sensor that was fine
Our block history lives in a Meilisearch index called block_events. Since May, the only real arrivals in it come from Cloudflare's firewall stream, pulled hourly by a job called block-events-cf-sync. The job's status page has read SUCCESS for every hour of the last 29 days. It really did run. It really did write.
We asked the index a simple question: how many edge blocks in the last 30 days? The answer was 310, and every one of them was dated August 15 or 16. Nothing after. For a site that Cloudflare says blocks several hundred requests a day, that is not a quiet month. That is a dead sensor.
It was not dead. On August 16 we ran a backfill that normalized the numeric event-time field, blockedAtTs, across 2.9 million historical documents, and the backfill wrote milliseconds. The hourly sync job, written the day before, wrote seconds, because a comment said to match the convention of a different index. From August 16 15:46 UTC onward, every new document carried a timestamp a thousand times too small. Any reader asking "since 30 days ago, in milliseconds" saw nothing newer than the backfill. Twenty thousand five hundred and ninety-six documents, all present, all invisible.
The fix is one line in the writer and one scoped batch on the server: 20,596 documents re-normalized in a single task, waited on, read back by primary key, zero seconds-era documents remaining. Then we re-ran the question.
What the fixed data says
20,905 blocks from 2,559 unique IPs. Two adjacent Amazon Singapore /24s, 47.128.119.0/24 and 47.128.45.0/24, account for 9,191 of them, 44 percent of everything the edge stopped in a month. One user-agent string, an Android 5.0 WebKit build that has not shipped on a phone since 2016. Target paths: the blog root and, specifically, the Epstein-file posts. Our own /24 CIDR rule caught 4,857 of them; the custom firewall rules caught the rest. Country facets would tell you Singapore is our biggest adversary. It is not. It is one operator renting one AWS region.
Behind them: MEVSPACE in Poland (1,817), two Google Cloud ranges in Germany and the Netherlands, a French host, and China Mobile. The Palo Alto Networks scanner announces itself in its user-agent and was blocked 347 times anyway. Meta's crawler, 341, which we have written about before as the one real false positive in the shield.
We also faceted the honeypot side. Saudi Arabia shows 3,111 indicators all-time in our IOC index, and every one of them is a wordpress_scan from the edge honeypot inside this window. Lithuania 2,348, the Emirates 987, same family. Moldova is the odd one: 871 config_probe hits, which is the .env and cloud-credential class, not WordPress. The Saudi burst lines up with a one-day spike in Cloudflare's own market-region numbers on September 12. That is not a country attacking us either. That is a scanner fleet with Saudi exit addresses running the same WordPress checklist as the Lithuanian one.
The other lights we checked
The precursor forecast, which we reported in early September was anchored on a legacy threat level and understating the next-step CRITICAL probability by roughly eight times, is now fixed in production. The forecast and the status endpoint start from the same row of the matrix. What is still open: the model has never been scored against base rate. The trainer runs daily, it is honest that its own confidence is LOW, and it has never written a gate. Until it does, the forecast is UNKNOWN, not PASS, and we will keep saying so.
The enrichment cache, which we described in May as a persistent store for AbuseIPDB, VirusTotal, Shodan, GreyNoise and ThreatFox lookups that survives restarts, has zero documents. The cache-stats endpoint shows zero hits and zero misses for every provider since the last boot. A cache with no misses has no callers. Either the enrichment path is not being exercised, or the persistence layer never wired up. Both are on the list; neither is a customer-facing failure today, because the live enrichment endpoint answers correctly without it.
The Butterbot mailbox triage, dead since the August 16 credential split, is still dead. The poll module the container runs still reads the send-only credential. This one is a known, filed, unfixed item and it stays on the ledger until the port ships.
The self-hosted morning sweep landed on its cron, the harvester ran on schedule and flagged one weaponized proof of concept, and the daily GitHub hunt is producing: 315 repositories in the window, mostly Android RATs and token grabbers, plus a cluster of fake Claude and fake OpenAI installers we keep seeing.
The ingest: UNC3569 and GRAYRABBIT
The one real gap in Monday's headline sweep was Gen Digital's September 11 research on a one-click backdoor in Sogou Input Method, the keyboard software with a claimed 455 million monthly users. CVE-2026-51990: a crafted sgbiz: link launches SGMyInput.exe with attacker-controlled arguments, which opens an unvalidated URL in Sogou's embedded Chromium 80, which has no sandbox and has never been patched for CVE-2021-38003, the V8 bug Chrome fixed in October 2021. Google Threat Intelligence attributes the exploitation to UNC3569, a PRC-nexus hacker-for-hire crew tracked since 2021 against government, education, technology and finance targets in East and Southeast Asia. The payload is a backdoor called GRAYRABBIT, delivered by a 7-Zip sideload: legitimate 7z.exe, trojanized 7z.dll, encrypted payload, dropped into C:\Users\Public\Documents, with a process-count anti-analysis check and an NTFS alternate-data-stream self-delete.
We ran every indicator through the corpus before writing. The three SHA-256 hashes were already in our index, all three from ThreatFox, all three unattributed. That is corroboration and we cite it as such; ThreatFox had the files, ThreatFox is free, and anyone pulling ThreatFox was covered on the hashes. The network side was different. The C2 domain mail.uaiubifas.top, the exploit host noht1ng.top and the staging server 8.218.50.207 were in nothing we hold. The staging IP, an Alibaba Cloud Hong Kong box running an end-of-life nginx 1.18, scores zero at AbuseIPDB, is absent from ThreatFox, and VirusTotal has nothing on it. Its nearest dirty neighbors are other Alibaba Hong Kong addresses in the SSL Blacklist, a Cobalt Strike C2 and a GobRAT C2 in the same /16, which is the shape of that ASN, not evidence about this host.
Six records went into the feed under source manual-batch-grayrabbit-unc3569, with actor UNC3569, family GRAYRABBIT, both CVEs, and the Gen Digital and Hacker News references attached. Confidence 85 on the staging IP, 90 on the domains, 95 on the hashes. Each record was written, waited on, and read back by primary key before we counted it. This post is being published with that read-back in hand; if your feed pull after 15:00 UTC on September 14 does not contain mail.uaiubifas.top, tell us, because that would be the next false green.
To be clear about what this is: Gen Digital found it, Google attributed it, ThreatFox had the hashes. We had none of the network indicators until this afternoon. Our contribution is that the C2, the exploit host and the staging server are now in a free STIX, CSV and MISP feed with the actor name on them, three days after publication. That is distribution to the underserved, not detection.
Where this leaves the stance
A sensor with a green light and a wrong unit is worse than a sensor that is off, because nobody goes looking. We found this one by faceting the data on a Monday, not by any alarm. The 30-day arrival count went from 310 to 20,905 in one afternoon, and the story it tells, that a single AWS Singapore tenant is nearly half our block volume, was sitting there the whole time.
If you run a pipeline with numeric timestamps, go check the unit at every writer. Every one.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
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.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=our-edge-sensor-logged-success-every-hour-for-29-days-while-writing-timestamps-in-the-wrong-unit-fi
Comments