Topic starter
27/06/2026 1:41 pm
TL;DR: Device code phishing can convert a legitimate Microsoft sign-in into token theft, with refresh tokens surviving password resets unless accounts are explicitly revoked, according to Abnormal AI. The real defence is correlated identity, email, and post-compromise detection, because each step can look legitimate on its own.
Editorial analysis by NHI Mgmt Group, based on content published by Abnormal AI: “Why Device Code Phishing Demands a Modern Account Takeover Response”.
Key questions
Q: What breaks when a password reset is used as the only response to device code phishing?
A: A password reset may change the user secret, but it does not necessarily invalidate refresh tokens or active sessions that were issued earlier.
Q: Why do device code phishing attacks remain hard to confirm from a single login event?
A: Because the victim can authenticate on a real Microsoft page, the attacker can use a believable network location, and each step can appear legitimate in isolation.
Q: What are the clearest signs that a token-theft compromise is active?
A: Rogue MFA registration, suspicious mailbox rule creation, and security-setting changes are strong indicators that the attacker has moved beyond initial access and is trying to maintain persistence.
Practitioner guidance
- Correlate identity, email, and post-compromise telemetry Join sign-in logs, mailbox behaviour, MFA changes, and security-setting events so a legitimate-looking login can be evaluated in context rather than in isolation.
- Disable the account during containment Use account disablement to break refresh-token-based access before the attacker can continue session activity, because a password reset alone may leave tokens usable.
- Revoke active sessions explicitly Terminate live sessions and invalidate refresh tokens as part of response, especially when the compromise path involved device code phishing or other token theft.
Bottom line: Device code phishing works because it turns a legitimate Microsoft login flow into attacker-controlled token issuance, not because it defeats authentication outright.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
27/06/2026 3:07 pm
Token theft is now a session-governance problem, not just an authentication problem. Device code phishing succeeds because the attacker steals the output of a legitimate sign-in flow rather than forcing a failed one. That shifts the governance question from password strength to how identities, sessions, and tokens are validated across their full lifecycle. Practitioners should treat token issuance and token revocation as separate controls, not interchangeable outcomes.
A few things that frame the scale:
- Roughly 1 in 3 phishing payloads are delivered outside email, through channels such as social media, search ads and messaging apps.
A question worth separating out:
Q: What should teams do immediately after they suspect device code phishing?
A: Disable the account, revoke active sessions, and inspect mailbox and authentication settings before closing the incident. That sequence matters because refresh-token-based access can survive a password reset, so containment has to break the session as well as the credential path.
👉 Read our full editorial: Device code phishing turns Microsoft login flows into token theft