A genuine Microsoft sign-in page can still lead to an attacker-controlled session. The N0va phishkit abuses device-code authentication to obtain access and refresh tokens even when a victim completes multifactor authentication (MFA).
ANY.RUN disclosed N0va in September 2026 after observing targeting across North America and Europe, including government, technology, consulting, and healthcare organizations. The campaign spans enterprises that may manage Microsoft identities across multiple cloud tenants, offices, and jurisdictions, increasing the need for consistent identity monitoring and access controls.
How N0va abuses Microsoft device-code authentication
In its analysis of the N0va phishkit, ANY.RUN documented lures impersonating Microsoft Security, Teams, SharePoint, OneDrive, DocuSign, Google Drive, Dropbox, Zoom, and Adobe Sign. Researchers also observed attack infrastructure distributed among compromised legitimate websites, Cloudflare Workers, and Linode Object Storage.
N0va initiates an authentication request and convinces the victim to complete it through Microsoft’s legitimate sign-in infrastructure. The victim can complete MFA while authorizing the attacker-initiated session, which can result in valid access and refresh tokens. Similar attacks have driven a broader rise in device-code phishing against Microsoft 365 accounts.
Microsoft documented the same authentication weakness in a separate April 2026 campaign. Attackers directed victims through legitimate Microsoft authentication and received valid tokens after sign-in.
ANY.RUN also observed N0va using token exchange and device registration in an attempt to establish Primary Refresh Token-based single sign-on access. Stolen or attacker-obtained tokens can make malicious activity resemble normal account use, a challenge also seen when malicious Microsoft 365 logins blend in with legitimate traffic.
Blocking device-code abuse and token replay
Microsoft recommends getting as close as possible to blocking device-code flow outright, while limiting exceptions to documented use cases in its Conditional Access guidance.
Security teams can reduce exposure through seven measures:
- Audit and restrict device-code authentication. Identify legitimate dependencies and tightly scope any exceptions.
- Monitor suspicious authentication activity. Investigate unexpected device-code sign-ins, unfamiliar applications, unusual locations, and privileged-account activity.
- Strengthen authentication for high-risk accounts. Use passkeys or FIDO2 security keys, while maintaining device-code restrictions because phishing-resistant authentication alone does not prevent malicious authorization requests.
- Use Token Protection where supported. Microsoft’s Token Protection control can require device-bound sign-in session tokens for supported applications and devices.
- Apply risk-based access controls. Use Conditional Access and identity-risk signals to challenge or block suspicious authentication.
- Contain compromised identities beyond password resets. Revoke refresh tokens, force reauthentication, review account and device changes, and disable accounts when immediate containment is necessary.
- Test incident response plans for token theft. Exercise token revocation, identity-log review, account containment, and coordination among SOC, IAM, email, and cloud teams.
Attackers increasingly target session tokens and authentication workflows, making token activity an important part of post-login monitoring.
Since July 1, 2026, new Entra tenants have blocked device-code flow through Microsoft Security Defaults. N0va shows how legitimate authentication can be abused when users authorize the wrong session, requiring defenders to validate both the authentication request and the token activity that follows.
Read more: A separate campaign shows the same identity-security pressure from another direction: BigBear 2.0 stole authenticated Microsoft 365 sessions across hundreds of targeted organizations, reinforcing the need to monitor what happens after MFA succeeds.