Key Takeaways <\/h2>\n\n\n\n\n- OAuth Device Code phishing is rising rapidly. <\/strong>Campaigns abusing Microsoft\u2019s Device Authorization Grant are increasing, with hundreds of phishing URLs appearing in short timeframes. <\/li>\n<\/ul>\n\n\n\n
\n- Account takeover can occur without credential theft. <\/strong>Victims authenticate on legitimate Microsoft pages, yet attackers still receive OAuth tokens that grant account access. <\/li>\n<\/ul>\n\n\n\n
\n- The attack abuses legitimate authentication flows. <\/strong>Threat actors initiate the device authorization process themselves and trick victims into approving it. <\/li>\n<\/ul>\n\n\n\n
\n- Token abuse replaces password theft. <\/strong>Access tokens and refresh tokens allow attackers to operate within Microsoft 365 without needing stolen credentials. <\/li>\n<\/ul>\n\n\n\n
\n- Encrypted HTTPS traffic hides attack signals. <\/strong>Because activity happens on legitimate domains and encrypted channels, detection using traditional indicators becomes harder. <\/li>\n<\/ul>\n\n\n\n
\n- Automatic SSL decryption improves detection speed. <\/strong>ANY.RUN Sandbox extracts SSL keys from process memory to decrypt HTTPS traffic, revealing hidden scripts and network activity that enable faster investigations and reduced MTTD and MTTR. <\/li>\n<\/ul>\n\n\n\n
How the Attack Works <\/h2>\n\n\n\n
In this campaign, attackers abuse Microsoft\u2019s device login process<\/strong>, which is normally used to sign in on devices that cannot display a full login page. <\/p>\n\n\n\nThe attacker first initiates a login request with Microsoft. This generates two values: <\/p>\n\n\n\n
\n- user_code<\/strong> \u2014 a short, human-readable code (e.g., EL4BGRHUZ) displayed on the fake page as a \u201cverification code;\u201d <\/li>\n<\/ul>\n\n\n\n
\n- device_code<\/strong> \u2014 an internal session identifier held only by the attacker, never shown to the victim. This is the ‘claim ticket’ the attacker uses to poll Microsoft’s token endpoint. <\/li>\n<\/ul>\n\n\n\n
The victim is then shown the user_code<\/strong> on a phishing page, often disguised as a document verification step (for example, a fake DocuSign notification). The page instructs the user to copy the code and enter it at microsoft[.]com\/devicelogin<\/strong>. <\/p>\n\n\n\nFrom the user\u2019s perspective, everything appears legitimate. They are redirected to a real Microsoft page, where they enter their credentials and complete MFA. <\/p>\n\n\n\n
However, by entering the verification code, the user is unknowingly approving a login request that was initiated by the attacker. While the victim sees only the user_code<\/strong>, the attacker uses the associated device_code<\/strong> to collect authentication tokens from Microsoft once the approval is completed. <\/p>\n\n\n\nMicrosoft then issues access tokens<\/strong> to the attacker\u2019s session, allowing them to access the victim\u2019s Microsoft 365 account. Because the login happens through legitimate Microsoft infrastructure, no credentials are stolen on the phishing page and no fake login form is required. <\/p>\n\n\n\nWhy This Attack Poses a Critical Risk and Is Harder for SOC Teams to Detect <\/h2>\n\n\n\n
OAuth Device Code phishing changes how account compromise happens. This campaign represents a structural shift: <\/p>\n\n\n\n
\n- The victim interacts with legitimate Microsoft domains; <\/li>\n<\/ul>\n\n\n\n
\n- Credentials and MFA are entered on authentic pages; <\/li>\n<\/ul>\n\n\n\n
\n- The attack runs entirely over encrypted HTTPS; <\/li>\n<\/ul>\n\n\n\n
\n- Traditional phishing indicators may not trigger. <\/li>\n<\/ul>\n\n\n\n
As a result, token abuse replaces password theft. Detection relies heavily on visibility into encrypted network traffic and behavioral artifacts rather than domain reputation alone. <\/p>\n\n\n\n
For SOC teams, this means: <\/p>\n\n\n\n
\n- Delayed detection<\/strong>: Account compromise may only be noticed after suspicious activity appears. <\/li>\n<\/ul>\n\n\n\n
\n- Longer investigations<\/strong>: Analysts must reconstruct token-based access rather than analyze credential theft. <\/li>\n<\/ul>\n\n\n\n
\n- Higher incident impact<\/strong>: Attackers can operate inside Microsoft 365 immediately after token issuance. <\/li>\n<\/ul>\n\n\n\n
For organizations, this creates a critical risk<\/strong>: attackers can immediately access corporate email, internal documents, and shared resources, impersonate employees in business email compromise schemes, and potentially maintain persistent access through refresh tokens, turning a single phishing interaction into data exposure, financial fraud, or broader account compromise<\/strong>. <\/p>\n\n\n\nOAuth Device Code Phishing Example: Full Attack Analysis <\/h2>\n\n\n\n
- \n
- Account takeover can occur without credential theft. <\/strong>Victims authenticate on legitimate Microsoft pages, yet attackers still receive OAuth tokens that grant account access. <\/li>\n<\/ul>\n\n\n\n
- \n
- The attack abuses legitimate authentication flows. <\/strong>Threat actors initiate the device authorization process themselves and trick victims into approving it. <\/li>\n<\/ul>\n\n\n\n
- \n
- Token abuse replaces password theft. <\/strong>Access tokens and refresh tokens allow attackers to operate within Microsoft 365 without needing stolen credentials. <\/li>\n<\/ul>\n\n\n\n
- \n
- Encrypted HTTPS traffic hides attack signals. <\/strong>Because activity happens on legitimate domains and encrypted channels, detection using traditional indicators becomes harder. <\/li>\n<\/ul>\n\n\n\n
- \n
- Automatic SSL decryption improves detection speed. <\/strong>ANY.RUN Sandbox extracts SSL keys from process memory to decrypt HTTPS traffic, revealing hidden scripts and network activity that enable faster investigations and reduced MTTD and MTTR. <\/li>\n<\/ul>\n\n\n\n
How the Attack Works <\/h2>\n\n\n\n
In this campaign, attackers abuse Microsoft\u2019s device login process<\/strong>, which is normally used to sign in on devices that cannot display a full login page. <\/p>\n\n\n\n
The attacker first initiates a login request with Microsoft. This generates two values: <\/p>\n\n\n\n
- \n
- user_code<\/strong> \u2014 a short, human-readable code (e.g., EL4BGRHUZ) displayed on the fake page as a \u201cverification code;\u201d <\/li>\n<\/ul>\n\n\n\n
- \n
- device_code<\/strong> \u2014 an internal session identifier held only by the attacker, never shown to the victim. This is the ‘claim ticket’ the attacker uses to poll Microsoft’s token endpoint. <\/li>\n<\/ul>\n\n\n\n
The victim is then shown the user_code<\/strong> on a phishing page, often disguised as a document verification step (for example, a fake DocuSign notification). The page instructs the user to copy the code and enter it at microsoft[.]com\/devicelogin<\/strong>. <\/p>\n\n\n\n
From the user\u2019s perspective, everything appears legitimate. They are redirected to a real Microsoft page, where they enter their credentials and complete MFA. <\/p>\n\n\n\n
However, by entering the verification code, the user is unknowingly approving a login request that was initiated by the attacker. While the victim sees only the user_code<\/strong>, the attacker uses the associated device_code<\/strong> to collect authentication tokens from Microsoft once the approval is completed. <\/p>\n\n\n\n
Microsoft then issues access tokens<\/strong> to the attacker\u2019s session, allowing them to access the victim\u2019s Microsoft 365 account. Because the login happens through legitimate Microsoft infrastructure, no credentials are stolen on the phishing page and no fake login form is required. <\/p>\n\n\n\n
Why This Attack Poses a Critical Risk and Is Harder for SOC Teams to Detect <\/h2>\n\n\n\n
OAuth Device Code phishing changes how account compromise happens. This campaign represents a structural shift: <\/p>\n\n\n\n
- \n
- The victim interacts with legitimate Microsoft domains; <\/li>\n<\/ul>\n\n\n\n
- \n
- Credentials and MFA are entered on authentic pages; <\/li>\n<\/ul>\n\n\n\n
- \n
- The attack runs entirely over encrypted HTTPS; <\/li>\n<\/ul>\n\n\n\n
- \n
- Traditional phishing indicators may not trigger. <\/li>\n<\/ul>\n\n\n\n
As a result, token abuse replaces password theft. Detection relies heavily on visibility into encrypted network traffic and behavioral artifacts rather than domain reputation alone. <\/p>\n\n\n\n
For SOC teams, this means: <\/p>\n\n\n\n
- \n
- Delayed detection<\/strong>: Account compromise may only be noticed after suspicious activity appears. <\/li>\n<\/ul>\n\n\n\n
- \n
- Longer investigations<\/strong>: Analysts must reconstruct token-based access rather than analyze credential theft. <\/li>\n<\/ul>\n\n\n\n
- \n
- Higher incident impact<\/strong>: Attackers can operate inside Microsoft 365 immediately after token issuance. <\/li>\n<\/ul>\n\n\n\n
For organizations, this creates a critical risk<\/strong>: attackers can immediately access corporate email, internal documents, and shared resources, impersonate employees in business email compromise schemes, and potentially maintain persistent access through refresh tokens, turning a single phishing interaction into data exposure, financial fraud, or broader account compromise<\/strong>. <\/p>\n\n\n\n
OAuth Device Code Phishing Example: Full Attack Analysis <\/h2>\n\n\n\n
- Higher incident impact<\/strong>: Attackers can operate inside Microsoft 365 immediately after token issuance. <\/li>\n<\/ul>\n\n\n\n
- Longer investigations<\/strong>: Analysts must reconstruct token-based access rather than analyze credential theft. <\/li>\n<\/ul>\n\n\n\n
- Delayed detection<\/strong>: Account compromise may only be noticed after suspicious activity appears. <\/li>\n<\/ul>\n\n\n\n
- Traditional phishing indicators may not trigger. <\/li>\n<\/ul>\n\n\n\n
- The attack runs entirely over encrypted HTTPS; <\/li>\n<\/ul>\n\n\n\n
- Credentials and MFA are entered on authentic pages; <\/li>\n<\/ul>\n\n\n\n
- The victim interacts with legitimate Microsoft domains; <\/li>\n<\/ul>\n\n\n\n
- device_code<\/strong> \u2014 an internal session identifier held only by the attacker, never shown to the victim. This is the ‘claim ticket’ the attacker uses to poll Microsoft’s token endpoint. <\/li>\n<\/ul>\n\n\n\n
- user_code<\/strong> \u2014 a short, human-readable code (e.g., EL4BGRHUZ) displayed on the fake page as a \u201cverification code;\u201d <\/li>\n<\/ul>\n\n\n\n
- Automatic SSL decryption improves detection speed. <\/strong>ANY.RUN Sandbox extracts SSL keys from process memory to decrypt HTTPS traffic, revealing hidden scripts and network activity that enable faster investigations and reduced MTTD and MTTR. <\/li>\n<\/ul>\n\n\n\n
- Encrypted HTTPS traffic hides attack signals. <\/strong>Because activity happens on legitimate domains and encrypted channels, detection using traditional indicators becomes harder. <\/li>\n<\/ul>\n\n\n\n
- Token abuse replaces password theft. <\/strong>Access tokens and refresh tokens allow attackers to operate within Microsoft 365 without needing stolen credentials. <\/li>\n<\/ul>\n\n\n\n
- The attack abuses legitimate authentication flows. <\/strong>Threat actors initiate the device authorization process themselves and trick victims into approving it. <\/li>\n<\/ul>\n\n\n\n
![\"\"](\"\/cybersecurity-blog\/wp-content\/uploads\/2026\/03\/image-1-1024x562.png\")
![\"\"](\"\/cybersecurity-blog\/wp-content\/uploads\/2026\/03\/image2-1-1024x711.png\")