A researcher at Huntress published something this week that should bother anyone who thinks multi-factor authentication is the finish line. He got a real Microsoft login window to open on a Windows 11 desktop, typed a real password, completed a real MFA prompt, and watched the access token and refresh token land in his own listener seconds later (Huntress).
Nothing about it was fake. The login page was served by login.microsoftonline.com. The process rendering it was a signed Microsoft binary called WWAHost.exe. There was no lookalike domain, no certificate warning, no typo in the URL for a sharp user to catch. The user did everything right, and it did not matter, because the attacker captured what Microsoft handed back after the login succeeded.
Two things keep this from being a five-alarm fire. It was a researcher demo, not a campaign seen in the wild. And it requires Developer Mode to be turned on in Windows, which takes local administrator rights. But those are exactly the conditions a lot of small businesses accidentally meet: one person who does a little scripting, one workstation where everybody is a local admin because that was easier three years ago.
The bigger point stands regardless of this specific trick. Once an attacker holds your session token, MFA is already behind them. Here is what to actually do about it.
1. Turn Developer Mode off and keep it off
This is the single control that breaks the attack described above. Check Settings, For developers, Developer mode on every Windows machine. Then enforce it centrally so it cannot be flipped back on: set the registry value AllowDevelopmentWithoutDevLicense under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock to 0, and push that through Intune or group policy rather than one machine at a time. Almost no one in an accounting firm or a dental office needs Developer Mode. If one developer genuinely does, make it an exception you know about.
2. Stop handing out local administrator rights
Every step in that attack chain after Developer Mode runs as a normal user with no prompts. Developer Mode itself needs admin. Take local admin away from day-to-day accounts and give the people who need it a separate elevated account. This one change kills a long list of attacks, not just this one, and it is the cheapest thing on this list.
3. Require a managed device, not just a password and a code
In Entra ID, build a Conditional Access policy that requires a compliant or Entra-joined device for access to Microsoft 365. A stolen token replayed from an attacker’s own machine fails that check. This is the control that turns “they have my token” into “they have a token that does not work anywhere useful.”
4. Turn on token protection where you can
Entra’s token protection (sometimes called token binding) ties a sign-in session to the device it was issued on. Coverage is not universal yet, but turn it on for the sign-in scenarios that support it. Pair it with shorter session lifetimes so a stolen refresh token has a shelf life measured in hours, not months.
5. Make session revocation part of your playbook
When an account gets compromised, most people reset the password and move on. That does not kill an active token. Your response steps should be: reset the password, revoke all sign-in sessions for that user, then review what the account did while it was out of your control. Write it down now so nobody is improvising it at 9pm on a Friday.
6. Audit which apps have consent to your tenant
Go into Enterprise applications in Entra and look at what has been granted access to mail and files. Remove anything you do not recognize. Then block ordinary users from consenting to new apps on their own and route those requests through an admin approval workflow. Token abuse and malicious OAuth app consent land in the same place: an attacker reading your email without ever logging in as you.
7. Put real endpoint detection on every machine
Signature-based antivirus has nothing obvious to flag when every component in the chain is a signed Microsoft binary behaving normally. Behavioral endpoint detection (what we deploy and monitor for clients) is what catches the odd thing: an unusual process reaching out to a server nobody has seen before. We wrote about a related pattern earlier, where attackers used a convincing fake help desk approach in an earlier post, and the lesson is the same. The tell is the behavior, not the file.
What this means for you
Keep using MFA. It still stops the overwhelming majority of account takeovers. Just stop treating it as the whole plan. The attacks that matter now target what happens after a successful login, which means device controls, session handling, and what your endpoints are allowed to run.
Steps 1 through 4 and 6 are configuration work in Microsoft 365 and Windows that we handle as part of managing a client’s tenant. If you are not sure where your tenant stands on any of these, that is a short conversation. Book a free 15-minute consult.