top of page

We Whois'd Every IP in Five Threat Reports. Four of Twenty-Nine Were GitHub, Google and Cloudflare.

Writer: Patrick Duggan
Patrick Duggan
1 hour ago
6 min read

Last week produced five public reports with hard network indicators: a joint advisory from CISA, the FBI and the Secret Service on SafePay ransomware, Palo Alto's Unit 42 on active exploitation of a PAN-OS GlobalProtect bypass, SOCRadar on the INC and The Gentlemen ransomware infrastructure, Microsoft Threat Intelligence on Storm-0940's use of an agentic AI framework, and Volexity on the chained Ivanti Connect Secure zero-days.


Between them they published twenty-nine IPv4 addresses as indicators. We ran a whois on every single one before letting any of it near our feed, because that is the rule here. It takes about ninety seconds.


Four of the twenty-nine belong to infrastructure that nobody should ever block.





The four


All four are in the government joint advisory, AA26-293A, published October 20.


140.82.114.4 is GitHub, Inc. That is github.com. The advisory lists it as a SafePay victim intrusion host.


185.199.108.133 is GitHub, Inc. That is GitHub Pages. Also listed as an intrusion host.


104.26.2.223 is Cloudflare, Inc. Also listed as an intrusion host.


173.194.194.94 is Google LLC. Listed under hosting victim data.


Ingest that table the way most teams ingest advisories, and you have blocked github.com, GitHub Pages, Cloudflare and Google for everyone behind your perimeter. Your developers cannot clone. Your build agents cannot fetch. The outage you cause is bigger than the intrusion you were defending against, and it will take you a while to work out why, because the cause is sitting in a file you were told to trust.


The advisory does carry a warning, as a note under the table: verify IP addresses before blocking, since cloud-hosted addresses may be reassigned. That sentence is correct. It is also an admission that the table cannot be used as published, and no automated consumer will ever read it.



The twenty-five that were fine


This is the part that surprised us, and it is why the headline number is worth more than an anecdote.


The four commercial and vendor reports were clean. Every address in them resolved to hosting, VPS or bulletproof-adjacent infrastructure, which is exactly what attacker infrastructure looks like.


Unit 42's nine PAN-OS exploitation addresses resolved to Sharktech, ColoCrossing, Private Layer, a 31173 range, a Canadian colo and a Pacific telco. SOCRadar's seven INC and Gentlemen hosts resolved to a LACNIC allocation in Uruguay, a Trinidad ISP, an Estonian host, a Marshall Islands holding company and a Dutch range. Microsoft's three Storm-0940 spray addresses all sat inside one FranTech range. Volexity's single Ivanti command-and-control host sat on a small US network.


Not one CDN. Not one platform. Not one search engine.


So the finding is not "threat reports are sloppy." In this sample it is narrower and stranger than that: the only source that shipped unusable rows was the one with three federal agencies on the letterhead, and it shipped four of nine.


We are not going to over-read that. One advisory is a sample of one, and we are not claiming government advisories are systematically worse than vendor reports — twenty-nine indicators across five documents cannot carry that weight. What it does establish is that the authority of a source tells you nothing about whether its indicator table is safe to automate, and that the check which would have caught it costs nothing.



Why this happens


An IOC table flattens two very different statements into one column.


"This address appeared somewhere in this incident" and "block this address" are not the same claim. A victim exfiltrating data to a Google-hosted service, a payload staged on GitHub Pages, a C2 hiding behind Cloudflare — all of those legitimately appear in an incident timeline. None of them is a blockable indicator, because the thing you would be blocking is a shared platform serving millions of people, one of whom was the attacker.


The analyst writing the report knows the difference. The CSV does not have a column for it. And the consumer, three automated hops downstream, has neither the analyst nor the column.



The same lens, pointed at ourselves


We ran the check on our own published blocklist the same afternoon, because a rule you only apply outward is marketing.


Our IP feed publishes with a default minimum confidence of 50, and the comparison is inclusive. Every Tor exit node in our corpus was scored exactly 50 — so 509 of them have been shipping in the default download, labeled with a threat type of anonymization.


The intent was right and the arithmetic was wrong. The comment sitting next to that number, written by us, says Tor nodes aren't inherently malicious. Somebody scored the lane low on purpose to keep it out of the way, and 50 put it precisely inside the default instead of safely below it. Anonymization is a property of a host, not an observation that it did anything, and a defender pulling our file with no parameters was getting 509 blocking decisions we made on their behalf without saying so. That lands hardest on the people Tor exists for.


One half of our own pipeline already knew. The component that promotes corroborated indicators up to blocking confidence refuses to promote a Tor exit and logs the reason. The publishing path never asked it.


We have moved the lane to 40, below the floor, where it stays fully available to anyone who asks for it by passing a lower minimum confidence — because plenty of networks do want to refuse Tor, and that is their decision to make rather than ours to make quietly. The rows are unchanged and still dated. As of this writing the harvester has not yet re-run, so the live file still carries them at 50; it will carry them at 40 after the next cycle, and you can check that yourself rather than take our word for it.



Two rules worth stealing


Whois every address in every advisory before you ingest it, including a government one. A primary source is not a clean source. The same ninety-second check caught something else last week: a domain in a vendor report impersonating a well-known CDN, which turned out to have been registered this past May through Cloudflare with no registrant organization, while the real CDN's zones are entirely different names. Verified before listing, so it was safe to list. Trusted blindly, we would have published a blocklist entry against a CDN under a slightly different spelling.


If a lane must not be blocked by default, score it below your floor, not near it. "Low confidence" and "do not block this" are different statements and a number cannot hold both. Something that must never reach a blocklist belongs out of the file, or below the floor with the reason recorded in the row.


And then check the artifact rather than the intention. We found ours by downloading our own published file and grouping the rows by source. Any lane where every row carries the identical score was set by a rule rather than by evidence, and that rule is worth reading.



Do this yourself


Nothing here required a tool you do not have. Whois is free. Downloading a blocklist and counting what is in it is free. The entire study was twenty-nine lookups and a column count, and it found four rows that would have taken a competent team's morning away from them.


If you consume any blocklist, ours included: group the rows by source, look at the confidence distribution, and ask what happens at your floor. Then whois the top twenty and see whether you recognize any of the owners.


Our IP feed is at analytics dot dugganusa dot com slash api slash v1 slash stix-feed slash ips.csv, free with a registered key. Count the rows and tell us where we are wrong. This is correction twenty-six we have published this year, and we guarantee a twenty-seventh exists that we have not found — call it the five percent we will not pretend away.




Her name was Renee Nicole Good.


His name was Alex Jeffery Pretti.




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-whois-d-every-ip-in-five-threat-reports-four-of-twenty-nine-were-github-google-and-cloudflare



Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page