The FBI’s Internet Crime Complaint Center (IC3) issued an urgent alert on May 21, 2026, warning that a new phishing-as-a-service platform named Kali365 is actively being used to compromise Microsoft 365 accounts. First spotted in April 2026, Kali365 exploits the OAuth device code flow—a legitimate authentication mechanism—to trick users into granting attackers persistent access to their cloud environments. The alert underscores a growing trend in which cybercriminals lower the barrier to sophisticated attacks by offering ready-made phishing kits, while organizations struggle to keep pace with novel abuse of trusted protocols.

What is Kali365? A Phishing-as-a-Service Powerhouse

Kali365 operates as a turnkey phishing-as-a-service (PhaaS) platform. For a subscription fee, threat actors gain access to a web-based dashboard that automates every stage of the device code phishing attack. The platform handles the generation of phishing pages, the initiation of device code requests against Microsoft’s identity platform, and the capture of resulting OAuth tokens. It even includes real-time dashboards that display active campaigns and credentials harvested.

Because the platform handles the technical heavy lifting, even low-skill attackers can launch convincing campaigns. They simply configure a lure—often a fake meeting invitation, a shared document notification, or a security alert—and distribute it via email or messaging apps. The platform then guides victims through a seemingly legitimate sign-in flow that ultimately hands over access to their Microsoft 365 accounts.

How Device Code Phishing Works: Abusing a Legitimate Flow

Device code authentication is an OAuth 2.0 grant type designed for input-constrained devices like smart TVs, printers, or IoT gadgets. Instead of redirecting the user to a browser on the same device, it presents a short alphanumeric code and a URL where the user completes sign-in on a separate device, such as a smartphone or laptop. Once the user enters the code and authenticates, the original device receives an OAuth token.

Attackers abuse this flow by first initiating a device code request from their own machine, then sending the victim a phishing email with the URL and code, disguised as a legitimate Microsoft login prompt. When the unsuspecting user visits the link and enters the code, they are prompted to sign in with their corporate credentials. After successful authentication, the attacker’s device receives a token that grants access to the user’s resources—email, files, Teams chats, and potentially administrative privileges if the account has elevated rights.

Kali365 streamlines this entire process. It scripts the device code request, crafts a realistic phishing page mimicking the official Microsoft login, and captures the OAuth refresh token once the victim completes the flow. The token can then be used to maintain persistent access, often surviving password changes, because it represents an authorized OAuth application in the victim’s Azure AD (Entra ID) tenant.

The FBI Warning: A Detailed Breakdown

The IC3 alert, released on May 21, 2026, marks a significant escalation in the official response to this technique. While device code phishing has been known since at least 2020, the commoditization of the attack through Kali365 has caused a spike in incidents reported to the FBI. The warning notes that the platform is being actively marketed on underground forums and has been linked to multiple breaches across the United States and Europe.

Key points from the FBI’s advisory include:
- Kali365 was first observed in early April 2026 and quickly gained traction due to its automation and evasion capabilities.
- The attacks predominantly target Microsoft 365 business users, leveraging the device code flow inherent to Entra ID (formerly Azure AD).
- Stolen tokens grant access to email, SharePoint, OneDrive, and Teams, and can be used for lateral movement within the compromised tenant.
- The FBI recommends organizations review their conditional access policies and implement strict controls on device code authentication.

The alert also highlights that because the phishing interaction occurs entirely on the victim’s browser—with the actual device code request originating from the attacker’s machine—traditional anti-phishing defenses may not detect the threat. The login page is the legitimate Microsoft URL, and the code entry is a standard part of the authentication flow.

Technical Deep Dive: The OAuth Device Code Grant in Microsoft 365

To understand why Kali365 is effective, we must examine the device code grant itself. When an application wants to authenticate a user on a device without a rich browser, it requests a device code from the authorization server (Entra ID). The server returns a device_code and a user_code. The user is instructed to visit https://microsoft.com/devicelogin and enter the user_code. Once the user authenticates and consents, the application can poll the token endpoint with the device_code to obtain access and refresh tokens.

Attackers replace the legitimate application with their own rogue app registered in a tenant they control—or they abuse a multi-tenant app. Kali365 automates the setup: it registers a malicious app in the attacker’s Entra ID directory, obtains a device code, and presents the code and login URL to the victim. The phishing page often frames this as a “You have a new shared document” or “Your session has expired” prompt, urging the user to sign in immediately.

The stolen refresh token is incredibly valuable because it can be used to generate new access tokens indefinitely, provided the application remains authorized and the token does not expire or get revoked. Even if the user changes their password, the token remains valid. The only sure way to revoke access is to remove the OAuth consent grant from the user’s “App registrations” in Azure AD or disable device code flow entirely.

Impact on Microsoft 365 and Entra ID

The FBI’s alert makes clear that Kali365 targets Microsoft 365 extensively. Once an attacker obtains a valid token, they can:
- Read, send, and delete emails.
- Access and exfiltrate files from OneDrive and SharePoint.
- Join or monitor Teams meetings and chats.
- Gain access to other SaaS applications if single sign-on is configured.
- Escalate privileges if the compromised account belongs to an administrator, potentially taking over the entire tenant.

