FBI Kali365 Warning 2026: why OAuth device-code phishing slips past MFA

The FBI PSA in 60 seconds

FBI IC3 alert PSA260521 describes Kali365 as a turnkey phishing kit sold on Russian-language Telegram channels and underground forums. Operators pay roughly $199 per month for hosted landing pages, automated victim funneling, and a console that surfaces freshly hijacked Microsoft 365 sessions in near real time. The FBI says targets include managed service providers, accounting and law firms, healthcare networks, and small to mid-size enterprises that run on Microsoft 365 but lack mature conditional access policies. BleepingComputer's coverage adds that several incident-response firms began seeing Kali365 indicators in late February 2026, with a sharp uptick through April. What makes Kali365 different from the usual fake-login kits is what it asks the victim to do: not type a password, but enter a short device code at the real microsoft.com domain.

How OAuth device-code phishing actually works

OAuth's device authorization grant, defined in RFC 8628 and implemented by Microsoft Entra ID, was designed for hardware without a real browser. Think smart TVs, Xbox consoles, IoT devices, CLI tools like the Azure CLI or kubectl. The flow looks like this on a friendly day:

1. The device asks Microsoft's token endpoint for a fresh device code. Microsoft returns two strings: a long device code (used by the device to poll for the token) and a short user code, typically eight or nine characters like "FQRMNXSP".
2. The device shows the user code on its screen and says: "go to microsoft.com/devicelogin and enter FQRMNXSP".
3. The user opens a browser, signs into their Microsoft 365 account normally (including MFA), and types the code into the page at microsoft.com/devicelogin.
4. Microsoft binds the authenticated session to the device code. The device, still polling, receives an access token and a refresh token.

Now replace "device" with "attacker server" and watch the flow break. A Kali365 operator initiates a device-code request against Microsoft's endpoint, harvesting the user code. Then a phishing email lands in your inbox claiming you need to enroll a new Teams Room, approve a SharePoint sync, or activate a Microsoft Defender for Endpoint license. The email tells you to visit microsoft.com/devicelogin and paste in a code that the attacker generated. You sign into your real Microsoft account, type the code, and click confirm. Microsoft, doing exactly what it was designed to do, sends an access token and refresh token to the attacker's polling server. You never typed a credential into anything malicious, your MFA push was approved correctly, and yet the attacker now holds a session that looks indistinguishable from yours.

Why MFA does not save you

Multi-factor authentication assumes the failure mode is a stolen password being replayed somewhere it should not be. The whole point of a second factor is to break that replay. Device-code phishing inverts the assumption. The attacker never tries to replay your password. You authenticate exactly as Microsoft expects, on the real microsoft.com domain, on the device you always use, against your tenant's real identity provider. The MFA challenge fires and you approve it because you genuinely are signing in. The fraud is not at the authentication step. It is at the consent step, where you bind your freshly authenticated session to the wrong piece of hardware.

Microsoft Authenticator number matching, which we covered in the MFA fatigue post, does not help here either. Number matching defeats push spam by forcing the user to type a number from the login screen they did not open. In device-code phishing the user opens the login screen themselves. There is no anomaly to flag.

This is why the FBI used the phrase "post-MFA" persistent compromise in PSA260521. Once the attacker holds the access token and refresh token, they can pull Outlook mail, send messages from your address, enumerate the SharePoint tenant, register their own MFA method on your account, and silently refresh the session for as long as the refresh token lives. No future MFA prompt fires because the attacker never re-authenticates. They just keep refreshing.

What SafeBrowz sees on the network

Our detection engineering team has been mapping Kali365 landing-page infrastructure since late February. A few patterns matter, and they are the patterns our 3-layer engine is specifically tuned to catch.

First, the landing pages almost never live on microsoft.com itself. They live on lookalike hosts that funnel the victim toward the legitimate microsoft.com/devicelogin URL only after a fake "verify your tenant" or "register your device" interstitial. The interstitial is where the social engineering happens, and that interstitial almost always sits on a newly registered domain. From the campaigns we have analyzed, typical Kali365 lookalike domain age is under seven days at the moment of compromise. Some are under twelve hours. This is the strongest server-side signal we have for the kit family, and it lines up perfectly with how our Layer 2 reputation lookups behave: Google Safe Browsing, PhishTank, and URLhaus all surface fresh malicious domains within hours, and our extension reads those feeds for every navigation.

