The approval that adds a stranger
Device code phishing explained by Ilia Zavialov: the approval given on the real login page
Every phishing lesson your staff ever sat through taught them to check the address bar. This attack passes that check. There is no lookalike domain, no fake form and no password to steal. The employee lands on the genuine sign-in page of the service they use every day, types a short code somebody sent them, approves, and an attacker device is now signed in to their account with a valid session. Huntress counted a single campaign in March 2026 that reached 344 organisations across five countries, and attempts rose by 1380 percent between the second half of 2025 and the first months of 2026.
English version for the United Kingdom.
01
What the flow was built for
Device code sign-in exists because some devices cannot handle a login form. A television, a conference room display, a printer or a command line tool has no comfortable way to accept a password and a second factor. So the device shows a short code and asks you to open a page on your phone or laptop, type the code and approve.
The approval binds a session to whichever device asked for the code. That is the whole point of the design and also the whole problem. Nothing in the flow proves that the device asking is the device standing in front of you.
The flow has always worked this way and is not broken. What changed is that criminals noticed the gap between what the person thinks they are approving and what they are actually approving.
It helps to say out loud what the screen is really asking. The wording on the approval page talks about signing in to an application, which most people read as confirming their own action. The honest version would be a question about whether a device somewhere else should be allowed into this account, and almost nobody would answer yes to that.
02
How it is turned around
The attacker starts the flow from their own machine and receives a code that stays valid for a short window, typically minutes. Then they need one person to type it. The message carrying the code is the only social engineering in the whole attack.
The pretext is usually mundane. A meeting invitation, an IT notice about re-enrolling a device, a shared document that wants a quick confirmation. In February 2025 the group tracked as Storm-2372 sent these as Teams meeting invites, which is about as ordinary as a message gets.
The employee opens the real page, types the code, approves with their usual second factor, and sees exactly what they expect to see. The attacker now holds a session, and with it the mailbox, the files and often the ability to enrol further devices at leisure.
The password is never involved. Changing it afterwards does nothing on its own, because the session already exists and lives independently of the credential that started it.
03
Why the usual advice fails here
Check the sender is weak advice when the message arrives through a genuine internal channel or a compromised partner mailbox, which is the common case rather than the exception.
Check the link is weaker still. The link is correct. It goes to the real provider on the real domain with a valid certificate, which is why link rewriting and lookalike domain detection have nothing to flag.
Check for a form to fill in fails too, because the only thing typed is a short code that looks harmless and carries no obvious secret. People who would never type a password into a strange page will type a six character code without hesitating.
The one piece of advice that does work is narrow enough to teach in a sentence: a code you did not ask for should never be entered anywhere. If you did not just start something on a device in front of you, the request is not yours.
04
What the numbers say
The March 2026 campaign hit 344 organisations across the United States, Canada, Australia, New Zealand and Germany. That spread matters: it shows an operation running at volume against ordinary companies rather than a targeted intrusion into a handful of them.
Attempts grew by 1380 percent between July to December 2025 and January to April 2026. Huntress and Microsoft separately recorded roughly a tenfold rise in the first half of 2026 against the second half of 2025.
The tooling is rented. Kits sold as a service handle the code generation and the message templates, which is why the technique spread across so many unrelated victims in a single month. Nobody involved needs to understand the protocol.
Read those figures as a forecast rather than a summary. A technique that rents cheaply, defeats the training everybody has already paid for and leaves a clean audit trail on the provider side is not going to fade on its own. It fades when the setting is turned off.
05
What shows up in the logs
A successful sign-in from an unfamiliar location using the device code grant, immediately after a legitimate sign-in by the same user from their usual place. Two sign-ins, both valid, minutes apart, from different countries.
A new device registered to the account without a corresponding help desk ticket or asset record. This is the detail that most often survives the first week, because attackers rarely bother to clean up a device entry.
Mailbox rules created shortly after, usually moving messages that mention payments, invoices or security to a folder nobody reads. The rule is the attacker keeping the account quiet while they work.
None of this is subtle once you look for it. The difficulty is that the sign-in itself carries no failure and no anomaly score, so nothing raises its hand unless someone has written the rule.
06
Closing it by configuration
Switch the device code grant off for the users who have no device that needs it. Almost nobody in finance or legal signs in from a conference room display. This single setting removes the attack for most of the organisation and costs nothing.
Where the flow is genuinely needed, restrict it by device compliance and by network location, so a valid code approved from an unmanaged machine in another country still fails at the policy layer.
Alert on the grant type rather than on the person. A rule that fires whenever a device code sign-in succeeds is noisy for about a week, after which the legitimate uses are a short known list and everything else deserves a phone call.
Make session revocation part of the standard response. Resetting a password without ending sessions leaves the attacker exactly where they were, which is the single most common mistake in the first hour of one of these incidents.
07
What to tell people
Keep the lesson to one rule. Codes come out of devices in front of you and go into pages you opened yourself. A code that arrives in a message and asks to be entered somewhere is an attack, whoever appears to have sent it.
Give them a reporting route that is faster than deciding. Most people who fall for this had a flicker of doubt and no obvious place to put it, so they resolved it by complying.
Say plainly that approving one is not a firing offence. The reason these incidents run for days is that the person who approved the request works out what happened and then says nothing.
| What the defence looks for | Ordinary phishing | Device code phishing |
|---|---|---|
| Domain in the address bar | Lookalike or unrelated | The real provider domain |
| Certificate | Often fresh or mismatched | Valid, belongs to the provider |
| What the person types | Password and a code | A short code only |
| Where the password goes | To the attacker | Nowhere, it is never used |
| Effect of a password reset | Cuts the attacker off | Changes nothing on its own |
| What the attacker ends with | Credentials to replay | A live session and a registered device |
Questions and answers
Does multi factor authentication stop this?
Not by itself. The employee completes their second factor honestly on the real page, so the flow succeeds exactly as designed. The attack abuses a legitimate approval rather than bypassing the check.
Will changing the password help?
Only together with ending the sessions. The attacker holds a token that was issued at approval time and keeps working after a reset, which is why revocation has to happen in the same action.
How long does the attacker have to get the code entered?
Usually minutes, because the code expires quickly. That is why these messages press for speed, and it is also why a delay of a few minutes while someone checks is often enough to kill the attempt.
Can we just turn the device code flow off?
For most users, yes, and that is the cleanest fix. Keep it enabled only for the groups that genuinely sign in from displays or command line tools, and restrict those by device compliance.
What is the first thing to do once we spot one?
End every session for the account, remove the device that was registered, then check for mailbox rules and forwarding created after the approval. Password reset comes after those, not before.
How do we find out whether this already happened?
Search sign-in logs for the device code grant type across the last few months. Legitimate use is a short and predictable list, so anything outside it is worth a direct conversation with the user.