Kali365: How This Phishing Kit Defeats MFA in M365

Why MFA alone no longer offers protection

Classic phishing targets the password. MFA was built exactly for that and still works well there: anyone who only knows the password gets no further without the second factor. Kali365 and comparable attack techniques such as adversary-in-the-middle phishing (AiTM) and device code phishing, however, no longer target the password at all. They target what is created after a successful login: the session token (access and refresh token) that Microsoft Entra ID issues once the MFA check has been completed.

This token is the digital ID that confirms to a device: “This person has just successfully signed in with a password and a second factor.” Whoever holds this token no longer needs to sign in, they are already signed in. It is exactly this token that Kali365 captures, not the password and not the MFA code.

How the Kali365 attack works in detail

Kali365 does not exploit a security vulnerability for this, it abuses an entirely legitimate Microsoft feature: the OAuth 2.0 Device Authorization Grant, better known as the device code flow. It was originally built to let devices without their own keyboard or browser, such as smart TVs, streaming boxes, printers, or conference room systems, sign in via a second device. To do this, the user opens the genuine Microsoft page microsoft.com/devicelogin and enters a short code shown to them by the device. According to the FBI advisory, the attack runs in four steps:

The lure

The victim receives a convincing phishing email that imitates a trusted cloud or document-sharing notification, for example a supposed SharePoint or Teams alert. The email contains a device code and asks the recipient to enter it on a “verification page.”

The authorization

The victim clicks the link and does not land on a fake page, but actually on the genuine Microsoft page microsoft.com/devicelogin. There they enter the code supplied by the attacker and confirm the sign-in, usually including their own MFA prompt. There is no spoofed domain, no typo in the URL, and no suspicious login screen to spot.

The token theft

In the background, the Kali365 platform itself has requested exactly this device code from Microsoft. As soon as the victim confirms the code and completes MFA, Microsoft issues the access and refresh token not to the victim, but to the attacker’s device. The attacker receives a fully valid, MFA-confirmed session token without ever having to enter a factor themselves.

Persistence

With the stolen token, the attacker gets immediate access to Outlook, Teams, OneDrive and SharePoint, as well as any other SaaS application connected via single sign-on, all without a password and without another MFA prompt. Refresh tokens are also often valid for weeks.

This is exactly the answer to why MFA does not help: the MFA check happens completely normally, just on the attacker’s device instead of one that belongs to the organization. The victim effectively completes the MFA confirmation on the attacker’s behalf. There is no point in the flow where a classic second factor could still prevent access, because the attacker never needs to possess it themselves.

According to the FBI, Kali365 also offers its customers a convenient dashboard with AI-generated phishing templates, automated campaigns, and a live overview of which victims have already entered the code, including automatic handover of the captured tokens.

How easy is it to “subscribe” to Kali365?

What is actually most alarming about Kali365 is not the technology behind it, but the way it is sold. According to the FBI and several security analysts, Kali365 is openly advertised through Telegram channels as a monthly subscription, following the classic software-as-a-service model. Anyone who pays gets access to a web dashboard, ready-made phishing templates, AI-powered text generators for the lure emails, and a tracking interface for the running campaign. Programming skills, server administration, or knowledge of OAuth flows are no longer required, the platform handles all of that itself.

This drives the barrier to entry for this type of attack down to almost nothing. From an organization’s perspective, that means the threat no longer comes only from highly specialized attacker groups, but potentially from anyone willing to pay a few dozen dollars for a subscription. That is exactly why the FBI and CISA rate Kali365 as so dangerous, and why their joint warning is so urgent.

What happens after a successful takeover?

A stolen token is not an end in itself for attackers, it is the starting point of the actual attack chain. In the cases documented by the FBI and by security vendors, several steps typically follow, either automated or semi-automated:

📂

Data exfiltration via OneDrive & SharePoint

Using the valid token, the attacker systematically searches the victim’s OneDrive, SharePoint, and Teams files for sensitive documents, credentials, or financial records, and downloads them in bulk.

📥

Hidden inbox rules

Unobtrusive rules are created in the Outlook mailbox that automatically move or delete certain replies (for example, to fraud attempts or colleagues’ follow-up questions) into hidden subfolders, so the victim notices the abuse as late as possible.

✉️

Abuse for further phishing

