M ManySignal

Use Case: Identity

Session token theft and hijacking

The attacker bypassed MFA by stealing the session cookie. No credentials needed. Just the cookie. ManySignal detects the replay from a different device before they get past the inbox.

Book a demo Identity attack surface
Attack scenario

MFA doesn't protect the session, only the login

Session token theft has become the dominant technique for bypassing MFA in enterprise environments. Tools like evilginx2, Modlishka, and the commercial Caffeine phishing kit act as reverse proxies between the user and the legitimate login page. The user completes MFA normally — the proxy captures the resulting session cookie in transit and forwards it to the attacker.

From the IdP's perspective, the MFA succeeded. The session is valid. The attacker now uses the cookie from their own machine, giving them full authenticated access to every app the session token covers — typically the entire Microsoft 365 or Google Workspace tenant.

Detection logic 
rule: session_token_replay
type: behavioral + fingerprint
sources:
  - microsoft_365_audit
  - google_workspace_token_events
  - okta_system_log
trigger:
  - event: session.api_call OR resource.access
  - condition: |
      session_ip != session_origin_ip
      AND device_fingerprint != session_origin_fingerprint
      AND session_age < 8h
enrichments:
  - ip_reputation: virustotal, shodan
  - phishing_infra: urlscan, certstream
  - mdm_device: intune, jamf
mitre: T1539 (Steal Web Session Cookie)
Triage agent questions
1

Does the session token's originating device fingerprint match the current request's device fingerprint?

Browser fingerprint
2

Has the session IP address changed since token issuance, and if so, to which ASN?

Network enrichment
3

Is the user agent string identical to the one used at original authentication?

Session metadata
4

Was the token issued from a managed device (MDM-enrolled)?

Intune / Jamf
5

Are there active evilginx2-style phishing domains targeting this organization?

Threat intel
6

What resources were accessed using this session in the past 30 minutes?

App audit log
Response playbook
1

Revoke the specific session token via IdP or app API

Autonomous
2

Force re-authentication with phishing-resistant MFA (FIDO2)

Autonomous
3

Block the suspicious IP at the WAF or Zscaler policy layer

Approve-gated
4

Capture full session audit log for forensic timeline

Autonomous
5

If mail or data accessed: escalate to data exposure playbook

Recommend

Legacy SOC comparison

A legacy SIEM has no session fingerprint model. The replayed cookie looks like a normal API call — same user, same token, different IP. Without device fingerprint correlation, the only alert is a minor IP change that most rules ignore. The attacker has hours of undetected access.

MITRE ATT&CK mapping

T1539 — Steal Web Session CookieT1550.004 — Use Alternate Auth Material: Web Session CookieT1111 — MFA Interception

Session hijacking FAQ

How does ManySignal detect session hijacking without breaking legitimate session roaming?

ManySignal builds a fingerprint model per session at issuance time, covering device OS, browser version, screen resolution, timezone, and network ASN. Legitimate session roaming (e.g., mobile switching from WiFi to cellular) shows ASN change but consistent device fingerprint. Hijacked sessions show both ASN and fingerprint changes simultaneously.

Does this detect evilginx2 and Modlishka AiTM proxies?

Yes. Adversary-in-the-middle proxies steal the session cookie after MFA, so the authentication event looks legitimate. ManySignal detects the subsequent cookie reuse from a different IP/device by monitoring post-authentication session metadata changes — a pattern AiTM proxies cannot avoid.

What applications are covered?

Any application that emits session audit logs to a supported data source. This includes Microsoft 365, Google Workspace, Okta-protected apps, Salesforce, GitHub, and AWS Console sessions. App-level session tokens from custom applications are supported via the ManySignal API ingestion connector.

Can ManySignal revoke sessions in SaaS applications directly?

For Microsoft 365, Google Workspace, Okta, and Salesforce — yes, ManySignal executes session revocation via the respective admin APIs as an autonomous response step. For other applications, the playbook generates a revocation runbook for the analyst.

Detect cookie replay before the attacker reaches the inbox

Session fingerprinting across M365, Google Workspace, and Okta — zero engineering required.

Book a demo Explore the platform