How are you defending against EvilToken-style device code phishing?
Asked by
MellowCedar47
We've had several near-breaches involving an EvilToken-style attack. A compromised account sends convincing messages to everyone in the victim's address book, often linking to a legitimate-looking SharePoint site. When someone follows the link, they're shown a spoofed Microsoft sign-in and MFA flow, which tricks them into authorizing the attacker's device and continuing the campaign. What controls and response steps are working for your organization?
Answers
Use layered access controls: require phishing-resistant MFA such as FIDO2 security keys or passkeys for higher-risk users, require compliant corporate-owned devices, and block unfamiliar sign-in conditions. A policy requiring corporate devices can stop authorization attempts from unmanaged systems.
Reply to this answer
If device code authentication is part of the attack path, block that flow with a Conditional Access policy unless there’s a documented business need for it. It’s better to remove the execution path than rely entirely on users recognizing a very convincing message.
Reply to this answer
User training and realistic internal simulations are still useful, especially because these messages can come from trusted partners or internal divisions and may point to genuine Microsoft or SharePoint pages. But training shouldn’t be the primary defense—this is difficult for users to identify when the sender and destination both appear legitimate.
Reply to this answer
Have a containment playbook ready for anyone who may have approved one of these prompts. Revoke active sessions and refresh tokens, reset the password, remove unauthorized authentication methods, review OAuth app consent, inspect inbox rules and forwarding, check recent SharePoint activity, and look for suspicious outbound mail. Fast help-desk escalation is important so the response doesn’t get improvised during an incident.
Reply to this answer
Add your answer
Answers are reviewed before publication.
MellowCedar47: That makes sense. We’re looking at device restrictions alongside blocking the device code flow so we’re not depending on just one control.