FBI Warns of Kali365: M365 Phishing Bypasses MFA

On May 21, 2026, the FBI Internet Crime Complaint Center issued Public Service Announcement I-052126-PSA warning organizations about a phishing-as-a-service platform called Kali365. The kit runs on Telegram and hijacks Microsoft 365 accounts without ever capturing a password or intercepting a multi-factor authentication code. For community banks, credit unions, and mortgage companies, the news beneath the news is that the attack works against tenants where multi-factor authentication is fully deployed and working exactly as designed.

What makes the attack hard to talk about is also why it works: it abuses a legitimate Microsoft sign-in flow. There is no fake login page, no spoofed domain, and no credential-harvesting form. The victim authenticates on microsoft.com using their real password and their real authenticator, and Microsoft issues a real, multi-factor-authentication-satisfied access token. That token simply does not go to the victim's device. It goes to the attacker.

If you have read our April coverage of M365 device code phishing and how multi-factor authentication is being bypassed at scale, the attack class is familiar. What changed in May is the packaging: Kali365 is a named, commercial kit with its own FBI advisory, AI-generated lures, target-tracking dashboards, and a second adversary-in-the-middle mode bundled in. The control that closes the door is one Conditional Access policy in Microsoft Entra ID, and ABT's M365 Guardian operating model has already been deploying it.

Kali365: What the FBI Just Warned About

The FBI advisory, identifier I-052126-PSA, is unusually direct. Kali365 is described as a Phishing-as-a-Service platform first observed in April 2026 and distributed through Telegram. The kit lets cyber threat actors capture OAuth access and refresh tokens, gain persistent access to Microsoft 365 environments, and bypass multi-factor authentication without intercepting user credentials. Through the platform subscription, attackers receive AI-generated phishing lures, automated campaign templates, real-time tracking dashboards, and OAuth token capture infrastructure.

What makes the FBI's framing notable for financial institutions is the audience description. The bureau explicitly cites attacks across financial services alongside manufacturing, education, government, and healthcare. The IC3 advisory is not a vague awareness notice. It is a structural warning that a class of attack that previously required developer skill is now available as a subscription product to operators with no technical background.

The commercial framing is part of the story. Industry press reporting describes Kali365 as sold by subscription on Telegram channels, which places enterprise-grade account takeover in reach of operators with no technical background. Whatever the exact monthly figure ends up being in any one listing, the structural change is what matters for risk modeling: where previous device code phishing required developer skill to assemble the polling infrastructure and the AI-generated lure pipeline, Kali365 packages that into a turnkey subscription.

About six weeks separated kit emergence from a federal advisory. That is fast, even for a commercial kit. For institutions that wait for the next Patch Tuesday to act on identity threats, the implication is uncomfortable. There is no patch here. The attack works because the protocol works as designed.

How a Single Code Hands Over a Microsoft 365 Account

The OAuth 2.0 Device Authorization Grant, defined in IETF RFC 8628, exists for a real and useful reason. Some devices cannot reasonably display a browser or accept keyboard input. Smart televisions in lobby branches, conference room systems, kiosks, and printers all need a way to sign in to Microsoft 365 services without an awkward on-screen keyboard. The device flow solves this by issuing a short user code that the operator enters on a second device with a full browser. Microsoft implements this through the verification page at microsoft.com/devicelogin and the device code endpoint inside the Microsoft identity platform.

Kali365 weaponizes this through a four-step pattern that the FBI advisory describes in plain language. Each step is, on its own, a normal Microsoft sign-in event.

An attacker sends a phishing email impersonating a trusted cloud productivity or document-sharing service. According to security research from Arctic Wolf cited in The Register, the most common impersonations are DocuSign requesting a signature, SharePoint sharing a new file, OneDrive alerting to a document, and Adobe Acrobat Sign requesting action. The email contains a short numeric code and clear instructions to visit a Microsoft verification page. Both the page and the code are real.

Targeted users navigate to microsoft.com/devicelogin, paste in the code, and complete their normal sign-in. They enter their corporate password, satisfy multi-factor authentication using their authenticator app or hardware key, and approve the access request. There is no spoofed domain, no fake login form, and no behavioral anomaly that traditional phishing filters can detect at the message layer.

