Why This Is New

The conventional defender response to credential phishing rests on two assumptions: the phishing page is not the real identity provider, and the URL or visual asset will betray that. Adversary-in-the-middle phishing kits invalidate both assumptions. The page the victim sees is the real provider page, relayed through the kit. Brand checks pass. URL similarity blocks rotate too slowly. The conventional response was never going to catch this.

What is new in detection over the past two years is that defenders stopped trying to fingerprint the page and started fingerprinting the relay. Sekoia's work on JA3 and JA4 fingerprints of Tycoon 2FA, Mamba 2FA, and other kits opened a network-layer detection surface. Microsoft, Cloudflare, and Trustwave have each added page-side and identity-provider-side correlations. None of these signals is a complete control by itself, but together they cover the technique with high confidence.

The Technique End-to-End

The kit operator stands up a server running a reverse proxy configured to forward traffic to the targeted identity provider. The lure delivers a victim to the proxy under an attacker-controlled domain. The proxy issues TLS to the victim using its own certificate; the victim's browser sees the attacker domain in the address bar (the only part of the experience that is not the real provider). The victim submits credentials. The proxy forwards them to the provider. The provider issues a multi-factor challenge. The proxy forwards the challenge to the victim. The victim completes the challenge. The provider issues a session cookie. The proxy strips the cookie from the response, captures it, and forwards a rewritten cookie to the victim.

At the end of the exchange, the operator has a valid session cookie scoped to the real identity provider. They walk away from the proxy and use the cookie from their own infrastructure. The victim sees a successful login.

Why Current Controls Miss It

URL similarity does not help because the proxy does not need to look like the provider — only the page it serves does, and that page is real. SafeBrowsing and SmartScreen catch some kit infrastructure when it is well-known, but rotation outpaces the lists. Brand-based user training works against the lure (the email that gets the victim to click), but not against the rest of the chain. MFA is satisfied. Conditional Access on user-risk firing late, after the session is in the operator's hands, is too slow to prevent the steal.

The signals that do work live in the layers the conventional response was not watching: TLS fingerprints in network telemetry, cookie-rewriting tells in HTTP responses, page-side DOM differences from the canonical provider response, and identity-provider sign-in correlations after the fact.

Worked Example

**Network layer: TLS fingerprints.** Sekoia and others have published JA3 and JA4 fingerprints associated with the reverse-proxy software stacks common to Tycoon 2FA and Mamba 2FA. A network detection that watches for these fingerprints on outbound TLS to identity-provider impersonation domains produces a small, high-confidence stream of suspect connections. The fingerprints rotate when the kit updates its TLS library or randomization settings, so the watchlist needs to be refreshed against vendor reporting. Treat it as an enrichment signal, not a sole control.

**Cookie layer: rewriting tells.** A reverse proxy must rewrite cookies between two origins: the real identity provider's cookie domain and the attacker domain visible to the victim. The rewriting is not always clean. Public analyses have pointed to specific Set-Cookie ordering anomalies, missing or extra Domain directives, and inconsistent SameSite attribute application as visible signs of a relay. Where TLS interception is in place (corporate proxies), defenders can sample these directly. Where it is not, the cookie tells are accessible only on the endpoint via browser developer-tool comparisons or extension telemetry.

**Page layer: DOM baseline diffs.** A canonical Microsoft or Google login page has a stable DOM shape, post-message wiring, and asset hashes. A relayed page renders nearly identically but has subtle differences: the proxy injects its own JavaScript to rewrite form-action URLs, intercept the multi-factor challenge response, and persist the session cookie. A headless-browser comparison between a known-good provider page and a suspect page surfaces these injections reliably. Sekoia and Trustwave have published sample diffs.

**Identity-provider layer: post-hoc correlation.** Even if the relay is not detected during the exchange, the identity provider's sign-in logs record evidence of it. The interactive sign-in completes from the victim's IP. Within minutes, non-interactive token redemption follows from the operator's IP. The two events on the same UPN within a short window from different ASNs is the cleanest single-event indicator that the technique succeeded.

Detection Ideas

The query below operationalizes the identity-provider correlation. It runs over the most recent two hours and flags any UPN with a successful interactive sign-in followed within fifteen minutes by a non-interactive token use from a different ASN. The window and ASN comparison are the primary tunables. Geography comparison alone is too coarse — operators routinely use residential proxies in the victim's country.

// Surface the AitM relay tell: an interactive sign-in followed by
// non-interactive token use from a different ASN within minutes.
let window = 15m;
let interactive =
    SigninLogs
    | where TimeGenerated > ago(2h)
    | where ResultType == 0
    | project VictimTime = TimeGenerated, UserPrincipalName,
              VictimIP = IPAddress,
              VictimCountry = LocationDetails.countryOrRegion,
              VictimASN = AutonomousSystemNumber,
              VictimApp = AppDisplayName;
let nonInteractive =
    AADNonInteractiveUserSignInLogs
    | where TimeGenerated > ago(2h)
    | where ResultType == 0
    | project ReuseTime = TimeGenerated, UserPrincipalName,
              ReuseIP = IPAddress,
              ReuseCountry = LocationDetails.countryOrRegion,
              ReuseASN = AutonomousSystemNumber,
              ReuseApp = AppDisplayName;
interactive
| join kind=inner nonInteractive on UserPrincipalName
| where ReuseTime between (VictimTime .. VictimTime + window)
| where VictimASN != ReuseASN
| project VictimTime, ReuseTime, UserPrincipalName,
          VictimApp, ReuseApp,
          VictimIP, VictimCountry, VictimASN,
          ReuseIP, ReuseCountry, ReuseASN

Pair the rule with Defender for Cloud Apps' "Activity from infrequent country" and "Unusual ISP for an OAuth app" policies for redundancy. In Defender XDR, the equivalent join lives in IdentityLogonEvents and CloudAppEvents, where the response actions attach to the alert directly.

Limitations and Caveats

Several signal sources that were promising in early reporting have weakened.

**Geography alone** is unreliable. Operators routing through residential proxies in the victim's country defeat country-based comparisons. The ASN comparison in the query above is the residual signal that survives this evasion.

**JA3 and JA4 watchlists** rot. Kit operators randomize TLS settings or update their proxy stacks. The fingerprints from a six-month-old report may no longer match. Treat them as enrichment with a refresh cadence tied to vendor publication.

**Browser fingerprint alone** is unreliable. The operator's reuse of the captured cookie typically uses a browser configured to mimic the victim's device fingerprint, including user-agent, language, and screen-size headers. Where the browser fingerprint differs, treat it as a signal; where it does not, do not assume legitimacy.

**The non-interactive correlation rule** has a false-positive class: travel within a sign-in session, where a user authenticates from one network and the device's background services then refresh tokens from a different network shortly after. Tuning against the user's typical mobility profile reduces this; some environments accept it as noise and triage manually.