From Cookies to Keys: Why Hackers Don’t Need Your Passwords Anymore

What Happened

Hackers are increasingly stealing session tokens (the digital cookies that keep you logged into websites) instead of just passwords. This affects anyone using web browsers for work, especially those accessing cloud services or developer tools. It matters because stealing these tokens allows attackers to completely bypass multi-factor authentication and sneak into corporate networks unnoticed. Organizations should respond by shortening how long sessions stay active, monitoring for unusual login locations, and using decoy credentials to catch intruders.

Key Takeaways

• Attackers are increasingly using infostealers to harvest session tokens, allowing them to bypass MFA and traditional password-based security.
• Stolen session tokens are sold on dark web markets, with prices varying based on access level (e.g., Slack, AWS, and M365 tokens command premium prices).
• Initial Access Brokers (IABs) enrich raw infostealer logs with add-ons like developer tokens and vault exports to maximize resale value.
• Automated tools like OpenBullet and StealyBot are used to replay stolen sessions and simulate legitimate logins.
• Defenders must implement short-lived sessions, anomaly detection, and canary credentials, as MFA alone is insufficient against session replay.

Affected Systems

• Web browsers
• Cloud services (Google Workspace, Microsoft 365, Slack, AWS, GitHub)
• Developer environments
• Password managers

Attack Chain

Attackers first infect a victim's endpoint with infostealer malware to harvest browser session cookies, password manager vaults, and developer tokens. These stolen logs are sold on dark web markets by Initial Access Brokers. Buyers then use automated tools like OpenBullet or StealyBot to replay the session tokens, bypassing MFA and gaining authenticated access to cloud environments. Once inside, attackers can move laterally, steal intellectual property, or deploy ransomware.

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: No
• Other Detection Logic: No

The article does not provide specific detection rules, but outlines behavioral monitoring strategies such as detecting anomalous authentication patterns and device fingerprint mismatches.

Detection Engineering Assessment

EDR Visibility: Low — EDR tools are typically tuned to detect brute force, credential stuffing, or known malware signatures, not session replays using valid tokens from unmanaged devices. Network Visibility: Medium — Network monitoring can detect anomalous login locations, VPN/proxy usage, or AiTM phishing domains, but encrypted session replay traffic blends in with legitimate web traffic. Detection Difficulty: Hard — Session hijacking uses valid authentication tokens, meaning attackers appear as legitimate users. Detecting this requires baselining normal user behavior and correlating anomalies across IP, geolocation, browser fingerprint, and OS.

Required Log Sources

• Cloud Provider Logs (AWS CloudTrail, Azure AD/Entra ID)
• Web Application Access Logs
• Identity Provider (IdP) Logs
• VPN/Proxy Logs

Hunting Hypotheses

Control Gaps

• Standard MFA (bypassed by session replay)
• Traditional EDR (blind to web session reuse on unmanaged devices)

Key Behavioral Indicators

• Sudden change in browser fingerprint within an active session
• Authentication from unmanaged devices or unexpected OS (e.g., Mac and Windows simultaneously)
• Access to canary credentials or decoy tokens

False Positive Assessment

• Medium. Anomaly-based detection for session hijacking relies on IP, location, and browser fingerprint changes, which can frequently occur when legitimate users travel, switch between Wi-Fi and cellular networks, or use privacy-enhancing browser extensions.

Recommendations

Immediate Mitigation

• Verify against your organization's incident response runbook and team escalation paths before acting.
• Consider forcing active session revocation for users suspected of infostealer compromise.
• Evaluate whether to block authentication attempts originating from known malicious proxy or VPN networks identified in threat intelligence.

Infrastructure Hardening

• Consider implementing short-lived session tokens to reduce the window of opportunity for session replay attacks.
• If supported by your web applications, ensure cookies are configured with Secure and HttpOnly flags to prevent client-side extraction.
• Evaluate deploying canary credentials (decoy tokens or accounts) within developer environments to detect unauthorized access attempts.

User Protection

• Consider enforcing device binding or conditional access policies that require authentication from managed, compliant devices.
• If applicable, evaluate transitioning to FIDO2/WebAuthn hardware keys, which provide stronger resistance against AiTM phishing compared to standard MFA.

Security Awareness

• Consider updating security awareness training to highlight the risks of downloading cracked software or unverified browser extensions, which are common infostealer vectors.
• Evaluate educating developers on the risks of storing personal access tokens (PATs) and cloud credentials in plaintext files like .env or .aws/credentials.

MITRE ATT&CK Mapping

• T1539 - Steal Session Cookie
• T1550.004 - Use Alternate Authentication Material: Web Session Cookie
• T1552 - Forage for Credentials
• T1566 - Phishing
• T1111 - Two-Factor Authentication Interception

Additional IOCs

• Ips:
  • 102[.]222[.]15[.]40 - Anomalous authentication IP associated with MESON_NETWORK_PROXY used in a suspected session hijacking incident.
  • 2605:7980:0:2478::1 - Attacker IPv6 address (RouterHosting LLC) used in an Adversary-in-the-Middle (AiTM) phishing incident.
• Domains:
  • isoo[.]3bindustriesconnect[.]com - Malicious domain used for Adversary-in-the-Middle (AiTM) phishing.
• Urls:
  • hxxps://isoo[.]3bindustriesconnect[.]com/ - Malicious site used for Adversary-in-the-Middle (AiTM) phishing to steal Microsoft 365 session tokens.