The phishing kit that doesn't need your password, just one code you type in
A phishing-as-a-service kit is hijacking Microsoft 365 mailboxes by abusing a legitimate OAuth flow, no password or malware required. Here's how it works.
By David Lara, Founder
Founder-reviewed ·How we research and correct articles
Most phishing advice boils down to “don’t type your password into a fake login page.” That advice is useless against the kit that drove last week’s biggest phishing-as-a-service surge, because it doesn’t ask for your password at all. It asks you to type a six-character code into a real Microsoft login page — the actual one, at the actual URL — and that’s the entire attack.
According to Cybersecurity News’ tracking of the week of July 20-26, 2026, global phishing-as-a-service activity surged to 7,295 tracked uploads, driven overwhelmingly by OAuth device-code flow abuse and adversary-in-the-middle kits aimed at Microsoft 365 identities — a category the kit known as EvilTokens has come to dominate.
Why this is worse than a normal password-phishing attack
Traditional credential phishing has a natural defense: a fake login page lives at a fake URL, and multi-factor authentication stops most credential-only compromises even when someone falls for it. Device-code phishing sidesteps both protections, because there’s no fake page to spot and no password for MFA to protect.
| Traditional password phishing | Device-code phishing (EvilTokens) | |
|---|---|---|
| Where the victim logs in | A fake, look-alike page | The real Microsoft login page |
| What the attacker needs from the victim | Password (and often MFA code) | One short code, typed into the real site |
| Stops it if MFA is enabled? | ✓ | — |
| URL a trained user could spot as fake | ✓ | — |
| What the attacker ends up with | Password, sometimes a session | A live, MFA-verified access token |
How the device-code flow gets turned against you
The OAuth 2.0 device authorization grant exists for a legitimate reason: it’s how you sign into a device with no easy way to type a password, like a smart TV or a printer. The device shows a short code, you go to a Microsoft page on your phone or laptop, enter the code, and Microsoft links the two — the device gets a token without ever seeing your password.
EvilTokens abuses exactly that flow, generating a real device-code request and getting the victim to complete the other half of it:
How an EvilTokens-style device-code attack plays out
The attacker generates a real device code
The kit initiates a genuine Microsoft OAuth device-authorization request, which produces a real, short-lived code — there's nothing fake about this step.
The victim receives a lure with that code
Delivered by email, Teams message, or QR code, framed as something routine — a document to review, a meeting invite, a security verification step.
The victim enters the code on the real Microsoft page
Because the login page is genuinely Microsoft's, there's no URL mismatch, no certificate warning, none of the visual cues that normally tip someone off.
The victim completes MFA — for the attacker's session
Any MFA prompt the victim sees and approves is authorizing the attacker's device-code request, not their own. Two-factor authentication doesn't fail here; it succeeds, for the wrong session.
Microsoft issues a valid access token to the attacker's device
The attacker now holds a live, MFA-verified token to Microsoft 365 — mail, files, Teams, SharePoint, OneDrive — without ever touching a password.
Why an outbound team should care specifically
A compromised Microsoft 365 mailbox isn’t just a general IT problem — for anyone running outreach, it’s often the exact mailbox connected to sending infrastructure, replies, and CRM sync. Once an attacker holds a live token to that mailbox, they can read every reply thread, see suppression and opt-out requests before your team does, and — worst case — use the compromised account’s standing trust to send convincing business email compromise attempts from an address your prospects already recognize and trust. A device-code compromise doesn’t trip the alarms a straightforward credential-stuffing attempt would, because from Microsoft’s side, it looks exactly like a normal, MFA-verified sign-in — because it is one, just authorizing the wrong device.
This also means the entire posture of “we require MFA, we’re covered” needs an asterisk. MFA is still worth requiring — it stops the overwhelming majority of credential-based attacks — but it was never designed to stop a victim from voluntarily approving the wrong session, and that’s precisely the gap this kit is built to exploit.
Why this spread as fast as it did
Kits like EvilTokens aren’t built and operated by a single group running one campaign — they’re sold as a subscription, advertised through Telegram channels, and packaged so that anyone can rent the infrastructure without understanding the OAuth mechanics underneath it. That’s the same commoditization pattern that turned ransomware from a specialist skill into an industry: once the hard part is packaged as a product, the number of people capable of running the attack stops being the limiting factor, and volume becomes a function of how many people are willing to pay for access rather than how many people understand device-code grants.
It’s also why AI-generated lure content matters here specifically. The weakest link in this attack was always the lure — the message convincing someone to enter a code they didn’t generate themselves. A generic, poorly-written lure is exactly what security awareness training teaches people to spot. A lure tailored to sound like a specific vendor, a specific internal process, or a specific ongoing project closes that gap, and generating that kind of tailored, plausible text at scale is precisely what large language models are good at. The kit doesn’t need a skilled social engineer behind every attempt anymore; it needs a prompt.
What actually reduces exposure here
None of the fixes require abandoning device-code sign-in entirely, since it’s a legitimate and sometimes necessary flow. They’re about making the specific social-engineering step harder to fall for:
- Treat “enter this code” prompts with the same suspicion as a password request, especially if the lure arrived unprompted. A legitimate device-code sign-in is something you initiated on a device in front of you, not something a message asked you to complete.
- Restrict device-code flow at the tenant level if your organization doesn’t need it. Microsoft and several vendors published guidance through 2026 on disabling or conditionally restricting the device authorization grant for tenants that don’t rely on it for legitimate hardware sign-ins.
- Watch for sign-ins from unfamiliar device types or locations immediately after a code-entry event — the gap between “victim entered a code” and “attacker’s session is live” is the shortest window you have to catch this before real damage starts.
- Assume any mailbox that touches your sending domain is a higher-value target than a typical employee inbox, and hold it to a tighter standard: dedicated monitoring, faster credential rotation, and no standing device-code exceptions.
Common questions
If I already require MFA, am I protected against this?
MFA stops most credential-based attacks, but device-code phishing works by getting the victim to complete MFA on the attacker's session rather than their own — so requiring MFA alone doesn't close this specific gap. It still matters; it's just not sufficient on its own against this technique.
How is this different from a normal phishing link?
A normal phishing link sends you to a fake site designed to look like a real one. Device-code phishing sends you to the genuine Microsoft login page — there's no fake URL to catch, because nothing about the destination is fake. Only the context that led you there is.
Does connecting a mailbox to a sending platform increase this risk?
Connecting a mailbox through a proper OAuth grant scoped to what the platform actually needs doesn't meaningfully change your exposure to this attack, since the vulnerability is in how a user gets tricked into approving a session, not in what's connected to the account. What matters is treating any mailbox in your sending or reply chain as a high-value target for exactly this kind of social engineering.
What should I actually tell my team, in one sentence?
If a message asks you to enter a code on a login page to complete something you didn't start yourself, stop and verify out of band before typing it in — a real device sign-in is something you initiated, not something a message asked you to finish.
What this looks like once it’s already happened
The signals that separate a fast catch from a slow one are worth naming explicitly, because by the time this reaches a mailbox tied to your sending domain, the difference is measured in how much reply history and prospect trust the attacker gets to touch before someone notices. A sign-in from an unfamiliar device type, immediately followed by new mail rules, forwarding addresses, or app registrations being created inside the account, is the pattern security teams now associate with a completed device-code compromise — the attacker isn’t just reading mail, they’re setting up ways to keep reading it even after the victim changes their password. None of that requires the attacker to ever type a password themselves, and none of it looks like a brute-force attempt to whatever’s monitoring for one.
Where Norbelys fits into reducing this exposure
Connecting a mailbox to Norbelys uses a standard, scoped OAuth grant — you authorize a specific, named integration through Microsoft or Google’s own consent screen, not a code typed in response to an unsolicited prompt, and the resulting access is limited to what sending and reply-tracking actually require. That’s the legitimate version of the same underlying mechanism this attack abuses, and knowing the difference between the two is most of the defense: a Norbelys connection request will always originate from an action you took in the dashboard, never from a message asking you to enter a code somewhere else.
Beyond the connection itself, DMARC monitoring gives you an independent signal if a compromised mailbox starts being used to send mail that shouldn’t be leaving your domain — a device-code compromise that turns into an outbound abuse attempt shows up there before it shows up anywhere else. And because suppression and reply data live inside Norbelys rather than solely inside the mailbox itself, a compromised inbox doesn’t automatically mean a compromised view of who’s replied, who’s opted out, and what your sending domain has actually been doing.
That layered visibility is the point: no single control here claims to make a well-crafted device-code lure impossible to fall for, because nothing does. What it does instead is make sure a single moment of someone typing the wrong code into the wrong page doesn’t quietly become weeks of unnoticed mailbox access with no independent signal catching it. See how domain health and DMARC monitoring work together, and put a layer of independent visibility between a single compromised mailbox and the reputation of your entire sending domain.