The FBI has issued an urgent public warning about a new phishing-as-a-service kit called Kali365 that exploits the OAuth device-code authentication flow to steal Microsoft 365 access tokens without ever capturing a user’s password. The alert, published May 21, 2026, on the Internet Crime Complaint Center (IC3) website, marks a significant evolution in phishing tactics that bypasses multi-factor authentication (MFA) and traditional credential harvesting.

First spotted in the wild in April 2026, Kali365 represents a commoditized threat sold on dark web forums. Criminals can purchase ready-to-use campaigns that trick employees and consumers into granting persistent access to their Microsoft 365 environments, including email, OneDrive, Teams, and any applications registered with Azure AD.

Unlike conventional phishing kits that steal passwords and session cookies, Kali365 leverages the legitimate OAuth 2.0 device authorization grant, a flow designed for input-constrained devices like smart TVs or printers. Attackers abuse it by obtaining a device code from Microsoft’s identity platform, then luring a victim into entering that code at the legitimate Microsoft login page. Once entered, the victim unknowingly authorizes the attacker’s session, handing over a powerful token that can be refreshed indefinitely.

The Anatomy of a Device-Code Phishing Attack

To understand why Kali365 is alarming security teams, one must first grasp how device-code authentication works. When a device lacks a browser or keyboard, it can display a short code and a URL—such as microsoft.com/devicelogin—and instruct the user to visit that URL on a separate device and enter the code. Behind the scenes, the application polls Microsoft’s token endpoint until the user completes the sign-in, at which point it receives an access token and a refresh token.

Attackers hijack this process by initiating a legitimate device code request from their own controlled servers. They obtain a code and expiration window (typically 15 minutes), then craft a phishing message—often via email, SMS, or even QR codes—commanding the target to “verify their account” by visiting the exact same legitimate Microsoft URL and entering the code. To the victim, the site is authentic, the SSL certificate is valid, and no password is directly asked for by the attacker. But the moment they log in and consent, the attacker’s waiting process obtains tokens tied to the victim’s identity.

Because the sign-in happens on the victim’s own browser and device, all MFA prompts, conditional access evaluations, and compliant device checks are satisfied as if it were a normal login. The attacker doesn’t need to bypass MFA—they simply wait for the victim to complete it. This elegantly sidesteps the primary defenses that have made password stealing harder.

Inside Kali365: Features and Automation

According to the FBI’s analysis, Kali365 automates the entire attack chain. The kit’s operators provide a web-based dashboard where clients configure phishing lures, monitor active device codes, and manage harvested tokens. Key capabilities include:

  • Template engine: Pre-written emails and SMS messages that mimic Microsoft security alerts, IT department notifications, or urgent account verification requests.
  • Real-time token capture: As soon as a victim enters the code, the dashboard displays the stolen access and refresh tokens, along with metadata like user principal name, device info, and tenant ID.
  • Token persistence: The kit stores refresh tokens, allowing attackers to re-generate access tokens long after the initial compromise—sometimes for weeks or months, depending on the token lifetime policies in the victim’s organization.
  • Evasion techniques: Kali365 uses residential proxy rotation and user-agent spoofing to blend token requests with normal traffic, making it harder for Microsoft’s anomaly detection to flag the streaming endpoint polls.

Sold for as little as $300 per month, Kali365 lowers the technical barrier to entry. Affiliates need no deep knowledge of OAuth flows; the kit handles the complex token exchanges. The FBI notes that the service also offers “support” via private Telegram channels, where clients can troubleshoot failures or share successful lures.

Why Tokens Are More Dangerous Than Passwords

A stolen password, even in combination with a session cookie, has a limited lifespan. Once a user changes their password or the session expires, the attacker loses access. A stolen OAuth token—especially a refresh token—can be far more persistent. Microsoft’s default configuration often issues refresh tokens valid for up to 90 days, and until mid-2026, many tenants still used older policies that extended this to 90 days with rolling renewal, effectively granting perpetual access as long as the attacker used it regularly.

