The FBI has issued an urgent alert about Kali365, a phishing-as-a-service platform that sidesteps multifactor authentication by weaponizing the legitimate Microsoft device-code authorization flow. Distributed primarily through Telegram channels, the kit lets attackers harvest OAuth tokens with alarming ease, turning a convenience feature into a backdoor for account takeover.

Kali365 marks a significant escalation in credential phishing because it doesn’t steal passwords. Instead, it tricks a victim into completing a Microsoft 365 sign-in on the attacker’s behalf, granting a durable access token that survives password changes and works even with MFA enabled. The FBI’s advisory, published in late May, warns that the platform is actively targeting enterprise and government Microsoft 365 tenants, with ransom demands and data exfiltration often following an initial compromise.

The core of the attack is the OAuth 2.0 Device Authorization Grant—a flow designed for input-constrained devices like smart TVs or IoT gadgets. When a user invokes the flow, Microsoft displays a short alphanumeric code on the device’s screen. The user then navigates to https://microsoft.com/devicelogin on a separate browser, enters the code, authenticates, and possibly performs MFA. Once complete, the device receives a token.

Kali365 abuses this exactly as intended. An attacker launches a device-code request to Microsoft’s endpoint, obtains a user code and a verification URL, then sends the victim a phishing message: “Your Microsoft 365 session expired. Visit aka.ms/devicelogin and enter code A1B2C3D4 to restore access.” The link is real, the page is real, and the code is real. No fake login form is ever served. The victim follows the instructions, authenticates—completing any MFA challenge—and moments later Kali365 captures the resulting access token and refresh token. The attacker immediately registers a rogue device in Azure AD, often naming it to blend into a corporate fleet.

The token holds everything: delegated permissions to Microsoft Graph, Outlook, SharePoint, OneDrive, Teams. Depending on the target’s assigned roles and conditional access posture, the attacker may move laterally, search email for financial information, download sensitive files, or register additional OAuth applications to maintain persistence even if the original token expires.

Anatomy of the Kali365 Platform

Kali365 is sold as a subscription service on Telegram, with tiers ranging from basic one-shot token grabbers to full-featured kits that automate the entire campaign. The platform includes:

  • A control panel for generating device-code flows and monitoring active lures.
  • Pre-written phishing templates mimicking IT helpdesk notifications, Microsoft alerts, and collaboration invitations.
  • Integrated token replay and validation so the attacker immediately knows whether the token works.
  • A “setup wizard” that automatically configures an Azure AD application registration with the required delegated permissions, bypassing the need for the attacker to understand OAuth details.
  • Token refresh automation using the captured refresh token, ensuring access remains active for days or weeks.

Because the platform relies on the legitimate Microsoft identity provider, traditional anti-phishing defenses fail. URL filters see the real login.microsoftonline.com domain. Browser-based security tools detect no credential harvesting form. Email gateways that scan for suspicious links find only a trusted Microsoft URL. MFA is not bypassed in the technical sense—it’s completed willingly by the victim on the genuine Microsoft page.

Why Token Theft Matters

A stolen OAuth token is arguably more dangerous than a stolen password. It can be used to access resources without presenting a password or completing MFA again until the token expires or is revoked. Microsoft 365 refresh tokens used by native clients often have a 90-day validity by default. Combined with a device registration in Azure AD, the attacker can enroll the rogue device into Intune and receive configuration profiles, Wi-Fi certificates, and even line-of-business applications. This blurs the line between a simple mailbox compromise and a full network intrusion.

The FBI advisory notes that in several observed incidents, Kali365 operators used the initial token to:

  • Search email for “wire transfer,” “invoice,” or “payment” to stage financial fraud.
  • Access SharePoint and OneDrive for intellectual property theft.
  • Create new Enterprise Applications in Azure AD with mail.read permissions across the entire tenant, establishing persistent graph API access.
  • Send Teams messages internally to socially engineer other employees.

Organizations using Microsoft 365 without strict conditional access controls are especially vulnerable. Even organizations that have rolled out security defaults can be at risk because the device-code flow is considered a first-party Microsoft authentication and may not trigger risk-based conditional access policies unless specifically configured.

FBI Advisory: Key Recommendations

The FBI’s alert provides concrete mitigation steps. The most critical is to block device-code authentication entirely if your organization doesn’t use it. This can be done via Conditional Access in Azure AD:

  • Create a policy targeting all users.
  • Under “Cloud apps or actions,” select “All cloud apps.”
  • Under “Conditions,” select “Authentication flows,” then select “Device code flow” and set to “Block.”

For organizations that must allow device-code flow (for example, development teams using Azure CLI or PowerShell on headless systems), the FBI advises restricting it to only those specific users and requiring additional authentication strength factors. Microsoft’s documentation also highlights that device-code flow should be combined with Terms of Use or frequent user sign-in frequency controls.

