During a recent incident response engagement for a major financial services provider in Mumbai, I observed a series of successful logins that bypassed SMS-based Multi-Factor Authentication (MFA) entirely. The logs showed no failed MFA attempts; instead, the attacker moved directly from the login page to sensitive internal API endpoints. This wasn't a credential stuffing attack. It was session token theft, likely facilitated by a "Lumma" infostealer variant distributed through a malicious Tally.ERP 9 "crack" downloaded by an accounting employee. This scenario is becoming the baseline for modern breaches in the Indian corporate landscape, where traditional perimeter defenses are rendered obsolete by the portability of session cookies.
Understanding Auth Token Theft: The Modern Session Hijacking Threat
Authentication tokens, specifically session cookies like those used in Microsoft 365 (FedAuth) or Google Workspace (OSID), are the digital equivalent of a "Fast Pass" at a theme park. Once a user successfully authenticates via password and MFA, the server issues a token that the browser presents for every subsequent request. If an attacker steals this token, they don't need the user's password or their physical MFA device. They simply inject the stolen cookie into their own browser and assume the user's identity.
What is an Authentication Token?
Most modern web applications use JSON Web Tokens (JWT) or opaque session strings. In the context of OAuth 2.0 and OpenID Connect (OIDC), we primarily deal with access tokens, refresh tokens, and ID tokens. Access tokens are short-lived and used to access resources, while refresh tokens are long-lived and used to obtain new access tokens without re-authenticating. In the Indian SME sector, where legacy software often interacts with modern cloud portals, these tokens are frequently stored in insecure browser caches or local SQLite databases.
How Attackers Steal Tokens: From Phishing to Malware
I have identified two primary vectors currently dominating the threat landscape. First is the use of Infostealers (Lumina, Rhadamanthys, StealC). These are lightweight binaries that target browser "Local State" keys and "Cookies" databases. Second is the use of Adversary-in-the-Middle (AiTM) frameworks. Unlike traditional phishing that steals passwords, AiTM proxies the entire login session in real-time.
We recently analyzed a sample leveraging CVE-2023-38831, a WinRAR zero-day documented in the NIST NVD. The attacker sent a ZIP file containing a "GST Compliance Update" PDF. When the victim opened the PDF, a hidden script executed, exfiltrating the Chrome User Data folder to a C2 server. This bypassed the DPDP Act 2023 compliance controls the firm had spent months implementing, as the "unauthorized access" occurred using a valid, authenticated session.
The Rise of Adversary-in-the-Middle (AiTM) Attacks
Tools like Evilginx2 and Muraena have lowered the barrier for AiTM attacks. These tools act as a reverse proxy between the victim and the legitimate service (e.g., login.microsoftonline.com). When the victim enters their MFA code, the proxy captures the resulting session cookie. I have seen these proxies hosted on low-cost cloud providers in India, often using .in or .org.in domains to appear legitimate to local users.
Key Indicators of Auth Token Theft
Detecting token theft requires shifting focus from "failed login attempts" to "anomalous session behavior." Since the attacker uses a valid token, the login itself is successful. We must look for the "Session Shift"—the moment the token is used by a device or IP address that does not match the one that originated the session.
Anomalous IP Addresses and Geolocation Shifts
The most obvious indicator is a session suddenly originating from a new IP address. However, in India, this is complicated by Carrier-Grade NAT (CGNAT). Users on Jio or Airtel mobile networks frequently see their public IP change as they move between cell towers or as the ISP reallocates address space. A simple "New IP" alert will generate hundreds of false positives daily.
Instead, we filter for "ASN Shifts." If a session starts on a Jio (AS55836) residential connection and suddenly jumps to a DigitalOcean (AS14061) or AWS (AS16509) IP, the probability of token theft is near 100%. Attackers rarely use residential proxies for the initial exfiltration; they use VPS infrastructure to run their automated scripts.
Impossible Travel: Detecting Rapid Successive Logins
Impossible travel occurs when a user logs in from Mumbai and, ten minutes later, the same session is seen in Frankfurt. While VPNs can cause this, security teams should correlate these events with "User Agent" changes. If the Mumbai login was on "Chrome/Windows" and the Frankfurt activity is "Python-requests/Linux," it is a confirmed compromise.
Unusual User Agent Strings and Device Fingerprinting
Attackers often use automated scripts to leverage stolen tokens. These scripts might not perfectly emulate the victim's browser fingerprint. We monitor for changes in the User-Agent header within a single session. To extract this data from Nginx logs for analysis, especially when using a browser based SSH client to manage remote nodes, I use the following command:
$ grep -E "sessionid=|auth_token=" /var/log/nginx/access.log | awk '{print $1, $7, $12}' | sort | uniq -c | sort -nr
Output:
45 122.161.x.x /api/v1/user/profile Mozilla/5.0...Chrome/120.0.0.0
12 159.203.x.x /api/v1/user/profile python-requests/2.31.0
In the output above, the sudden switch to python-requests from a DigitalOcean IP (159.203.x.x) is a clear indicator that the sessionid has been compromised and is being used by an automated tool.
Atypical Resource Access Patterns
Once an attacker has a token, they typically perform discovery. This results in unusual access patterns, such as a user who normally only accesses "Salesforce" suddenly querying the "Global Address List" or "SharePoint Admin Center." We flag any session that accesses more than five unique administrative URLs within a 60-second window.
Technical Detection Strategies for Security Teams
Effective detection relies on centralizing logs from identity providers (IdP), web servers, and endpoint agents. We use Sigma rules to standardize these detections across different SIEM platforms like Sentinel, Splunk, or ELK.
Leveraging SIEM Rules for Token Monitoring
To detect session reuse across multiple IPs, we implement a rule that aggregates session cookies and counts the distinct source IPs associated with them. This is particularly effective for detecting "Token Replay" attacks.
title: Detect Session Token Usage from Multiple IPs
logsource: product: zeek service: http detection: selection: content_type: 'application/json' condition: selection | count(ip.src) by http.cookie > 1 timeframe: 1h falsepositives: - Mobile users switching from WiFi to 4G/5G (Jio/Airtel) - Corporate CGNAT gateways level: high
In an Indian context, we often tune the count(ip.src) threshold to 3 or 4 for mobile users to account for aggressive IP switching, while keeping it at 2 for users on static corporate leased lines.
Behavioral Analytics and Machine Learning Baselines
Advanced Identity Threat Detection and Response (ITDR) solutions build a baseline of "Normal User Behavior." This includes the typical time of day for logins, the standard set of applications accessed, and the typical throughput of data. When an attacker uses a stolen token to bulk-download documents from a OneDrive folder (a common precursor to ransomware), the deviation from the baseline triggers an alert.
Monitoring for MFA Bypass and Session Replay Patterns
We specifically look for "MFA Fatigue" followed by a successful login from a different IP. In many AiTM cases, the victim might receive multiple MFA prompts or a single prompt they approve, followed by the attacker immediately using the captured cookie. We correlate the ResultType: 50074 (MFA required) and ResultType: 0 (Success) events in Azure AD logs, checking if the IP addresses match.
Analyzing OAuth Application Permissions and Consent Grants
Attackers sometimes use stolen tokens to grant permissions to a malicious OAuth application. This provides "persistent" access even if the original session token is revoked. I use kubectl to monitor ingress logs for suspicious OAuth callback patterns in cloud-native environments:
$ kubectl logs -l app=ingress-controller --tail=1000 | jq 'select(.upstream_addr != .remote_addr)'
This filters for requests where the client IP doesn't match the expected upstream,
indicating potential proxying or header manipulation.
Tools and Technologies for Detection
Relying on a single layer of defense is insufficient. A multi-layered approach involving EDR, CASB, and ITDR is required to gain visibility into the session lifecycle, as session hijacking remains a prominent threat on the OWASP Top 10.
Endpoint Detection and Response (EDR) for Cookie Theft Prevention
Modern EDRs like CrowdStrike or SentinelOne now include specific detections for "Cookie Stealing." They monitor for unauthorized processes (like a suspicious powershell.exe or a renamed curl.exe) attempting to read the Cookies SQLite file in browser directories. For example, an alert is triggered if sqlite3.exe is spawned by an untrusted process to query %LocalAppData%\Google\Chrome\User Data\Default\Network\Cookies.
Cloud Access Security Brokers (CASB) and Token Visibility
CASBs provide a "choke point" where session attributes can be inspected. They can enforce policies that require a session to be tied to a specific device ID. If the device ID is missing or doesn't match the one stored in the IdP, the CASB can block the request, even if the session token is valid. This is critical for Indian organizations adopting a "Work from Anywhere" model.
Identity Threat Detection and Response (ITDR) Solutions
ITDR is a specialized category that focuses exclusively on the identity fabric. It looks for "Shadow Admins" and "Illicit Consent Grants." During a recent audit, we used ITDR to find an OAuth app named "Internal Mail Helper" that had Mail.ReadWrite permissions and had been authorized via a stolen session token three months prior. No one had noticed because the "login" logs were long gone.
Prevention and Mitigation Best Practices
Detection is reactive; we must also implement proactive controls to make stolen tokens useless or harder to acquire.
Implementing Conditional Access Policies
Conditional Access (CA) is the most effective tool for limiting the blast radius of token theft. We recommend policies that require "Compliant Devices" or "Hybrid Azure AD Joined" devices for sensitive applications. Even if an attacker steals a token, they cannot use it from their non-compliant Linux VPS because the CA policy will check for the device's health certificate.
The Role of Token Binding and Short-Lived Sessions
Token Binding (or Channel Binding) cryptographically ties the session token to the TLS connection between the client and the server. If the token is moved to a different TLS connection (the attacker's machine), it becomes invalid. While support for Token Binding is still evolving, reducing session lifetimes (e.g., forcing re-authentication every 8 hours) limits the window of opportunity for an attacker.
Continuous Access Evaluation (CAE) Protocols
CAE allows the IdP to revoke tokens in near real-time when a "critical event" occurs, such as a password reset, a device being marked non-compliant, or a significant IP address change. Instead of waiting for the token to expire, the resource provider (like Outlook or SharePoint) proactively checks with the IdP. This is a game-changer for mitigating the impact of stolen long-lived sessions.
Enforcing Phishing-Resistant MFA (FIDO2/WebAuthn)
Traditional MFA (SMS, TOTP, Push) is vulnerable to AiTM. FIDO2/WebAuthn (using YubiKeys or Windows Hello) is phishing-resistant because the authentication is bound to the origin (the domain name). An Evilginx2 proxy sitting at login.microsoft-security.in cannot satisfy a FIDO2 challenge meant for login.microsoftonline.com. For high-value targets in India, especially those handling large INR transactions, moving to FIDO2 is no longer optional.
Incident Response: What to Do When a Token is Compromised
When a session compromise is confirmed, speed is the priority. The attacker is already "inside" the perimeter.
Automated Session Revocation Workflows
Manual revocation is too slow. We implement automated playbooks that trigger upon a "High" severity identity alert. In Azure AD, this involves the Revoke-AzureADUserAllRefreshToken PowerShell command. This immediately invalidates all active sessions for the user, forcing them to re-authenticate with MFA.
# Revoking all sessions for a compromised user
$ Connect-AzureAD $ Revoke-AzureADUserAllRefreshToken -ObjectId "[email protected]"
Rotating Signing Keys and Refresh Tokens
In cases where the compromise is widespread (e.g., a breach of the IdP itself), rotating the token signing keys is necessary. This is a disruptive "nuclear option" as it logs out every user in the organization, but it is the only way to ensure that forged tokens are invalidated.
Forensic Investigation of Stolen Session Activity
To understand what the attacker did, we must reconstruct the session. We use tshark to analyze packet captures if we have them, or we parse web server logs to find the first instance of the stolen token. We look for "Subject" mismatches in certificates if the attacker tried to use their own proxy.
$ openssl s_client -connect target-app.in:443 -showcerts < /dev/null 2>/dev/null | openssl x509 -text -noout | grep -i "Subject:"
This allows us to verify if the certificate presented by the app matches the expected
organization details, helping identify AiTM proxies.
We also analyze the User Data on the victim's endpoint. If we find that the Local State file (which contains the key to decrypt Chrome cookies) was accessed by a non-browser process, we can confirm the use of an infostealer. Under the DPDP Act 2023, this forensic detail is vital for documenting the "nature of the breach" when reporting to CERT-In, which requires notification within 6 hours of discovery for certain types of incidents.
Next Command: Monitor for 401 Unauthorized spikes following a mass session revocation to identify attacker scripts attempting to reconnect.