Tycoon Nation: How Commoditised AiTM Kits Are Owning Microsoft 365

6 days ago
6 min read

Unlike Google-targeted attacks, the Microsoft 365 PhaaS ecosystem is well-documented, heavily researched — and quietly industrialised. Here's the full picture from kit purchase to BEC payout.

Business email compromise used to require skill. Attackers needed to understand Exchange internals, craft convincing social engineering at scale, and know how to quietly live inside a compromised tenant without triggering alerts. That skillset still exists — but it's no longer required. Today you can rent it for $120.

The Microsoft 365 PhaaS ecosystem is, frankly, mature. While Google-targeting kits are underreported and likely circulating in the same underground markets, the M365 side has been thoroughly catalogued by threat researchers at Sekoia, Proofpoint, Barracuda, Sygnia, Invictus IR, and Microsoft's own Defender team. What has emerged is a portrait of an industrialised attack supply chain that makes sophisticated

MFA bypass accessible to any moderately motivated criminal with a Telegram account and a few hundred dollars in Bitcoin.

This article documents how these kits work, what attackers do once inside, and — critically — what forensic artefacts they leave behind, because the most repeatable attacks leave the most repeatable evidence.

The Kit: Tycoon 2FA

Tycoon 2FA is the dominant player. First observed in August 2023 by Sekoia researchers, it emerged as an evolution of an earlier kit called Dadsec OTT — the Tycoon developer likely forked that codebase and extended it with AiTM-specific capabilities. It is sold via Telegram through a channel called the "Saad Tycoon Group", advertising ready-to-use Microsoft 365 and Gmail phishing pages, attachment templates, and access to an administration panel that lets customers monitor ongoing campaigns in real time.

Pricing starts at $120 for a 10-day window, scaling upward depending on the top-level domain and kit features selected — typically maxing around $320. Payment is via Bitcoin. By mid-2024, the operator's wallet had logged more than 1,800 transactions, with cumulative revenues estimated at over $394,000. This is not a hobby project. It is a running business with active product development: a major updated version was released in March 2024 with enhanced obfuscation and anti-detection capabilities, followed by another significant update in November 2024 specifically designed to defeat security tooling inspection.

How the Attack Works: The Kill Chain

The attack is an Adversary-in-the-Middle operation. Unlike traditional phishing that captures static credentials and codes, an AiTM kit inserts a reverse proxy between the victim and Microsoft's real authentication infrastructure. The victim's browser is talking to a pixel-perfect Microsoft login page — which is, technically, real, because all traffic is being relayed through the proxy. MFA is not broken; it is completed legitimately by the victim, and the authenticated session cookie produced by that successful MFA challenge is captured by the proxy in real time.

The Inbox Rule: The Most Important Forensic Artefact

If there is one finding that IR practitioners should prioritise in any M365 compromise, it is the inbox rule created immediately after session takeover. This is documented extensively across independent IR firms' caseloads — Invictus IR, Sygnia, Microsoft Defender researchers, and Huntress have all highlighted it — and it is operationally deliberate.

The attacker's goal with these rules is simple: the victim must not know the account is compromised. A rule that deletes all incoming email, or silently moves security alert messages to a folder the victim never opens, can buy days of undetected access. In the Microsoft-documented energy sector campaign, the attacker's rule was specific: delete all incoming emails and mark all messages as read, eliminating visual cues of new activity.

The hidden rule problem is particularly insidious. Attackers have learned that rules created through MAPI manipulation — rather than the standard Outlook or OWA interface — do not appear in the Exchange admin center's rules list. Standard client-side auditing misses them entirely. MFCMAPI or PowerShell with the -IncludeHidden flag is required to surface them, a fact that many incident responders do not encounter until they're deep into a case wondering why a mailbox appears clean despite clear signs of compromise.

Why MFA Didn't Stop It — And What Would

The most common client reaction to these incidents is disbelief. MFA was enabled. The user completed the challenge. How is there a compromise? The answer is that AiTM attacks do not attack MFA — they work around it by stealing the output of a successful MFA session (the cookie) rather than trying to intercept or defeat the MFA mechanism itself.

Once a session cookie is obtained, it represents an authenticated, trusted browser session. Microsoft's infrastructure sees it as a legitimate continuation of a session that was properly MFA-verified. Changing the password after the fact does not help: the cookie was issued before the password change, and Microsoft's session management does not automatically invalidate cookies when passwords are reset unless administrators explicitly revoke all active sessions.

