During our recent incident response engagements, we observed a 37x increase in token theft attempts targeting Microsoft Entra ID (formerly Azure AD) tenants. The primary vector is no longer simple password harvesting but the abuse of the OAuth 2.0 Device Authorization Grant (RFC 8628). This flow, designed for input-constrained devices like smart TVs or CLI tools, allows an attacker to bypass Multi-Factor Authentication (MFA) by tricking a user into authorizing a malicious session on a secondary device.
Device Code Phishing Explained: The Mechanics of OAuth 2.0 Exploitation
The Device Code Flow is a four-step process. First, a client (the attacker's script) requests a code from the authorization server. The server returns a user_code and a device_code. The attacker then presents the user_code to the victim via a phishing email, directing them to https://microsoft.com/devicelogin.
Once the victim enters the code and authenticates, the attacker’s script, which has been polling the token endpoint in the background, receives an access_token and a refresh_token. Because the victim performed the MFA on their own trusted device, the token issued to the attacker is fully validated. We have seen this used to gain persistent access to Exchange Online and SharePoint without ever knowing the victim's password. This highlights the critical need for a shared SSH key alternative that relies on identity-based access rather than static credentials or easily phished tokens.
The Role of Microsoft Device Login in Modern Phishing Schemes
Microsoft’s implementation of this flow is particularly vulnerable to social engineering because the login page is hosted on a legitimate Microsoft domain. Unlike traditional phishing where the URL micros0ft-login.com might trigger suspicion, microsoft.com/devicelogin is a trusted site. The attacker only needs to convince the user that the code is for a legitimate purpose, such as a "Mandatory Security Update" or "IT Support Session."
Why Attackers are Moving Beyond Traditional Credential Harvesting
Traditional phishing is failing against mature organizations. With the mandate for MFA becoming standard across Indian financial sectors and global enterprises, stealing a password is often useless. Device code phishing provides a "Session-as-a-Service" outcome. By capturing the token, the attacker inherits the user's session context, including their MFA claims and conditional access compliance status.
We analyzed several kits being sold on darknet forums for approximately ₹40,000 (roughly $500). These kits automate the polling process and immediately use the captured tokens to dump the Global Address List (GAL) or set up mailbox forwarding rules. This speed makes manual detection nearly impossible without automated SIEM logic.
Anatomy of a Device Code Phishing Campaign
A typical campaign begins with the attacker initiating a request to the Microsoft identity platform. They use a public client ID, often the one associated with the Microsoft Office or Azure PowerShell applications, to appear legitimate.
Example of an attacker initiating a device code request using PowerShell's Client ID
curl -X POST https://login.microsoftonline.com/common/oauth2/v2.0/devicecode \ -d "client_id=1950a258-227b-4e31-a9cf-717495945fc2" \ -d "scope=https://graph.microsoft.com/.default offline_access"
The response from the server provides the user_code that the attacker will send to the victim. The attacker then starts a polling loop to wait for the user to complete the authentication.
Common Lures Used in Microsoft 365 Phishing Campaigns
We have identified three primary lures used in 2024 and 2025:
- The "MFA Verification" Lure: "Your account requires a secondary device verification. Please go to microsoft.com/devicelogin and enter the code: ABC-DEF."
- The "Shared Document" Lure: "An encrypted document has been shared. To view it on your workstation, authorize the secure viewer using the following code."
- The "IT Support" Lure: "A remote support session has been initiated by your administrator. Please authorize the connection."
Case Study: Insights from Device Code Phishing Proofpoint Research
Research from Proofpoint and our own internal telemetry shows that attackers are increasingly targeting high-value individuals (VIPs) and IT administrators. In one instance, an attacker successfully compromised a Global Admin account in a Mumbai-based fintech firm. The attacker used the Azure PowerShell client ID, which allowed them to bypass most basic Conditional Access policies that only looked for "Browser" or "Mobile App" platforms.
The breach resulted in the exfiltration of sensitive financial data, violating several clauses of the DPDP Act 2023. The organization failed to notify the authorities within the required timeframe because they could not distinguish the attacker's PowerShell session from legitimate administrative activity.
The Evolution of Device Code Phishing in 2025
In 2025, we are seeing the rise of "Phishing-as-a-Service" (PaaS) platforms that integrate device code flows. These platforms provide a dashboard for attackers to manage thousands of concurrent polling sessions.
New Trends and Sophisticated Tactics for 2025
Attackers are now using proxy-aware scripts that rotate IP addresses to match the victim's geographic location. If the victim is based in Bengaluru, the attacker will poll the token endpoint from a Bengaluru-based VPN or residential proxy. This defeats simple "impossible travel" alerts in the SIEM.
Bypassing Multi-Factor Authentication (MFA) via Device Authorization
The critical flaw in the device code flow is that it decouples the authentication device from the authorized device. The victim performs the MFA on their phone or laptop, but the token is issued to the attacker's machine. Since the token contains the amr (Authentication Methods Reference) claim for MFA, subsequent requests using that token are considered fully authenticated.
The Rise of Automated Phishing-as-a-Service (PaaS) Toolkits
Toolkits like Evilnoob and TokenTactics have been updated to support automated token refreshing. Once a token is captured, these tools automatically request a new one before the old one expires, ensuring persistent access even if the user changes their password (unless sessions are explicitly revoked).
Red Team Perspectives: Simulating Device Code Phishing
To test organizational resilience, we use several open-source frameworks to simulate these attacks. The goal is to identify if the SOC can detect the specific device_code grant type in the logs.
Device Code Phishing Red Team Tools and Frameworks
One of the most effective tools for this is AADInternals. It allows a red teamer to initiate the flow and poll for tokens with a single command.
Using AADInternals to simulate a device code attack
Import-Module AADInternals Get-AADIntAccessTokenWithDeviceCode -ClientId "1950a258-227b-4e31-a9cf-717495945fc2" -Resource "https://graph.microsoft.com"
Testing Organizational Resilience Against Token Theft
When we conduct these exercises, we look for two things:
- Does the SIEM trigger an alert when a device code flow is initiated from an unknown IP?
- Does the Conditional Access policy block the flow for users who do not require it?
Ethical Hacking: Demonstrating the Impact of a Successful Breach
After obtaining the token, we demonstrate impact by accessing the Microsoft Graph API. We can dump emails, modify inbox rules, or even create new guest accounts if the compromised user has sufficient permissions.
Accessing Graph API with a stolen token to list messages
curl -H "Authorization: Bearer " "https://graph.microsoft.com/v1.0/me/messages"
Detection Strategies: Identifying Device Code Phishing Attacks
Detection must center on the SigninLogs and AADNonInteractiveUserSignInLogs tables in Microsoft Sentinel or any SIEM ingesting Entra ID logs. To handle the volume of logs effectively, organizations should focus on optimizing SOC workflows through automated correlation.
Device Code Phishing Detection: Key Indicators of Compromise (IoCs)
The most reliable IoC is the AuthenticationProtocol field. Legitimate device code flows are rare in a standard corporate environment.
Monitoring Azure AD Sign-in Logs for Anomalous Device Registrations
We recommend using KQL (Kusto Query Language) to hunt for these events. Look for successful sign-ins where the protocol is deviceCode and the AppDisplayName is a common administrative tool like "Azure PowerShell" or "Microsoft Office."
// KQL Query for Microsoft Sentinel to detect Device Code Flow SigninLogs | where AuthenticationProtocol == "deviceCode" | where ResultType == 0 // Success | extend DeviceId = tostring(DeviceDetail.deviceId) | project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, DeviceId, Location | sort by TimeGenerated desc
Leveraging SIEM and EDR for Real-Time Alerting
We also monitor for "Token Replay" signatures. If a token is used from an IP address that differs significantly from the one that performed the authentication, it should trigger a high-severity alert. In India, where many employees use mobile hotspots or varying ISP routes, we tune this logic to look for ASN (Autonomous System Number) changes rather than just IP changes.
Detecting Polling Behavior in Web Logs
If you have visibility into outbound web traffic, you can look for repeated POST requests to /common/oauth2/v2.0/token with the grant_type=urn:ietf:params:oauth:grant-type:device_code. A high frequency of these requests from a single source IP is indicative of an attacker polling for a victim's response.
Prevention and Mitigation: Securing the Authentication Flow
Prevention is more effective than detection, given the speed of token exploitation. The primary defense is restricting the use of the device code flow entirely.
Device Code Phishing Prevention Best Practices
We recommend a "Deny by Default" approach. Most users do not need to use the device code flow. It should be restricted to specific service accounts or developers who require secure SSH access for teams via CLI tools.
Configuring Device Code Phishing Conditional Access Policies
Microsoft Entra ID allows you to control the device code flow via Conditional Access. However, it is not a direct toggle. Instead, you must use "Authentication Contexts" or restrict the "Global Reader" and other admin roles to specific trusted locations or compliant devices.
Restricting the Device Authorization Grant Flow in Microsoft Entra ID
The most effective way to block this attack is to use the "Continuous Access Evaluation" (CAE) and strictly define "Workload Identities." For standard users, you can use a Conditional Access policy to block access to "All Cloud Apps" when the device is not marked as compliant or hybrid joined, which effectively kills the attacker's ability to use the token on their non-managed machine.
User Awareness Training: Spotting Device Code Requests
Users must be taught that microsoft.com/devicelogin is only for secondary devices like conference room TVs or printers. If they receive a code request while browsing on their laptop, it is a 100% indicator of a phishing attempt. We have found that internal simulations using tools like Gophish, modified for device codes, reduce click rates by 60% over six months.
Conclusion: Building a Robust Defense Against Device-Based Attacks
The shift toward device code phishing represents a natural evolution in the threat landscape. As MFA becomes ubiquitous, attackers will continue to target the session itself rather than the credentials. SOC teams must adapt by moving beyond simple "failed login" alerts and focusing on the telemetry of successful, yet anomalous, authentication flows.
Summary of the 2025 Threat Landscape
We expect to see more integration between device code phishing and Adversary-in-the-Middle (AiTM) attacks. The goal is the same: the acquisition of a high-value session token. Organizations must also consider the legal implications under the DPDP Act 2023, where a failure to implement "reasonable security safeguards" (like monitoring for known OAuth abuses) could lead to significant penalties.
Final Checklist for Securing Microsoft Environments
- Disable the Device Code Flow for all users except those with a documented business need.
- Implement a KQL-based alert in Microsoft Sentinel for
AuthenticationProtocol == "deviceCode". - Audit all
AppIdpermissions to ensure that public clients cannot request high-privilege scopes. - Enforce "Compliant Device" requirements in Conditional Access to prevent token usage on attacker-controlled hardware.
- Review CERT-In advisory CIAD-2023-0038 for additional guidance on phishing mitigation in the Indian context.
To verify your current exposure, run the following command to check for any recent successful device code logins in your tenant using the Azure CLI:
List successful device code sign-ins in the last 24 hours
az monitor logged-analytics query --workspace --analytics-query "SigninLogs | where AuthenticationProtocol == 'deviceCode' and ResultType == 0 | project TimeGenerated, UserPrincipalName"