Device Code Phishing Forensics What We Learned Investigating...

src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md

@@ -199,6 +199,14 @@ The tool [**ROPCI**](https://github.com/wunderwuzzi23/ropci) can also be used to
 
 </details>
 
+### Device-code block limited to selected resources
+
+**Prerequisites:** A Conditional Access policy blocks the [device code flow](../../az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md) for selected resources rather than **All resources**, and the user is allowed to register a device.<sup>[[7]](#references)[[21]](#references)</sup>
+
+Microsoft enforces authentication-flow policies on the Device Registration Service (DRS) only when they target **All resources**. A block limited to selected apps can therefore leave the Microsoft Authentication Broker-to-DRS device-code path open.<sup>[[7]](#references)[[21]](#references)</sup> If the victim completes that flow, the attacker can register a device and exchange the Broker refresh token for a Primary Refresh Token (PRT), as described in [Phishing PRTs](../../az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md#phishing-prts).<sup>[[20]](#references)[[21]](#references)</sup> The victim still performs MFA, and later access remains subject to other Conditional Access controls.<sup>[[20]](#references)</sup>
+
+Check the policy's **Target resources** and the Conditional Access result of Broker/DRS sign-ins. An **All resources** policy does not cover DRS if that resource is explicitly excluded for device enrollment.<sup>[[7]](#references)</sup>
+
 ## Other Az MFA Bypasses
 
 ### Ring tone
@@ -356,5 +364,7 @@ Invoke-WebRequest -Uri $data[0].downloadUrl -OutFile ./downloaded-file
 - [17] [Migrate from Azure AD Graph to Microsoft Graph](https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview)
 - [18] [Authentication methods in Microsoft Entra ID - Voice call](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-phone-options)
 - [19] [AADInternals](https://github.com/Gerenios/AADInternals)
+- [20] [Phishing the Phishing Resistant](https://dirkjanm.io/assets/raw/Phishing%20the%20Phishing%20Resistant.pdf)
+- [21] [Device Code Phishing Forensics: What We Learned Investigating BEC in the Wild](https://research.eye.security/device-code-phishing-forensics/)
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md

@@ -47,6 +47,8 @@ This works especially well against **Microsoft first-party public clients** beca
 4. The victim opens the **real** Microsoft page, enters the code, signs in, satisfies MFA, and grants consent if requested.<sup>[[1]](#references)[[2]](#references)[[3]](#references)[[5]](#references)</sup>
 5. The attacker polls the token endpoint until `authorization_pending` becomes a successful token response.<sup>[[3]](#references)[[4]](#references)</sup>
 
+The `expires_in` response field limits how long the user code is valid. Microsoft documents a default of 15 minutes, so a delayed lure must request a fresh code instead of reusing one embedded in a static page or message.<sup>[[3]](#references)[[24]](#references)</sup>
+
 ### Captive-portal and staged-lure delivery
 
 Device-code phishing does not need to start with a direct code in an email. Traffic manipulation on a hotel or conference network can redirect the captive-portal flow to an operator-controlled landing page. The page can then present the Microsoft code as a normal connectivity or identity check. This context increases credibility because the user already expects to authenticate before receiving network access.<sup>[[18]](#references)[[19]](#references)</sup>
@@ -162,7 +164,7 @@ DeviceCodePhishing server --domain [TENANT_DOMAIN] \
 > [!CAUTION]
 > The project's current documentation says this automatic redirect technique no longer works for normal Entra tenants. The tool now performs a preflight check and continues only for a federated tenant. Treat this as a version- and tenant-dependent technique rather than a universal replacement for the standard device-code workflow.<sup>[[22]](#references)</sup>
 
-For refresh-token pivoting, FOCI behavior, and other token exchange tricks, check [Az - Tokens & Public Applications](../az-basic-information/az-tokens-and-public-applications.md).
+For refresh-token pivoting, FOCI behavior, and other token exchange tricks, check [Az - Tokens & Public Applications](../az-basic-information/az-tokens-and-public-applications.md). For the Conditional Access resource-scope gap in the Broker/DRS path, check [Conditional Access Policies & MFA Bypass](../az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md#device-code-block-limited-to-selected-resources).
 
 ## Detection & Hunting
 
@@ -229,5 +231,6 @@ For authorization-code handoff and DRS abuse, correlate several weak signals ins
 - [21] [Dangerous Invitations: Russian Threat Actor Spoofs European Security Events in Targeted Phishing Attacks](https://www.volexity.com/blog/2025/12/04/dangerous-invitations-russian-threat-actor-spoofs-european-security-events-in-targeted-phishing-attacks/)
 - [22] [DeviceCodePhishing](https://github.com/denniskniep/DeviceCodePhishing)
 - [23] [Microsoft identity platform and OAuth 2.0 authorization code flow](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow)
+- [24] [Device Code Phishing Forensics: What We Learned Investigating BEC in the Wild](https://research.eye.security/device-code-phishing-forensics/)
 
 {{#include ../../../banners/hacktricks-training.md}}