Montana Talks resurfaced the warning on August 27, but the FBI’s Internet Crime Complaint Center issued its public service announcement on May 21, 2026. The timing matters. This is not a newly disclosed zero-day in Microsoft 365, nor a flaw users can patch from Windows Update. It is a social-engineering attack against a legitimate Microsoft Entra authentication feature, and Microsoft already provides Conditional Access controls designed to restrict it.
The FBI says Kali365 was first observed in April 2026 and has primarily been distributed through Telegram as a phishing-as-a-service subscription. Its operators provide AI-generated lures, campaign templates, target-tracking dashboards and token-capture capabilities, reducing the skill required to run a convincing account-takeover campaign.
The victim logs in at Microsoft — for the attacker
Kali365 relies on OAuth 2.0 device authorization, commonly called device code flow. Microsoft designed the flow for hardware with awkward or nonexistent keyboards: a Teams Rooms system, smart display, printer, streaming device or other shared endpoint can show a short code, while the user completes sign-in on a separate browser-capable device.
That legitimate workflow creates the opening. In the FBI’s description, a phishing email impersonates a document-sharing or cloud productivity service and supplies a device code along with directions to visit Microsoft’s genuine verification page. The target enters the attacker-generated code and signs in, often completing the organization’s usual multifactor-authentication challenge.
At that moment, MFA has worked exactly as designed: it verified that the real user authorized the requested sign-in. The problem is that the user unknowingly authorized the attacker’s device, which then receives OAuth access and refresh tokens. The attacker can use those tokens to access Microsoft 365 services without collecting a password or asking the user for another MFA approval.
BleepingComputer independently reported that Kali365 abuses Microsoft’s standard device authorization grant, a protocol intended for input-constrained devices. Microsoft’s own identity-platform documentation confirms the underlying behavior: once the user completes the browser sign-in, the original device can obtain access tokens and refresh tokens.
This is why the “always check the URL” habit, while still useful, does not stop this particular lure. A victim may genuinely be looking at a Microsoft sign-in page. The warning sign is contextual: a device code should only be entered when the user personally initiated device setup or sign-in. An unsolicited email, Teams message, voicemail notice or shared-file prompt has no legitimate reason to supply a code for a user to type into Microsoft’s device-login process.
Microsoft recommends blocking the flow where it is not needed
The FBI’s advice is unusually specific: create a Microsoft Entra Conditional Access policy that blocks device code flow for users, auditing existing usage first and making limited exceptions only for necessary business processes. Microsoft’s current Entra documentation goes further, recommending organizations get as close as possible to a unilateral block as they can.
For tenants that do not use device-code authentication, the policy is straightforward in principle: target users, target all resources, select Device code flow under the Authentication Flows condition, and set the grant control to block access. Microsoft recommends beginning in report-only mode, then reviewing policy impact and sign-in logs before enforcement.
That staged rollout is not bureaucratic caution. Device code flow remains a valid requirement for some devices and legacy workflows. Microsoft specifically calls out Teams devices, digital signage, printers, IoT hardware and other endpoints with limited local input. A blanket block can interrupt a conference-room system or device-registration workflow that nobody documented until it stops working.
Administrators should therefore review Entra sign-in logs for the authentication protocol “Device code flow,” identify the application and account involved, and document each legitimate exception. Microsoft also notes that authentication-flow restrictions can continue to affect later token refreshes because sessions created through device-code flow are protocol-tracked. In other words, a policy may block access later in an app that was not the original target of the device-code sign-in.
A safe rollout has three practical steps:
- Run the device-code block in report-only mode and examine the affected sign-ins before changing it to enabled.
- Preserve narrowly scoped exceptions for documented device accounts or approved workflows rather than allowing the flow for broad user groups.
- Exclude tested emergency access, or break-glass, accounts so a Conditional Access error cannot leave every administrator locked out.
Microsoft’s guidance adds an implementation wrinkle for environments using device registration. Authentication-flow rules aimed at all resources can affect Device Registration Service sign-ins, so administrators need to validate that service and apply Microsoft’s documented exception where appropriate. This is a security control worth deploying, but it is not one to activate blindly during a busy workday.
Authentication transfer deserves a separate decision
The FBI also recommends blocking authentication transfer policies. This is related to device-code risk but is a separate Microsoft Entra authentication flow: it transfers an authenticated state from one device to another, such as scanning a QR code shown in desktop Outlook to sign into Outlook on a phone.
Microsoft says authentication transfer is enabled by default and recommends that organizations evaluate whether they need it. Where there is no approved business need for cross-device sign-in, a Conditional Access policy can block it, again after testing and with emergency accounts excluded.
The distinction matters operationally. Blocking device code flow directly addresses the technique described in the FBI’s Kali365 alert. Blocking authentication transfer reduces a second route for token theft or replay on another device, but it may change a familiar onboarding convenience for employees. IT teams should treat the policies as two explicit risk decisions, not assume that switching off one automatically covers the other.
Huntress researchers, who analyzed Kali365 infrastructure after observing a burst of device-code authentication events from Tencent Cloud addresses in May, reported that variants of the platform included both device-code phishing and adversary-in-the-middle capabilities. The FBI alert itself centers on token capture through device codes. That difference is useful for defenders: blocking device code flow removes the specific route the FBI described, but it does not eliminate phishing generally or replace phishing-resistant sign-in controls.
A password reset alone does not complete incident response
The supplied account-security advice is correct in its central point: changing a password is not a complete response to a Kali365-style compromise. The attacker’s access depends on the tokens issued after the user authorized the rogue device, rather than on a password the attacker knows.
For an Entra-managed work account, Microsoft’s emergency guidance is to block the user’s ability to sign in, revoke sessions or refresh tokens, investigate the account, then restore access when appropriate. Revoking sessions invalidates the user’s refresh tokens, preventing the normal token-renewal path that would otherwise keep access alive.
But administrators should avoid promising more than that control delivers. Microsoft states that Entra ID cannot directly revoke a session token issued by an individual application. Browser applications can maintain their own cookies and session policies, and the timing of reauthentication varies by app. A compromised mailbox or account should therefore be treated as an incident requiring review of active sessions, unfamiliar devices, mailbox rules, OAuth app consent, forwarding settings, files accessed or shared, and financial or executive conversations exposed during the access window.
The FBI asks victims to preserve the phishing message, including headers and body, and record suspicious logins with their time, IP address and location, plus unauthorized devices or active sessions. Those details matter to an internal security team as much as to an IC3 report: they can reveal whether the incident was isolated or part of a wider campaign using the same lure, sender infrastructure or cloud-hosted source.
For individual Microsoft 365 users, the rule is simpler and should be included in awareness training: do not enter a device code received in an email, message or unexpected prompt. Start at the application or device you are setting up. If it displays a code as part of a sign-in process you initiated, proceed through the normal Microsoft page yourself. If someone else supplied the code, stop and report it.
The practical change is in Entra policy, not user panic
Kali365 is evidence that password theft is no longer required for a Microsoft 365 takeover. MFA remains essential, but it cannot protect a user who is tricked into approving an attacker’s authentication request through a legitimate Microsoft page.
For Microsoft 365 tenants, the immediate milestone is a completed sign-in-log review and a report-only Conditional Access policy for device code flow. Organizations that find no valid dependency can then block the flow tenant-wide, retain narrowly tested exceptions where necessary, and remove one of the easier paths Kali365 was built to commercialize.