The uncomfortable truth

A lot of defenders still picture credential theft as “malware that dumps passwords.”

That happens, sure.

But the bigger modern truth is this: the browser already holds everything an attacker wants.

  • session cookies that bypass MFA
  • saved passwords
  • autofill data
  • OAuth tokens and refresh tokens
  • single sign-on sessions
  • cloud app access

If an attacker can steal or reuse that browser state, they can log in like you, often without triggering the “password failed” signals everyone expects.

And sometimes they do it without deploying any obvious malware.

The browser becomes the battlefield.

Why the browser is such a high-value target

If you are an attacker, you have two choices:

1) Fight the identity layer: MFA, conditional access, device checks, password resets
2) Steal the session: cookies/tokens that already passed those checks

Guess which one scales.

Once a session is stolen, “strong passwords” are irrelevant. Even MFA can be irrelevant, depending on how the session is replayed and what controls the org has in place.

This is why stealers are popular—but it is also why you can see credential theft patterns even when you don’t see “malware.”

The main “no-malware” paths attackers use

Let’s keep this practical. Here are the most common ways browser-based theft happens without a big obvious payload.

1) Phishing that steals sessions, not passwords

Classic phishing wants credentials. Modern phishing often wants the session.

Common patterns:

  • reverse-proxy phishing (victim logs in, attacker steals token)
  • MFA fatigue leading to an approved session
  • OAuth consent phishing (attacker gets app access)

You might never see a payload. You just see:

  • successful login
  • followed by “impossible travel” or new device access
  • followed by mailbox rules or cloud app abuse

2) “Living off the land” collection on the host

If an attacker already has some level of host access (remote tool, admin session, stolen creds), they may not need malware.

They can:

  • copy browser profile directories
  • exfiltrate cookie and login databases
  • export browser state from user directories

This can look like “normal file access” unless you have telemetry for it.

3) Rogue browser extensions

Extensions are effectively code execution inside the browser. A malicious or compromised extension can:

  • read page content
  • hook authentication flows
  • steal tokens
  • capture credentials
  • modify transactions

This often bypasses traditional endpoint detection because nothing “drops” on disk in the way defenders expect.

4) Sync abuse and account takeover

If an attacker compromises an identity that has browser sync enabled:

  • saved passwords can sync
  • browsing data can sync
  • sessions can be re-established quickly

You might see no host artifacts at all—just identity-level activity.

What it looks like in telemetry

This is where defenders usually lose time: they hunt for malware artifacts that may not exist.

Instead, look for browser-access patterns + identity abuse patterns.

Host-level signals (if you have endpoint telemetry)

High-signal behaviors:

  • unusual access to browser databases:
    • Chrome/Edge: Login Data, Cookies, Local State
    • Firefox: logins.json, cookies.sqlite, key4.db
  • unusual process reading those files (not the browser itself)
  • compressed archives created from browser profile directories
  • data staging in Temp/Roaming shortly before outbound transfer

You are not trying to prove “credential theft.” You are trying to identify activity consistent with browser state collection.

Identity-level signals (often the real story)

Look for:

  • new device or location logins
  • token refresh activity from new IPs
  • abnormal OAuth app grants
  • mailbox rule creation shortly after sign-in
  • new forwarding rules or suspicious consent events

If you only hunt on endpoint signals, you miss the part that matters: the stolen access being used.

A quick casefile pattern: “No malware, but the browser got looted”

Here is a pattern I have seen repeatedly:

1) User reports nothing unusual.
2) Identity logs show a successful sign-in from an unusual location.
3) Within minutes, mailbox rules appear (forwarding, delete, hide).
4) EDR shows no obvious malware.
5) Later, endpoint logs reveal non-browser processes accessed:

  • Login Data
  • Cookies
  • Local State

The “malware” may have been ephemeral, fileless, remote tooling, or a legitimate admin session abused. But the objective is still the same: steal access through the browser session.

Defensive moves that actually reduce impact

Here are the controls that matter in the real world:

1) Treat cookies and sessions as credentials

  • shorten session lifetime for high-risk apps
  • require re-authentication for sensitive actions
  • bind sessions to device posture where possible

2) Harden browser profile access

  • limit who can run arbitrary executables on endpoints
  • monitor non-browser access to credential stores
  • reduce local password storage (policy / enterprise password managers)

3) Control extensions

  • allowlist extensions in enterprise
  • monitor new extension installs
  • alert on extensions requesting high-risk permissions

4) Strengthen identity detection

  • conditional access + device compliance
  • risky sign-in policies
  • alerts on OAuth consent grants
  • alerts on mailbox rule creation

If your detections only trigger when ransomware executes, you are too late.

What to do when you suspect browser-session theft

1) Assume credentials and sessions are compromised
2) Revoke sessions and refresh tokens where possible
3) Reset passwords (but don’t stop there)
4) Review OAuth app consents and remove suspicious grants
5) Audit mailbox rules, forwarding, delegated access
6) Hunt for other impacted users with similar sign-in patterns

The point is not “find malware.” The point is “remove stolen access.”

Artifact Annex (field notes)

Host artifacts (browser stores)

Chromium (Chrome/Edge/Brave)

  • ...\User Data\Default\Login Data
  • ...\User Data\Default\Cookies
  • ...\User Data\Local State

Firefox

  • ...\Profiles\<profile>\logins.json
  • ...\Profiles\<profile>\cookies.sqlite
  • ...\Profiles\<profile>\key4.db

Detection ideas (high signal)

  • Non-browser process accessing Login Data/Cookies/Local State
  • Archive creation from browser profile directories
  • Outbound transfer immediately following browser DB access
  • Identity alerts: new OAuth grants + mailbox rules shortly after sign-in

Response pivots

  • token/session revocation events
  • OAuth application consent history
  • mailbox forwarding rules + inbox rules + delegated access