Second, the lookalike host names cluster around a handful of structural variants. We see "ms-teams-rooms-{tenant}.{tld}", "microsoft365-activate-{region}.{tld}", "m365-defender-onboard.{tld}", "office-licensing-portal.{tld}", "azureportal-verify.{tld}", "sharepoint-sync-{department}.{tld}", and a long tail of one-off creative names. Many use cheap or abused TLDs (.shop, .top, .xyz, .live, .click) because they are inexpensive at scale. Microsoft is one of the 550+ brands in our local detection database, and the brand-specific signature catches every one of the lookalike-suffix variants the moment the navigation begins, before the page even paints.

Third, the landing-page content has a tell that our Layer 3 AI content analysis is exceptionally good at finding. The kit needs to convince a real person to copy a real OAuth user code and paste it into a real Microsoft page. That requires written social-engineering copy: instructions like "you have been issued a one-time onboarding code: XXXX-XXXX", "open microsoft.com/devicelogin in a new tab", "this code expires in 8 minutes". This language is rare on legitimate Microsoft surfaces. Microsoft does not normally ask a human to copy device codes between two windows. When our AI deep scan sees that pattern combined with Microsoft branding on a non-microsoft.com host, the verdict is danger every time. We did not write a Kali365-specific rule. We did not have to. The general "lookalike brand + OAuth handoff instruction" pattern fires on the entire kit family because the kit family cannot stop producing those instructions and still function.

Why browser-side beats email-only here

The Kali365 advisory is going to get framed in some places as a reason to buy more secure email gateway. Our perspective is harsher. Email gateways are necessary, but for this attack class they are insufficient by design.

SPF, DKIM, and DMARC validate that the sending domain controls the message. Kali365 operators routinely send from compromised legitimate tenants (the kit hijacks Microsoft 365 mailboxes and uses them as launchpads for the next wave), so the email passes every authentication check. The sending domain is real. The display name is real. The signature block is real. Sandboxing the link does not help much either, because the landing page often presents benign content to non-human user agents and renders the OAuth interstitial only when fingerprinted as a real browser.

By the time the user clicks the link, the gateway has already approved the message. The defense has to be wherever the rendering happens. That is the browser. A browser-side scanner that holds a 550+ brand database, reads global reputation feeds, and runs language-model content analysis on the rendered page is the only layer that sees the moment of compromise. That is the layer SafeBrowz sits at, and that is why we built it the way we did.

How SafeBrowz blocks this threat

SafeBrowz runs a 3-layer detection architecture: Local + APIs + AI.

• Layer 1 - Local detection: 60+ URL patterns plus 550+ brand-specific signatures (Microsoft and Microsoft365 / Outlook / Teams / SharePoint / Azure variants included), Cyrillic and Punycode homograph awareness, and community lists run directly inside the extension before the page renders. The lookalike-host structural patterns described above (ms-teams-rooms-*, microsoft365-activate-*, m365-defender-onboard-*, office-licensing-portal-*) all match the brand-impersonation rule family on Layer 1 and block before paint.
• Layer 2 - API reputation: server-side aggregation of Google Safe Browsing, PhishTank, URLhaus, ScamAdviser, and 30+ scam-TLD checks. Newly registered Microsoft lookalike domains (typical Kali365 domain age under seven days) surface in PhishTank and URLhaus within hours, often within minutes. Our extension reads those signals on every navigation.
• Layer 3 - AI deep scan (Premium): a multi-language content analyzer that reads the rendered page and reasons about intent. For Kali365 the giveaway signature is "lookalike Microsoft branding plus OAuth device-code handoff instructions plus expiring user code". When that pattern shows up on a non-microsoft.com host, the verdict is danger. The same engine works in 100+ languages, which matters because Kali365 ships localized landing pages for Spanish, Portuguese, Arabic, French, and German targets.

Detection signatures come from threat-intelligence research and our brand database, not from user browsing data. Per-user URL history is never stored.

What enterprises and consumers do right now

If you run a Microsoft 365 tenant, do not wait for next quarter to address Kali365. Specific steps in priority order:

