← Back to Blog

Threat Research

Sneaky 2FA Returns: Trusted Sender Abuse, Route Polymorphism, and Microsoft 365 Replay Against Enterprise IT

A compromised trusted SaaS sender delivered a Microsoft security lure to enterprise IT users and routed victims into a session-polymorphic Sneaky/WikiKit kit with identity checks, tenant-branded rendering, signed resource access, credential replay, and MFA collection paths.

By ZeroBEC Team · June 30, 2026 · 14 min read

ZeroBEC prevented a targeted Microsoft 365 phishing campaign that combined compromised sender trust with a Sneaky 2FA-style phishing kit. The message was sent from a compromised third-party SaaS sender account that had previously been trusted by the recipient environment and was aimed at enterprise IT recipients rather than a broad consumer audience.

Executive summary

The phishing infrastructure shows clear evolution of the Sneaky 2FA / WikiKit-style framework. It mutates the session wrapper across visits, including route namespaces, loader names, identity-binding handlers, validation slugs, security tokens, decoy destinations, timestamps, and resource URLs. The core JavaScript modules remain stable, but the loader and session surface change enough to weaken filename, hash-only, and page-title detections.

The kit is not a static Microsoft clone. It performs identity-driven rendering, pre-fills the target identity, supports tenant-branded Microsoft sign-in pages, includes an organization sign-in transition, and exposes password, verification-code, SMS, Authenticator approval, number matching, method-selection, and final redirect paths.

Controlled testing with non-valid credentials produced Microsoft Entra ID sign-in events within minutes. The attempts targeted OfficeHome through a browser client and used a Windows and Edge user agent. This confirms near-real-time credential replay against Microsoft Entra ID.

Campaign correlation: why Sneaky 2FA is a strong match

Sekoia described Sneaky 2FA as an AiTM phishing kit targeting Microsoft 365 accounts and distributed through the Sneaky Log Phishing-as-a-Service ecosystem. Sekoia's original Sneaky 2FA analysis also documented autograb behavior, generated phishing paths, server-side Microsoft authentication handling, and detection opportunities around user-agent shifts.

NJCCIC later highlighted Sneaky Log Phishing-as-a-Service, providing additional public context for Sneaky Log as a phishing service operation. eSentire and Menlo Security also documented Sneaky2FA / Sneaky-style campaigns using CAPTCHA or browser-gating behavior and Microsoft 365 themed pages. Their case notes and defensive funnel analyses provide useful ecosystem context.

The observed asset set, MFA workflow, href[.]li decoy behavior, and Sneaky/WikiKit-style page structure make Sneaky 2FA a strong match for this case. This campaign shows the framework moving beyond a recognizable landing page into an end-to-end phishing system: mutable session wrapper, signed resource access, tenant branding, and replay telemetry that connect the email stage, browser stage, and Entra stage into a single intrusion path.

Initial access: trusted sender abuse against enterprise IT

The email was not sent from a disposable domain. It came from a compromised third-party SaaS sender account that had previously been trusted by the recipient environment. That trusted relationship changed the economics of the attack: the sender looked familiar enough to enter the mail flow, while the message content drove the victim toward a Microsoft account-security action.

The visible lure was a Microsoft "Unusual Sign-in activity" alert. It warned that the account would be temporarily locked unless the recipient reviewed the activity within 24 hours. The fake sign-in details used Canada/Toronto, a Chrome browser, and a lure IP. That IP appears in the message body as social-engineering content and should not be treated as confirmed attacker infrastructure by itself.

Below the Microsoft security lure, the email contained a business-thread chain. That thread camouflage made the message look less like a standalone phish and more like a forwarded operational discussion. This matters because IT and security recipients see many messy internal and vendor-driven threads. The attacker used that reality against them.

Email authentication and delivery context

The delivery chain showed partial legitimacy rather than clean authentication alignment. The message passed through legitimate cloud-sending infrastructure, with SPF and DKIM passing for the cloud sender, while DMARC was not aligned for the visible sender domain. Microsoft headers also showed tenant-side handling that is consistent with a previously trusted sender path, including low friction treatment in the mail flow.

The important point is not that Amazon SES was malicious. It was not. The important point is that sender trust and cloud-sending legitimacy can blind reputation-only decisions when the actual account behind the SaaS sender is compromised.

A chain within the chain: redirect laundering and session setup

