497 Logins Out of 200,000 Attempts Took 79 Organizations. The Kit We Covered in August Needed 9,426 Emails. Same Bypass, Opposite Economics.
Huntress published a Microsoft 365 campaign this week that compromised 97 accounts across 79 organizations between July 14 and September 22. The attackers did not break multi-factor authentication. They waited for victims to complete it correctly, stole the session token that completing it produced, and replayed it.
The headline numbers are 97 and 79. The number that actually teaches you something is a different one: 497 successful sign-ins against more than 200,000 failed attempts.
That is a quarter of one percent. And it is the most interesting thing in the report, because we covered a campaign in August that hit roughly half.
The same bypass at both ends of the cost curve
In August we wrote about Mirage2FA, a commercial phishing platform also tracked as LinXcoded. It targeted 9,426 email addresses and potentially compromised 4,532 sessions. Call it forty-eight percent, against organizations that overwhelmingly had MFA switched on.
Set the two next to each other and resist the urge to divide one by the other, because the denominators are not the same thing. Mirage2FA's 9,426 counts people who received a tailored phish. This week's 200,000 counts login attempts against a tenant. One measures how often a human fell for something; the other measures how often a machine guessed right. You cannot honestly compute a ratio across that boundary, and we are not going to pretend otherwise.
What you can say is the thing that matters: post-MFA session theft is now available at both ends of the economic spectrum, and it works at both.
Mirage2FA is the expensive, quiet version. A tailored lure, sent from a company you genuinely do business with, converting one target in two. This week's campaign is the cheap, loud version. Two hundred thousand attempts is not stealth, it is weather. It still landed inside seventy-nine organizations.
A defense tuned for one of those shapes does not see the other. If your detection assumes attackers are noisy, Mirage2FA walks past it. If your detection assumes attackers are careful, this one does.
Your MFA did not fail
This is worth stating plainly because the opposite conclusion is the expensive one.
In a token replay, the user completes authentication properly. The second factor is presented, accepted and consumed. The control did the job it was designed to do. What the attacker takes is the artifact issued afterward: the session token that says "this person already proved who they are, stop asking."
Every downstream action is then a valid, authenticated session. There is no failed login to alert on, because there was no failed login. There is no password to rotate that helps, because the password was never the weak part.
The practical consequence is that sign-in success is the wrong thing to watch. By the time a replayed token shows up as a successful sign-in, you are looking at the attacker's authenticated session and it looks exactly like the user's.
Where it does become visible
Three places, and none of them require an indicator from anyone else. That matters, because this campaign is not attributed to a named actor and the infrastructure detail available is a hosting provider in Hamburg, which Huntress is careful to say does not establish that the provider participated. You are not getting a clean blocklist out of this one.
Device registrations in Entra. The attackers registered 48 rogue devices. That is the persistence step, and it is the loudest thing they did. A device joining an account whose owner has not changed hardware is a question worth asking every single time, and it is logged by default.
MFA method changes, especially removals. The campaign added attacker-controlled methods and removed the legitimate ones. Addition alone is ordinary; people get new phones. Removal is the tell. Users almost never delete a working second factor, and an add paired with a remove inside one session is close to diagnostic.
Inbox rules created immediately after sign-in. Rules that file away or mark-as-read anything matching finance, invoice, payment or security keywords. In this campaign that concealment was load-bearing: a payroll request went out to an external accountant, and the rules existed so the account holder would not see the replies.
The through-line is that the campaign becomes visible in what the account does in the first ten minutes after authenticating, not in the authentication itself.
Why we are publishing this when a vendor already has
Because the comparison is ours to make and nobody else is positioned to make it.
We covered the hotel Wi-Fi captive-portal attacks in July, where a poisoned gateway served an attacker's login page to someone who typed a legitimate Microsoft address and never received an email at all. We covered two phishing kits in August that route around M365 MFA from opposite directions. We covered Mirage2FA at the end of August. We covered Huntress's own 81-million-attempt Azure CLI spray in the same period, and used it to audit our own signup gate, which turned out to be unable to see IPv6 either.
Four campaigns, one target surface, five months. That run is what lets us say the useful thing here instead of restating the vendor's summary: this is not an emerging technique, it is a mature market with tooling at multiple price points, and the common factor across every one of them is that the organization's MFA was working.
Our own threat sweep graded this story a gap in our coverage this morning. It was wrong, and the reason is instructive: it matched on headline tokens and found no post with "token replay" in the title. The coverage was there under four different names. A single-key lookup produces both false gaps and false confidence, which is why the grading runs on several axes and why a weak match gets demoted rather than trusted.
What to do this week
Pull your Entra device registration log for the last ninety days and look at every join against whether that person actually changed devices. The campaign window opened July 14, so ninety days is the right lookback, not thirty.
Alert on MFA method removal as its own event, separately from addition. If you can only build one new detection from this post, build that one.
Audit inbox rules created in the last quarter for anything that hides mail from the mailbox owner, and treat creation-shortly-after-sign-in as the correlation to key on.
And revoke sessions, not just passwords. A password reset does not invalidate a stolen token. If you respond to a suspected compromise by forcing a password change and nothing else, the attacker's session survives your incident response entirely.
Ninety-five percent confidence. The five percent here is attribution: nobody has named an actor, and the hosting provider appearing in the replay traffic is a data point about where servers were rented, not about who rented them.
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=497-logins-out-of-200-000-attempts-took-79-organizations-the-kit-we-covered-in-august-needed-9-426
Comments