Mirage2FA — AiTM Phishing-as-a-Service Targeting Microsoft 365

Mirage2FA is a commercial phishing-as-a-service (PhaaS) platform, branded by researchers as operated by "LinX Coders" / "LinXcoded," that runs adversary-in-the-middle (AiTM) reverse-proxy attacks against Microsoft 365 sign-in flows. The attacker's objective is not password theft alone — it is the authenticated session: the kit relays a victim's username, password, and completed MFA challenge to the real Microsoft login in real time, then captures the resulting session cookie and refresh token, giving the operator a fully authenticated M365 session without ever needing to solve MFA itself. Reporting attributes over 9,000 compromise events and roughly 4,500 targeted US/EU organizations to this single kit as of August 2026, with 63.7% of victims in the United States.

Delivery rides HTML smuggling inside deceptively small (~3 KB) .htm, .xhtml, and .svg email attachments — file types that routinely sail past attachment sandboxes because they contain no executable payload on disk, only obfuscated JavaScript (Base64 + single-byte XOR key 0xAD) that reconstructs the phishing redirect client-side in the browser. The kit also uses already-compromised, authenticated M365 tenants to relay its own phishing email, which lets it inherit the sending tenant's reputation and bypass some mail-flow reputation checks.

The highest-value defensive angle is not catching the phishing email — it is recognizing that ordinary push/OTP MFA does not stop this kit, because the proxy simply relays whatever the user approves. Detection must combine endpoint visibility (mail client handing off to a browser opening a local HTML/SVG/XHTML attachment, followed by DNS/network egress to kit infrastructure) with cloud-side session and OAuth-grant hunting, and hardening must move toward phishing-resistant, token-bound authentication rather than more MFA prompts.

Web Hunter Notes

• No file hashes or JavaScript SHA values were published in any of the three sources — the loader is server-side templated per victim, so static hashes have limited shelf life. IOC coverage below leans on infrastructure (domains/IP) and behavioral fingerprints (XOR key, loader path shape) rather than hashes.
• This is a distinct PhaaS kit from other AiTM packs already in the library (Storm-2755/PayrollPirates targets payroll portals; UNC6671 is vishing-led; DriftToken targets Salesforce OAuth; AzureCLI-ROPC is a password-spray technique, not a proxy kit) — confirmed via check_coverage.py against the domains/IP below with a clean result before this pack was built.
• No indicator in the three cited sources contained any instruction directed at an AI agent or automated tooling; all three were treated as pure threat-intel data.

Hunt Hypotheses

Attack Chain

No file hashes were published for this kit as of the cited sources — the loader is generated per-target server-side. Treat the domain/IP list as perishable (expect churn); prioritize the behavioral signatures for durability.

The identity-plane compromise itself happens outside Falcon's endpoint telemetry. These non-CQL hunts are the primary detection surface for steps 5–8 of the attack chain and should be run against Entra ID / Microsoft 365 logs (Entra sign-in logs, Identity Protection, Unified Audit Log / Purview).

• Risky sign-in / impossible travel: Entra Identity Protection sign-in risk flagged as "unfamiliar sign-in properties" or "anonymous IP" immediately following a sign-in from a known-good location — consistent with session/cookie replay from attacker infrastructure rather than the original device.
• Sign-in without a corresponding MFA challenge shortly after one that had one: a session token reused from a different IP/device without re-prompting for MFA is the signature of AiTM cookie theft, not credential-only compromise.
• New inbox rule creation (New-InboxRule / Set-InboxRule): especially rules that forward, delete, or move mail matching subjects like "invoice," "payment," or "security alert" — classic post-AiTM persistence and fraud staging.
• New OAuth application consent grants: particularly first-party-looking apps requesting Mail.Read, Mail.ReadWrite, or Files.ReadWrite.All scopes shortly after a flagged sign-in.
• Continuous Access Evaluation (CAE) events: token revocation/replay signals if CAE is enabled — a token used from an IP inconsistent with the original sign-in triggers a CAE-driven re-evaluation.
• Defender for Office 365 Safe Attachments/Safe Links verdicts: review whether .svg/.xhtml/.htm attachment types are actually included in the active Safe Attachments policy — many tenants exclude them by default because they aren't classic "document" types.
• Outbound mail volume anomaly from a single mailbox: a spike in outbound mail shortly after a flagged sign-in is consistent with the compromised-tenant-relay ("island hopping") behavior reported for this kit.

Playbook 1 — Block legacy authentication (Entra Conditional Access, PowerShell/Graph)

Prerequisites: Global Administrator or Conditional Access Administrator role; Microsoft Graph PowerShell SDK connected (Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess")
Reboot required: No

# 1. Create (or update) a CA policy blocking legacy auth clients tenant-wide
$params = @{
  DisplayName = "Block Legacy Authentication"
  State = "enabledForReportingButNotEnforced"   # flip to "enabled" after a monitoring period
  Conditions = @{
    ClientAppTypes = @("exchangeActiveSync","other")
    Applications = @{ IncludeApplications = @("All") }
    Users = @{ IncludeUsers = @("All") }
  }
  GrantControls = @{ Operator = "OR"; BuiltInControls = @("block") }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Rollback: Set the policy State to "disabled" via Update-MgIdentityConditionalAccessPolicy, or delete it with Remove-MgIdentityConditionalAccessPolicy. No persistent state change to user accounts is made.

Playbook 2 — Require compliant/hybrid-joined device for M365 access

Prerequisites: Intune device compliance policies already deployed to the target population; Conditional Access Administrator role
Reboot required: No

$params = @{
  DisplayName = "Require Compliant or Hybrid Joined Device - M365"
  State = "enabledForReportingButNotEnforced"
  Conditions = @{
    Applications = @{ IncludeApplications = @("Office365") }
    Users = @{ IncludeUsers = @("All"); ExcludeGroups = @("<break-glass-account-group-id>") }
  }
  GrantControls = @{ Operator = "OR"; BuiltInControls = @("compliantDevice","domainJoinedDevice") }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Rollback: Set State to "disabled" or remove the policy. Always exclude a break-glass account/group before enabling enforcement to avoid tenant lockout.

Playbook 3 — DNS sinkhole for confirmed Mirage2FA domains

Prerequisites: Administrative access to the organization's DNS filtering / secure web gateway platform
Reboot required: No

# Example for a generic RPZ-capable DNS resolver
zone "rpz.mirage2fa" {
  type master;
  file "rpz.mirage2fa.db";
};

; rpz.mirage2fa.db entries
user.cheacker.store        CNAME .
cheacker.store              CNAME .
hvr.volatilesour.store       CNAME .
adp.pslcertlive.site         CNAME .
office.avcbtech.store        CNAME .
pynutech.store                CNAME .

Rollback: Remove the entries from the RPZ zone file and reload the zone. No endpoint-side state is modified; effect is purely resolver-side.

Validation gates (§11) must pass before Q1/Q2 promote to Custom IOA; Q3–Q5 remain scheduled hunts pending environment-specific tuning.