The phishing URL did not expose the final kit immediately. The click moved through multiple trusted redirect services, then an intermediate site, and only then reached the final phishing host. Those trusted redirectors should not be treated as standalone blocklist indicators. They are pivots. The malicious signal appears when the chain resolves into the final host, long route namespace, identity-binding route, session-specific loader, and kit assets.

Safe Links wrapper
  → trusted Google redirect services
  → ad click redirect service
  → intermediate site
  → final phishing host
  → long session route namespace
  → base64 identity-binding handler
  → signed resource URL
  → Microsoft-styled phishing page

This layered chain reduces the value of single-point URL inspection. Each hop can look reasonable in isolation. The full path reveals the intent.

Identity check gate before the Microsoft page

Before the Microsoft credential page is exposed, the victim sees a lightweight identity-check page. The page uses normal security-check language such as "One more step," "Almost there," and "Confirm to proceed." The gate normalizes friction, delays exposure of the credential page, and filters automated scanners that do not complete the browser flow.

Tenant and federation-aware rendering

The kit is not a single static Microsoft clone. During controlled testing with a synthetic address from a large branded Microsoft 365 tenant, the page rendered a tenant-branded Microsoft-style sign-in screen and loaded the tenant illustration from Microsoft AAD CDN infrastructure. That behavior shows identity-driven tenant discovery or tenant branding retrieval before the password step.

The observed branding path followed this pattern:

hxxps://aadcdn[.]msauthimages[.]net/.../logintenantbranding/0/illustration?ts=<timestamp>

The HTML snapshots also include an organization sign-in transition. In practice, the kit has UI support for managed and federated-looking account experiences. Combined with the Entra replay evidence, this makes the page much closer to an authentication workflow emulator than a static credential form.

Framework evolution: session-polymorphic wrapper around stable core modules

Repeated snapshots showed a consistent pattern: the core obfuscated modules were reused, but the surrounding session wrapper changed. This is the most important evolution point for detections. The operator does not need to rebuild the entire kit on every visit. It can preserve the tested core workflow while mutating the external surface that defenders are most likely to key on.

The mutable wrapper included:

• JavaScript loader filenames
• Long route namespace
• Identity-binding handler below the session route
• Validation endpoint slug
• Security token and timestamp values
• Page title and decoy destination
• Query parameter schema
• Target identity and tenant branding URL
• Signed resource URL with hashed IP and user-agent values

The stable core included:

• Microsoft sign-in template and page states
• Password and MFA state machine
• Image-based error and MFA assets
• Browser validation and anti-analysis layer
• Final redirect logic
• Decoded logical workflow actions such as password validation, code validation, SMS validation, and Authenticator polling

Detection impact: filename-only, hash-only, and page-title detections will miss the broader campaign. Durable detection should focus on the combination of route behavior, identity binding, signed resource tokens, decoded workflow strings, kit assets, tenant-branding retrieval, and Entra replay telemetry.

Reversed capabilities supported by the kit

The reversed page exposes a complete Microsoft authentication workflow. The JavaScript function names are randomized, but the logical roles remain visible through the HTML configuration, state maps, asset usage, and runtime behavior.

Anti-analysis and browser-gating features

The kit includes a browser validation layer that goes beyond simple obfuscation. The goal is to decide whether the visitor behaves like a real user before exposing or progressing the phishing flow.

• Noscript refresh and fallback behavior
• Honeypot field checks
• Disabled text selection and right-click resistance
• Strict-mode PageValidator-style configuration
• Mouse movement variability and timing checks
• Click and keypress timing checks
• Canvas fingerprint collection
• WebGL and browser capability checks
• Automation and headless-browser checks, including webdriver artifacts
• Console and debugging detection
• Decoy or redirect behavior when validation fails

Session-bound routing and signed resource access

The URL sequence shows that the kit creates a long route namespace for the session and uses additional short handlers below that namespace. The target identity is bound in multiple places: query string email, base64 identity route, HTML state, and signed resource access.

Observed identity-binding route:

/<session-namespace>/YaR1zYfaCliK5?a=YWNjb3VudHN1cHBvcnRAbmV0ZmxpeC5jb20=

Decoded value: accountsupport@[synthetic branded tenant]

The signed resource token contained hashed IP and user-agent values, an expiration value, and an image selector. This design protects resources from simple replay and makes scanner reuse of captured URLs less reliable.