Meanwhile, the attacker's polling loop, which has been hammering the Microsoft token endpoint every few seconds since the code was generated, receives valid access and refresh tokens at the moment the victim approves. Those tokens are bound to the victim's identity, satisfy the tenant's multi-factor authentication requirements, and carry whatever scopes the original OAuth client requested. From the Microsoft Entra ID sign-in log perspective, the user has just authenticated successfully.

With access and refresh tokens in hand, the attacker can reach Outlook for mail and contacts, Microsoft Teams for chats and channel content, OneDrive for files, and the Microsoft Graph for everything else the original scope allowed. As long as the refresh token remains valid and is not revoked, the attacker can keep generating new access tokens on demand. No password reset on the victim's account interrupts that loop. Independent research from Compass Security has even documented attackers using the captured session to register their own FIDO2 security keys and other authentication methods on the victim's account, creating a backdoor for the next attack cycle.

Why Your Multi-Factor Authentication Did Not Stop It

The hardest conversation after a Kali365 incident is the one with the board or the supervisory committee. The institution did the right things. Conditional Access required multi-factor authentication. Users were enrolled. The authenticator app worked. Yet an attacker now has live access to mailboxes and shared files. The reason multi-factor authentication did not save the day is the same reason the attack works at all: the victim completed multi-factor authentication, and the token issued in response is what the attacker collected.

This is also why moving to phishing-resistant multi-factor authentication, such as FIDO2 security keys, passkeys, or Windows Hello for Business, is a partial defense rather than a complete one. Those factors raise the cost of attacks that try to capture credentials or intercept a session at the browser. They do not stop a token from being issued through a flow that the tenant permits. A FIDO2 deployment without device-code-flow controls in front of it is more secure against adversary-in-the-middle credential theft and still vulnerable to the Kali365 pattern.

Cloud Security Alliance research from March 2026, which documented 340 confirmed Microsoft 365 compromises across an earlier wave of device code phishing, made the same observation in protocol terms. The detection surface inside Microsoft Entra ID exists. The protocol-level mitigation exists. Both are policy decisions an administrator has to actively make and enforce.

How Kali365 turns a real Microsoft 365 sign-in into an attacker session. Each step occurs on legitimate Microsoft infrastructure, which is why the kit defeats multi-factor authentication without ever touching a credential.

The Microsoft Control That Closes the Gap

Microsoft's recommended control for this attack pattern is unambiguous. The Microsoft Entra documentation on Conditional Access authentication flows states directly that Microsoft recommends blocking device code flow wherever possible. Microsoft now publishes a Microsoft-managed Conditional Access policy named Block device code flow that administrators can enable inside the Entra admin center with no scripting required. The Center for Internet Security incorporated the same control into the CIS Microsoft 365 Foundations Benchmark version 6.0.0 as level-one control 5.2.2.12, recommending that the device code sign-in flow be blocked by default for tenants that do not have a documented operational use case.

Inside the Microsoft Entra admin center, the mechanics are short enough to describe in a paragraph. Under Protection, then Conditional Access, then Policies, an administrator creates a new policy that includes all users and excludes break-glass accounts. The target resources are set to all resources, the Authentication Flows condition is set to Yes, Device code flow is selected, and the Grant control is set to Block access. Microsoft recommends starting in report-only mode for a few days to confirm there are no legitimate device-code flows in production that the policy would break, such as a properly registered Microsoft Teams Room device, then promoting the policy to enabled.

For institutions running Microsoft Teams Rooms or genuine kiosk hardware that depends on device code flow, the path is to exclude those specific service principals or use a network-location condition that permits device code flow only from documented locations. The control surface is granular enough to handle real operational exceptions without surrendering the whole policy.

Detection: What to Look For in Entra ID Sign-In Logs

Even with the Conditional Access policy in place, a security operations function should know how to identify device code flow events in the Microsoft Entra ID sign-in log. The block policy applies at the moment a token is issued. If a refresh token already existed before the policy was enabled, it can still be used until it expires, which means the block can fail to apply on certain legacy sessions. Detection is also the answer for tenants where the policy is intentionally scoped to exclude a service principal that handles Teams Rooms or similar hardware.