"Password resets alone are insufficient — impacted organizations must ensure that they have revoked active session cookies and removed attacker-created inbox rules." — Microsoft Defender Security Research Team, January 2026

The only authentication mechanisms technically resistant to AiTM attacks are FIDO2 hardware security keys and passkeys. Both bind the authentication response cryptographically to the legitimate origin domain using the WebAuthn standard. A proxy server relaying traffic from a phishing domain cannot forge this binding — the cryptographic assertion will fail if the origin doesn't match. TOTP codes, SMS OTPs, and Authenticator push notifications are all susceptible, because they produce portable, origin-agnostic proofs that a proxy can relay unchanged.

The Anti-Analysis Arms Race

What makes Tycoon 2FA and its competitors genuinely sophisticated is not the AiTM technique itself — that has been publicly documented and implementable via open-source tools like Evilginx for years. It is the anti-analysis layer that now ships as a standard product feature.

The March 2024 update introduced heavily obfuscated JavaScript with dynamic code generation that alters its structure on each execution, defeating signature-based detection. The November 2024 update specifically targeted the tooling security researchers use to analyse phishing pages — blocking developer tool shortcuts, detecting debugger attachment, preventing element inspection, and redirecting to legitimate decoy sites when automated analysis is detected.

Backend validation ensures phishing payloads only execute if a specific server response value is returned, meaning URL scanners that don't fully emulate the authentication flow receive only a clean redirect.

The Multi-Org Cascade: When One Compromise Becomes Ten

One of the more alarming real-world patterns, documented by both Sygnia and Microsoft's Defender team, is the cascading multi-organisation spread that can result from a single AiTM compromise. The attacker, once inside a victim account, harvests the victim's recent email contacts and threads. Phishing emails sent from the compromised account to those contacts arrive from a trusted domain with legitimate email authentication. Each recipient who clicks and completes MFA yields another compromised session. Each of those victims' contacts becomes the next target pool.

In the energy sector campaign documented by Microsoft in January 2026, a single initial compromise spawned a chain of AiTM attacks across multiple distinct organisations. The attack was specifically designed to abuse SharePoint file-sharing links — because a link to a shared file in SharePoint looks inherently legitimate, even to security-aware users. The phishing campaign from just one compromised user sent over 600 emails targeting contacts both inside and outside the victim's organisation.

What to Look For: IR Triage Checklist

For practitioners responding to a suspected M365 AiTM compromise, the following artifacts are the highest-priority items in the Unified Audit Log and Entra ID sign-in logs.

Confirm the UAL is enabled first — query Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIsEnabled — because without it, forensic reconstruction is severely limited.

Sign-in logs should be examined for the originating IP and ASN of the first post-compromise session: expect a VPS provider, often in a jurisdiction inconsistent with the victim's normal login pattern. The timestamp delta between the phishing email being clicked, the MFA completion, and the attacker's VPS login is often under five minutes in automated kit operations. UAL operations to search include New-InboxRule, Set-Mailbox, UpdateInboxRules, and MailItemsAccessed — the last being critical for understanding what the attacker read before the compromise was detected.

Remediation must include explicit session revocation — not just a password reset. All active refresh tokens for the compromised account must be revoked via Entra ID (formerly Azure AD), and all inbox rules should be audited and removed, including those hidden from standard views. MFA method changes made by the attacker during the compromise window should also be reviewed and rolled back.

Bottom Line

Microsoft 365 AiTM attacks via PhaaS toolkits are no longer an emerging threat — they are the dominant mode of MFA bypass against enterprise Microsoft environments. Tycoon 2FA alone has been tied to over 64,000 documented incidents, operates across more than 1,100 domains, and generated nearly $400,000 in revenue before many organisations had updated their defensive playbooks to account for session-cookie theft as distinct from credential theft.

The key shift in posture required is treating post-authentication session management as a security control in its own right. FIDO2 mandates for high-value accounts eliminate the AiTM vector entirely. Conditional access policies that continuously evaluate session legitimacy — not just at login — reduce attacker dwell time when cookies are stolen. And inbox rule monitoring in the UAL, correlated with anomalous sign-in events, gives defenders the best forensic hook into detecting kit-based operations, because the most automated attacks are also the most consistent.