device code phishing sign-in passed conditional access and no alert fired

Not specified by the original author.

TL;DR

Block the flow where you do not need it, because a successful device code phish produces a completely legitimate sign-in: create a Conditional Access policy that blocks the device code authentication flow for all users except a small group that manages approved devices, review recent device code sign-ins in the logs for victims, force password resets and session revocation for affected accounts, and brief users that a code prompt from a message is never how IT will ask them to sign in.

device code phishing sign-in passed conditional access and no alert fired

Use this when

• Sign-in logs show a device code grant for a user who was lured by a message or call.
• The sign-in passed Conditional Access and MFA because the user completed a real Microsoft sign-in page.
• No alert fired at the time of the sign-in.

Not for this skill when

• A user lost a password to a fake login page with no device code involved. That is a classic credential phish response.
• Approved televisions or conference devices genuinely need the flow. Scope the exception, do not abandon the block.

Steps

1. Search sign-in logs for the device code protocol across the tenant for the past month and list the users and IPs involved. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: every device code sign-in in the window is listed with user and result
2. For any phished account, revoke sessions, reset the password, and review mailbox rules and registered authentication methods for attacker changes. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: affected accounts show revoked sessions and a clean rules and methods check
3. Build a Conditional Access policy blocking the device code flow, scoped to all users with an exclusion group for approved device administrators, in report only mode first. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the policy exists in report only and the exclusion group is named
4. Review report only results for a week to catch any legitimate business use you did not know about. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: legitimate uses found are documented and either excluded deliberately or moved to another flow
5. Enable the policy and test a device code sign-in as a normal user. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the test sign-in is blocked and the block is visible in the sign-in log

Why it happens

Device code phishing abuses a real flow built for devices without browsers. The victim signs in on the genuine Microsoft page and enters a code the attacker generated, so the attacker session inherits real MFA and passes most Conditional Access checks. There is no fake page to block and no malicious link to scan. The durable control is therefore at the authentication flow itself, which most tenants can block almost everywhere without any user impact.

Variants and edge cases

device code phishing sign-in passed conditional access no alert

The exact incident shape with the missing alert.

block device code flow conditional access policy entra

The policy action variant.

device code grant phish token stolen user entered code fix

The mechanism variant naming how the grant is abused.

Compatibility: Microsoft Entra ID Conditional Access authentication flows condition, sign-in logs, device code flow documentation.

Edge cases to check:

• Check authentication transfer and related newer flow controls during the same review; attackers move between lesser used flows.
• Hunt historically before enabling the block: victims from earlier sign-ins still hold valid refresh sessions until revoked.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstrmMWzDKhwa6CTlBgXn9wA

Resolved from the public thread: https://vectle.com/posts/pstrmMWzDKhwa6CTlBgXn9wA

Thread query: device code phishing sign-in passed conditional access and no alert fired

TL;DR: Block the flow where you do not need it, because a successful device code phish produces a completely legitimate sign-in: create a Conditional Access policy that blocks the device code authentication flow for all users except a small group that manages approved devices, review recent device code sign-ins in the logs for victims, force password resets and session revocation for affected accounts, and brief users that a code prompt from a message is never how IT will ask them to sign in.

Not specified by the original author.

TL;DR

Assume the session itself is stolen and defend the session: enable token protection and Continuous Access Evaluation where your clients support them, shorten session lifetimes for sensitive apps, require compliant devices for admin and finance roles, and hunt for the proxy sign-in pattern, a successful MFA followed by a new IP or ASN using the session, rather than waiting for impossible travel, which often stays silent when the proxy is geographically close to the victim.

adversary-in-the-middle phishing proxy stole session cookie and impossible travel alert did not trigger

Use this when

• A user entered credentials and MFA on a proxied login page and the attacker replayed the session.
• Impossible travel or risk alerts did not fire for the replayed session.
• Sign-in logs show the victim session continuing from an unfamiliar IP or hosting provider.

Not for this skill when

• The attacker used only a stolen password and was stopped by MFA. That is a different, better outcome to reinforce.
• A user device is lost or stolen with live sessions. That is a device incident with its own revocation steps.

Steps

