Block Device Code Phishing: Protect Microsoft 365 From Kali365

Kali365 takes Microsoft 365 sessions through device code phishing: a code arrives, the user signs in legitimately on Microsoft's own page, and the tokens are issued to the attacker. If that is new to you, start with what Kali365 actually is — this piece assumes it and goes straight to the tenant.

The headline is better than most threat write-ups allow: the main control is one Conditional Access policy, and Microsoft's own guidance is that device code flow is rarely used by customers and frequently used by attackers. The work is in the order you do things.

1. Audit before you block

Do not lead with the policy. Blocking an authentication flow that something in your estate quietly depends on is how a security improvement becomes an outage.

Go to your Microsoft Entra sign-in logs and filter for device code flow over the last 30 to 90 days. For most tenants the result is nothing, or a handful of entries from one team. The things that legitimately show up tend to be:

Teams Rooms, signage and other shared-device sign-ins.
Command-line and automation tooling on headless servers, including some older authentication paths in scripts nobody has revisited.
A small number of VDI and thin-client setups.
Developers using CLI tools interactively.

Write down what you find and who owns it. Everything on that list is either an exclusion you will create deliberately or a thing you will move to a better authentication method. What you must not do is discover it from a service desk ticket on Monday morning.

2. Block the flow in Conditional Access

Microsoft Entra Conditional Access has an Authentication flows condition that targets device code flow directly. Create a policy that applies to all users and all cloud apps, with that condition set, and Block access as the grant control. Microsoft documents the policy itself in block authentication flows.

Three things to get right:

Exclude your emergency access accounts. This is non-negotiable and it is the step people skip. Break-glass accounts sit outside every Conditional Access policy, this one included, and they are tested on a schedule.
Start in report-only. Run it for a week and read the results against the audit you just did. Report-only mode exists precisely so a tenant-wide block can be proven before it bites.
Scope exclusions to accounts, not to everyone. If a team genuinely needs device code flow for a shared device, exclude that account or that device group — never the whole flow for the whole tenant "until we work it out", because that sentence has no expiry date.

3. Block authentication transfer as well

The same Authentication flows condition covers authentication transfer, which moves an authenticated session from one device to another. The FBI's advisory names it alongside device code flow for the same reason: it is another legitimate mechanism for getting an authenticated session somewhere other than where the authentication happened.

Audit it the same way, and block it unless you can name the thing that needs it.

4. Be honest about what MFA does and does not do here

This is the step where a lot of tenant hardening plans go wrong, because the instinct is to answer any phishing story with stronger authentication.

Phishing-resistant MFA is worth deploying and it will not stop this. The user authenticates correctly, on the real Microsoft page, with whatever credential you issued them; a passkey succeeds exactly as a code would. The weakness is not in proving who the user is, it is in where the resulting token goes.

Two controls do reduce the value of a stolen token, and both are worth having:

Continuous access evaluation lets capable applications react to a revocation in near real time instead of waiting out an access token's lifetime.
Token protection binds a session to the device it was issued to, so a token lifted elsewhere is worth less. Check its current support scope against your estate before you plan around it.

Deploy phishing-resistant methods anyway. Just do not file them under "Kali365 handled".

5. Hunt for what already happened

Blocking the flow stops new attempts. It does nothing about a token taken last month, which is still refreshing itself quite happily.

In the sign-in logs, the shapes worth looking for are:

Successful device code authentications before your block went in — each one is a question to answer, not a finding to file.
Refresh-token grants with no preceding interactive sign-in for that user and session.
A first-party Microsoft client ID appearing in a context that makes no sense for that user — an Office client authenticating from hosting infrastructure, for instance.
Sign-ins from autonomous systems you have no business relationship with, particularly cloud hosting providers, and scripted user-agent strings.

Published indicators — specific address ranges, agent strings — go stale quickly, so treat the vendor research as a starting shape rather than a list to paste in. The durable signal is the pattern: a valid session doing things from somewhere the user is not.

Then check the places a successful operator leaves marks, because the mailbox is usually where the money is:

Inbox rules that move, mark read or delete anything matching invoice, payment, bank or remittance.
Forwarding — both user-level and transport-level.
New or modified mail-flow rules and inbound or outbound connectors.
Recent OAuth application consents, especially ones granted by a non-admin.
Changes to registered authentication methods, which is how persistence outlives the token.

6. Revoke properly, not hopefully

If you find a compromised session, resetting the password is not the fix — it is one part of a fix, and on its own it leaves the token-based session intact.

Microsoft's guidance on revoking user access is explicit: revoke the sign-in sessions. In the Entra admin centre that is Revoke sessions on the user's overview page; in Microsoft Graph PowerShell it is Revoke-MgUserSignInSession. Then reset the password, re-register authentication methods, and remove whatever the operator added — the rules, the forwarding, the consented apps.

Expect a lag. Access tokens issued by Microsoft Entra last an hour by default, so an application that is not CAE-capable can keep working until its current token expires. That hour is a reason to act quickly, not a reason to assume the revocation failed.

Making it a standing check

All six steps above describe a state, and states drift. A Conditional Access policy gets an exclusion added during an incident and nobody removes it. A new tenant arrives through an acquisition without the policy. Someone turns something off to test a theory on a Friday.

So the question is not "did we block device code flow?" — it is "is it still blocked, and would we notice if it were not?" That is a quarterly check with a named owner, in the same pass that looks at MFA coverage, guest accounts and app registrations.

Copilot SafeScan runs that identity pass read-only — Conditional Access, MFA coverage, guests and app registrations among 23 checks across six domains — scores it out of 100, and gives you remediation steps and a generated PowerShell script per failing check. It will not write to your tenant: there is no write scope in the consent at all. Rescan after you change the policy and the finding closes or it does not.

Run a free scan