There is a line in Huntress’s latest research that should make anyone responsible for Microsoft 365 security pay attention:
MFA = PASS. Token = ISSUED.
That is really what this attack is about.
Huntress has published a detailed report, EvilTokens and the Rise of AI-Powered Phishing, examining a series of attacks targeting Microsoft 365 accounts.
The interesting part isn’t simply that criminals are using AI.
It is that they are combining AI-generated phishing with legitimate cloud infrastructure, genuine Microsoft authentication processes and stolen access tokens.
From the victim’s point of view, remarkably little may look wrong and that changes some of the advice we’ve traditionally given people about phishing.
The research and statistics referenced in this article come from the Huntress report EvilTokens and the Rise of AI-Powered Phishing. Credit to the Huntress research and SOC teams for the investigation.
What did Huntress find?
Between July–December 2025 and January–April 2026, Huntress recorded a 1,380% increase in detected device-code phishing attacks.
Around 30% were associated with Railway infrastructure and another 27.5% with BL Networks. During the first major Railway-linked wave, Huntress found no two phishing messages were identical across 344 victim organisations.
Traditional bulk phishing often gives defenders patterns to look for.
Same wording.
Same subject.
Same dodgy link.
Same attachment.
AI changes the economics of that.
Huntress found EvilTokens incorporating AI into its phishing-as-a-service operation to generate lures tailored to somebody’s job. A person involved in procurement might receive something about a proposal or bid, for example. Once an account was compromised, AI could then analyse email, calendars and documents looking for useful information, including payment conversations that could potentially be turned into business email compromise.
This isn’t AI magically “hacking” Microsoft 365, it is AI making the social engineering surrounding the attack quicker, cheaper and more believable.
That’s arguably more useful to the criminal.
What is device-code phishing?
Microsoft created device-code authentication for perfectly legitimate reasons.
Think of a device where entering a username and password is awkward. A smart TV or meeting-room device, for example.
Instead, the device displays a code.
You visit a Microsoft authentication page on another device, enter the code and authenticate.
The problem is that an attacker can start that process too.
They generate the device code and persuade you to enter it.
And this is where the normal phishing advice starts to fall apart.
You might actually visit:
microsoft.com/devicelogin
The certificate is valid.
The Microsoft branding is genuine.
You enter your own details directly into Microsoft’s website.
You complete MFA.
Everything appears to be legitimate.
But the authentication request was initiated by the attacker.
Once you approve it, the attacker’s session receives the resulting OAuth tokens. Huntress points out that these tokens can give an attacker access without them ever needing to know the victim’s password.
That is a very different phishing lesson from:
“Look for spelling mistakes and check whether the login page looks genuine.”
The login page is genuine.
What happens next?
Huntress illustrates this with a fictional construction-company employee receiving what appears to be a subcontractor bid.
She follows a prompt, enters an eight-character code at Microsoft’s genuine login page and completes MFA.
Meanwhile, other employees receive different lures: one apparently from DocuSign, another about a password expiry.
Different emails.
Same underlying attack.
All of them complete genuine Microsoft authentication flows.
Behind the scenes, however, the attacker’s infrastructure receives valid OAuth tokens.
Huntress describes how an attacker could then read the victim’s mailbox, identify an upcoming payment and send changed payment instructions from the person’s real email account.
That is why identity attacks can become business email compromise very quickly.
From the supplier’s perspective, the message may come from somebody they already know, from the right email address and as part of an existing conversation.
Legitimate infrastructure makes detection harder
Another clever part of the campaign was its use of services that weren’t inherently malicious.
Huntress initially linked a major wave to Railway, a legitimate platform used by developers to deploy applications.
According to the report, three Railway IP addresses accounted for roughly 83% of the observed events during that wave, while Microsoft’s risk scoring flagged zero incidents associated with those authentications. Huntress subsequently deployed a Conditional Access policy blocking known Railway infrastructure for suitable customers and says it prevented more than 600 incidents while the campaign was active.
The attackers then changed infrastructure.
Huntress later observed similar activity originating from BL Networks.
And that is another lesson from the report.
Blocking one IP address or one domain is useful during an incident.
It isn’t the long-term answer.
The infrastructure is disposable.
Where does AiTM phishing fit into this?
Device-code phishing isn’t the only method targeting authentication tokens.
Huntress also notes the growth of phishing-as-a-service platforms supporting Adversary-in-the-Middle, or AiTM, attacks alongside device-code phishing.
The two techniques work differently.
With an AiTM attack, the criminal effectively places their phishing infrastructure between you and the genuine authentication service. You enter the credentials, Microsoft challenges for MFA, you approve it and the attacker captures the authenticated session.
That can make conventional MFA vulnerable because the attacker isn’t necessarily trying to guess the second factor. They’re relaying the authentication process and stealing what comes afterwards.
Microsoft specifically recommends moving towards phishing-resistant MFA, such as passkeys/FIDO2 and Windows Hello for Business, to address attacks including AiTM.
But there is an important distinction.
Passkeys aren’t the complete answer to device-code phishing
A FIDO2 passkey is tied cryptographically to the genuine website. That makes it extremely difficult for a fake Microsoft website or AiTM proxy to trick the user into authenticating to the wrong origin.
Device-code phishing is different.
The victim may be authenticating directly against the real Microsoft website.
So organisations also need controls around the authentication flow itself.
Microsoft calls device-code flow a high-risk authentication method and recommends blocking it wherever possible.
That’s an important nuance.
“Turn on MFA” is still good advice.
It just isn’t the end of the conversation any more.
What can organisations do?
The Huntress report makes the point that there isn’t one magic control that stops everything. Its recommendations combine identity visibility, Conditional Access and better user awareness.
For organisations using Microsoft 365, I would concentrate on these areas:
- Block device-code authentication if you don’t use it. Microsoft recommends getting as close as possible to a tenant-wide block. If you genuinely need it for something such as Teams Rooms or particular tooling, identify those use cases and tightly scope the exception rather than leaving the flow available to everyone.
- Require compliant devices for sensitive Microsoft 365 services. Huntress recommends requiring a compliant device for Exchange Online and SharePoint because device-code authentication cannot proceed from a non-compliant device when that requirement is enforced.
- Move towards phishing-resistant authentication. Passkeys, FIDO2 security keys and Windows Hello for Business provide much stronger protection against conventional phishing and AiTM attacks than passwords plus SMS codes or push prompts. Microsoft’s current guidance increasingly treats phishing-resistant MFA as the direction organisations should be heading.
- Consider token protection where your environment supports it. Microsoft’s Token Protection Conditional Access control cryptographically binds supported sign-in session tokens to the device, so stealing one doesn’t automatically mean it can be replayed elsewhere. It isn’t universal and should be regarded as defence in depth rather than a silver bullet.
- Monitor identities, not just endpoints. Huntress’s investigation demonstrates why authentication telemetry matters. Look at how somebody authenticated, the device involved, unusual hosting networks, new device registrations and what the account does afterwards. Huntress also recommends examining suspicious Graph API activity and user-consented applications following a compromise.
- Make sure your incident response deals with tokens. Simply changing somebody’s password may not be enough once an authenticated session has been stolen. Huntress recommends disabling a confirmed compromised account and revoking refresh tokens. Continuous Access Evaluation can also allow supported Microsoft services to respond much more quickly when an account is disabled or tokens are revoked.
- Change the phishing message you give employees. Teach people that a real Microsoft website doesn’t automatically mean the request that sent them there was legitimate. A simple rule is: if somebody sends you a device code and you didn’t personally start a device sign-in or setup process, stop and check it. Make reporting easy – the sooner somebody says, “I’ve just done something and I’m not sure about it,” the more options the security team has.
Don’t turn this into another reason to blame employees
One part of the Huntress report particularly stood out to me.
As phishing becomes more personalised and attackers deliberately make malicious activity resemble normal work, Huntress argues that blaming employees for failing to spot every attack isn’t the answer. People need to be comfortable speaking up quickly when something doesn’t feel right.
I agree. We can’t spend years telling people:
“Only enter your Microsoft password into Microsoft’s website.”
Then blame them when the criminal sends them to Microsoft’s website.
Security awareness has to evolve as the attacks evolve.
The goal isn’t to turn every employee into a threat analyst, it’s to build sensible technical controls around them and give them enough context to recognise when something unusual is happening.
If somebody has already entered a device code
Don’t just change the password and assume the job is done.
The issue may now be an authenticated token rather than a stolen password.
Huntress recommends disabling the compromised identity as well as revoking its refresh tokens. It also advises checking for newly registered devices, reviewing Graph API activity for possible mailbox reconnaissance or exfiltration, and inspecting applications to which the user may have granted consent.
That investigation matters because the visible phishing email might only have been the beginning.
The bigger lesson
The most important takeaway from the Huntress research isn’t really EvilTokens.
It is that attackers increasingly don’t need to smash through security controls.
They can abuse the legitimate ones.
A genuine cloud platform.
A genuine Microsoft login.
A genuine MFA request.
A genuine OAuth token.
Individually, every part can appear normal.
That’s why modern Microsoft 365 security increasingly needs to look beyond “Did MFA succeed?”
The better questions are:
How was the authentication started?
Which device completed it?
Should that authentication flow have been allowed at all?
And what did the identity do next?
That is where device-code phishing stops looking like an email problem and starts looking like what it really is. An identity security problem.