Because the token-granting app is often granted a broad scope like Mail.Read, Files.ReadWrite, or offline_access, the attacker can perform these actions without further user interaction. The stealth nature of the attack means detection often occurs only when anomalous file access or email forwarding rules are noticed—weeks after compromise.

Defensive Measures and Conditional Access

The most critical defense lies in Entra ID’s conditional access policies. Microsoft has long provided controls to block or restrict device code authentication. The FBI’s warning reinforces the need to:
- Disable the device code grant entirely if not used by legitimate applications. This can be done through Conditional Access by targeting the “Authentication flows” condition and setting “Device code flow” to “Block.”
- For environments that require device code flow (e.g., for PowerShell scripts on headless servers), implement strict location-based or device compliance policies, requiring managed devices or trusted IP ranges.
- Enable “Continuous Access Evaluation” (CAE) to reduce token lifetime and force reevaluation on critical events, though this doesn’t prevent initial consent.
- Educate users never to enter a device code unless they initiated the request. The microsoft.com/devicelogin page explicitly warns, “Never enter a device code from an unsolicited email or message.”

Organizations should also audit existing OAuth consent grants. The Azure AD Portal’s “Enterprise applications” blade shows all consented applications. Revoking suspect grants and enabling admin consent workflows can prevent users from blindly authorizing rogue apps.

Real-World Implications and Community Reactions

Even though the windowsforum community discussion was not available, industry reaction to the FBI alert has been swift. Security practitioners on Twitter and LinkedIn have shared that they’ve observed a surge in device code phishing attempts over the past month. One common theme: attackers are combining Kali365 with business email compromise (BEC) tactics, using the compromised account to send internal phishing messages that spread the attack organically.

IT administrators report challenges in balancing usability with security. Blind blocking of device code flow breaks legitimate scenarios like Azure CLI authentication on Linux servers. The community response, however, leans toward aggressive blocking paired with tight exceptions for specific service accounts and approved IPs.

Microsoft has not released a dedicated statement beyond the existing guidance on device code flow abuse, as the technique exploits a fundamentally working-as-designed feature. The ransom is on organizations to configure their tenant settings correctly.

The Bigger Picture: PhaaS and the Democratization of Cybercrime

Kali365 is no outlier. The PhaaS model has become dominant, with platforms like EvilProxy, Tycoon, and NakedPages offering various phishing vectors. Device code abuse represents an evolution because it doesn’t rely on stealing passwords or MFA codes—it steals tokens after a legitimate authentication. This makes it highly resistant to multi-factor authentication (MFA). The FBI’s alert notes that accounts protected by MFA were still compromised, because the user completed the second factor during the code-entry process.

This democratization means that small and medium businesses, which often lack mature conditional access policies, are at heightened risk. The FBI recommends that all organizations—regardless of size—review their Microsoft 365 security baseline and implement the recommended controls immediately.

Actionable Takeaways for Microsoft 365 Admins

Based on the FBI guidance and security best practices, administrators should take the following steps:
1. Inventory device code flow usage. Check Azure AD sign-in logs filtered by “Device code flow” to see if any legitimate usage exists. If not, block it outright.
2. Create a dedicated Conditional Access policy. Navigate to Azure AD > Security > Conditional Access, create a new policy, select “All users” or a specific group, choose “All cloud apps,” under “Conditions” select “Authentication flows,” and toggle “Device code flow” to “Block.”
3. Implement user education. Reinforce that device codes should only be entered when the user themselves initiated the process, such as when setting up a new device or running a known script.
4. Monitor OAuth consent. Regularly review the “OAuth consent” report in the Azure AD portal and use Microsoft Defender for Cloud Apps to detect anomalous OAuth activity.
5. Use advanced hunting. For organizations with Microsoft 365 Defender, run queries looking for unusual device code logins, such as sign-ins from unfamiliar IPs or ISPs.
6. Activate the new “Device code flow block” security posture in Microsoft’s recent Entra ID security defaults, if the tenant is eligible, though this feature may still be rolling out.

Looking Forward: Can This Attack Be Stopped?

Kali365 and similar platforms will likely continue to evolve. Defenders must recognize that MFA alone is not a panacea. The industry needs more robust token protection mechanisms, such as binding tokens to the original device or requiring proof-of-possession of a cryptographic key. Protocols like DPoP (Demonstration of Proof-of-Possession) are being standardized for OAuth 2.0 to address this, but widespread adoption is still years away.

In the near term, the most effective countermeasure is disabling unnecessary authentication flows. The FBI’s warning has already prompted several large enterprises to flip the switch on device code flow, causing minimal business disruption while closing a significant attack vector.

The emergence of Kali365 is a stark reminder that attackers relentlessly exploit trust in standard protocols. As phishing-as-a-service platforms lower the barrier to entry, the responsibility shifts to organizations to harden their identity infrastructure. For Microsoft 365 users, the message is clear: if you don’t actively use device code authentication, block it now.