Detecting and Mitigating Browser Session Hijacking (T1185)

Multi-factor authentication protects the login. It does not protect a session that is already open. T1185, Browser Session Hijacking, is the technique of taking over a user's live browser. MITRE files it under the collection tactic for Windows.

How attackers use it

MITRE describes adversaries using vulnerabilities and normal functions in browser software to change content, change user behavior and intercept information. Two cases are named.

• Injection to inherit the session. Software is injected into a browser so it inherits the user's cookies, HTTP sessions and SSL client certificates. The browser then becomes a way to pivot into an authenticated intranet. This may need specific process permissions, such as SeDebugPrivilege or high integrity, administrator rights.
• Proxy pivoting. Traffic from the adversary's browser is routed through the user's browser by a proxy that redirects web traffic. This does not change the user's own traffic, and the connection ends as soon as the browser closes. The adversary takes on the security context of whichever browser process holds the proxy.

Browsers usually create a new process per tab, with permissions and certificates separated, so the process matters. With those rights, an adversary could potentially browse to any intranet resource the browser can reach, such as SharePoint or webmail. MITRE adds that browser pivoting may bypass the security provided by two-factor authentication, since the user already passed it.

The MITRE page lists many tools and families that do this, including Cobalt Strike, Dridex and QakBot.

How to detect it

MITRE's strategy for Windows is a chain:

1. The adversary gains high integrity or special privileges, for example SeDebugPrivilege.
2. They find a running browser process and open it with write or inject rights.
3. They modify it, for example with CreateRemoteThread or a DLL load, to inherit cookies and tokens or set up a pivot.
4. Optionally, they create a new logon session or use explicit credentials and drive the victim browser to intranet resources.

Useful telemetry on Windows:

• Process access (Sysmon event ID 10). One process opening a browser process with rights that allow memory writes or thread creation.
• Remote thread creation (Sysmon event ID 8). A thread created in a browser process by another process.
• Image loads (Sysmon event ID 7). Unexpected DLLs loaded into the browser.
• Privilege use (Security event 4672 and 4673). Special privileges assigned to a logon, and use of sensitive privileges, which include SeDebugPrivilege.
• Intranet side. Requests to internal apps from a user session at odd hours or in patterns the user does not show, such as bulk browsing of document libraries.

Your browser vendor's own process names change over time, so build the list of browser executables from your endpoint inventory, not from a guess.

How to reduce the risk

MITRE lists two mitigations.

1. Close browser sessions regularly, and when they are no longer needed. A hijack needs a live session, so shortening session life shortens exposure. Shorter session lifetimes on sensitive apps and re-authentication for sensitive actions back this up.
2. Restrict user permissions. Browser pivoting needs a high integrity process to launch from. Limiting rights, and closing off privilege escalation paths including User Account Control bypasses (T1548.002), reduces exposure.

These point to a broader rule. Standard users with no local administrator rights make this much harder, and administrators should use separate accounts, and ideally separate machines or browsers, for admin work.

Check your own environment

Windows, read-only:

whoami /priv
whoami /groups

Run these in an ordinary session and an elevated one. If the everyday account shows SeDebugPrivilege enabled, find out why.

Review as a team:

• Do daily users have local administrator rights? Count them.
• Is Sysmon or an endpoint product recording process access and remote thread creation against browser processes?
• Which internal apps rely on the browser session alone, with long-lived cookies and no re-authentication for sensitive actions?
• Do admins browse the web from the same account they use for administration?
• Are client certificates, which a hijacked browser can use, stored so that the browser can use them without a prompt?

Quick check

Sources

• MITRE ATT&CK, T1185 Browser Session Hijacking