Decoded signed resource token payload:

{
  "ip":  "236fb946557b271893ce8f39188aea859093b9fb68f5a34c988baf8af9a1ca7b",
  "ua":  "f9d9e5fc7a9e5166686bdd114f1297037eeccac3a3d2e78979e5f727bf4bb895",
  "exp": 1782872370,
  "img": 3
}

Credential replay confirmed in Microsoft Entra ID

The strongest proof came from controlled testing with non-valid credentials. Shortly after submission, Microsoft Entra ID recorded failed sign-in attempts against the targeted account. The attempts targeted OfficeHome through a browser client, used a Windows and Edge user agent, and failed with Entra error 50126. This confirms live replay of submitted credentials to Microsoft Entra ID.

Detection and hunting opportunities

Hunting should not chase trusted redirectors by themselves. Microsoft and Google redirect services appear in many legitimate workflows. In this campaign, they matter only when the chain resolves into the final phishing host, session route namespace, identity-binding handler, and kit assets.

Recommended web and URL hunting should focus on the final host and the kit-specific path behavior:

// Web/proxy concept, pseudocode
where Url has "accessidriveappsigner[.]dersonmfginc[.]com"
   or Url has "dersonmfginc[.]com"
   or Url matches "[?&]e=.*@"
   or Url matches "/[A-Za-z0-9_-]{80,}/js/[A-Za-z0-9]{10,}\.js"
   or Url has "verify_app[.]png"
   or Url has "verifnotif2[.]png"
   or Url has "appnotif2[.]png"

Recommended Entra hunting should focus on replay telemetry from the observed replay infrastructure and behavior:

SigninLogs
| where AppDisplayName == "OfficeHome"
| where ResultType == 50126
| where ClientAppUsed == "Browser"
| where IPAddress in~ (
    "2a13:9241:b54b:cafb:a8c7:a8fd:554d[:]ec58",
    "2a13:9246:aa74:e116:5346:5d5d:61fb[:]fb93"
  )
  or AutonomousSystemNumber == 216157
| project TimeGenerated, UserPrincipalName, IPAddress, AutonomousSystemNumber,
          UserAgent, AppDisplayName, ResultType, ResultDescription

Recommended email hunting should focus on the lure and trust-abuse pattern, not broad blocking of the cloud sender:

Email events or message trace concept
where Subject has "Mailbox Pending Notice"
   or Subject has "Unusual Sign-in activity"
   or Subject has "Case-ID:"
where Sender is a previously trusted third-party SaaS sender
where DKIM domain differs from the visible sender brand
where body contains "Review Activity" and a Microsoft security-alert lure

Indicators of compromise and hunting context

All displayed network indicators are defanged. Items marked as "context only" are useful for correlation but should not be blocked globally without additional evidence.

Web and session indicators

Replay indicators

Kit asset indicators

Email indicators and context

ZeroBEC conclusions: why this attack matters

This case shows Sneaky 2FA-style evolution across the full attack chain. The campaign did not rely on one trick. It combined a compromised trusted sender, enterprise IT targeting, business-thread camouflage, trusted redirect laundering, an identity-check gate, a session-polymorphic loader, tenant-branded rendering, signed resource access, live Entra credential replay, and MFA collection paths.

The most important finding is the cross-stage nature of the attack. No single layer carried the full signal. The sender looked trusted. The redirectors looked legitimate in isolation. The Microsoft page rendered tenant-aware branding. The replay only appeared in Entra after the controlled credential submission. Traditional SEG logic that stops at sender reputation, single URL reputation, or static body analysis will miss too much of the chain.

In the observed environment, secure email gateways and native cloud controls were bypassed or neutralized before ZeroBEC intervention. The attacker abused trust that already existed in the mail flow and then shifted the decisive evidence into the browser and identity layers.

ZeroBEC is needed because BEC and ATO defense has to correlate the entire user journey: sender trust, historical sender behavior, message intent, redirect behavior, browser-stage kit signals, tenant-aware rendering, credential replay telemetry, and MFA follow-on risk. This is the layer where this campaign becomes visible.

For defenders, the practical takeaway is clear: do not treat "trusted sender" as safe, do not treat trusted redirectors as harmless when they lead into a session-gated phishing host, and do not rely on static page or filename indicators for Sneaky 2FA-style infrastructure. The detection strategy has to follow the attack across email, web, and identity.