Steal Web Session Cookie

Cookie theft rarely opens an intrusion; it usually follows a phishing lure or a commodity malware drop. QakBot and XLoader both harvest browser cookies as one line item in a broader credential-theft routine that also grabs saved passwords and autofill data, and CookieMiner specifically targets Chrome and Safari cookies to bypass two-factor authentication on cryptocurrency exchanges. APT42 has used custom malware built specifically to pull login and cookie data from a victim's browsers as part of longer surveillance operations.

Once the cookie is stolen, it flows into T1550.004 (Use Alternate Authentication Material: Web Session Cookie): the attacker loads it into their own browser and is inside the application as the victim, no separate authentication step required. From there the pattern looks like any other account takeover, a hijacked mail session used for business email compromise, an unauthorized OAuth grant, or lateral movement into a SaaS admin console that trusts the same session. Because the token is already authenticated, this stage often skips every control built around the login event itself.

Legitimate software touches cookie stores constantly. Browser sync and profile-migration tools, enterprise backup agents, and DLP or forensic suites that inspect browser artifacts for compliance all open the same Cookies and cookies.sqlite files a stealer would target. Password managers and some VPN clients also read cookie data to support session-aware autofill, and endpoint-management agents that inventory installed browser extensions can trip a broad 'non-browser process touched Cookies' rule on their own.

The fix is the same allow-list discipline every credential-store rule needs: baseline the specific processes and service accounts your backup, DLP, and endpoint-management stack actually use, and scope the alert to anything outside that set. For the remote-debugging-port rule, treat headless-browser QA automation as an expected exception by allow-listing the CI or build-agent accounts and hosts that run it, since a real attacker rarely launches the debugging port from a build server's service account in the middle of a business day.

When a cookie-access or debugging-port alert fires, first confirm whether the process and account match a known backup, sync, or test-automation workflow; if they do not, check whether the browser was actively logged into anything sensitive, an SSO portal, admin console, or webmail, at the time of access. Then check the account's recent sign-in history for a token replay: a new session from an unfamiliar IP, ASN, or device fingerprint immediately after the cookie access is the confirming signal, exactly what the Anomalous Token correlation is built to surface.

If theft is confirmed, revoke the session at the identity provider so the token is invalidated and the user is forced to re-authenticate, reset the affected account's password, and re-enroll MFA if the method itself may have been captured alongside the cookie. Because a replayed cookie bypasses login controls entirely, treat every application the compromised session reached, not just the identity provider, as potentially touched, and pull application-level audit logs for actions taken during the session window before closing the incident.