On May 21, 2026, the FBI's Internet Crime Complaint Center (IC3) published a public service announcement, alert number I-052126-PSA, warning defenders about a phishing-as-a-service (PhaaS) platform called Kali365. The advisory is short, but its implications are not. Kali365 industrializes one of the most effective MFA-bypass techniques in circulation: it uses the OAuth 2.0 device-authorization flow to trick victims into handing attackers valid Microsoft 365 access and refresh tokens, without ever intercepting a password and without the attacker completing any MFA challenge of their own.
What makes Kali365 worth a federal advisory is not novelty in the technique. Device-code phishing has been documented for over a year, including in Microsoft's own analyses of campaigns through early 2026. What is new is commoditization. Kali365 is sold as a subscription service, distributed primarily through Telegram, and bundles AI-generated phishing lures, automated campaign templates, real-time target-tracking dashboards, and turnkey OAuth token capture. It lowers the barrier to entry so far that a technically unsophisticated buyer can run a credential-free, MFA-immune token-theft campaign against any organization that has not explicitly disabled the device-code flow.
This is the identity-security story of mid-2026 in microcosm: the most durable attacks no longer target the password or even the second factor. They target the authorization layer — the tokens issued after a legitimate, fully-MFA'd login. This post breaks down how Kali365 works, what the FBI recommends, what detection looks like, and the one conditional-access change that structurally defeats the entire technique.
TL;DR
- The FBI/IC3 PSA I-052126-PSA, dated May 21, 2026, warns about Kali365, a phishing-as-a-service kit first seen in April 2026 and distributed primarily via Telegram.
- Kali365 abuses the OAuth 2.0 device-authorization (device-code) flow to capture Microsoft 365 access and refresh tokens without intercepting credentials and without completing any MFA challenge.
- With a valid refresh token, attackers maintain long-term, password-free, MFA-immune access to Outlook, Teams, and OneDrive until the token is revoked or expires, blending into normal activity.
- The kit lowers the skill barrier: it provides AI-generated lures, campaign templates, target-tracking dashboards, and token-capture as a subscription product.
- The single most effective mitigation, per the FBI: create a conditional-access policy that blocks the device-code flow for all users (excluding break-glass accounts), and audit existing device-code usage first.
- The PSA provides no IOCs; defense is configuration-led and behavior-based, not signature-based.
What happened
The IC3 advisory (alert I-052126-PSA, May 21, 2026) describes Kali365 as a PhaaS platform that "emerged in April 2026" and is being distributed in the wild, "primarily via Telegram." Its purpose is to let threat actors "obtain Microsoft 365 access tokens and bypass multi-factor authentication (MFA) protocols" — and to do so without intercepting the user's credentials.
The advisory frames Kali365 as an accessibility multiplier. It provides subscribers with AI-generated phishing lures, automated campaign templates, real-time individual- and entity-tracking dashboards, and OAuth token capture capabilities. In other words, the operator does not need to understand OAuth, write a phishing kit, or stand up infrastructure. They subscribe, point the tooling at targets, and harvest tokens.
The FBI's recommended mitigations are squarely focused on the device-code flow. The PSA advises defenders to create a conditional-access policy that blocks the device-code flow for all users, to audit existing device-code flow usage first, to block authentication-transfer policies, and to exclude emergency (break-glass) access accounts from the restriction so administrators are not locked out. Notably, the PSA itself includes no indicators of compromise — a deliberate signal that this is a technique-and-configuration problem, not something you block with a domain feed.
How the attack works
Device-code phishing is effective precisely because every step the victim takes happens on legitimate Microsoft infrastructure. There is no fake login page to spot. The deception is entirely in the framing of why the user is being asked to enter a code.
[1] Attacker initiates a device-code authorization request to Microsoft
| Microsoft returns a real device code + the real
| https://microsoft.com/devicelogin URL
v
[2] Kali365 sends an AI-generated lure to the victim
| "Enter this code to access the shared document / join the meeting"
v
[3] Victim visits the GENUINE Microsoft devicelogin page
| enters the code, signs in, completes MFA (all real, all legit)
v
[4] Microsoft issues ACCESS + REFRESH tokens to the device that
initiated the request -- i.e. the ATTACKER, not the victim
v
[5] Attacker holds valid tokens -> Outlook / Teams / OneDrive
| no password, no further MFA, persistence via refresh token
v
[6] Refresh token mints new access tokens until revoked or expired
The mechanic in step 4 is the crux. The OAuth device-authorization grant (RFC 8628) was designed for input-constrained devices — smart TVs, CLI tools, IoT — where typing a password is impractical. The device that initiates the flow receives the tokens once a human authorizes the request elsewhere. Kali365 weaponizes that separation: the attacker's infrastructure initiates the flow, and the victim is socially engineered into being the human who authorizes it. From Microsoft's perspective, a legitimate user signed in and approved a device-code request. From the victim's perspective, they entered a code on a real Microsoft page. Both are true. Neither sees the theft.
Because the attacker now holds a refresh token, the access is durable. Refresh tokens are designed to silently mint new access tokens so users do not have to re-authenticate constantly. In the attacker's hands, that same property means persistent access that "blends in with normal account activity" until the token is explicitly revoked or naturally expires. This is why device-code phishing defeats even phishing-resistant MFA in the conventional sense: there is no spoofed origin for a FIDO2 authenticator to reject, because the victim is authenticating against the real Microsoft origin. The attack is not on the login; it is on what the login produces.
The following is an illustrative, non-functional sketch of the request/response shape to make the token-handoff concrete. It is not runnable and omits parameters; it exists only to show which party ends up with the tokens.
# ILLUSTRATIVE — device-code flow abuse (not functional code)
# Attacker -> Microsoft (initiates flow):
POST /devicecode scope="offline_access ..."
# Microsoft -> Attacker:
{ "device_code": "...", "user_code": "ABCD-EFGH",
"verification_uri": "https://microsoft.com/devicelogin" }
# Kali365 lure -> Victim: "enter ABCD-EFGH at the link to view the file"
# Victim authenticates on the REAL page, completes MFA.
# Attacker polls Microsoft until authorized:
POST /token device_code="..."
# Microsoft -> Attacker (the INITIATING device):
{ "access_token": "...", "refresh_token": "...", # <-- attacker holds these
"expires_in": 3600 }
What detection looks like
With no IOCs to match, detection is behavioral and lives in Entra ID sign-in logs and Microsoft 365 audit telemetry.
- Device-code authentications you did not expect. In Entra ID sign-in logs, filter on the device-code authentication protocol. Most organizations have very few legitimate device-code sign-ins; a spike, or sign-ins from users who would never use a CLI/IoT flow, is a strong signal.
- Token issuance followed by access from new infrastructure. A successful device-code sign-in from the user's normal context, immediately followed by Graph/Outlook/Teams access from a different ASN or geography, indicates the tokens left the building.
- Refresh-token reuse from anomalous origins. Watch for access tokens minted from a refresh token where the originating IP/device fingerprint drifts away from the user's baseline.
- Post-access mailbox and collaboration activity. Token-holding attackers commonly create inbox rules (often with odd or single-character names), enumerate mail via Microsoft Graph, and access OneDrive/Teams content. Baseline per-identity Graph usage and alert on spikes.
- Entra ID Protection risk detections. "Anomalous token" and "unfamiliar sign-in properties" detections frequently fire on device-code abuse; route them to a SOC queue rather than letting them auto-remediate silently.
What to do Monday morning
Ordered by impact, following and extending the FBI's guidance.
- Audit current device-code flow usage before you block it. Query Entra ID sign-in logs for the device-code authentication protocol over the last 30-90 days to identify any legitimate consumers (legacy CLI tools, specific IoT/AV equipment). You need this inventory so the block does not break a real workflow.
- Create a conditional-access policy that blocks the device-code flow for all users. This is the FBI's primary recommendation and it structurally defeats Kali365. In Entra ID, build a CA policy targeting the device-code authentication flow with Grant = Block.
- Exclude break-glass / emergency-access accounts from the block. Ensure at least two emergency accounts are excluded so a misconfiguration cannot lock administrators out.
- Block authentication-transfer flows as the PSA advises, to close the adjacent token-handoff techniques.
- Shorten token lifetimes and enable Continuous Access Evaluation (CAE). CAE lets Entra ID revoke access near-real-time on risk signals, shrinking the window a stolen refresh token stays useful even if one is captured.
- Revoke sessions on any suspected compromise. Use the Microsoft 365 revoke-sessions action and reset the affected user's tokens; a password reset alone does not invalidate already-issued refresh tokens.
- Brief users on the specific lure shape. Tell staff plainly: Microsoft will not ask you to "enter a code to view a document" or "to join a meeting." A request to type a code at microsoft.com/devicelogin that you did not initiate is a red flag to report, not complete.
Why this keeps happening
The recurring lesson of 2026 is that the security perimeter moved from credentials to tokens, but most controls and most user training did not. Organizations invested heavily in MFA on the premise that it stops phishing. Device-code phishing sidesteps that premise entirely: it does not phish the password and it does not phish the second factor. It phishes the authorization decision, using Microsoft's own legitimate flow as the stage. The victim's MFA works perfectly — for the attacker.
Commoditization is the accelerant. When a technique requires a skilled operator, its volume is bounded by the supply of skilled operators. PhaaS kits like Kali365 break that bound. By packaging AI-generated lures, campaign automation, target dashboards, and token capture into a Telegram subscription, the kit converts a niche tradecraft into a point-and-click product. The result is more campaigns, run by less capable actors, against a wider set of targets — which is exactly why a federal advisory was warranted for a technique that is not, in itself, new.
Underneath both is a configuration default: the device-code flow is enabled in most tenants because RFC 8628 exists for good reasons, and disabling it requires a deliberate conditional-access policy that many organizations never created. Attackers thrive in the gap between "enabled by default" and "actually needed."
The structural fix
The decisive control here lives in your identity provider, not in a supply-chain tool: a conditional-access policy that blocks the device-code flow, plus CAE and short token lifetimes. We will state plainly that Safeguard does not replace that. Make the Entra ID change first.
Where Safeguard reduces blast radius is in what a stolen token can ultimately reach. A device-code-phished token grants access to mailboxes, Teams, and OneDrive — exactly the places where engineers and operators paste API keys, deployment tokens, and connection strings. The value of a compromised M365 session scales with the live secrets sitting inside it. Secret detection across code, CI/CD, and IaC shrinks that payoff by surfacing the static credentials that would otherwise be discoverable from an authenticated session and flagging them for rotation toward short-lived alternatives. It would not stop the device-code phish, but it shortens dwell time and limits what the next-stage pivot can monetize. Wiring those findings into an incident-response workflow that treats any token-theft detection as a secrets-exposure event — revoking sessions and rotating reachable secrets — is the honest, available improvement.
What we know we don't know
- The PSA does not name a specific threat actor operating Kali365 or quantify victims; treat scale and attribution as open.
- No IOCs were published with the advisory. Any domain or IP lists circulating in secondary reporting are not FBI-confirmed.
- Subscription pricing and exact feature set of Kali365 are described at a high level; specifics vary across secondary reporting and are not authoritatively confirmed.
- The relationship between Kali365 and other 2026 device-code/AiTM campaigns (e.g., Microsoft's documented device-code and "code of conduct" activity) is one of shared technique, not confirmed shared operators.
References
- FBI / IC3 Public Service Announcement I-052126-PSA, "Kali365 Phishing-as-a-Service Kit Hijacks Microsoft 365 Access Tokens" (May 21, 2026): https://www.ic3.gov/PSA/2026/PSA260521
- Infosecurity Magazine, "FBI Warns 'Kali365' Phishing Kit Hijacks Microsoft 365 OAuth Tokens": https://www.infosecurity-magazine.com/news/fbi-kali365-phishing-kit-m365/
- Cybersecurity Dive, "FBI warns about PhaaS platform used to access Microsoft 365 environments": https://www.cybersecuritydive.com/news/fbi-warns-phishing-platform-microsoft-365/821105/
- Help Net Security, "Microsoft 365 users targeted by new phishing threat that bypasses MFA": https://www.helpnetsecurity.com/2026/05/22/kali365-microsoft-365-phishing-fbi-warning/
- Malwarebytes, "Kali365 phishing kit bypasses MFA and steals Microsoft logins": https://www.malwarebytes.com/blog/scams/2026/05/kali365-phishing-kit-bypasses-mfa-and-steals-microsoft-logins
Internal reading: