Introducing Matrix: A Microsoft 365 AiTM Platform Overlapping the Sneaky2FA Lineage

Matrix is a Microsoft 365 credential-phishing operator panel and adversary-in-the-middle (AiTM) harvester that Abnormal observed in late July 2026. Although the “Matrix | Portal” name has not appeared in prior public reporting, its underlying code contains substantial overlap with phishing kits that Abnormal threat researchers previously captured and analyzed.

The strongest evidence consists of five identical files and an operator-panel script with substantial line-for-line overlap. Together, these artifacts provide strong evidence of a shared build and support placing Matrix within the same lineage. They do not, however, establish a shared operator or confirm that Matrix is an existing product under a new name.

Matrix appears to be one branded deployment within this broader ecosystem, and the cluster is full of others. To demonstrate how such a rented kit operates, we traced one deployment’s infrastructure and functionality from initial delivery through the operator panel.

The Kill Chain, Stage by Stage

The campaign combines authenticated delivery from a compromised account, nested-attachment link concealment, legitimate redirect services, behavioral cloaking, and a live Microsoft 365 AiTM relay.

Stage 1. Delivery: The Malicious Link Hides Inside a Nested Attachment

The lure is unremarkable: a routine-looking OneDrive notification prompting the recipient to open a shared document. It’s the kind of automated alert that rarely earns a second look. What makes it dangerous is how it reaches the inbox.

The email authenticates cleanly because it is sent from a real, compromised Microsoft 365 mailbox at an unrelated third party. As a result, SPF and DKIM pass, and it’s delivered. The operator URL appears inside a nested message/rfc822 attachment rather than the message body. That single design choice is the campaign's most important defensive gap.

Because the malicious link never appears in the fields a mail gateway or URL scanner reads, link-based inspection and link-based hunting are blind to it. The payload becomes malicious only after the recipient clicks and signs in, leaving nothing in the message that is anomalous within an authentication-and-reputation model.

Inside that notification, the displayed sender is spoofed as one1drvs[.]com—a digit-1 typosquat of onedrive[.]com that never resolves and exists only to dress the decoy. This is not the address that delivered the mail; it is the from-line displayed inside the fake OneDrive notice. Clicking begins the laundering chain.

Stage 2. Redirection: Legitimate Services Launder the Click Before a Cloak Screens It

The Open Document link passes through two abused-but-legitimate SaaS services—a QuestionStar survey link and then a Zoho Insights click-tracker—before reaching an operator-controlled free-DNS zone fronted by Cloudflare.

A cloaking interstitial (index.php) runs a session-counter state machine. Automated fetches and scanners receive a hidden decoy and a page reload, or a fail-open redirect to a Wikipedia article. A real interactive browser, by contrast, receives the obfuscated redirector to the harvester. In the captured instance, the recipient’s email is included in the URL fragment (location.hash); therefore, it never reaches a server or gateway log.

The harvester is a pixel-accurate Microsoft 365/Entra sign-in, served by the same PHP application. It borrows its credibility straight from Microsoft, using Fluent UI and hotlinking genuine Microsoft CDN assets, allowing it to reproduce the legitimate sign-in experience. Other elements are designed to evade inspection rather than deceive the target. For example, the page title reads "Microsoft 365 Secure Sign-In," but the string is padded with 84 zero-width characters to defeat string matching.

The page collects the username, then the password, and then adapts to whichever multi-factor method the target actually uses.

Stage 3. Harvest: A Live AiTM Relay Defeats the Target's MFA

This is not a store-and-forward credential form. Six independent indicators in the deobfuscated client code show that the backend maintains a live authenticated session with the real Microsoft sign-in service while the target proceeds.

After the password step, the server returns an array of the target’s registered MFA methods (i.e., push number-matching, Authenticator OTP, or SMS), and the page adaptively reveals only the options available to that account. It displays the live Authenticator number-match digits and fetches the target organization's real Entra logo and background, allowing the fake page to reflect the organization’s own branding.

All of that is only possible if the backend communicates with Microsoft in real time as the target types.

What the Matrix Platform Can Do

The entire platform is a single server-rendered PHP application (PHP 8.4.23 on Plesk/Apache, Cloudflare-fronted). One codebase serves every hop from the cloak onward, and there is no REST or JSON API. All 30 probed /api/* variants matched the nonsense controls; the surface below shows the full contract. It reduces to two POST endpoints reached by extensionless rewrite—one target-facing and one operator-facing—plus the static assets and cloak routes that support them.

Operator Console Capabilities

The operator console, branded "Matrix | Portal," sits at /<kitdir>/admin/login. In this instance, the served page is password-only, but the shipped panel code includes an operator-side one-time code gate and a per-affiliate reference code pairing widget.

Neither appears in this deployment—the handlers are length-guarded against elements absent from the served DOM. We therefore report them as latent capabilities rather than active ones. These latent features are consistent with a multi-tenant service in which affiliates connect to a shared backend.

Mapping the API Surface

Every route below was probed first-party. "Observed" means the response was captured; "Inferred" means the behavior is read from the shipped code because exercising it would have required submitting data to the operator.

Harvester Capabilities and Evasion

Client-code analysis shows the harvester is broader and better concealed than the single Microsoft page rendered on this capture suggests. A response-type field routes separate Microsoft, Okta, and GoDaddy account branches, though only the Microsoft branch was exercised here. Additionally, a 14-locale string table, paired with a "Stay signed in" emulation, enables the page to localize for each visitor.

The harvester is also built to resist analysis. Its favicon is an inline data URI, preventing external favicon requests and leaving favicon-hash pivots such as urlscan, Shodan, and FOFA with nothing to match. The 181 KB script is hardened with Obfuscator.io, which applies string-array rotation, self-defending code, a constructor('debu'+'gger') trap, and console-method hijacking.

The Sneaky2FA Overlap: Five Identical Files, and an Honest Gap

We compared Matrix artifact by artifact with two Kratos deployments that Abnormal captured directly and independently hashed. This allowed us to evaluate the underlying files rather than rely on hashes reported by another vendor.

Five images served by the Matrix operator panel are identical to files from a Kratos deployment Abnormal captured in July.  Its panel login script also shares 37 of approximately 82 lines verbatim with a Kratos panel we captured in June, including the same login endpoint, 60-second send-code cooldown, and redirect to ../admin/index.

Together, these artifacts place Matrix within the Sneaky2FA lineage, a phishing-as-a-service kit reportedly used by thousands of subscribers, each of whom brands and hosts their own instance. However, they do not establish that Matrix is simply an existing product under a new name. They also do not reveal whether it belongs to the branch publicly known as Kratos or another closely related variant.

The comparison below presents the evidence in descending order of strength. Entries derived from public reporting are identified accordingly; the strongest matches are based on artifacts that Abnormal captured directly on both sides.

Dimension-by-Dimension Comparison

The evidence supports a shared lineage, but its attribution value has clear limits. First, the shared artifacts do not identify the operator because the same builder files may be distributed to multiple subscribers.

Second, they cannot be used to determine to which branch of the lineage Matrix belongs. Abnormal’s Kratos capture is identical across every shared operator asset except one, and Matrix does not serve the file that distinguishes them.

Third, the artifacts do not directly connect this deployment to the infrastructure disrupted by law enforcement in July 2026. The evidence places Matrix within the broader lineage, but whether it is a reskin of the disrupted platform remains unknown.

The Franchise: One Builder, Many Brands

The overlap extends well beyond this deployment. The kit stylesheet (page/styles/app.css) and operator image set recur across a cluster of phishing hosts spanning multiple providers, dates, and brand names, including “Matrix | Portal.” We also identified the same 13-character kit directory on eight hosts across five free-DNS providers between May 21 and July 14, 2026.

This pattern is consistent with a franchise model in which a single builder distributes the kit as a service and individual subscribers brand and host their own instances. Public reporting indicates that the Sneaky2FA-lineage service operated through approximately 1,800 “franchisees,” who ran roughly 15,000 campaigns per month before German and US law enforcement disrupted its central infrastructure in July 2026.,

Matrix appears to be one such branded deployment, with “Thanatos” representing another. The shared files point to a common builder, not a common operator. The reused kit directory is a narrower exception: its recurrence across multiple hosts links those deployments to the same build and likely the same subscriber.

Broad, Indiscriminate Targeting from Hijacked Mailboxes

From early analysis, the lures arrive from compromised accounts at legitimate organizations: genuine third-party Microsoft 365 mailboxes whose owners are victims, not the adversary. Because the sending account changes across deployments, the specific mailbox carries no durable attribution value and is best read as access the operator happened to hold rather than a signature of who is behind the campaign.

The targeting is broad and opportunistic rather than concentrated in one sector. Observed recipients span retail, professional services, technology, and finance, ranging from senior executives and general managers to project managers and generic role mailboxes. This distribution is consistent with automated blasts to recipient lists scraped from compromised mailboxes rather than a curated campaign against a single industry.

What to Do: Contain the Session and Hunt the Kit

The technical picture points to two priorities for defenders: contain the live, MFA-satisfied session and identify the reusable kit components that persist beyond any single domain.

• Revoke sessions, not just passwords. For any user who reached the harvester, revoke Entra refresh tokens and active sessions and re-enroll MFA. The stolen artifact is a live, MFA-satisfied session that a password reset does not invalidate.

• Treat nested-attachment document notices as a detection surface. Authenticated mail from a rarely-seen third-party sender carrying a nested message/rfc822 or octet-stream attachment that renders as a OneDrive or document-ready notice should be a first-class signal, because the malicious link never appears in the message body.

• Assume adversary-in-the-middle, and watch the session layer. Alert on an Entra sign-in from a new session shortly after an interactive MFA success from an unusual network, a pattern consistent with session relay.

• Hunt the kit, not this week's domain. Pivot on durable file hashes and the backend endpoints called by the panel. Free-DNS zones and shared hosts rotate quickly, but the underlying build is more stable.

• Preserve the do-not-block list. Keep the abused SaaS redirectors, takeover-victim SaaS apex, and shared Cloudflare edge off block lists to prevent remediation from causing its own outage

A Commodity Platform, Re-Skinned Faster than It Can Be Named

Matrix appears less like an entirely new threat than a familiar platform operating under a new name. Examining it file by file reveals which elements are likely to persist across deployments: a real-time AiTM harvester that adapts to the target’s MFA methods and organizational branding, a delivery technique that conceals the malicious link inside an attachment, and a subscription-based operator panel that affiliates can deploy on disposable free-DNS infrastructure.

The branding and hosting will continue to change, but the underlying build is more durable. File hashes, backend endpoints, and AiTM behavior can persist across reskins and re-hosting, making them more reliable hunting signals than any single domain or panel name. By focusing on those shared characteristics, defenders can identify future deployments before their latest branding is publicly documented.

For additional insight into the attack landscape, visit Abnormal Intelligence, our threat intelligence data and research hub.

Indicators of Compromise (IOCs)

Tier 1 indicators are durable kit fingerprints with the strongest long-term hunting value. Tier 2 represents live operator infrastructure, while Tier 3 consists of perishable or shared indicators that should generally be monitored rather than hard-blocked. Each row includes a recommended action.

Do-Not-Block

The indicators below represent legitimate infrastructure entangled in the attack.

¹ Kratos assessed as an evolution of Sneaky2FA (Sekoia; PCRisk; Trend Micro).

² Operation Olympus Blade: disruption of the Sneaky2FA/Kratos central infrastructure, 2026-07-20 (BleepingComputer; teiss; cyberpress).