.webp)
Most security advice boils down to one thing: enable MFA. And that's still good advice. But in May 2026, the FBI published a public service announcement about a phishing platform called Kali365 that lets attackers take over Microsoft 365 accounts while completely bypassing MFA - without ever stealing your password.
This isn't a theoretical attack. Kali365 launched in April 2026 and spread quickly through Telegram, giving less-technical attackers access to pre-built phishing templates, AI-generated lures, and real-time tracking dashboards. If your business runs on Microsoft 365 - and most businesses do - this is worth understanding.
What Is Device Code Phishing?
Device code phishing abuses a legitimate part of Microsoft's authentication system called the OAuth 2.0 Device Authorization Grant (RFC 8628). This flow was designed for devices that don't have keyboards or browsers - think smart TVs, IoT sensors, or Azure command-line tools - to authenticate against Microsoft without a traditional login screen.
Here's how Microsoft intended it to work: a device displays a short code and tells you to go to microsoft.com/devicelogin, enter the code, and sign in with your account. The device then receives an authenticated token and you're in. It's a legitimate, useful feature.
Attackers figured out they could trigger that flow themselves, send you the code, and collect the authentication token when you enter it. The entire attack happens on real Microsoft pages. There's no fake login page to detect, no spoofed certificate to warn you, and no malware dropped on your machine.
The Kali365 Platform: What the FBI Found
According to the FBI's May 2026 advisory, Kali365 is a Phishing-as-a-Service (PhaaS) platform first seen in April 2026 and distributed via Telegram. For a subscription fee, anyone can get:
- AI-generated phishing email templates impersonating vendors, document-sharing services, and cloud apps
- Automated campaign tools to send lure messages at scale
- Real-time dashboards showing which targets clicked and authorized the session
- Automated OAuth token capture - so the attacker receives a ready-to-use Microsoft 365 session the moment you approve the code
Once the token is captured, the attacker has persistent access to Outlook, Teams, OneDrive, and any other Microsoft 365 service the compromised account can reach - without needing your password and without triggering another MFA prompt.
How the Attack Plays Out, Step by Step
Understanding the sequence helps you recognize it before completing it.
Step 1: The Email Arrives
You receive an email that looks like it's from a vendor, a partner, or an internal IT system. Common pretexts include: "verify your account to access the shared document," "your Teams session requires re-authentication," or "approve this to receive the pending invoice." The email includes a short alphanumeric code and instructions to enter it at microsoft.com/devicelogin.
Step 2: You Visit a Real Microsoft Page
You follow the instructions. You land on the actual Microsoft verification page - legitimate certificate, correct domain, no red flags. You sign in with your real credentials, complete your MFA challenge, and enter the code. Everything looks correct, because technically it is. You just completed a valid authentication on Microsoft's own servers.
Step 3: The Attacker Gets Your Session
The code you entered was one the attacker generated by calling Microsoft's API a few minutes earlier. When you approved it, Microsoft issued an OAuth access token and a refresh token to the attacker's infrastructure. They now have a valid, authenticated Microsoft 365 session for your account. Refresh tokens typically stay valid for 60 to 90 days unless revoked.
Step 4: Persistence and Lateral Access
Within minutes, an attacker with this access can read your emails, search OneDrive for sensitive documents, create inbox rules to forward copies of your mail to an external address, and attempt to reach other connected systems. If you have admin-level access to your tenant, the potential impact is significantly broader.
Why Standard MFA Doesn't Stop This
This is the part that catches people off guard. Device code phishing doesn't bypass MFA by intercepting or tricking the authentication system. You complete your MFA challenge correctly, on the real Microsoft website. The system is doing exactly what it's supposed to do - verifying that the person signing in is really you. The problem is that you're unknowingly approving the wrong session.
Traditional phishing awareness training also helps less here, because employees are trained to check the URL bar and look for fake login pages. There is no fake page. The same limitation applies to email security filters - the lure email often contains no malicious link, just text and a short code.
None of this means MFA is useless - it absolutely isn't. Accounts without MFA are exposed to a much wider range of attacks. But device code phishing specifically targets the gap between "this user is who they claim to be" (what MFA verifies) and "this user intended to authorize this particular session" (which MFA doesn't verify).
What to Check in Your Microsoft 365 Environment Right Now
If you manage your own Microsoft 365 environment or have an IT provider who does, here are a few practical things to review:
Review Sign-In Logs for Device Code Activity
In Entra ID (formerly Azure Active Directory), go to Sign-in logs and filter by Authentication Protocol. Look for entries showing "Device code flow" from standard users who have no reason to be using Azure CLI, headless PowerShell scripts, or IoT tools. A regular employee on a Windows laptop authenticating via device code is unusual and worth investigating.
Check for Suspicious Inbox Rules
After a successful device code attack, attackers frequently create inbox rules to auto-forward mail or hide security notifications. In Exchange Online admin center, you can audit mailbox rules across your tenant. Look for forwarding rules pointing to external addresses, or rules that auto-delete messages matching keywords like "password reset," "security alert," or "unusual sign-in."
Look for New OAuth App Consents
Attackers sometimes use a stolen session to register OAuth applications that maintain longer-term persistence even after the original token expires. In Entra ID under Enterprise Applications, review any apps granted access to your tenant - especially recently added ones with broad permissions like Mail.Read, Mail.ReadWrite, or Files.ReadWrite.
How to Block Device Code Flow in Microsoft 365
The most direct defense is a Conditional Access policy in Entra ID that blocks device code flow for users who have no legitimate need for it. For most small and mid-size businesses, that's nearly everyone.
The FBI advisory recommends these specific steps:
- Audit your environment first. Before creating any blocking policy, check your Entra ID sign-in logs to see if any users or apps legitimately depend on device code flow. Common legitimate uses include Azure CLI scripts run by developers, certain Power BI data refresh scenarios, and Teams Room display devices.
- Create a Conditional Access policy. In Entra ID under Security - Conditional Access, create a policy that targets device code flow authentication and blocks it for all users, with exceptions for the specific accounts or service principals that need it.
- Exclude emergency admin accounts. Your break-glass accounts should always be excluded from restrictive Conditional Access policies to prevent accidental lockout.
- Block authentication transfer. A related policy prevents users from transferring an authenticated session from one device to another - a separate but related attack path worth closing at the same time.
This is the kind of configuration that's straightforward once you know about it, but easy to miss if you're not actively monitoring for new attack techniques. A vulnerability and configuration management program with your IT provider can help catch these gaps before attackers do.
Additional Layers That Strengthen Your Defenses
Phishing-Resistant Authentication Methods
FIDO2 hardware security keys and passkeys add a layer of protection that's harder to abuse in social engineering attacks because they bind the cryptographic challenge to the specific origin and session context. For high-value accounts - executives, finance staff, IT administrators - upgrading to hardware keys is worth the investment even if you've already blocked device code flow.
Update Your Security Awareness Training
Most phishing training still focuses on "check the URL and look for typos in the domain name." Device code phishing needs one additional rule taught explicitly: never enter a Microsoft verification code unless you personally initiated the sign-in. That's a simple concept, but it has to be part of your security awareness training curriculum to be useful.
Token Lifetime Policies
Microsoft allows you to configure token lifetimes for your tenant. Shortening refresh token validity for non-compliant or unmanaged devices limits the window an attacker has to use a stolen session. It won't prevent the initial compromise, but it reduces long-term persistence.
Continuous Access Evaluation
Microsoft's Continuous Access Evaluation (CAE) feature lets Entra ID revoke tokens in near-real-time when it detects anomalous conditions - like a sudden IP change mid-session or an account being flagged. Enabling CAE adds an active detection layer on top of the preventive controls above, and it's available to most Microsoft 365 business plans.
The Bigger Picture
Device code phishing is part of a broader shift that's been developing for several years: attackers moving away from stealing credentials toward stealing tokens and authenticated sessions. When MFA became widespread, the value of a plain stolen password dropped. So attackers shifted focus to stealing what MFA produces - the session token - rather than the input that feeds into it.
This is why the security conversation for small and mid-size businesses has moved past "enable MFA and call it done." MFA is still a necessary baseline - it closes off a huge range of attacks. But the next layer involves controlling which authentication flows are allowed, monitoring Entra ID logs for unusual session behavior, and having someone actively watching for new techniques like this one.
If you want to understand where your Microsoft 365 environment stands - what flows are enabled, what Conditional Access policies are in place, what your sign-in logs are showing - a Microsoft 365 security audit is a reasonable place to start. We run these for clients regularly, and the findings are almost always actionable.
If you have questions about your specific setup or want a second set of eyes on your Entra ID configuration, we're happy to help.
Frequently Asked Questions
Does this attack affect Google Workspace users too?
Device code phishing specifically abuses Microsoft's OAuth 2.0 Device Authorization Grant flow. Google Workspace supports OAuth flows, but this particular attack pattern targets Microsoft's devicelogin endpoint. Google Workspace users face their own OAuth-based threats (consent phishing is a real issue there), but the specific Kali365 attack described here is a Microsoft 365 problem.
How do I know if my account has already been compromised this way?
Check your Entra ID sign-in logs for device code flow entries associated with your account, particularly from unfamiliar IP addresses or locations. Also review active sessions under My Account - Security - Sign-in activity on the Microsoft account portal. If you see sessions you don't recognize, change your password, revoke all active sessions, and alert your IT team. Then check your inbox rules for any forwarding you didn't configure.
Will blocking device code flow break tools we're already using?
It might, depending on your setup. Azure CLI used by developers, some Power Automate workflows, and Teams Room devices can legitimately use this flow. That's why the FBI advisory specifically recommends auditing before blocking - you need to understand your legitimate dependencies first. For most standard business users on laptops and phones, there's no valid reason for device code flow, and blocking it for that group carries very low risk.
Is this only a problem for large enterprises?
No - and that's actually the point of a platform like Kali365. It's designed to lower the technical barrier for attackers, which means smaller businesses are more reachable targets, not less. Large enterprises often have dedicated identity security teams monitoring Entra ID logs for exactly this kind of anomaly. Most small businesses don't, which makes the detection gap wider for them.
Should I ask my IT provider about this?
Yes, it's worth a direct question: "Is device code flow blocked in our Conditional Access policies?" If your provider manages your Microsoft 365 environment, they should be able to confirm this quickly. If they're not sure, that's useful information. Your managed IT services provider should be tracking advisories like this one and proactively reviewing your configuration when new attack patterns emerge.
