A worker finishes multifactor authentication on the real Microsoft login page and still leaves the attacker holding fresh access and refresh tokens. That is the N0va phishkit pattern reported in 2026: device-code phishing against workforce Microsoft sign-in, not a spoofed password box and not live OTP capture on a reverse proxy. According to eSecurity Planet, the kit obtains access and refresh tokens even when the victim completes MFA, because the victim authorizes an attacker-initiated device-code session on legitimate Microsoft infrastructure. Public reporting does not establish named victim organizations, confirmed record counts, or ransom figures.
How N0va turns real Microsoft sign-in into attacker tokens
Device-code authentication is the OAuth-style flow built for input-constrained clients. One side starts a device authorization request and receives a user code plus a verification URI. The human opens a browser, reaches Microsoft’s real sign-in experience, proves identity (password plus whatever MFA the account already uses), and enters the code. Tokens are then issued to the client that started the flow, not to “whoever typed the password on a phishing page.”
N0va’s operators flip that design. They start the device-code request. Lures push the victim toward completing the ceremony under everyday work themes. According to eSecurity Planet’s write-up of the campaign, impersonations include Microsoft Security, Teams, SharePoint, OneDrive, DocuSign, Google Drive, Dropbox, Zoom, and Adobe Sign. Infrastructure mixed compromised legitimate websites with Cloudflare Workers and Linode Object Storage, which keeps the path looking like routine productivity friction rather than a cartoon fake login.
The critical moment is not a mistyped password into attacker HTML. The victim lands on real login.microsoft.com, completes genuine authentication, and satisfies MFA there. eSecurity Planet put the failure mode in one line researchers keep quoting: “A genuine Microsoft sign-in page can still lead to an attacker-controlled session.” ANY.RUN’s sandbox observations, reported in early September 2026 without a public calendar day pinned in the secondary coverage, showed the same shape: the victim can complete MFA while authorizing the attacker-initiated session, which can result in valid access and refresh tokens.
No direct password or OTP harvest is required for that handoff. Whatever second factor the user already had (push, TOTP, or similar) only gates the real Microsoft ceremony. It does not bind the newly issued tokens away from the client that opened the device-code request. Calling this an “MFA failure at the prompt” misses the mechanism. Authentication succeeded. The session material went to the wrong party because the human approved the wrong client context.
Public reporting does not establish a single-company blast radius or a named threat-actor group beyond the N0va kit label. Coverage describes kit-level targeting of organizations in North America and Europe across government, technology, consulting, and healthcare. Treat those sectors as the reported aim of the lure set, not as a verified list of breached tenants.
| Control at the moment | What reporting shows | Why it did not stop token handoff |
|---|---|---|
| Password on real Microsoft page | Victim authenticates for real | Correct IdP still issues tokens to starter client |
| MFA on real Microsoft page | Victim completes MFA | MFA only gates that sign-in, not client binding |
| Device-code user approval | Victim enters attacker-started code | Authorizes attacker-held token endpoint |
| Phishing-resistant login factor alone | Not shown as a hard stop here | Still can authorize a malicious device-code client |
Why finishing MFA left refresh tokens with the attacker
Once Microsoft accepts the sign-in, access and refresh tokens are normal post-authentication artifacts. MFA has already done its job for that ceremony. It cannot un-issue tokens that a completed device-code grant just delivered to the attacker’s client.
That is why password resets and “prompt MFA again” theater fail as first responses if refresh tokens and related session state remain valid. The attacker is not sitting on a captured OTP seed. The attacker is sitting on cloud-issued secrets that SSO and API clients already trust. In a Microsoft 365 / Entra world, one good refresh path is a skeleton key across mail, files, chat, and whatever else federates from that identity plane. Classic SSO amplifies the mistake: many apps never demand a fresh human proof once the upstream token is accepted.
This pattern is adjacent to, not proven identical with, a Microsoft-documented device-code phishing campaign from April 2026. Microsoft described attackers directing victims through legitimate Microsoft authentication and receiving valid tokens after sign-in. That is the same authentication weakness class N0va abuses. Public reporting does not establish that N0va operators are the same actors as that April activity. Use the earlier campaign for timeline and control context, not for merged attribution.
On 1 July 2026, Microsoft Security Defaults began blocking device-code flow by default for new Entra tenants. Existing tenants stay exposed unless Conditional Access or equivalent policy restricts the grant. Kit operators did not need a novel crypto break. They needed organizations that still allowed device-code for workforce identities and users trained to “just complete the Microsoft prompt” when a DocuSign- or Teams-themed message said the file would not open otherwise.
Phishing-resistant authenticators harden the login ceremony against origin-spoofed password and OTP theater. They do not, by themselves, stop a user from authorizing a malicious device-code client on the real Microsoft origin. Public guidance cited in the eSecurity Planet report pairs stronger authenticators with explicit device-code restrictions, monitoring of suspicious device-code sign-ins, Token Protection where supported, risk-based Conditional Access, and revoke-and-contain steps that go beyond password reset. Factor upgrades without grant restrictions leave the approval path open.
From stolen tokens to PRT-oriented device persistence
Initial token theft is only the first post-auth move. Reporting on N0va describes follow-on token exchange and device registration aimed at Primary Refresh Token (PRT)-based SSO persistence on Entra. A PRT-backed posture is how Windows and Entra glue continuous SSO across resources. If operators register a device and obtain durable refresh material tied to that trust, access outlives the first browser session the lure created.
At that stage the problem is no longer “did MFA fire.” It is token possession plus device trust. Password reset does not automatically clear refresh tokens, registered devices, or PRT-backed SSO. Re-prompting MFA on one app does not evaporate a refresh token held elsewhere. Containment is revoke refresh tokens, review and remove suspicious device registrations, tighten Conditional Access, and apply Token Protection controls where the platform supports them. That work is operational hygiene after a completed authentication, not another push notification.
Files, mailboxes, or admin actions taken with those tokens are downstream of a successful identity handoff. No login factor undoes a session that already exists. Prevention value for this class sits in stopping or tightly constraining the device-code grant and in making stolen bearer material harder to replay from non-compliant clients, not in hoping the next MFA prompt scares off someone who already holds refresh tokens.
Compare the two industrial failure modes people keep mixing up. AiTM reverse-proxy kits that steal passwords and OTPs on a fake page are credential-phase theft of transferable factors. N0va, as reported, is not that story. Here the factors succeed on the real page, and the transferable prize is the token bundle issued afterward. Honest incident language matters: this attack happened after authentication succeeded for the attacker-started client. There was no MFA prompt left to “fail” at the moment tokens changed hands.
Defenders who only ask “did we enforce MFA?” will rubber-stamp a green checkbox while device-code remains broadly allowed. Defenders who ask “which grants can a phished human still approve, and how long do refresh tokens and device trust live?” are closer to the actual kill chain.
If you want to skip the attack details and go straight to what can stop this path, read the related article on mfa2point0.com: Entra controls that address N0va-style device-code token theft.
FAQ
Did N0va steal passwords or one-time codes from a fake Microsoft page?
No. Public reporting on the N0va phishkit describes device-code phishing in which victims complete genuine sign-in and MFA on real Microsoft login infrastructure while authorizing an attacker-initiated session. According to eSecurity Planet, the attacker receives issued access and refresh tokens after that success. The coverage does not describe classic AiTM reverse-proxy capture of passwords or OTPs as the required first step.
Why did MFA on login.microsoft.com not keep the tokens away from attackers?
MFA on login.microsoft.com only proved the human to Microsoft for that ceremony. In the N0va pattern, the device-code grant had already been started by the attacker, so completed authentication caused Microsoft to issue access and refresh tokens to the attacker’s client. MFA does not reassign or void those tokens after a successful grant. The failure sits in client authorization and token issuance, not in a missing second factor on a spoofed form.
Is N0va the same campaign Microsoft documented in April 2026?
Public reporting does not establish that N0va operators are the same actors as the April 2026 Microsoft-documented device-code phishing campaign. Both abuse the same weakness class: victims authenticate on legitimate Microsoft infrastructure and attackers receive valid tokens afterward. Treat the April activity as adjacent context for the technique and for control guidance, not as proven shared attribution with the N0va kit label.
Does resetting the user’s password kick N0va operators out?
Not reliably by itself. After N0va-style theft, attackers may hold refresh tokens and pursue token exchange plus device registration for PRT-oriented SSO persistence. Password reset and a fresh MFA prompt do not automatically clear refresh tokens, registered devices, or PRT-backed SSO. Microsoft-oriented guidance summarized in public reporting emphasizes revoking refresh tokens, restricting device-code authentication, monitoring suspicious device-code sign-ins, using Token Protection where supported, and containing device trust, not password change alone.
Which organizations were confirmed hit, and how many records leaked?
Public reporting does not establish named victim organizations, confirmed compromise totals, or affected record counts for the N0va phishkit. Coverage describes a kit-level campaign with observed targeting themes in North America and Europe across government, technology, consulting, and healthcare. Until primary disclosures name tenants and figures, those details remain unknown.