Other recommendations include:

  • Enforce phishing-resistant MFA methods such as FIDO2 security keys or Windows Hello for Business. While MFA is not the silver bullet here, stronger methods can reduce the likelihood of remote attackers taking over the token issuance process.
  • Monitor the Azure AD sign-in logs for “device code flow” authentication events. Sign-ins from unfamiliar locations or unknown device IDs should be investigated immediately.
  • Use Azure AD Identity Protection’s “token issuer anomaly” detection, which flags when a token is redeemed from an unexpected IP or device.
  • Review existing Enterprise Applications and Service Principals for rogue registrations. Revoke any app with excessive permissions.
  • Educate users that no legitimate IT notice will ever ask them to navigate to a login page and enter a code unprompted.

Microsoft has acknowledged the attack vector in its own guidance, emphasizing that the device-code flow is inherently a user-interactive grant and thus subject to social engineering. The company is reportedly exploring improvements to the flow, such as requiring additional verification when a device-code request originates from a suspicious IP range, but no timeline has been announced.

The Bigger Picture: Phishing as a Service

Kali365 is part of a broader industrialization of phishing. Phishing-as-a-service platforms have lowered the barrier to entry for cybercriminals dramatically. For a few hundred dollars a month, attackers gain access to bulletproof hosting, proxy networks to hide their true location, real-time token capture, and even technical support—all without writing a single line of code.

These platforms are increasingly leveraging automation and AI to improve their success rates. Some kits now dynamically generate lure themes based on the target’s industry, pulling logos and company-specific language from publicly available data. The result is phishing that is more convincing and harder to detect than ever before.

Device-code phishing specifically exploits the human tendency to follow instructions, especially when they appear to come from a trusted source. It also leverages the fact that most users have been trained to look for the green lock and the correct URL—both of which are present, giving a false sense of security.

Practical Steps for Security Teams

Security leaders should treat the Kali365 advisory as a call to immediately audit their conditional access policies. Start with the device-code flow block. Then, take the following additional actions:

  1. Inventory all existing device-code authentication requests in the last 30 days. In the Azure AD sign-in logs, filter by “authentication protocol: device code” to see if any are legitimate. If none, disable the flow entirely.
  2. Implement continuous access evaluation (CAE) if not already enabled. CAE can revoke tokens in near real-time when a user’s risk level changes, limiting the window for stolen token usage.
  3. Deploy Azure AD Application Governance to detect anomalous OAuth app registrations. Set up alerts for any new multi-tenant app registration in the tenant.
  4. Run the “Revoke-AzureADUserAllRefreshToken” PowerShell cmdlet for any compromised user to immediately invalidate all refresh tokens.
  5. Increase the frequency of user and entity behavior analytics (UEBA) reviews to spot token replay from unusual geolocations.
  6. Pressure test your environment by attempting a device-code phishing attack against a test account. Use an open-source tool like TokenTactics (with proper authorization) to see if your detective controls fire.

What Users Need to Know

While technical defenses are essential, user education remains a critical layer. Employees should be trained to recognize and report any unsolicited message asking them to go to a website and enter a code. These requests often come via email, but SMS and Teams messages are increasingly common.

Key points for user training:

  • Microsoft will never send a code and ask you to enter it on a separate page to restore access.
  • If you receive such a request, forward it to your security team using the “Report Message” button in Outlook or the equivalent in your email client.
  • Do not enter any code into any site unless you specifically requested it yourself as part of a known IT process (e.g., setting up a new smart TV app).
  • When in doubt, contact your helpdesk via a known phone number—never trust contact details provided in the suspicious message itself.

Organizations should test their workforce with simulated device-code phishing lures to identify high-risk user groups and tailor additional training accordingly.

The Road Ahead

Device-code phishing is not a new technique—it was demonstrated at Black Hat years ago—but it has surged in popularity because it consistently evades controls that organizations have spent years implementing. The commercial availability of Kali365 signals that attackers have productized this technique, and we can expect copycat platforms to emerge.

Microsoft is likely to introduce stronger friction into the device-code flow. Possibilities include requiring a pre-authenticated session on the same browser before accepting a device code, or flagging flows where the browser that performs the login differs from the one that initiated the code. However, any such change must balance security with usability for legitimate scenarios, which range from Linux command-line tools to cross-device smart TV activations.

In the interim, the responsibility falls on defenders to disable the flow where possible and to build robust detection and response capabilities for token-based attacks. The shift from credential theft to token theft is a permanent evolution of the threat landscape, and identity protection strategies must adapt accordingly.

Kali365 is a stark reminder that even the most trusted authentication mechanisms can be turned against the user. When the login page is real and the MFA prompt is real, the only thing standing between an attacker and your data is the awareness and training of the person behind the keyboard.