Kali365 is the latest reminder that Microsoft 365 phishing has moved beyond fake login pages and stolen passwords. According to the FBI, Kali365 is a phishing-as-a-service platform first seen in April 2026 and distributed mainly through Telegram. Its purpose is direct: help attackers obtain Microsoft 365 OAuth access and refresh tokens, bypass common MFA controls, and gain access to Outlook, Teams, OneDrive, and related cloud services without needing to intercept the victim’s password.
That distinction matters. Many organizations still treat phishing as a credential-theft problem. The assumed attack pattern is familiar: a user receives a malicious email, visits a fake login page, enters a username and password, and maybe approves an MFA prompt. Security teams then respond by resetting the password, checking mailbox rules, and retraining the user.
Kali365 points to a different model. The attacker may never need the password at all. Instead, the victim is tricked into authorizing a sign-in flow that produces valid tokens for the attacker. Once those tokens are issued, the attacker can use them to access Microsoft 365 resources as the victim. From the defender’s perspective, the activity may look less like malware execution and more like a legitimate cloud session from an identity that already passed authentication.
That is why this class of attack is better viewed as identity takeover, not simple phishing.
How Kali365 Changes the Attack Surface
The FBI describes Kali365 as a platform that gives threat actors access to AI-generated phishing lures, campaign templates, tracking dashboards, and OAuth token capture capability. The phishing-as-a-service model matters as much as the technical method. It reduces the skill required to run campaigns against Microsoft 365 users, packaging cloud identity abuse into a subscription-style criminal service.
The attack chain described by the FBI relies on Microsoft’s device code flow. Device code authentication is a legitimate OAuth flow used in cases where a device has limited input capability. A user may be asked to visit a Microsoft verification page on another device, enter a short code, and approve access. In legitimate scenarios, this can support sign-in for devices or tools that cannot easily present a full browser-based login process.
Kali365 turns that pattern into a social engineering path. The attacker sends a phishing message that impersonates a cloud productivity, document-sharing, or collaboration service. The message includes a device code and tells the user to visit a real Microsoft verification page. The user is not sent to a fake Microsoft domain. They are sent to Microsoft infrastructure, which makes the interaction feel more credible than a classic phishing site.
The victim enters the code, completes the prompts, and unknowingly authorizes the attacker-controlled device or session. At that point, the attacker can obtain OAuth access and refresh tokens. The access token grants access to a protected resource for a limited period. The refresh token can be used to request new access tokens, extending access until the token expires, is revoked, or is blocked by policy.
The result is a phishing attack that sidesteps many familiar warning signs. The user may not type a password into a fake page. The domain may be legitimate. MFA may be completed. The attacker does not need to guess, spray, or reuse the password. The compromise happens through authorization.
Why MFA Alone Does Not Solve This
MFA remains one of the strongest baseline controls against password theft, password spraying, and credential stuffing. It still blocks a large portion of low-effort account compromise. The issue is that many MFA deployments were built to defend against stolen credentials, not stolen sessions or maliciously authorized OAuth flows.
In a token-based phishing attack, the attacker is not always trying to defeat MFA cryptographically. The attacker is trying to place themselves into an authentication or authorization process that the user completes. Once the user approves the flow, the attacker receives artifacts that represent authenticated access.
This is the same strategic weakness that made adversary-in-the-middle phishing so damaging. In AiTM phishing, the attacker proxies the sign-in session between the user and the legitimate service. The user completes authentication, and the attacker captures the session cookie or token that proves the session is already authenticated. Microsoft has documented this pattern in earlier Microsoft 365 campaigns where attackers used stolen session material to access mailboxes and then launch business email compromise activity.
Kali365 follows the same broader trend, but with emphasis on device code abuse and OAuth token capture. The core lesson is that MFA must be paired with controls that account for token issuance, token use, device state, authentication flow, session risk, and phishing-resistant methods.
Push notifications, SMS codes, voice calls, and one-time passwords can still leave room for social engineering. Phishing-resistant authentication, such as FIDO2 security keys, certificate-based authentication, and platform-bound passwordless methods, raises the bar by tying authentication to the legitimate origin and reducing the ability to replay or proxy the process.
Why Microsoft 365 Is Such a High-Value Target
Microsoft 365 accounts are attractive targets because they are rarely isolated accounts. A single compromised identity can expose email, files, chats, calendar data, internal contacts, SharePoint sites, Teams conversations, third-party app access, and password reset messages. For many organizations, Microsoft 365 is also connected to SSO, SaaS applications, device management, compliance workflows, and executive communications.
Once an attacker takes over a Microsoft 365 identity, the account can become both a data source and a launch point. Outlook can be searched for invoices, wire instructions, contracts, password reset links, VPN instructions, HR documents, client communications, and internal escalation paths. OneDrive and SharePoint may contain proposals, exports, spreadsheets, engineering documents, legal records, or regulated data. Teams can give the attacker context, relationships, and a trusted channel for follow-on phishing.
That trusted channel is the real force multiplier. A phishing email from an external sender is one problem. A phishing message from a real employee mailbox is far harder for users to dismiss. Internal compromise lets attackers inherit reputation. They can reply to existing threads, use real signatures, reference active projects, and send malicious links to coworkers, customers, vendors, or finance teams.
This is where phishing turns into identity takeover. The attacker is no longer pretending to be the user from the outside. They are operating through the user’s actual account.
The Attack Chain in Practice
A Kali365-style campaign may begin with a message framed around a shared document, compliance notice, Teams invite, voicemail alert, HR workflow, payment file, or internal review. The lure does not need to include malware. It needs to convince the recipient to complete a Microsoft sign-in or device verification action.
The victim is instructed to enter a device code at a Microsoft verification page. The legitimacy of the Microsoft page lowers suspicion. The user may see familiar tenant branding, normal Microsoft prompts, or expected MFA prompts. To the user, the sequence can appear to be a normal Microsoft 365 authentication step.
Behind the scenes, the attacker is waiting for the authorization to complete. Once it does, OAuth tokens are issued. Depending on the token, application permissions, user privileges, Conditional Access state, and session controls, the attacker may gain access to Exchange Online, Teams, OneDrive, SharePoint, or other Microsoft 365 resources.
From there, common post-compromise actions may include mailbox reconnaissance, inbox rule creation, message forwarding, OAuth app abuse, internal phishing, file download, Teams impersonation, persistence through refresh tokens, and attempts to access sensitive SaaS applications tied to the same identity provider.
The attacker may also use the mailbox to study the organization before acting. They can search for terms like “invoice,” “wire,” “ACH,” “payroll,” “password,” “VPN,” “MFA,” “Duo,” “Okta,” “SharePoint,” “contract,” “legal,” or “W-9.” They can identify who approves payments, who manages vendors, who owns IT workflows, and who communicates with clients. That reconnaissance can feed business email compromise, data theft, extortion, or deeper intrusion attempts.
Detection Challenges
Kali365-style activity can be difficult to detect with controls that focus only on links, attachments, or malware. The most meaningful signals often appear in identity, SaaS, and mailbox telemetry.
Security teams should pay close attention to Microsoft Entra sign-in logs, authentication protocol details, device code flow usage, unfamiliar clients, impossible travel, anomalous IP addresses, new user agents, first-seen applications, risky sign-ins, and changes in session behavior. A device code flow event for a user who never uses device-based sign-in should be treated as high-signal, especially when followed by Exchange, Teams, SharePoint, or OneDrive access from unfamiliar infrastructure.
Mailbox telemetry is just as valuable. Watch for inbox rule creation, suspicious forwarding, mass message access, unusual search behavior, deletion of security alerts, new mail transport patterns, and outbound phishing from a previously normal user. In many Microsoft 365 incidents, the first clear evidence of compromise is not the initial phish. It is the mailbox behavior after access has been gained.
OAuth and application activity also matter. Teams should review new app consents, unusual delegated permissions, token use from unmanaged devices, suspicious consent grants, and access patterns that do not match the user’s normal work behavior. Identity takeover often becomes durable through permissions, sessions, and trusted cloud workflows rather than through malware persistence on an endpoint.
A practical detection strategy should correlate events across Microsoft Entra ID, Exchange Online, Defender for Office 365, Defender for Cloud Apps, endpoint telemetry, and SIEM data. A single sign-in event may not prove compromise. A device code flow event followed by mailbox search activity, inbox rule creation, and SharePoint downloads from a new ASN is a much stronger case.
Controls That Matter
The FBI’s guidance centers on limiting device code flow abuse. Organizations should audit legitimate device code flow usage, then use Conditional Access to block or restrict it. For most users, device code flow is unnecessary. Where it is needed, exceptions should be narrow, documented, and monitored.
Microsoft Entra Conditional Access can be used to block authentication flows such as device code flow. This should be tested in report-only mode first, then moved into enforcement after legitimate business dependencies are identified. Emergency access accounts need careful handling so organizations do not lock themselves out during policy rollout.
Authentication transfer policies also deserve review. Microsoft provides controls to block authentication transfer, which can reduce abuse of flows where a user transfers authentication from one device context to another. This is relevant to the same broader problem: attackers manipulating legitimate authentication features to obtain valid access.
Phishing-resistant MFA should be prioritized for administrators, finance users, executives, help desk staff, HR staff, and users with access to sensitive data or broad SaaS privileges. Regular MFA is still useful, but high-risk roles need authentication methods that resist token replay and real-time social engineering. FIDO2 security keys and certificate-based authentication are stronger options than push approval or one-time passcodes.
Session controls should also be tightened. Sign-in frequency, persistent browser session restrictions, compliant-device requirements, device state checks, risk-based Conditional Access, and app-enforced restrictions can reduce the useful life of stolen tokens. These controls must be balanced against operational impact, but leaving long-lived sessions broadly available creates an opening for token theft campaigns.
For incident response, password reset alone is insufficient. If OAuth or refresh tokens may have been stolen, responders should revoke sessions, invalidate refresh tokens, review app consents, remove malicious inbox rules, disable forwarding, inspect mailbox audit logs, review recent file access, check Teams activity, and search for follow-on phishing sent from the account. The account should be treated as an active cloud compromise, not a simple password event.
What SOC Teams Should Hunt For
SOC teams should build detections around abnormal device code flow usage. Start with a baseline of accounts and resource accounts that legitimately use device code authentication. Any new usage outside that baseline should be reviewed. High-value users should generate higher-severity alerts.
Look for Microsoft 365 sign-ins where the authentication protocol or flow indicates device code use, followed by access to Exchange Online, SharePoint, OneDrive, or Teams from a new location, new ASN, unmanaged device, or unfamiliar client. Look for a user completing a device code flow shortly after receiving an external email containing Microsoft verification instructions or document-sharing language.
Mailbox hunting should include new inbox rules that move, delete, mark read, or forward messages. Rules targeting words like “invoice,” “payment,” “wire,” “MFA,” “security,” “alert,” or “password” are especially suspicious. External forwarding and hidden forwarding deserve high priority.
Teams hunting should include unusual direct messages from compromised users, new links sent to many recipients, and messages referencing document access, urgent review, or code entry. Internal phishing over Teams can spread quickly, and users may trust it more than email.
File access hunting should include mass downloads, access to sensitive SharePoint paths, downloads from new IP ranges, and access to files unrelated to the user’s role. Identity takeover often includes quiet collection before the attacker sends the next lure.
OAuth hunting should include new delegated permissions, unusual app consent, unknown client IDs, and tokens issued to applications that do not align with normal user activity. Attackers may use OAuth access to avoid older indicators such as mailbox login through a browser.
What Executives Need to Understand
Kali365 is not just another phishing kit. It reflects a larger shift in how attackers target cloud-first organizations. The user account has become the control plane. If an attacker can control an identity, they may not need malware, lateral movement, or exploit chains to cause damage. They can access data, impersonate trusted employees, manipulate financial workflows, and compromise more users from inside the tenant.
That changes how organizations should measure phishing risk. Click rates and training completion are not enough. Leaders should ask whether the organization can block risky authentication flows, enforce phishing-resistant MFA for high-risk users, detect token misuse, revoke sessions during an incident, and correlate identity activity with mailbox and SaaS behavior.
Microsoft 365 security cannot be treated as an email-filtering problem alone. The defensive model has to include identity governance, Conditional Access, token lifecycle management, app consent control, mailbox auditing, SaaS monitoring, and tested response playbooks.
The Bottom Line
Kali365 shows where Microsoft 365 phishing is headed. Attackers are moving from credential theft to session and token abuse, using legitimate Microsoft authentication flows and phishing-as-a-service tooling to gain access that looks valid at first glance.
The right response is not to abandon MFA. It is to mature beyond basic MFA. Organizations need phishing-resistant authentication, restricted device code flow, stronger Conditional Access policies, tighter session controls, OAuth visibility, and SOC detections built around identity behavior after authentication.
The central question is no longer whether a user entered a password into a fake page. The better question is whether an attacker obtained a valid way to act as that user inside Microsoft 365. Kali365 makes that risk clear, and it should push security teams to treat cloud identity as one of the primary attack surfaces in the enterprise.
How Can Netizen Help?
Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally.
Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.
Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.
Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.