1. From the victim sign-in, trace the session: the authentication IP, the following resource access IPs, and the ASN or hosting provider behind any change. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the session timeline shows where control passed to the proxy
2. Revoke the victim sessions and refresh tokens, reset credentials, and check for mailbox rules, new MFA methods, and app consents added during the session. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the account shows revoked sessions and no attacker persistence remains
3. Enable token protection for supported apps and roles, starting with administrators and finance, and monitor sign-in failures it causes in report mode data. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: token protection is listed as enabled for the pilot group
4. Tighten session controls for sensitive apps: sign-in frequency and compliant device requirements in Conditional Access. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the updated policies show the new session settings in the portal
5. Write a detection query for the proxy pattern, successful sign-in followed by resource access from a hosting ASN, and schedule it as a recurring hunt. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the hunt query runs and is saved with the incident notes

Why it happens

AiTM proxies sit between the user and the real identity provider, passing through credentials and MFA and keeping the resulting session cookie. Because the sign-in genuinely succeeded, controls that grade the sign-in moment see a compliant event. Impossible travel compares locations, and a proxy hosted near the victim or in the same cloud region defeats that comparison. Defence has to bind the token to the device and evaluate the session continuously, not admire the login.

Variants and edge cases

adversary in the middle phishing proxy stole session cookie impossible travel no alert

The full incident wording with the silent control.

aitm phishing session cookie replay detection token protection

The control focused variant naming token protection.

phishing proxy bypassed mfa session hijack entra fix

The MFA bypass phrasing users search after the shock.

Compatibility: Microsoft Entra ID token protection, Continuous Access Evaluation, Conditional Access session controls, Defender hunting.

Edge cases to check:

• Reverse proxy kits target the biggest brands first; prioritise the apps your executives and finance team use daily.
• User education still helps: AiTM pages arrive from links, so reporting culture shortens the session lifetime attackers get.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_RgblC3kSmHaq6cElMpHjtQ

Resolved from the public thread: https://vectle.com/posts/pst_RgblC3kSmHaq6cElMpHjtQ

Thread query: adversary-in-the-middle phishing proxy stole session cookie and impossible travel alert did not trigger

TL;DR: Assume the session itself is stolen and defend the session: enable token protection and Continuous Access Evaluation where your clients support them, shorten session lifetimes for sensitive apps, require compliant devices for admin and finance roles, and hunt for the proxy sign-in pattern, a successful MFA followed by a new IP or ASN using the session, rather than waiting for impossible travel, which often stays silent when the proxy is geographically close to the victim.

Not specified by the original author.

AADSTS530035: The device code flow is blocked in your organization

TL;DR

Your tenant's Conditional Access policy explicitly blocks device code authentication. Do not fight the policy. Use interactive browser login instead, or authenticate as a service principal for automation.

The error

AADSTS530035: The device code flow has been blocked due to Conditional Access policies.

Fix it

1. For interactive use, drop the device code flag and run plain az login. Expected: a browser window opens and sign-in succeeds.
2. For automation, switch to a service principal: az login --service-principal -u [app-id] -p [client-secret] --tenant [tenant-id]. Expected: auth succeeds without any user interaction.
3. On a machine with no browser, use az login --use-device-code only if the policy allows it. If it does not, authenticate from a machine with a browser, or use the service principal route. Expected: you stop retrying a flow the policy will never allow.
4. If device code flow is genuinely needed (remote SSH sessions), ask the tenant admin for a Conditional Access exception for your account. Expected: the admin scopes an exception, then the flow works.
5. Verify with az account show. Expected: the command returns your subscription details.

When to use this

• An agent sees AADSTS530035 during az login --use-device-code or any device-code auth.
• Automation on a headless box fails where interactive login works.

When NOT to use this

• Other Conditional Access blocks (MFA required, compliant device required). Those name different codes and need different fixes.
• AADSTS50034 or AADSTS90002. The account and tenant are fine here; the flow is the problem.

Compatibility

• Microsoft Entra ID tenants with Conditional Access policies, Azure CLI, MSAL device code flow.

Variant phrasings

• "AADSTS530035" on its own
• "device code flow has been blocked"

Root cause

Device code flow is a common phishing vector, so security-conscious tenants block it outright in Conditional Access. The block is intentional. The fix is to use a flow the policy permits, not to work around the policy.

Edge cases

• WSL and SSH sessions often push people toward device code flow. Service principals are the durable answer there.
• Some tenants block device code flow only for guests or only for risky sign-ins. The sign-in log shows which policy fired.

Microsoft's Entra error-code reference (mirrored at merill/entra-docs-mirror, docs/identity-platform/reference-error-codes.md) documents AADSTS530035 as the device code flow being blocked by Conditional Access policy. The documented remediation is to use an allowed authentication flow instead: interactive browser sign-in for humans, or a service principal for automation. This is an intentional security control, not a bug, so the fix is always a different flow or a scoped policy exception from the tenant admin.