Notifications
Clear all
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.
NHIMG editorial — based on content published by Abnormal AI: device code phishing and token theft through the VENOM attack flow
Questions worth separating out
Q: How should security teams handle device code phishing in Microsoft 365?
A: Treat device code phishing as token theft, not as a simple login anomaly.
Q: Why do password resets sometimes fail to stop Microsoft 365 compromise?
A: Password resets can fail because the attacker may already hold valid refresh tokens.
Q: What should teams look for after a suspicious Microsoft login?
A: Look for the behaviour that follows the login, not the login itself.
Practitioner guidance
- Block device code flows where they are not required Restrict device code authentication to approved use cases and high-friction exception paths.
- Treat token revocation as a first-class containment step When compromise is suspected, revoke refresh tokens and disable the account rather than relying on password reset alone.
- Correlate identity and mailbox behaviour during triage Investigate suspicious sign-ins alongside mailbox rule creation, MFA method changes, security settings access, and related post-login activity.
What's in the full article
Abnormal AI's full report covers the operational detail this post intentionally leaves for the source:
- The exact VENOM attack flow from device code request to token capture and session persistence.
- Examples of follow-on attacker behaviours such as rogue MFA registration and mailbox rule creation.
- Containment workflow detail for session sign-out, token revocation, password reset, and account disablement.
- Behavioral detection logic used to distinguish a legitimate-looking sign-in from active compromise.
👉 Read Abnormal AI's analysis of device code phishing and token theft →
Device code phishing and token theft: are your controls keeping up?
Explore further
27/06/2026 3:07 pm
Device code phishing is a session-trust failure, not a password failure. The attack works because defenders still over-weight authentication success as evidence of legitimacy. In reality, the victim can complete a genuine Microsoft login while the attacker captures the resulting session artefacts, which means the control problem has moved from password protection to session authenticity and revocation. Practitioners should treat successful sign-in as an input to correlation, not as proof of safety.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who is accountable when token-based account takeover succeeds?
A: Accountability sits with the team responsible for authentication policy, token revocation, and incident containment across identity and email systems. If the programme cannot revoke sessions quickly, it has accepted a persistence risk that password management alone cannot solve.
👉 Read our full editorial: Device code phishing turns Microsoft login flows into token theft
