We Held 36 Campaign Indicators a Median 34 Days Early. Our Own Edge Blocked Almost None of Them.
We went back through every campaign we wrote up between September 1 and October 19, 65 of them, and asked one question of each indicator: was it already in our index before we wrote about it? For 36 of them it was, a median 34 days earlier. And 34 of those 36 sat at a confidence score low enough that our own edge never blocked them. We held the shape. We did not act on it. Here is what that looks like, what we built today because of it, and the two times our own security review stopped us from making it worse.
What we checked
Every campaign we covered gets its indicators ingested under a named batch, so the set is easy to pull: 65 batches, 1,952 distinct IPs, domains and URL hosts. For each one we searched the rest of the index for the same value, or for an IP in the same /24, recorded before our campaign batch went in. Hashes and packages were not part of this pass, so for those two the answer is unknown, not zero.
"Early" here means early against our own write-up date, not against the vendor's report, which usually came out a few days before we wrote. And none of the early records are ours. They came from ThreatFox (19), TweetFeed (9), URLhaus (6) and OpenPhish (2). The people who submitted them deserve the credit. Our part is that we carried their records, and the question this post is about is what we did with them.
The shape shows up before the name does
The early records almost never named the actor. ThreatFox listed a C2 from the AOMEI Backupper campaign as an AdaptixC2 server on June 22, almost four months before our write-up attributed it to UNC7017. Two DarkSword addresses were listed as a Sliver server and an "Unknown malware" host. CyberXero's infrastructure was VShell and Cobalt Strike. The label was the tool, not the operator. That is the shape: a C2 framework on a cheap VPS, reported by somebody who scans for them, weeks before the campaign gets a name.
Two cases from today's chain analysis show how much that matters. GhostAction's exfiltration server, 193.32.204[.]199, went into our feed on October 11. The "copycat" wave reported on October 16 used the same server with new campaign markers, so anyone blocking the IP lane had that wave's exfil cut off five days before it was reported. And PoeLLM's C2, 5.78.73[.]122, sat in URLhaus as a Mirai download host from June 13, almost four months before Lumen's report on the campaign. Trellix made the same point in its September hunting report: reused infrastructure is often what surfaces a campaign at all.
Why we did not act on it
Our edge shield blocks at confidence 80. A single community submission to ThreatFox or TweetFeed comes in at 70, which is in the default CSVs our customers pull, but below the line where our own edge acts. So 34 of the 36 early records reached every subscriber who sets their own threshold lower, and never reached the edge protecting our own sites. The data was there. The decision layer above it was not.
We found a second gap while checking the headlines. Our IP blocklist file serves bare IP addresses. URLhaus lists URLs, and when a URL's host is an IP address, like http://5.78.73[.]122:81/private/bins.sh, that IP never made it into the IP lane at all. For almost four months the only records of PoeLLM's C2 were URLhaus URLs at confidence 80, and our IP file never served them. The IP reached the default file when we ingested it ourselves on October 8, at 75, and it is in today's default file because of a fresh ThreatFox record. It has never been in the file at 80, the level our own edge uses.
What we built: promote on convergence, not on a single voice
The idea is simple. One report is a claim. Two independent sources reporting the same IP is a shape. So we built a job that runs every six hours, looks at 180 days of lane evidence, and raises an IP to 80 when the sources agree, with every promotion naming its sources and their dates.
The first draft was wrong, and our own security review caught it twice before it went live.
The first review pointed out that ThreatFox and TweetFeed both accept anyone's submission. One tweet plus one ThreatFox entry would be "two independent sources," and that would let an attacker aim our edge at a victim's IP address. A single ThreatFox entry labeled with a C2 framework was worse. We ran that first rule against live data in a dry run: it would have promoted 1,365 IPs, most of them single submissions labeled VShell. A cap of 500 stopped it, and it was shipped disarmed, so nothing was written.
The second review found three more holes. Our vendor-blog lane takes every IP mentioned in a security vendor's post, which includes victims and examples, so it cannot count as vetted. A cloud /24 can be rented next to a victim, so "our honeypot saw this neighborhood" cannot be the second voice. And an IP that was malicious five months ago and has since been reassigned to someone innocent could be promoted by one fresh crowd submission.
The rule that shipped: an IP is raised to 80 only when two or more sources carry it, one of them is a lane where listings are checked (URLhaus, SSLBL or Feodo), and that checked lane saw it in the last 30 days. A C2-framework label or our honeypot seeing the /24 raises the score to 85, but never qualifies an IP by itself. Against today's data that rule would promote 253 IPs. We read a sample by hand: Mirai droppers serving bot.x86 and mirai.x64, GUIDLOADER payload hosts, AMOS stealer download paths, all bare IPs on VPS and colocation ranges, each with a URLhaus listing from the last month and a ThreatFox record beside it.
The honest cost
Hardening has a price. Of the 24 early IPs in our sweep, the first rule would have caught 8 before our write-up. The shipped rule catches 1. Most of the early catches were exactly the case an attacker could fake: one community report with a framework label. We chose the version that cannot be turned against a victim, because a false positive at the edge is the real cost of a blocklist.
The way back to those catches is not more crowd sources. It is checking the C2 ourselves. There are 5,197 IPs right now that carry a C2-framework label from a single source. If we connect to each one and confirm the listener looks like the framework it is labeled as, that observation is ours, and nobody can submit it on our behalf. That is the next thing we are building.
What this means if you use our feed
If you pull our CSVs with your own minimum confidence, nothing changes for you: the records were already there, and you set the threshold. If you use 80, as our own edge does, you will start seeing rows with the source convergence-promoter once we turn it on. Each one names the lanes that agreed and the date each first saw the IP, so you can check our reasoning instead of trusting it. Promotions that stop being confirmed drop back to 70 after 30 days.
And the headlines say where this goes next. C2 is moving onto platforms nobody can blocklist: Steam profiles for a WordPress campaign, a poem on GitHub for PoeLLM, SharePoint and the Graph API for Havoc, blockchain transactions for ChainDrop and Overlord. An IP blocklist cannot follow that. Tracking which account or address the malware reads its instructions from is the facet we need next, and we will report on it when we have it.
The free key that pulls the feed at any threshold you choose is at https://analytics.dugganusa.com/stix/register?utm_source=blog&utm_campaign=held-early-not-acted-on
If this was useful, or if it wasn't, the rating widget below takes ten seconds and is the only way we know.
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=we-held-36-campaign-indicators-a-median-34-days-early-our-own-edge-blocked-almost-none-of-them
Comments