Kali365 Turns Microsoft Login Flow Into a Phishing Tool#
The FBI is warning about Kali365, a phishing-as-a-service platform used to hijack Microsoft 365 accounts without stealing passwords or intercepting MFA codes directly.
The important part is the method. Kali365 abuses Microsoft’s legitimate OAuth 2.0 Device Authorization grant flow. That flow exists for devices with limited input, such as TVs, printers, conference room systems, streaming boxes, and IoT hardware. The device shows a short code. The user opens Microsoft’s device login page on another device, enters the code, and completes authentication.
In a phishing scenario, the attacker starts that flow first. They generate the code. Then they convince the victim to enter it at Microsoft’s real device login portal. If the victim completes MFA, Microsoft issues an OAuth access token to the session initiated by the attacker.
That is why this class of attack is dangerous. The victim may not type a password into a fake page. They may not give away a one-time MFA code. They may be interacting with a real Microsoft login page. But they are authorizing the wrong session.
What the FBI Says Kali365 Provides#
According to the report, Kali365 first appeared in April 2026 and is being distributed through Telegram channels to cybercriminal buyers. Its pitch is simple: lower the skill required to compromise Microsoft 365 accounts.
The FBI warning describes capabilities that include AI-generated phishing lures, automated campaign templates, real-time victim-tracking dashboards, and token-capture functionality. That matters because phishing-as-a-service does not need to invent new authentication weaknesses every time. It packages repeatable abuse into a service model.
BleepingComputer also notes prior reporting on device-code and voice-phishing activity against Microsoft Entra accounts, including activity tied to extortion groups such as ShinyHunters. The source also cites Arctic Wolf research from April that observed broad Kali365 activity targeting organizations worldwide.
In those campaigns, phishing emails directed victims to Microsoft’s device code login portal. The victim entered the attacker-provided code and unknowingly granted access. After compromise, attackers accessed mailboxes and created malicious inbox rules to hide activity. In some cases, they also registered new devices inside the victim’s Microsoft environment, extending their foothold.
Arctic Wolf described Kali365 as operating like a business. The structure reportedly includes administrators handling development, resellers promoting the service, and affiliates running campaigns. That model is familiar from other cybercrime markets. It turns a technique into a supply chain.
The MFA Lesson Is Uncomfortable#
This attack does not prove MFA is useless. It proves that MFA is not the whole trust decision.
MFA is still effective against many basic credential attacks. But device code phishing shifts the question. The attacker is not always trying to defeat MFA technically. They are trying to make the user complete MFA for a session the attacker controls.
Once the OAuth token is issued, the attacker can access whatever the user can access through single sign-on. The source specifically mentions Microsoft 365, Salesforce, and other cloud SaaS platforms connected through the user’s account. In practice, the blast radius depends on the user’s permissions, conditional access rules, session controls, device trust, and downstream app access.
This is the part organizations should not flatten into a generic phishing story. A stolen password can be reset. A malicious inbox rule can persist after the first login. A registered attacker-controlled device can change the recovery path. A valid token may look less suspicious than a crude login attempt from a known bad host.
The control problem is not only “did the user pass MFA?” It is “what session did they authorize, from what context, for what device, and with what follow-on access?”
Cookie Link Adds a Second Route#
The source also describes a second Kali365 attack mode called “Cookie Link.” Arctic Wolf reportedly identified it as an adversary-in-the-middle mode.
In this setup, the victim is proxied through attacker-controlled infrastructure. After the victim logs in and completes MFA, the attacker captures authenticated browser sessions, session cookies, and tokens. That is a different route to the same strategic goal: avoid needing the password again by taking the session material that proves authentication already happened.
The details matter because defenders often build controls around credential theft as the central event. These campaigns show why session theft and delegated authorization need equal attention. If a helpdesk, detection rule, or incident workflow only asks whether the password was exposed, it can miss the more useful attacker asset.
What Organizations Should Check#
The FBI recommends restricting or fully blocking device code authentication flows with Conditional Access policies where possible. That is the cleanest control if the business does not need the flow.
Where device code authentication is genuinely required, it should not be left as a broad default. Organizations should audit where it is used, which users and apps need it, and whether those cases can be narrowed. Legacy convenience should not become a standing external access path.
The FBI also recommends blocking authentication transfer policies that allow authentication sessions to move between devices. The source further says impacted organizations should report incidents to the Internet Crime Complaint Center and preserve phishing emails, suspicious login data, and unauthorized device registrations.
Practical checks for defenders:
- Review Conditional Access rules for device code authentication.
- Audit recent device code usage across Microsoft Entra and Microsoft 365.
- Look for suspicious OAuth grants, unfamiliar devices, and unusual app access.
- Check mailbox rules for hidden forwarding, deletion, or folder movement behavior.
- Review sign-ins that look successful but have odd location, device, or client patterns.
- Preserve phishing messages and login artifacts before cleanup.
For user training, the message should be precise. Do not tell users only to avoid fake login pages. In these attacks, the Microsoft page can be real. The warning sign is being asked to enter a device code when they did not initiate a device login themselves.
What Not to Overclaim#
The available source does not say every Microsoft 365 tenant is compromised. It does not say device code authentication is malicious by design. It does not provide a universal exploit count, victim count, or guaranteed indicator set.
The claim is narrower and still serious: Kali365 is packaging device code phishing and session-capture techniques for broader criminal use, and the FBI is warning organizations to reduce exposure.
The larger trend is clear enough. Attackers are moving toward flows where the user completes normal authentication, MFA included, but grants access to the wrong party. That makes identity security less about one login prompt and more about the full chain: authorization flow, token issuance, session movement, device registration, and SaaS access after the fact.
If Microsoft 365 is central to the organization, this is worth checking now. Not because Kali365 is the only tool in the field, but because the pattern is reusable.