1. Audit your sign-in activity at aka.ms/signin. Look for OAuth grants from device names you do not recognize, geographic mismatches, and "Other client" device entries on accounts that should be browser-only.
2. Revoke active sessions tenant-wide for high-risk users. In the Microsoft 365 admin center go to Users, pick the account, open Sign-in activity, and click Revoke. Refresh tokens hold even after a password reset; revoking sessions is the only way to forcibly kill them.
3. Set Conditional Access policies that disable the device code flow except for explicit personas. Microsoft Entra now ships a built-in Conditional Access template for "Block authentication flows - Device code flow" (policy reference). Most tenants should block device code for everyone except IT operators who actually use Azure CLI or kubectl. This single change ends Kali365 in your tenant.
4. Inspect the OAuth consent log. Microsoft 365 admin, Enterprise applications, Audit logs. Filter for ConsentEvents in the last 30 days. Look for unknown application IDs, especially anything resembling generic CLI or scripted tool names. Unknown consents granted around the time of suspicious sign-ins are the smoking gun.
5. Enforce phishing-resistant MFA on the highest-risk personas. FIDO2 security keys or platform passkeys for finance, legal, executive admins, and IT operators. Device-code phishing is the rare attack that works against authenticator-app MFA. Pure passkeys still raise the bar because the attacker's polling server cannot drive a passkey-bound session.
6. If you suspect a Microsoft Authenticator account has been touched by an attacker, remove it from the app, reset MFA from a clean device, and re-enroll. While you are there, audit registered MFA methods on the user object; attackers love to silently add a phone number or a TOTP secret of their own as a backdoor.
7. Train users on one specific sentence. "Microsoft will never email you a code to paste into microsoft.com/devicelogin". If a user sees that phrasing in an email, the email is hostile, full stop. This single sentence is more effective than any generic phishing-awareness training because it names the exact attack.

For consumer Microsoft accounts (outlook.com, hotmail.com, Xbox), the same logic applies, just narrower. Check account.microsoft.com/security for recent activity, sign out everywhere, and rotate the password. The consumer side does not expose Conditional Access policies, but the device code flow is much rarer in consumer scenarios, so an unexpected device-code prompt should be treated as guaranteed-hostile.

What comes next: our brand-pivot prediction

Kali365 is the first phishing-as-a-service kit to industrialize OAuth device-code abuse, but the technique is not Microsoft-specific. Any identity provider that ships an OAuth device authorization grant is structurally exposed. Our detection team's prediction for the next twelve months, based on what we see in our brand database and what we are starting to find in early-stage lookalike registrations:

• Google Workspace device-code phishing. Google supports the device flow for Google TV, Workspace CLI, and gcloud. Workspace tenants without Context-Aware Access are the most exposed. We expect a Kali365-style clone targeting Google identities within months.
• GitHub device flow abuse. The GitHub CLI uses the device flow to authenticate developers. A stolen GitHub session can lead directly to source-code exfiltration, malicious commits in supply-chain dependencies, and Actions secrets theft. Highly leveraged target, and very few organizations apply Conditional Access to GitHub.
• Anthropic Claude API and OpenAI API auth tokens. AI APIs do not currently use OAuth device flow, but the broader pattern (long-lived API tokens phished from developers via lookalike consent pages) is already real. We have started adding "Claude" and "Anthropic" to our brand database for exactly this reason.
• AWS IAM Identity Center (formerly SSO) device authorization. AWS supports a device authorization grant for CLI v2 sso login. An organization that relies on long-lived AWS SSO sessions for terraform and kubectl operators is one Kali365-style kit away from a worst-case cloud breach.
• Atlassian, Slack, Zoom. All of these expose OAuth consent screens that look highly trustworthy and rarely get audited. Kits will eventually target them once Microsoft 365 mitigation closes the most lucrative entry point.

One more observation. The PaaS economic model is the real story here, not the specific kit. At $199 a month with a Telegram support channel and a hosted control panel, Kali365 means an attacker no longer needs to understand OAuth at all. They need a credit card (or USDT in a Telegram wallet) and a target list. The skill floor for highly persistent, MFA-immune cloud account takeover has dropped to near zero. Every browser-layer defender should plan around that shift, not around the specific name on this month's advisory.

Frequently asked questions

What is Kali365 in one sentence?