The Cloud Security Alliance research note documented the field signatures that distinguish device code authentication from conventional interactive sign-ins. A successful device code event in the sign-in log carries the value authenticationProtocol: deviceCode and the value originalTransferMethod: deviceCodeFlow. Neither field is present in normal interactive sign-in events. Both can be queried directly in the Entra ID sign-in log filters, surfaced in a Microsoft Sentinel rule, or pushed into a managed detection and response pipeline.

For institutions that already feed Microsoft Entra ID sign-in logs into Microsoft Sentinel or another security information and event management platform, the equivalent rule is a short keyword match on those two field values, combined with anomaly logic on the IP, location, and client app. For those that rely on the Entra admin center filters alone, the workflow above is enough to surface the most common indicators within a few minutes per investigation. The same detection discipline pays off across the OAuth abuse pattern: our coverage of the ConsentFix v3 OAuth consent phishing toolkit walks through the related case where attackers hijack consent grants instead of device-code authorization.

What ABT M365 Guardian Already Has in Place

ABT operates as a Tier 1 Microsoft Cloud Solution Provider for more than 750 financial institutions across community banking, credit unions, and mortgage. We manage the Microsoft 365 tenant for those customers, which means we are the operating layer that decides which Conditional Access policies apply, how detection rules are wired into Microsoft Sentinel and Microsoft Defender, and how response runs when a sign-in anomaly surfaces. The Kali365 advisory is not the start of our work on this attack class. It is the latest data point reinforcing a posture we have already been running.

Microsoft's recommended Block device code flow Conditional Access policy is part of the M365 Guardian baseline. We deploy it in report-only mode during onboarding to identify any documented exceptions, then enable it for the rest of the tenant. Exceptions are handled by carving out specific service principals for hardware that genuinely requires the device flow, not by widening the policy.

Layered on top of that, our Tokenator detection logic in M365 Guardian watches for the sign-in event pattern that Microsoft documents as a precursor to device code abuse, including the AADSTS50199 error followed by a successful sign-in. Continuous Access Evaluation is enforced across managed tenants so that risk-event-triggered token revocation can cut an attacker's refresh token within minutes of an anomaly, not at the end of the standard refresh window. For admin and wire-initiation roles, we work with customers to roll out phishing-resistant multi-factor authentication using FIDO2 security keys, passkeys, or Windows Hello for Business so that the small percentage of users with the largest blast radius are on the strongest factor we can deploy.

If you read our recent coverage of the Microsoft Entra ID token service spoofing CVE and the Storm-2949 self-service password reset abuse pattern, the throughline is consistent. Identity is the first line, the Conditional Access layer is where the most important controls live, and the difference between a quiet quarter and a Saturday morning incident response call often comes down to which managed policies are enabled and which are still on the to-do list.

If your Microsoft 365 tenant blocks device code flow today, Kali365 is mostly a headline. If it does not, Kali365 is one Telegram subscription away from your inbox.

The Microsoft 365 controls that close the Kali365 gap. The Conditional Access policy decides whether device code flow is even allowed. Microsoft Defender, Microsoft Sentinel, and Continuous Access Evaluation handle detection and response when an exception applies.

What Financial Institutions Should Do This Week

Most institutions will not have the bandwidth to run a full identity-hardening project this quarter. That is fine. The Kali365 advisory does not require a full project. It requires a focused week of work in Microsoft Entra ID and the Microsoft Entra admin center. The five steps below are a tactical checklist that an internal team can run in five business days, or that an M365 Guardian team can run on your behalf in less time.

If that week falls in the middle of a core conversion, a Calyx migration, or an exam preparation cycle, the practical answer is to focus on Day 1 and Day 2 first. Auditing the sign-in log for deviceCode events takes about an hour for a typical community bank or credit union tenant. Creating the policy in report-only mode adds another hour. That alone moves you from undefended to instrumented and gives you the data you need to enable the policy when the operational window opens. Once the Conditional Access posture is in place, the next reasonable layer of defense is measurement: Microsoft Secure Score for financial executives walks through how to turn that posture into an ongoing board metric.

Frequently Asked Questions