Moreover, tokens grant scoped but often broad permissions. An attacker with a token authorized for Microsoft Graph can read emails, access SharePoint documents, send messages on behalf of the user, and in some configurations, escalate privileges by consenting to additional application permissions if the victim has the necessary roles.

The FBI warning specifically highlights that Kali365 targets tokens with the openid, profile, email, offline_access, and various Microsoft Graph scopes. The offline_access scope is what provisions the refresh token, making the attack especially durable.

FBI Alert Details and Observed TTPs

The alert, designated PSA-260521, outlines several technical indicators and tactics, techniques, and procedures (TTPs) observed in Kali365 campaigns:

  • Initial Access: Spearphishing emails with subject lines like “Microsoft 365: Device Activation Required” or “Urgent: Security Token Refresh.” Some campaigns used LinkedIn InMail to impersonate recruiters.
  • Device Code Request: The attacker’s infrastructure contacts login.microsoftonline.com/common/oauth2/v2.0/devicecode to obtain a device code and user verification URL.
  • User Execution: Victims are directed to microsoft.com/devicelogin and prompted to enter the code. The phishing message often creates a false sense of urgency, claiming the code expires in 5 minutes.
  • Token Harvesting: Once the victim completes sign-in, the attacker’s server receives tokens from the /token endpoint. The kit immediately exchanges the refresh token for a new access token to validate it.
  • Persistence: Attackers often register their own Azure AD applications in the victim’s tenant using automated scripts, ensuring long-term access even if the original token is revoked.

The FBI recommends that organizations review Azure AD sign-in logs for unusual device code events. Key indicators include:
- Device code sign-ins from unfamiliar IP addresses or locations that don’t match the user’s typical behavior.
- A sudden spike in device code usage within a tenant.
- Successful authentication immediately after a user reports an unusual notification.

Microsoft’s Defensive Measures and Guidance

Microsoft has long been aware of device code phishing risks and has introduced safeguards. Yet, because the flow is legitimate and required by many applications, outright disabling it isn’t always feasible. In response to the FBI alert, Microsoft re-emphasized several controls available to Entra ID (formerly Azure AD) administrators:

  • Conditional Access Policies: Admins can block device code authentication entirely or restrict it to trusted locations, device platforms, or compliant devices. For most organizations, blocking device code flow for all users except specific service accounts or IoT devices is a strong mitigation.
  • Restrict Device Code for Office 365: Microsoft 365 apps do not require device code authentication for regular user sign-in. Therefore, a policy that blocks the device code grant for all users effectively neuters Kali365 without impacting productivity.
  • Continuous Access Evaluation (CAE): While not a direct countermeasure for token theft, CAE can reduce the lifetime of stolen tokens by forcing re-evaluation when risky user actions are detected or when critical events (like password change) occur. However, CAE does not yet cover all scenarios.
  • Identity Protection and Risk-Based Policies: Microsoft Entra ID Protection can detect suspicious sign-in behaviors and automatically raise user risk levels, triggering a password reset or requiring additional MFA. While an attacker with a valid token might not trigger these immediately, their subsequent activities might.
  • Token Binding: Microsoft has been rolling out support for token binding, which cryptographically binds a token to a specific device. Kali365 tokens would be unusable from another device if binding is enforced, but adoption remains limited as of mid-2026.

Administrators are also urged to review application consent policies, as attackers sometimes use the initial token to grant consent to malicious applications. Enforcing admin consent workflow and blocking end-user consent for high-privilege scopes can prevent such pivoting.

Community Reaction: Windows Enthusiasts Sound the Alarm

On Windows-focused discussion boards and security forums, the FBI alert quickly became a top thread. Users expressed frustration that the device code flow remains enabled by default in many tenants, with one common sentiment being that “it’s a feature few people need but hackers love.” Several community members shared stories of their own organizations receiving suspicious device code prompts, often disguised as mandatory Microsoft verification steps.

