A few months ago, I had an idea for what I thought would be a great BSides talk on some novel areas of dynamic device code phishing. Ultimately there was good reason why no one else had talked about it, due to a number of limitations I will cover in this post. Regardless of the outcome, I figured that the items I learned would be interesting to cover in a post, and may inspire further digging into this subject.
Device Code Phishing 101
First off, what even is dynamic device code phishing? Dynamic device code phishing is a technique which has been widely used by threat actors and red teams alike for several years. The basic concept is as follows:
- An attacker generates a ‘device code’ with a service of their choice (I.e. Entra ID, GitHub etc) via the ‘Device Code Grant’ flow
- In actuality, both the ‘user code’ (The 6-10 character code) and a ‘device code’ (A more complex ID used for subsequent authentication) are generated on this step.
- This generated user code is then shown to a targeted user, who then enters the code into a portal within the legitimate service (e.g.
https://login.microsoftonline.com/common/oauth2/deviceauth) - The user is then prompted to authenticate
- Following successful authentication, the attacker can use the device code, generated alongside the user code, to obtain authentication material as the user, based on the scope of the original request.
The ‘dynamic’ part of this process is the ability to generate device codes automatically in response to a victim accessing a web page, or performing some action – rather than a red team operator copying and pasting the code in a message.
This leverages an aspect of the OAuth 2.0 specification which allows for authentication on ‘input constrained’ devices. You will have likely used this flow if you have authenticated to iPlayer or Netflix on your TV – where a code is used in place of entering a (hopefully) complex password via a TV remote. The TV generates a unique code, which is then used to authenticate using a non-input constrained device such as a phone or laptop.
Current Research
My research was inspired by a number of blogs which had covered this area, though I wasnt sure if anyone had joined the dots between them all. As previously mentioned, device code techniques within Entra ID have been known for some time, with device code phishing using GitHub being released with Praetorian’s research in July 2025.
Outside of this, both AWS and NPM have had techniques released previously, though I believe the authentication flow for AWS has since changed slightly. Both of these make for excellent potential targets for a spearphishing campaign, and in my opinion would likely enjoy far greater success than Entra ID based phishing, which is well covered by most anti-phishing training and is becoming increasingly challenging.
Huntress also covered this topic by focusing on Google Cloud, which is inherently limited by in-built controls to Google Cloud. This prevents obtaining any usable authentication material, and is strictly limited to basic information on the user with currently known client IDs.
My Theory
Based on the information above, I was confident that a number of other providers would support device code authentication, particularly platforms focusing on AI or sales/client management, which may offer less explosive access than GitHub or AWS, but would still suit targeted phishing campaigns.
To enable me to research these topics, I vibe coded a quick application to handle any OAuth-style API requests for device codes. This would support the initial request for a device code, as well as polling for responses to check if a given code had been authenticated by the target. The configuration for the different providers (GitHub/Entra ID etc) was handled via a YAML file to abstract the configuration from being hard-coded to the tooling.
For example, taking the GitHub device code technique, I could specify a given scope and client ID to match my pretext at the time, with the tool then generating and polling for a response. This is ultimately the same process which GitPhish performs.
After a successful authentication, the script will gather the resulting access token for future use.
Codex
One area I thought would be interesting to target would be Codex, given it has access to various codebases and may contain historic requests or the ability to influence system prompts and so on. In reality, the API is stateless and is unable to influence any of those items. Additionally, the device code flow is disabled by default and requires it to be enabled on an account specifically, though I suspect this will be quite common in reality.
On top of this configuration, there is also a warning about these codes being used by people phishing 😉.
To test, I then used the --device-auth flag in the Codex CLI, which generates a code.
By using Burp Suite, I could intercept this request to obtain the URLs used by Codex, allowing me to dynamically generate this code. This is shown below:
This resulted in a request URL of https://auth.openai.com/api/accounts/deviceauth/usercode and a polling URL of https://auth.openai.com/api/accounts/deviceauth/token, which requires both the user_code and device_auth_id fields in a JSON-formatted POST request, as shown in the image below.
Ultimately, this ac_ol_... API key was highly limited, and could only make basic requests for detail on the user. Whilst ‘free’ OpenAI credits would be welcomed, they hardly get us initial access!
Salesforce
Salesforce was an application which I thought would be a great target, in the footsteps of UNC6040’s vishing attacks using the Data Loader application in June 2025. Other blog posts had covered this topic in detail, highlighting how the Data Loader was generating a device code, which users could then enter to grant broad access to SalesForce.
Thankfully for the security of SalesForce users, this was heavily limited by SalesForce themselves, with changes in September 2025 preventing the usage of the device code flow.
Identity Providers (IdPs)
I was also hopeful that one of the major IdP’s may support device code authentication, though I was unable to find one which had known public client IDs. All of the platforms I checked did support the flow, but did not allow for dynamic generation of codes without a client ID. To obtain a client ID, you would need to generate an application in the relevant IdP, thus requiring access to the environment or heavily socially engineering a user:
- Auth0 (https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow)
- Okta (https://developer.okta.com/docs/guides/device-authorization-grant/main/)
- Ping Identity (https://docs.pingidentity.com/pingam/8/am-oauth2/rest-api-oauth2-device-code.html)
GitLab
In a similar fashion, GitLab also supports the device code flow but appears to require an application to be created first with support for the authentication flow. This application then has a unique client ID per-instance, which limits the ability to exploit it via phishing without internal knowledge.
Claude
At the time of writing, Claude/Claude Code doesn’t support the device code authentication flow, though several tickets have been raised to add support for authentication in headless or remote sessions, so this may be added in future. The remote control functionality is the closest concept, but it does not leverage device codes.
What’s Next?
Despite this setback, I think device code phishing via a number of these services could be a fantastic option for red teams or assumed compromise assessments to perform internal spearphishing, particularly within more hardened environments.
For example, searching within internal documentation for a client ID using that supports the device code flow could then allow for targeted spearphishing or vishing from an external position. This would make attribution of any attacks challenging and allow for the internal access to be retained for continued access. Especially when compared to the more typical approach of leveraging internal access to perform lateral movement or other more noisy actions between hosts.
Alternatively, this could allow for a form of ‘persistence’ by creating a device-code supporting application within the targeted IdP, then storing the client ID and secret. These values could allow for access to be regained from an external position through phishing. Whilst phishing to regain access is somewhat noisy, it could challenge defensive teams to spot malicious or unused applications with abnormal permissions/claims. This would of course rely on compromising a user with such privileges, which itself would be a challenge.
Despite the lack of current support for device code authentication, I feel it is reasonably likely that future developments in various products or platforms will lead to them becoming vulnerable in future, especially with the ongoing spread of AI platforms in particular. Equally, should public client IDs be discovered in some of these platforms then they will become far more viable for usage in initial access operations. Watch this space I guess!