Most phishing simulations still focus on two familiar outcomes: the target clicked the link, or the target typed a password. Device code phishing is a different attack path entirely. The target does not approve scary permissions and does not type credentials into a fake login page. Instead, they complete a normal Microsoft sign-in flow for a device code that belongs to the attacker. That distinction matters because it makes the technique both stealthier and harder to explain away. The target is sent to a legitimate Microsoft page at microsoft.com/devicelogin , signs in normally, completes MFA normally, and hands over tokens to an attacker-controlled device flow. The PhishU Framework now turns that technique into a point-and-click landing page template built into the same hosted workflow used for campaigns, reporting, analytics, and training. When the target completes device code authentication, the Framework records the event and surfaces it immediately so the operator can validate impact in real time. A Very Different Kind of OAuth Abuse At a high level, the PhishU Framework provisions a public client app, generates a fresh device code when the target lands on the page, displays that code with a copy button and instructions, and then polls Microsoft until the authentication completes. When the target signs in, the Framework captures the resulting access and refresh tokens. That makes device code phishing part of the same broader identity-and-token abuse family as Microsoft Entra OAuth Consent Grant simulation , but the path is different. OAuth Consent Grant asks the target to approve an app and its permissions. Device Code asks the target to log a device in for the attacker. No permissions screen. No Accept button. Just a normal Microsoft sign-in flow. That is also why the success profile is different. Device code phishing intentionally sticks to auto-approved scopes such as openid , profile , email , offline_access , and User.Read . The tradeoff is narrower initial access, but the target never sees a consent prompt. That makes the attack path quieter and often more believable. Operators configure the Microsoft Entra Device Code template directly inside the Framework, including the application display name the target will see during sign-in. The available scopes are limited to auto-approved scopes so the target sees no consent prompt. Why Attackers Like Device Code Phishing From an attacker perspective, the appeal is obvious. The target authenticates on the real Microsoft domain. The login page is legitimate. MFA is legitimate. The browser experience is legitimate. The only malicious part is who requested the device code in the first place. That makes device code phishing one of the cleaner ways to move beyond old credential-harvest thinking. It is not about stealing a password and hoping the target misses the fake page. It is about abusing a real Microsoft flow to get durable tokens without ever showing the victim a scary permissions screen. The real-world relevance is not theoretical either. Device code phishing has already been observed at scale against hundreds of Microsoft 365 organizations, which is exactly why this belongs in an authorized assessment platform built for realistic phishing work. The device code template presents a Microsoft-style sign-in page, generates a fresh code per visitor, and sends the target to the real Microsoft device login flow. Why This Matters for Defenders Most organizations are still much more prepared to think about fake login pages than token abuse. Device code phishing is a good example of why that gap matters. The target can do everything on a legitimate Microsoft page and still give an attacker durable access to their account. That changes what a phishing program should test. It is no longer enough to ask whether users can spot a fake login form. Defenders also need to know whether users will authenticate an attacker-controlled device code when the flow looks routine, polished, and familiar. That is exactly where the PhishU Framework fits. The technique is not treated like a disconnected proof of concept. It connects to campaign delivery, real-time visibility, captured-results workflows, reporting, and training. The device code flow ends with token capture and a clean handoff into the same post-capture workflow used for other token-based techniques in the platform. The console also surfaces device code captures as a live event, which makes it easy to tie the target action to the resulting token-based workflow before opening the captured-grants view. Same Token Explorer, Different Entry Point One of the strongest parts of the implementation is that device code captures feed straight into the same Token Explorer used for OAuth Consent Grant. The attack path is different, but the post-capture workflow is unified. Operators can inspect the grant, refresh tokens, view the victim profile, and let the Framework auto-discover what other Graph endpoints are accessible in th...