Discussions delved into the technical limitations of detection. Since the initial sign-in appears to come from the victim’s own IP and passes MFA, traditional SIEM rules often miss the attack. Enthusiasts have begun sharing custom Sentinel queries and PowerShell scripts to detect device code sign-ins correlated with out-of-band phishing reports. One user noted that while Microsoft’s documentation strongly recommends disabling device code, many small and mid-sized businesses are unaware of the risk until it’s too late.

The Windows community is also debating the broader implications for token-based authentication. As passwordless methods expand, the phishable surface shifts from static credentials to dynamic tokens. “We’ve traded one problem for another,” a veteran IT professional remarked. “Now the challenge is protecting the token lifecycle, not just the login moment.”

The Bigger Picture: Phishing Kits Get Smarter

Kali365 is not an isolated innovation. It belongs to a wave of advanced phishing kits that abuse legitimate protocols. In 2025, kits like FishXProxy and SniperPhish already exploited OAuth consent phishing, but device code abuse takes the deception a step further by involving the victim directly in the authentication on a genuine Microsoft page. This eliminates the need for fake login portals altogether, making detection dramatically harder.

Automation and artificial intelligence are accelerating these threats. Future iterations of Kali365 could integrate with AI voice cloning to deliver vishing calls that guide users through entering device codes. The FBI warns that cybercriminal groups are already experimenting with such multi-channel attacks.

For Windows users, the attack highlights a fundamental truth: identity has replaced the network perimeter, and tokens are the new keys to the kingdom. As organizations rush to adopt passwordless authentication and expand their reliance on Microsoft Entra, the burden of protecting those tokens shifts to comprehensive, zero-trust strategies that verify every access attempt, even if it comes from a legitimate-looking login session.

What Windows Users and IT Admins Should Do Now

While Microsoft works on longer-term architectural fixes, immediate action is essential:

  • Disable the device code grant for all users unless absolutely required by line-of-business applications. This can be done via Conditional Access by targeting the “Device Code” grant under session controls.
  • Audit existing device code usage to identify any legitimate scenarios. Often, only hardware like conference room panels or specialized IoT devices rely on it, and those can be whitelisted.
  • Educate users to never enter a device verification code from an unsolicited message. The official Microsoft login page will never randomly ask you to enter a code; such prompts should always be treated with suspicion and reported to IT.
  • Enable logging and monitoring for device code authentication attempts. Set up alerts in Microsoft Sentinel or other SIEM tools for all device code activity, with immediate investigation for any success events.
  • Review token lifetimes and consider reducing refresh token validity, especially for sensitive roles. While not a complete fix, it mitigates the persistence window.
  • Implement token protection policies in Microsoft Defender for Office 365, which can help identify and block known token replay attacks.

For home users and Microsoft 365 Personal subscribers, the FBI advises vigilance. Be wary of any email or text message directing you to microsoft.com/devicelogin unless you yourself initiated the process on a device that displayed the code.

The Road Ahead for Token Security

The emergence of Kali365 signals a maturing underground economy where sophisticated attack methods are packaged and sold like consumer software. As long as the device code flow exists—and it likely will, given its necessity for many IoT and zero-touch deployment scenarios—defenders must adapt.

Microsoft is reportedly exploring more restrictive default policies for device code in commercial tenants. Sources inside the company indicate that future releases of Windows and Entra ID will prompt administrators to explicitly opt into the feature rather than having it open out of the box. Additionally, machine learning models that detect anomalous device code activity are being refined to catch proxy rotation and other evasion techniques.

But the most critical shift must happen in mindset. Phishing is no longer just about stolen passwords; it’s about stolen sessions. Defense-in-depth for identity means combining strong authentication with real-time monitoring, least privilege, and continuous verification. Kali365 is a wake-up call—one that proves that even as we eliminate passwords, attackers will find the next weak link. This time, it’s the very mechanism designed for devices that can’t type.