Using the compromised, trusted mailbox, the attacker sends further phishing and spam emails to colleagues, customers, and partners, who typically trust this sender more than an unfamiliar address.

🔑

Expansion to other systems

Because a Microsoft 365 account often also grants access to other SaaS services such as Salesforce or HR systems via single sign-on, the attacker uses the token to move laterally into further cloud applications within the organization.

Because neither a password is changed nor an unusual MFA prompt is triggered, such compromises often go undetected for weeks. The most reliable early warning signs are unknown device registrations, sign-ins from unusual regions, and new forwarding or mailbox rules in the Microsoft 365 sign-in and audit logs that the user did not create themselves.

The most effective lever: restricting the device code flow with Conditional Access

Because the attack abuses a legitimate Microsoft feature, no antivirus software and no additional MFA method on its own will help. The most reliable protection is to block the device code flow for every account that does not actually need it. Microsoft itself recommends exactly this through a dedicated condition in Conditional Access. Here is how to set up the policy step by step in the Microsoft Entra admin center:

Sign in to the Microsoft Entra admin center with at least the Conditional Access Administrator role.
In the left-hand menu, go to Protection → Conditional Access → Policies.
Click New policy at the top and give it a clear name, for example “Block Device Code Flow (with exceptions).”
Under Assignments → Users, select All users under “Include.” Under “Exclude,” add at least your emergency access (break-glass) accounts so you do not lock yourself out in case of a misconfiguration.
Under Target resources, choose Cloud apps and include All cloud apps.
Go to Conditions → Authentication flows, set “Configure” to Yes, and enable Device code flow there. Confirm with “Done.”
Under Access controls → Grant, select Block access and confirm with “Select.”
At the bottom, set “Enable policy” to Report-only first and save with Create.
Monitor the impact for a few days using “Policy Impact” and the sign-in logs. Only once no unexpected blocks occur should you switch the policy from “Report-only” to On.

A note on staying current: the labels and navigation in the Entra admin center change from time to time. Double-check the current click paths against the official Microsoft documentation before you turn the policy on in production.

📹 Don’t forget exceptions for conference room systems

If you apply the policy as described above to “All cloud apps” and “All users,” you will also block legitimate uses of the device code flow. Conference room systems, Teams Rooms devices, some streaming boxes, printers, and older IoT devices frequently sign in using exactly this mechanism. Before you turn the policy on, filter the Entra sign-in logs specifically for the “Device Code” authentication protocol to find out which accounts and devices actually need this flow.

Then create a dedicated security group for these devices (for example, “Device Code Flow Exception – Conference Rooms”) and add that group under “Assignments → Users → Exclude” in your blocking policy. This keeps the conference room systems able to sign in while the device code flow is consistently blocked for all regular user accounts. This exception list should be documented and reviewed regularly so it does not quietly grow into a security gap of its own.

Conditional Access alone is not enough, awareness matters too

Conditional Access closes the technical attack path for Kali365. It does not change the fact that the attack begins with a credible phishing email designed to get a person to take an action. As long as employees follow emails containing device codes without checking them, variations of this attack technique will keep working, whether through other OAuth flows, QR codes, or new tricks that are not yet known today.

Our recommendation: Combine technical controls with targeted phishing awareness training. Employees should specifically learn what a device code login looks like, why an unsolicited request to enter a code on microsoft.com/devicelogin should always raise suspicion, and who to contact if in doubt before they confirm the code.

How Mint Secure can help

We help organizations protect themselves against exactly this type of identity attack, both technically and organizationally:

Conditional Access assessment

We review your Microsoft 365 tenant for risky authentication flows, identify genuine device code flow users, and design production-ready Conditional Access policies with you, exceptions included.

Phishing simulations & awareness training

Using realistic campaigns, including device code phishing, we train your employees hands-on and measure training success over time.

Incident response

In the event of an incident, we support the forensic investigation of an account takeover, help track down manipulated inbox rules, and contain the incident quickly.

M365 security health check

We assess your entire Microsoft 365 tenant against current threats and best practices, far beyond just Conditional Access.

Want to know whether your tenant is vulnerable to device code phishing like Kali365? We review your Conditional Access configuration and close the gap together with you. Get in touch now.

Kali365: How the Phishing Platform Defeats MFA in Microsoft 365, and How Conditional Access Stops It