Session hijacking bypasses authentication entirely. Instead of cracking passwords, attackers steal the session token issued after login - the digital proof of identity that websites accept in place of credentials. Once stolen, the attacker is indistinguishable from the legitimate user.
Before deploying an AiTM phishing infrastructure, the attacker profiles the target organization's authentication stack. Knowing the exact login portal, SSO provider, and MFA method allows them to build a pixel-perfect proxy that victims won't question.
Evilginx2 is a reverse proxy that sits between the victim and the legitimate Microsoft login page. It transparently forwards all traffic - including the MFA challenge and approval - while silently copying the session cookie the moment Microsoft issues it. The victim successfully logs in; the attacker gets the token.
The moment Sarah completes her MFA approval, Microsoft issues a pair of authenticated session cookies. These cookies are the proof of her completed authentication. Evilginx2 captures these in transit and stores them - Sarah is successfully logged into Microsoft 365, and so, silently, is the attacker.
Where AiTM targets a specific user, XSS harvests cookies from anyone visiting a vulnerable page. A single stored XSS payload in a comment field, product review, or profile bio silently exfiltrates the session cookie of every authenticated user who views that content - thousands of tokens at once.
The attacker opens a fresh browser profile, navigates to Microsoft 365, and uses a browser extension to inject Sarah's captured cookies. The server receives a request with a valid, authenticated session token and grants immediate access - no username, no password, no MFA prompt.
With Sarah's session, the attacker has access to her entire Microsoft 365 environment. CFO-level access yields financial data, M&A communications, payroll records, and the ability to send trusted emails to the entire organization. The session token is also valid for all M365-connected apps via OAuth.
Session hijacking is detected by anomalies in the session itself - not the credentials. The legitimate user and the attacker may be simultaneously active, from different IP addresses, in different geographies, or with abnormal access patterns. Behavioral analytics on session metadata, not just login events, is critical.
| Signal | Severity | Detection Source |
|---|---|---|
| Same session token used from two distinct IPs simultaneously | CRITICAL | Azure AD / Okta Logs |
| Impossible travel: login location changes faster than physically possible | CRITICAL | UEBA / Identity Protection |
| Bulk data access immediately after login from unusual IP | CRITICAL | CASB / DLP / Graph Audit |
| New OAuth application consent granted outside normal process | CRITICAL | M365 Audit Log / Defender |
| Known Tor/VPN exit node IP in authentication logs | MEDIUM | TI Feed / Conditional Access |
| User-Agent string inconsistency between legitimate and attacker sessions | MEDIUM | SIEM Correlation Rule |
| XSS payload delivered via outbound request to external domain with cookie param | LOW–MED | WAF / Proxy Logs |