In February 2024, researchers at Sekoia documented an adversary-in-the-middle phishing platform called Tycoon 2FA that had processed over 1,000 phishing domains and was being sold on criminal Telegram channels for $120 per month. Tycoon 2FA, like EvilProxy before it, operated as a reverse proxy: phishing emails directed victims to a Tycoon 2FA-controlled page that looked identical to the legitimate service being impersonated. When the victim entered their credentials and MFA code, Tycoon 2FA passed these to the real service in real time, received the authenticated session cookie, and stored it. The attacker then had an authenticated session that would work directly, without any need to go through the MFA challenge again. The MFA that organisations had deployed as a primary defence against credential theft had been bypassed, not by breaking the cryptography, but by stealing the session token that MFA had issued.
The session token theft model represents a fundamental shift in the attack surface that organisations must defend. Traditional credential theft attacks stolen a username and password; organisations responded with MFA, making stolen credentials alone insufficient. Attackers adapted by targeting session tokens, the bearer credentials that browsers use to maintain authenticated state after login. Session tokens are issued by the application after successful authentication, including MFA verification. Stealing a valid session token grants exactly the same access as completing the authentication process, bypassing every authentication control that was applied at login.
When a user authenticates to a web application, the application verifies their credentials and, if MFA is required, their second factor, then issues a session token: a cryptographically random value that the browser stores as a cookie. On subsequent requests, the browser presents this cookie to the server, which looks it up in its session store and identifies the user. The session token is the user's authentication credential for the duration of the session, and any actor who possesses it can make authenticated requests to the application without providing any of the original authentication factors.
Session tokens are particularly valuable when they correspond to sessions for high-privilege applications: corporate email accounts, cloud service consoles, financial systems, or administrative interfaces. A session token for a Microsoft 365 account, for example, grants access to the user's email, SharePoint files, Teams messages, and any other Microsoft 365 service the user has access to. If the token is also a refresh token rather than a short-lived access token, it can be used to obtain new access tokens for an extended period, maintaining access even after the original session would have expired.
The market value of session tokens on criminal markets reflects this access value. While basic credentials for consumer services sell for cents, session cookies for corporate Microsoft 365 accounts and AWS console sessions command significantly higher prices, because they eliminate the authentication step and provide immediate, working access to productive targets.
Session tokens are stolen through three primary mechanisms. Adversary-in-the-middle phishing, using platforms like EvilProxy, Tycoon 2FA, and Modlishka, intercepts session tokens in transit during the authentication process by proxying the victim's browser session through attacker-controlled infrastructure. The victim authenticates normally; the proxy captures the resulting session cookies before forwarding the authenticated response to the victim.
Infostealer malware extracts session cookies directly from the victim's browser. Modern browsers store session cookies in local databases (Chrome uses SQLite files in the user profile directory), and infostealers are specifically designed to locate and exfiltrate these databases. The extracted cookies include sessions for every service the victim has authenticated to during the browser's cookie retention period. An infostealer log from a device whose user authenticates to corporate systems will typically include session cookies for those systems alongside consumer account cookies.
Cross-site scripting (XSS) vulnerabilities in web applications allow attacker-injected JavaScript to read the session cookies of authenticated users who visit the vulnerable page, exfiltrating them to attacker-controlled servers. While content security policies and the HttpOnly cookie flag limit XSS-based cookie theft in modern applications, legacy applications without these protections remain vulnerable.
Detecting session token theft in progress requires monitoring for signs that a legitimate session is being used from unexpected contexts. Anomalies in session usage that warrant investigation include authentication from a new geographic location or IP address without a corresponding login event, simultaneous active sessions from different geographic locations or devices, and API access patterns that differ significantly from the authenticated user's historical behaviour.
Microsoft's Conditional Access policies and equivalent features in other identity platforms can enforce session token validity checks beyond simple bearer token presentation: requiring that the device from which the session is used meets compliance requirements, enforcing re-authentication for sensitive operations, and flagging sessions that are being used from unusual locations or on unknown devices. These controls limit the utility of stolen session tokens by adding context-dependent conditions that the attacker's access pattern may not satisfy.
At the detection layer, correlating authentication events with the infostealer log intelligence available through dark web monitoring creates a proactive detection capability: if an employee's session cookies appear in an infostealer log market, the security team can invalidate all active sessions for that user and force re-authentication before the stolen cookies are purchased and used. This pre-exploitation intervention is only possible when the intelligence monitoring detects the log before the attacker acts on it.
Organisations cannot prevent all session token theft, but they can reduce both the likelihood of theft and its impact when it occurs. The HttpOnly and Secure attributes on session cookies prevent JavaScript access and enforce HTTPS-only transmission respectively, addressing the XSS theft vector. Short session lifetimes limit the window during which a stolen token remains valid; a session that expires after 8 hours of inactivity limits the period of unauthorised access even if the theft is not detected immediately.
Device binding, associating session tokens with cryptographic credentials stored in the device's hardware security module, is an emerging control that addresses the session token portability problem directly. A session token that is cryptographically bound to a specific device cannot be exported and used from a different device, because the cryptographic proof required to validate the token cannot be replicated outside the original device's hardware security module. WebAuthn/FIDO2 passkeys implement this principle for authentication, and device-bound sessions extend it to the post-authentication token.
The detection and response component of session token risk management requires the ability to identify and invalidate specific sessions quickly when compromise is suspected. Applications that do not provide administrators with the ability to view and terminate active sessions leave organisations unable to respond effectively when session token theft is detected. Auditing the session management capabilities of critical applications and remediating gaps is a prerequisite for an effective session token theft response capability.
The security industry has promoted phishing-resistant authentication, particularly FIDO2/WebAuthn passkeys and hardware security keys, as the definitive solution to credential phishing and MFA bypass. These authentication methods are indeed resistant to adversary-in-the-middle phishing: the authentication credential is cryptographically bound to the legitimate origin, so a proxy site cannot obtain a credential that works on the real site. But phishing-resistant authentication addresses only the phishing vector for session token theft; it does not address the infostealer vector.
An employee who uses a FIDO2 hardware key for authentication to Microsoft 365 cannot have their authentication credential stolen through a phishing proxy. But if an infostealer infects their device, the infostealer can steal the session cookies that were issued after the FIDO2 authentication, which are stored in the browser's cookie database and are not bound to the hardware key. The session tokens remain the attack surface even when phishing-resistant authentication protects the authentication process itself.
This distinction is important for organisations planning their authentication security programme. Phishing-resistant MFA is a meaningful improvement over TOTP-based MFA for resisting adversary-in-the-middle attacks, and its deployment should be prioritised for the highest-risk users and systems. But it should be accompanied by the session management controls, device compliance enforcement, and infostealer intelligence monitoring that address the residual risk that phishing-resistant authentication does not eliminate. Treating FIDO2 deployment as a complete solution to session security risks underestimating the session token threat and potentially leaving significant attack surface unaddressed.
Most enterprise environments run a mix of applications with varying session management implementations. Modern cloud-native applications often implement token-based authentication with short-lived JWTs and refresh token rotation; legacy applications may use server-side session stores with cookies that persist for 24 hours or longer without device binding. This heterogeneity means that session security audits must assess each application's implementation individually rather than assuming a uniform standard applies across the environment.
A practical session management audit for an enterprise environment should prioritise applications based on the sensitivity of the data and actions they provide access to, and the current session configuration of each. Applications that provide access to financial systems, HR data, source code repositories, or administrative interfaces warrant the highest priority. For each prioritised application, the audit should assess session lifetime (what is the maximum period a session remains valid without re-authentication?), device binding (does the session validate that it is being used from the device that initiated it?), concurrent session limits (can an account have an unlimited number of simultaneous active sessions?), and administrative session visibility (can administrators view and terminate sessions for specific users?).
Remediation priorities follow the same risk logic. Extending session lifetimes beyond the minimum necessary for usability is a common convenience trade-off that significantly increases the window of opportunity for stolen session exploitation. Many enterprise applications have default session configurations that were set for user convenience rather than security, and the security impact of shortening session lifetimes is often lower than anticipated, since users working actively in an application trigger session refresh mechanisms that prevent them from being logged out during normal use. This is one remediation action that typically has a high security impact relative to its user experience cost, making it a priority in any session security remediation programme. Connecting these technical controls to the infostealer log monitoring that detects when session cookies have been stolen creates the complete loop from detection to response to prevention.
An adversary-in-the-middle (AiTM) phishing attack uses a reverse proxy server that sits between the victim and the legitimate service. When the victim clicks a phishing link, they connect to the attacker's proxy server, which forwards all requests to the legitimate service and returns all responses to the victim. The victim sees the legitimate website and completes authentication including MFA. The proxy captures the session cookie issued by the legitimate service after successful authentication and stores it for the attacker's use. Unlike traditional phishing that steals credentials to attempt re-authentication, AiTM phishing steals the post-authentication session token, which is valid regardless of MFA.
Modern browsers store session cookies in local database files within the user profile directory. Chrome uses SQLite databases (Cookies file in the user's Chrome profile), while Firefox uses similar SQLite files. Infostealer malware is specifically designed to locate these files, copy them, decrypt the values where necessary (Chrome encrypts cookie values using Windows DPAPI, which infostealers can decrypt using the same user context that encrypted them), and exfiltrate the decrypted cookie data. The entire process is automated and typically completes in seconds before the malware's other tasks or before security software detects the activity.
Device binding associates a session token with a cryptographic credential stored in the device's hardware, so that the session can only be used from the specific device that initiated it. If the session cookie is copied to another device, it cannot be used because the cryptographic proof required to validate the session cannot be produced outside the original device's hardware security module. Token binding (RFC 8471) is the IETF standard for this approach, but it has seen limited deployment because it requires support from both the client browser and the server. Chrome dropped support for token binding, and WebAuthn/FIDO2 passkeys provide the strongest form of device binding currently widely available, though passkeys apply to authentication rather than post-authentication session management.
When an employee's session cookies are found in infostealer log markets, the immediate response is to invalidate all active sessions for that user across all services that the cookies provide access to. Most enterprise identity providers allow administrators to revoke all active sessions for a specific user; this should be done as a priority before investigating the scope of the compromise. The employee should be notified, their device should be investigated for the infostealer infection, and the investigation should determine how the device was compromised (phishing, drive-by download, or malicious application) to prevent recurrence. The scope of data potentially accessible through the stolen sessions should be assessed and, if sensitive data was accessible, the appropriate incident response and notification procedures initiated.
The session security challenge has changed significantly as enterprise workloads have moved to SaaS and cloud platforms. In the traditional on-premises model, session management was controlled by applications running in the organisation's own infrastructure, giving security teams direct access to session stores and the ability to implement organisation-specific session policies. In the SaaS model, session management is controlled by the SaaS vendor, and the organisation's ability to configure session security is limited to the options the vendor provides in their product.
The variation in session security capabilities across SaaS vendors is significant. Some vendors offer fine-grained control over session lifetime, concurrent session limits, device binding, and administrative session visibility. Others offer only basic settings, and some provide no session management controls beyond the defaults. Auditing the session security capabilities of critical SaaS applications as part of vendor security assessments identifies gaps that should be raised with the vendor and factored into the risk assessment of the dependency on that SaaS service.
For Entra ID (formerly Azure AD) and other enterprise identity providers that act as single sign-on platforms for SaaS applications, Conditional Access policies can enforce session security standards that apply to all sessions regardless of the individual SaaS application's capabilities. A Conditional Access policy that requires re-authentication for sensitive applications after a defined idle period, or that invalidates sessions when the device compliance status changes, applies a consistent session security standard across the SaaS portfolio without requiring each individual application to implement equivalent controls. This identity provider-level session security layer is one of the most impactful investments for organisations with a large SaaS portfolio and variable vendor session security capabilities. Defending this layer requires monitoring for the infostealer activity that produces the stolen session tokens that bypass these controls.
Detecting session token theft in progress, or in the period immediately after the theft but before the stolen session is used, requires monitoring for specific anomaly signals in authentication and session data. The most valuable detection signals are those that indicate a session is being used in a way inconsistent with the device and context that initiated it, which are characteristics that stolen sessions will typically exhibit.
Impossible travel detection, flagging sessions that appear to be used from two geographically distant locations within a timeframe that makes physical travel impossible, is one of the most reliable signals for concurrent session theft. If a user authenticates from London and then appears to use a session from Singapore 30 minutes later, this pattern is almost certainly indicative of a stolen session being used from a different device in a different location. The session used from Singapore should be invalidated and the user required to re-authenticate with additional verification.
User agent and browser fingerprint changes within a single session provide a softer but still informative signal: if a session that began with a Chrome browser on Windows suddenly presents as Firefox on Linux in the same session, this suggests the session token has been exported to a different device. This signal is less reliable than impossible travel because some users legitimately use multiple devices, but in combination with other anomaly signals it contributes to a risk score that can trigger step-up authentication. Connecting session anomaly detection to the infostealer log monitoring that detects when session cookies have been stolen closes the loop between detection at the criminal distribution stage and detection at the exploitation stage.
Session token theft and lookalike domain registrations both leave detectable signals before they produce incidents. Defendis monitors infostealer log markets for corporate session cookies and credentials, tracks certificate transparency logs for newly registered domains resembling your organisation's brand, and alerts your team when these signals appear. Early warning on both vectors gives your security team the time to revoke compromised sessions, block lookalike domains, and warn users before an attack succeeds.
Request a demo to see how Defendis monitors session exposure and lookalike domain registrations for your organisation.
