Would a Threat Feed Have Saved McDonald's? Probably Not - And Here Is Exactly Where One Would
- Patrick Duggan
- 4 minutes ago
- 5 min read
On 16 August 2026, Hudson Rock's InfoStealers reported that an actor calling themselves TheHatman is selling internal employee directories said to be pulled from enterprise Azure and Entra portals using compromised credentials. The list of named organisations is not small: McDonald's at roughly 1.7 million records, TCS at 800,000, Vodafone at 425,000, HCL Technologies, InterContinental Hotels, Kyndryl, Gap, Hexaware, Wyndham. Around 3.6 million records in total, if the seller's counts are honest, which sellers' counts usually are not.
We run a threat intelligence feed. So the commercially convenient thing to write here is that our feed would have caught it.
It would not have. Not at the point where the damage happened. And we think the more useful article is the one that explains exactly where a feed stops being able to help you, because that boundary is where a lot of security money currently gets set on fire.
The chain, and the half of it nobody can sell you a feed for
By the time somebody types a correct password into a real Microsoft login page, there is no malicious infrastructure in the path. There is no bad IP to block, no suspicious domain to sinkhole, no file hash to match. There is an employee's actual password being used the way passwords are designed to be used.
That is not a threat intelligence problem. It is an identity problem — multi-factor authentication, conditional access, session-token binding, impossible-travel detection, and alerting on bulk directory reads. Any vendor who responds to this news by selling you indicators for stage four is selling you a product that is not in the path of the attack.
Stage three is even starker. The credential sits in a marketplace log. Nothing touches your network at all. There is nothing to detect because nothing is happening to you yet.
So: two of the four stages are genuinely unwinnable with a feed, and one of those two is where the actual theft occurred.
Where a feed does win, and what we actually carry
The left half of that chain is a different story, and it is the half where this becomes preventable rather than merely detectable.
Those credentials came from somewhere. The overwhelmingly common route is an infostealer — a piece of malware that lands on an employee's machine through a malicious package, a cracked application, or a phishing attachment, harvests every saved browser password and session cookie, and ships them to a command-and-control server. The theft of the credential is a network event. It is loud. It is blockable.
We checked what we hold against the families that do this work, at confidence 80 or above, which is the threshold at which an indicator reaches our published blocklists:
Vidar, 4,932 indicators. StealC, 1,188. RedLine, 948. AgentTesla, 653. Lumma, 662. Rhadamanthys, 525. Atomic, 206. FormBook, 146. Raccoon, 106. Azorult, 3.
Around 9,400 high-confidence indicators tied to the infrastructure that harvests exactly this class of credential. All of it free, no signup, no sales call.
If an employee laptop at any of those organisations had tried to reach one of those command-and-control servers while the organisation was consuming a feed carrying it, the exfiltration call fails. The stealer runs, finds the passwords, and cannot deliver them. The credential never reaches a marketplace and stage four never happens.
That is a real defensive win and it is available to anyone for nothing.
The thing we cannot tell you, and neither can anyone else
Here is the part that keeps this from being a marketing post.
The report published no indicators at all. No IP addresses, no domains, no file hashes, no tooling names, no storage accounts, no tenant identifiers. Nothing to check.
Which means we cannot test whether our coverage overlapped the infrastructure actually used in these intrusions. We do not know whether we would have blocked the specific stealer that took McDonald's credentials, because nobody has published what it was.
So we are not going to claim we would have saved them. We are going to say precisely this: we carry substantial coverage of the family of attack described, at the stage where it is stoppable, and there is no way to verify the specific case. If you see a vendor claiming they would have prevented this one, ask them which indicator they would have blocked. There is no correct answer available, because the data was never published.
We would also gently note that this is why publishing indicators matters. A breach report with no indicators is a story. A breach report with indicators is a defence that other people can deploy. Hudson Rock did good work surfacing the sale; the ecosystem would be better off if the technical detail travelled with it.
What to actually do about this, in order
First, and by a distance: check whether it is already too late. The credentials in these sales are already stolen. Nothing you block today un-steals them. Force a password reset, revoke active sessions and refresh tokens, and re-enrol MFA for any account you cannot positively account for. Revoking the session matters more than resetting the password — a stolen session cookie walks straight past MFA.
Second, close stage four properly. Conditional access on every human account, not just the administrators. Alert on bulk directory reads, because a legitimate employee does not enumerate the entire staff list. Audit which applications hold directory-wide read permissions — most estates have at least one service principal with far more access than anybody remembers granting it.
Third, close stages one and two, which is the cheap part. Pull an infostealer blocklist into your firewall or DNS resolver. Ours is free and ships as a STIX 2.1 feed, plus flat CSV for IPs, domains and hashes, plus OPNsense and Suricata formats, plus a Splunk-friendly output. If you would rather just ask a question than integrate a feed, our Jeevesus MCP server answers natural-language queries against the whole corpus — hand it an indicator and it will tell you whether it is known and what it is associated with, free and without authentication.
The honest summary
A threat feed would not have stopped the directory from being exported, because that was a valid login. A threat feed has a genuine shot at stopping the credential from being stolen in the first place, which is the only stage of this attack where an outsider could have intervened at all.
Those are different claims, and the difference is the whole article. The security industry has a strong commercial incentive to blur it, because "we would have stopped this" sells better than "we would have stopped the part four steps upstream, and we cannot prove it in this instance."
We cap our confidence at 95 percent on principle. On this one we would go lower, because the evidence needed to check ourselves was never published.
If you run an Azure or Entra tenant, the actionable item is not our feed. It is going and looking at which of your applications can read your entire directory, and how many of your people could have their session replayed today. We went and did exactly that to ourselves this weekend after reading the report, and found something we had written down wrong. That is a different article, and we will publish that one too.
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=would-a-threat-feed-have-saved-mcdonald-s-probably-not-and-here-is-exactly-where-one-would
Comments