Notifications
Clear all
Topic starter
14/07/2026 4:26 pm
TL;DR: Device code phishing is moving from niche technique to mainstream account takeover, with Proofpoint linking the rise to publicly released toolkits, phishing-as-a-service offerings, and LLM-generated attack content that lets attackers steal Microsoft 365 tokens at scale. The real failure is not MFA itself, but identity programmes that still assume a human will notice and reject the approval step in time.
NHIMG editorial — based on content published by Proofpoint: device code phishing threat analysis and campaign observations
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- Only 5.7% of organisations have full visibility into their service accounts.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: How should security teams reduce device code phishing risk in Microsoft 365 environments?
A: Security teams should limit device-code authentication to approved use cases, pair it with compliant-device requirements, and add sign-in detections for unusual polling, consent, and post-login mailbox activity.
Q: Why do device code phishing attacks bypass many standard phishing controls?
A: They use the real Microsoft login page, so there is no fake domain, no malicious payload, and no obvious infrastructure to block.
Q: What do organisations get wrong about defending against OAuth phishing?
A: They often over-focus on blocking suspicious links and under-focus on the legitimacy of the downstream login ceremony.
Practitioner guidance
- Block device-code flows for unmanaged access paths Restrict device authorization grants to approved device states and compliant endpoints, then monitor exceptions tightly where the flow must remain available.
- Instrument sign-in telemetry for code-polling abuse Correlate device-code issuance, token polling, and unusual consent activity so the attack chain is visible in identity logs.
What's in the full article
Proofpoint's full analysis covers the operational detail this post intentionally leaves for the source:
- Campaign-level examples of device-code phishing lures, landing pages, and QR-code delivery patterns.
- Observed PhaaS tooling, including how operators package token capture and campaign management.
- Detection-oriented indicators of compromise, including landing page patterns and API activity associated with device-code abuse.
- Additional examples of multilingual campaigns and actor tradecraft that help teams tune detections.
👉 Read Proofpoint's analysis of device code phishing and token theft →
Device code phishing is outpacing MFA-aware IAM controls?
Explore further
14/07/2026 4:34 pm
Device code phishing is not an MFA failure, it is a trust-boundary failure. The attack succeeds because identity programmes still treat a code entered into a trusted portal as a low-risk user action, even when the prompt was socially engineered. Once the portal is legitimate, many controls stop seeing maliciousness and only see normal authentication. Practitioners should treat this as a governance gap between authentication assurance and attacker influence.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who is accountable when browser-based phishing leads to account takeover?
A: Accountability usually spans identity security, endpoint protection, and the business owners of high-value accounts such as advertising platforms. The practical answer is to define who owns browser-based authentication risk, who monitors suspicious redirects, and who can revoke access or sessions immediately.
👉 Read our full editorial: Device code phishing is outpacing MFA-aware IAM controls
