Kali365 offers many tactics, including adversary-in-the-middle (AiTM) phishing to proxy the entire login and MFA flow. The victim sees a pixel-perfect Microsoft 365 sign-in page, completes their second factor, and believes they’ve safely stepped into their tenant. Behind the scenes, Kali365 has quietly captured their session and “slipped in” with them.
The first article focused on this shift: from traditional credential theft to turnkey session hijacking-as-a-service. I walked through how Kali365 packages AiTM into a Phishing-as-a-Service platform tuned specifically for Microsoft 365 tenants, and why this should keep MSPs awake at night. It lowers the bar for high-quality M365 phishing, scales tenant-aware campaigns, and directly targets the trust relationship between MSPs and their customers.
This post picks up from the moment the attacker has already slipped in behind your user and is now operating inside the tenant.
At the time of writing, Kali365 is fully operational and actively used by attackers in live Microsoft 365 environments.
No Slack account needed.
From Logged In to Owned
For this research, I simulated the full Kali365 flow from the defender’s side. I deliberately behaved as the end user who clicked the link, completed the sign-in, and went back to work, then tracked what happened in the tenant over the following hours and days. Every post-compromise action described here is based on real observations from controlled simulations, and some of the behaviors were captured in this specific run. In contrast, others were reproduced in separate simulations of similar AiTM and Kali365 operations.
The fake login page is only the setup. The real operation starts once Kali365 is inside the tenant with a valid identity.
The first step is Token Theft. The refresh tokens are fed into companion desktop tools that generate new, valid browser sessions on demand. No passwords, no extra prompts, no user interaction. From the tenant’s perspective, it is the same user returning to work. In practice, it is remote control of that identity.
By the time the operator holds stolen OAuth refresh tokens, the noisy part is over. The victim saw a normal Microsoft 365 sign-in, passed MFA, and the telemetry shows a clean session. Controls approved the activity. Kali365 uses that approval as the starting point.
After that comes Self-Service Password Reset Abuse. With the account already under control, the attacker triggers a self-password reset flow while they still hold valid sessions and tokens. The password is changed successfully, but existing long-lived refresh tokens and active sessions continue to work. For almost a full day, the operator keeps using the tenant “as the user,” even though the credentials have technically changed.
Only later, when controls finally catch up and the account is locked, do the new sign-ins start to fail. By that time, post-compromise actions have already been completed.
Next is New Device Registration. Using those live sessions, Kali365 registers a new device inside the tenant. That device is now listed as a managed, compliant endpoint. Future logins from it are treated as more trusted, not less. The environment effectively incorporates the attacker’s hardware into the fleet.
From the defender’s side, this is a blind spot. The registration originates from the attacker’s own machine, but it rides atop a valid identity and a legitimate token. In the logs it looks like a normal user enrolling another corporate device, while in reality the tenant has just granted long-term, policy-backed trust to a system it does not own or control.
Then come Malicious Inbox Rules. Hidden rules are created to delete, hide, or reroute emails containing strings such as “security warning”, “phishing”, “suspicious sign-in”, or “unauthorized login”. Security alerts, password reset notifications, and device registration emails are removed from the user’s normal view.
On top of that, the platform runs Internal Discovery. Using the same compromised identity and tokens, it systematically walks through mailboxes, Teams spaces, SharePoint sites, and OneDrive folders to map who talks to whom, where critical data lives, which services are in use, and which identities and groups are worth targeting next. Kali365 enumerates the full corporate contact list to map internal roles, management chains, finance approvers, suppliers, and customers. The address book becomes a targeting dataset for BEC.
Kali365 then uses BEC inside the tenant. Built-in writing is pointed at the victim’s sent items to learn their style. The tools generate BEC messages that match the victim’s tone, structure, and wording. To recipients, these messages appear to be normal requests from a known contact.
Kali365 is not standing still. It is evolving and arming itself with AI for vast operations inside the kit.
In the background, the platform looks for opportunities for Admin Abuse. It scans for administrative roles and privileged accounts it can reach from the compromised identity. Where possible, it resets passwords, disables selected users, creates new privileged accounts, deploys rogue app registrations, and relaxes conditional access or MFA coverage.
There are additional post-compromise operations available in Kali365, but the actions described here are the most common and most useful. They represent the core attack playbook observed across my simulations, including the minimum viable set of steps needed to turn a single successful click into persistent, high‑impact control over the tenant.
Closing This Round
Kali365 is not just another phishing kit. It is a post-compromise framework that treats Microsoft 365 as an identity platform to be owned, not a login page to be bypassed.
In the simulations I ran, one user click was enough to unlock a full sequence of actions with token theft and reuse, new device registration, inbox and contact abuse, internal discovery, and, in some cases, admin-level changes that reshaped the tenant itself. Some of these behaviors appeared in a cycle, and others surfaced across additional controlled simulations of similar AiTM flows, but the pattern is consistent.
From a defender’s point of view, this is the lesson. The story does not end when the user completes MFA or when the phishing URL is taken down. The real risk lives in what happens with that identity in the hours and days after the click.
If your detection and response focus only on blocking the initial lure, you will miss the quiet, token-driven work that turns “logged in” into “owned.” The next post will focus on that gap: practical ways to hunt for these post-compromise behaviors in Microsoft 365 and how to build detections that assume the attacker is already inside the tenant, working with the same tools and interfaces your users rely on every day.
What Comes Next
This post focused on what happens after the click, from the moment Kali365 turns a clean Microsoft 365 sign-in into practical, repeatable control over an identity and a tenant.
The next blog posts will go deeper in two directions. First, I will walk through the attacker mindset and infrastructure behind Kali365 operations, including how campaigns are prepared, how infrastructure is built and maintained, and how operators think about scale, risk, and return when targeting MSP and Microsoft 365 environments.
After that, the fourth post in the series will flip fully to the defender’s side and focus on mitigation and detection. It will cover concrete controls, hunting ideas, and telemetry you can use to spot these post-compromise behaviors in time, and how to harden your tenants so that one click does not automatically translate into long-term ownership.
Useful Links
