The FBI Just Warned That Kali365 Is the First Microsoft 365 Phishing Service That Bypasses MFA Without Ever Asking for a Password—Victims Complete the Real Microsoft Login Flow Themselves and Hand Over OAuth Tokens That Survive Every Additional Check

Key Takeaways

• The FBI issued a public service alert on May 22, 2026 warning of Kali365, a phishing as a service kit distributed through Telegram channels and first observed in April 2026.
• Kali365 ships AI generated phishing lures, automated campaign templates, an operator dashboard for live victim tracking, and an OAuth token capture pipeline.
• The attack vector is device code phishing—the victim enters a code on the real microsoft.com/devicelogin page, completes the legitimate Microsoft authentication including MFA, and unknowingly authorises the attacker's device to access their Microsoft 365 tenant.
• The captured OAuth access and refresh tokens give the attacker persistent access to Outlook, Teams, OneDrive, and any Microsoft 365 service the victim's account can reach, without ever needing the victim's password.
• Because the user authentication ran on legitimate Microsoft infrastructure, conventional anti phishing controls—URL reputation, brand impersonation detection, secure email gateway lookups—do not flag the flow.

What Is Kali365?

Kali365 is a phishing kit operated as a service. Customers pay the operator for access to a builder that produces a customised campaign—target list, email template, lure pretext, branding for the impersonated service. The kit handles the rest. It sends the phishing emails, registers the device codes on Microsoft's authentication backend, displays the codes to the victim through a believable user interface, and captures the OAuth tokens that come back when the victim completes the flow on Microsoft's real servers.

The marketing pitch—visible on the operator's Telegram channel—emphasises the same things that legitimate SaaS pitches emphasise. Low setup time, AI generated content quality, real time analytics on which targets are engaging, automated follow ups for victims who get close but do not complete the flow. The product is built for a customer who does not want to write code and does not want to maintain infrastructure. They sign up, configure a campaign, and pay per result.

It joins a crowded category. EvilTokens demonstrated the same vector at scale earlier this year, hitting 340 Microsoft 365 tenants. VoidProxy targets both Microsoft 365 and Google Workspace through a similar OAuth flow. Kali365's contribution to the category is the polished operator experience and the AI generation pipeline.

How Does Device Code Phishing Work?

Device code authentication is a real Microsoft feature, designed for devices with limited input capability—smart televisions, set top boxes, point of sale terminals—that need to authenticate against an Azure AD account without typing a password on a small keyboard. The flow is straightforward and intentional. The device displays a short code on its own screen and a URL. The user opens that URL on their phone or computer, signs in with their account, enters the code, and authorises the device to act on their behalf.

Kali365's exploit is the same flow but with the attacker's machine in place of the smart television. The kit registers a device code with Microsoft's authentication backend, which returns a code the kit displays to the victim through a fake page that looks like an internal SharePoint document, an HR portal, or a vendor invoice viewer. The lure pretext says: "to view this document, sign in with your work account at microsoft.com/devicelogin and enter the code." The victim does exactly that. The URL is real. The login is real. The MFA prompt is real. They click approve, the kit's device receives the OAuth tokens, and the attacker now has authenticated access to the victim's mailbox.

The strongest part of the attack is the legitimacy of the destination. Every defence trained on "phishing pages impersonate legitimate brands" fails here because the page is not impersonated. The victim is on the real Microsoft login page. The credentials never leave Microsoft's infrastructure. The token capture happens on the back end. The defender has no badly typo squatted domain to block.

Why MFA Does Not Stop This

The standard defence against credential phishing is multi factor authentication. The standard recommendation is to use a phishing resistant factor—FIDO2 security key, certificate based authentication, Windows Hello for Business. Each of those resists the most common phishing attack, which is the attacker proxying the victim's credentials and the resulting MFA prompt through their own infrastructure.

Device code phishing dodges that defence because the MFA prompt is not being proxied. The victim is interacting directly with Microsoft. Their FIDO2 key works. Their Windows Hello biometric works. Their app based prompt works. They complete the authentication on their own device, on Microsoft's real page, and the attacker only collects the artefact that comes out the other side—the OAuth refresh token Microsoft hands back to the device that requested the code.

The defensive primitive that works against device code phishing is conditional access policies that restrict device code authentication to specific apps, or that block it entirely. Microsoft has made this configurable through Entra ID Conditional Access. But the policy needs to be set explicitly. The default behaviour allows any user to authorise any device, which is the configuration Kali365's customers are exploiting.

What Comes Next After the Token Capture

Once Kali365 has the OAuth tokens, the post compromise playbook is predictable. The attacker reads the victim's email for context. They identify high value follow on targets—the finance team, the IT administrator, an executive—and use the compromised account to send internal phishing emails that get past the trust controls that block external senders. They harvest contact data. They search for credentials, recovery codes, password resets, and any sensitive document stored in OneDrive or accessible through Teams.

The refresh token survives until the user explicitly revokes it. That typically requires the IT team to discover the compromise—usually after the attacker has done damage—and to use the Microsoft 365 admin centre to invalidate the user's sessions and rotate their credentials. The window between initial access and revocation is the window during which the attacker collects whatever they came for. Recent campaigns have demonstrated post compromise windows of weeks before defenders notice anything.

The shift from credential theft to token theft is what makes the next generation of phishing kits operationally different from the previous one. Credentials can be rotated. Tokens have to be revoked, and revocation requires knowing the token exists.

What Defenders Should Do

First, configure Entra ID Conditional Access to restrict device code flow. The Microsoft recommended policy is to block device code authentication for all users except the small set who genuinely need it—help desk personnel for shared devices, kiosk operators, the rare service account that uses the flow. For most organisations, blocking it entirely is operationally cheap and removes the entire attack surface.

Second, train users on the specific lure pattern. The instruction "go to microsoft.com/devicelogin and enter this code" is not something an internal SharePoint or HR system asks for. If a user receives an email that asks them to do that, the email is malicious regardless of how legitimate the surrounding details look. This is a single sentence training point that materially reduces susceptibility.

Third, monitor the Entra ID sign in logs for device code authentication events. Microsoft logs every device code grant. Anomalous patterns—a sudden spike in device code authentications, codes registered from unfamiliar IP addresses, codes that authorise unusual application permissions—are the in band signal that defenders have. The logs are available in real time. Most SIEM connectors ingest them by default. The detection rule is one query.

Fourth, harden the inbox itself. The lure email has to land before the attack can proceed. Conventional spam filtering on its own is no longer sufficient; AI generated lures change the surface enough to slip past content classification. Anti tracking measures matter here too—marketing pixels report when an email is opened, which is the same signal that lets a phishing operator confirm a target is engaging with their lure. Stripping those pixels at the inbox layer denies the attacker the engagement telemetry they use to time follow up messages.

The Wider Pattern

The fact that the FBI is naming Kali365 specifically—rather than the generic "device code phishing campaigns are increasing" framing of earlier alerts—is the operational signal. The kit has reached a level of prevalence that warrants a named product warning. The kit's marketing materials suggest it is being adopted by less skilled operators who were previously running credential phishing kits that the standard MFA stack defeated.

For defenders, the implication is that the Microsoft 365 phishing landscape has shifted from "credential capture" to "token capture" as the default. The defensive playbook has to shift with it. Conditional Access policies for the device code flow are no longer a hardening recommendation for security forward organisations. They are a baseline configuration that any tenant left in default settings is, by May 2026, behind on.