.png)
Attackers persuaded employees to complete a legitimate device-based login, handing over valid tokens that granted access without a password. They used social engineering to send short codes and a login link so the victim would enter the code on a browser and approve the session. Once approved, the attacker received tokens and used APIs to read mail, find credentials, and spread further messages inside the organization. In some cases they registered a device to snatch a Primary Refresh Token (PRT) and stayed authenticated for months. This technique is stealthy because it uses normal authentication endpoints and can evade controls that watch for password failures or unusual sign-in errors.
The Device Code flow is an OAuth pattern that lets users authenticate a device or app that lacks a browser by entering a short code on a separate trusted device. It separates the token request from the user interaction so a headless client can get tokens after the user approves the code on another device. This is common in CLIs, IoT appliances, and automation scripts, and integrates with MFA in many environments. It’s designed for convenience and accessibility but also creates a different attack surface than browser-based logins. Administrators should treat these flows as high-value and monitor their use closely.
Attackers abuse the flow by initiating a legitimate device authorization and baiting a user to enter the displayed short code in their browser, effectively granting access to the attacker. Because approvals happen on a separate device, the user may believe they are completing a benign action. After approval the attacker receives tokens that can be exchanged for API access and refresh tokens. They can then read mail, enumerate contacts, and send more convincing phishing messages from within the organization. The campaign becomes self-sustaining if the attacker can register devices or obtain refresh tokens for persistent access.
Top indicators are unexpected device authorization requests tied to legitimate sign-in endpoints and approvals from unfamiliar devices or locations. Look for short-code approvals without an accompanying interactive browser session from the originating client, and API calls that suddenly appear on accounts that normally don’t use headless logins. Suspicious mailbox searches or mass forwarding rules are also red flags. Audit logs that show token issuance via a device code grant should be investigated, especially if followed by mailbox reads or token refresh actions. Rapid propagation of similar messages inside the tenant is another clear signal.
MFA reduces risk but does not fully block device code abuse because the user still explicitly approves the login during authentication. When a user completes the MFA step in their browser, the attacker benefits from that legitimate approval. MFA helps when combined with contextual policies that block authorizations from risky devices or locations, and when paired with detection for unusual token issuance. Relying on MFA alone is insufficient; controls must also examine how tokens are requested and used. Implement session and device risk checks to raise the bar.
Attackers obtain refresh tokens or register a device to secure a Primary Refresh Token (PRT), which allows them to refresh access tokens without user interaction. With refresh capability they can maintain continuous access even after the initial token expires. Some adversaries create a registered device record to appear as a trusted authentication method, making detection harder. Monitoring for newly registered devices and unusual refresh token grants is essential. Requiring device management enrollment or policy checks can prevent unmanaged devices from obtaining long-lived tokens.
Enable logging of device authorization grant events, token issuance by grant type, device registrations, and refresh token activity. Correlate those events with mailbox access patterns, API calls, and anomalous message sends. Configure alerts for short-code approvals and for sudden spikes in token refresh or email reads. Maintain baseline behavior profiles so deviations—like headless client activity on user accounts that never use them—are flagged. Regularly review audit logs for device grant events and investigate unusual sequences.
Preventive controls include limiting which apps can request device codes, enforcing conditional access on device-grant flows, and blocking unmanaged device registrations. Implement application consent policies and restrict third-party clients from using device auth where possible. Use conditional access to require compliant or hybrid-joined devices and to deny access from risky locations. Educate users to refuse unexpected short-code requests and establish reporting paths for suspicious messages.
First, revoke active tokens and refresh tokens for affected accounts and remove any registered attacker devices. Next, rotate credentials for service principals and applications that may have been accessed and inspect mailboxes for data theft or forwarding rules. Use mailbox audit logs to map what the attacker read and whom they targeted, then notify impacted parties. Finally, harden policies around device grants and apply tenant-wide controls to prevent recurrence. Consider a full tenant sweep to find additional accounts used as pivots.
Yes—disable device code grants for high‑risk applications, restrict app permissions, and enforce strict conditional access on grant flows. Require device enrollment or block legacy authentication methods where feasible. Limit API scopes to least privilege and use app consent restrictions to stop unauthorized clients from requesting tokens. Regularly review and remove stale app registrations and OAuth permissions. Applying these configuration changes lowers the chance an attacker can receive usable tokens.
User training helps by teaching staff to recognize token‑phishing patterns and to never approve unexpected device‑login prompts. Simulated phishing exercises that include device code scenarios make users more likely to spot social engineering. Provide simple rules: do not enter codes received unexpectedly, verify the sender via a second channel, and report suspicious requests immediately. Combine training with technical controls to create a layered defense. Clear escalation procedures speed containment when an incident occurs.
Unchecked application consent lets attackers use legitimate clients to request device authorization and get tokens without administrator oversight. Tightening consent policies ensures only approved apps can request high‑risk scopes and prevents malicious clients from obtaining access. Admin consent workflows, tenant-wide restriction of third‑party consent, and regular consent reviews reduce the chance an attacker will leverage a compromised or rogue app. Monitor consent grants and revoke unnecessary approvals promptly. This reduces the pathways attackers can use to start a device code session.
Secure automation by using managed identities, short-lived certificates, or service principals with tightly scoped permissions instead of interactive device grants. Where device login is unavoidable, enforce machine identity checks and store any client credentials in a hardened secrets store. Audit automated clients for unexpected behavior and restrict their ability to request refresh tokens. Use least-privilege roles and rotate secrets regularly to minimize impact from a leaked token. Combine these practices with continuous monitoring for abnormal token activity.
A: Variants have been observed in targeted campaigns against critical sectors, and the pattern is rising because it exploits normal authentication flows and user trust. Attackers value it for low friction and high payoff, especially when they can pivot using mail access. Organizations that don’t monitor device grants are especially vulnerable. Tracking these events and educating users reduces incidence. Treat device code approvals as high-risk events.
A: Blocking is possible for many tenants and applications, but it may break legitimate tooling that relies on device auth, like CLIs or IoT devices. Assess usage to identify which apps truly need it and disable it for the rest. When blocking isn’t feasible, apply strict conditional access and app restrictions to reduce risk. Consider alternative secure methods for automation where possible. Communicate changes to teams before enforcement.
A: Act immediately: revoke affected tokens, remove any registered devices, and investigate mailbox actions within hours. The attacker can move quickly with granted tokens, so timelines matter. Preserve logs for forensic analysis and notify impacted users and teams. Apply tenant-level mitigation while investigating to prevent broader spread. Speed and coordination reduce damage and recovery time.
A: Key sources include device authorization event logs, token issuance logs, identity protection signals, mailbox access logs, and API call traces. Correlating these provides the timeline and scope of access. Ensure logs are retained long enough for investigation and fed into SIEM or threat-hunting workflows. Alerts should trigger on anomalous sequences, not just isolated events. Regularly test log quality and visibility for these events.
A: Start with a focused device code hardening checklist that covers app consent policies, conditional access for device grants, token revocation procedures, and monitoring rules. Review your app registrations and third‑party consent policies, enforce device compliance, and tighten refresh token lifetimes. Palisade offers practical resources and guidance to secure authentication flows—see our device code flow prevention checklist for steps you can start applying today: Device code flow prevention checklist.