Kali365 is a phishing-as-a-service kit, called out by the FBI in PSA260521 on May 21, 2026, that hijacks Microsoft 365 accounts by abusing the OAuth 2.0 device authorization grant so victims approve the attacker's session on the real microsoft.com domain.

How is Kali365 different from a regular Microsoft phishing kit?

Regular Microsoft phishing kits trick the user into typing a password and MFA code into a fake login page. Kali365 never asks for credentials. It tricks the user into pasting a short OAuth device code into the real microsoft.com/devicelogin URL after authenticating normally. The attacker receives the session token, MFA was satisfied legitimately, and there is no obvious credential theft to detect.

Why does multi-factor authentication not block Kali365?

Because the victim performs a real, valid sign-in to their own Microsoft account, including a real MFA challenge they correctly approve. The malicious action happens at the consent step, where the freshly authenticated session is bound to the attacker's device code. MFA is not bypassed in the cryptographic sense; it is rendered irrelevant by tricking the user into authenticating on the attacker's behalf.

What is the single most effective fix for an enterprise?

Block the device code authentication flow in Conditional Access for everyone who does not specifically need it. Microsoft Entra ships a one-click template for this. Most organizations have zero legitimate device-code usage outside IT operators on Azure CLI or kubectl. Blocking it tenant-wide for normal users ends Kali365 in your environment immediately.

How does SafeBrowz detect Kali365 if the kit constantly rotates domains?

Layer 1 brand impersonation rules trigger on the structural lookalike pattern, not on a specific domain. Layer 2 reputation feeds (Google Safe Browsing, PhishTank, URLhaus) surface freshly registered hosts within hours of first abuse. Layer 3 AI content analysis identifies the OAuth device-code social-engineering language regardless of where the page is hosted. The kit has to keep producing copy that asks users to paste codes into microsoft.com/devicelogin, and that copy is what we recognize.

I think a user in my tenant approved a Kali365 device code. What do I do in the next 15 minutes?

Open the Microsoft 365 admin center, find the user, open Sign-in activity, click Revoke sessions. This invalidates every refresh token bound to the account. Reset the user's password. Reset MFA methods on the user object and remove any registered authenticator the user does not recognize. Open Enterprise applications and review the OAuth grants for that user, revoking anything you do not own. Then go to the audit log and pull every action the attacker session took.

Does SafeBrowz collect any data about the URLs my users visit?

No. SafeBrowz performs Layer 1 detection locally inside the browser, with no URL leaving the device. Layer 2 reputation checks query global blocklists with the domain only, never with identity. Layer 3 AI deep scan, available to Premium users, sends rendered content excerpts for analysis and discards them after the verdict. We do not store per-user URL history, instance identifiers, or IP-to-URL associations. The Chrome Web Store, AMO, and Edge listings all certify the extension as not collecting web history.

Will phishing-resistant MFA like FIDO2 keys stop Kali365?

Yes, indirectly. A FIDO2 security key or platform passkey cannot be driven by an attacker's polling server because the cryptographic challenge is bound to the origin domain the user is browsing. Even if the user is socially engineered into copying a code, the attacker's session can only complete if the device flow is allowed for that account. Pair phishing-resistant MFA with a Conditional Access policy that disables device code flow for that user, and the attack path is closed.

Related reading

• How to spot a fake Microsoft email - the upstream attack that often funnels into device-code phishing
• MFA fatigue push spam attack - the other major MFA bypass class, and why number matching defeats it
• Adversary-in-the-middle 2FA bypass - reverse-proxy phishing that also produces persistent session tokens
• Fake Microsoft tech-support popup scam (DOJ 2026) - the consumer-side cousin of enterprise Microsoft impersonation

Bottom line: Kali365 is not a clever new exploit. It is a productized abuse of a documented OAuth flow, packaged for non-experts at $199 a month, that turns Microsoft's own authentication endpoints into the delivery mechanism for persistent account compromise. The fix in your tenant is concrete: block the device code flow in Conditional Access, audit your OAuth consent log, revoke sessions on any user who clicked, and put a browser-layer detection engine in front of the inbox. The FBI's PSA260521 is the warning. The next twelve months will determine which organizations treated it as a wake-up call and which kept relying on email gateways and MFA push to defend a cloud where neither is sufficient on its own.