Browser session hijacking exposes NTLM relay limits in web apps

At a glance

What this is: NHI Mgmt Group's analysis, drawing on SpecterOps's blog post: NTLM relay against browser-based web applications can fail because parallel HTTP requests, session handling, and kernel-mode authentication break the assumptions behind SOCKS relays.

Why it matters: IAM and security teams need to understand when browser-based access paths preserve or destroy replayable identity state, because privileged web portals can still be reachable through relayed machine and user sessions.

Context

NTLM relay is not just a transport trick. In browser-driven access flows, the real issue is that authentication state and application state are often coupled in ways that make replay fragile, especially when the target relies on Windows authentication and privileged web interfaces. This creates a governance problem for privileged access management when the application is also the path to secrets.

The source scenario centres on internally hosted web portals that users and admins access through a browser, not a command-line tool. That distinction matters because a relayed session can look valid while still failing under browser concurrency, header handling, or kernel-mediated authentication checks.

The practical lesson is that browser-based access to privileged web apps has to be treated as a distinct identity path, not as a variant of SMB or MSSQL relay. The control surface changes from simple socket reuse to session binding, request ordering, and how the application evaluates authentication on each request.

Key questions

Q: How do attackers use NTLM relay attacks?

A: Attackers use NTLM relay attacks to capture an NTLM authentication attempt and relay it to another service that accepts the same authentication. This lets them authenticate as the victim without cracking the password. Defenders should prefer protocols that resist relay, require signing where supported, and reduce places where NTLM authentication is accepted.

Q: Why does cookie replay fail on some Windows-authenticated web apps?

A: Cookie replay fails on many Windows-authenticated web apps because the browser session is bound to the underlying Kerberos or NTLM logon, not just the cookie. If the app uses integrated authentication, channel binding, server-side session state, or revalidation against the Windows security context, a copied cookie will not recreate the original user or delegated token.

Q: How should teams handle privileged web portals that use NTLM authentication?

A: Treat privileged web portals that use NTLM authentication as high-risk access paths and move them behind stronger controls such as MFA, device trust, IP restriction, PAM checkout, and, where possible, Kerberos or modern federated sign-in. NTLM offers weak phishing resistance and limited session assurance, so privileged access through it should be tightly scoped, logged, and retired where feasible.

Q: What should defenders do when browser relay sessions stay active too long?

A: Defenders should shorten session lifetime, bind the session to the device or browser context, and force re-authentication for sensitive actions when browser-authenticated sessions stay active too long. Long-lived sessions increase the window for cookie theft, token replay, and unattended access, especially where the portal does not re-check identity or step up authentication.

Technical breakdown

Why browser concurrency breaks relayed HTTP sessions

Browser traffic is not a single linear exchange. Modern browsers open multiple connections, request embedded resources in parallel, and retry aggressively when pages stall. NTLM over HTTP is connection-bound, so the authenticated session lives on a specific TCP socket. If a SOCKS relay hands multiple browser requests to one socket without coordination, responses can interleave and corrupt the stream. A design that works for single-threaded command-line tools can therefore fail when the client expects concurrent page loading and per-request independence. See the Token and Session Security Guide.

Practical implication: Treat browser-facing relay support as a concurrency problem, not just a credential-forwarding problem.

Why kernel-mode authentication changes the replay model

With kernel-mode authentication enabled, HTTP.sys evaluates Windows authentication before the web application sees the request. That means the application cannot rely on a harvested cookie to bypass the underlying NTLM challenge unless a separate app-layer session layer already exists. In practice, anonymous and Windows-authenticated paths can coexist, but protected paths may still force re-authentication at the kernel boundary. This is why some targets allow cookie replay while others only work if the browser is proxied through the live authenticated connection. See the Identity Provider and SSO Security Guide.

Practical implication: Check whether the site is authenticated at the application layer or at HTTP.sys before assuming session replay will work.

Why browser state and relay state drift apart

Browser sessions carry cookies, headers, and navigation expectations that command-line relay tools often strip or ignore. When the relay infrastructure treats the authenticated socket as the only state carrier, the browser can receive prompts or partial content that appear to indicate failure even when the relay succeeded. The deeper problem is that the browser, the relay proxy, and the web application each maintain different notions of session identity. When those models do not align, user experience becomes misleading and the access path becomes unstable. See the Session Hijacking and Cookie Theft Guide.

Practical implication: Preserve browser headers and bind browser context to a single relay session when testing NTLM-protected web apps.

Threat narrative

Attacker objective: The objective is to use a relayed privileged identity to browse a protected web portal and reach secrets or administrative functions without possessing the underlying password.

1. Entry occurs when the operator captures NTLM authentication through a relay position and obtains a privileged domain account session without cracking the credential.
2. Escalation follows when the relayed session is used against a browser-based privileged web application that expects connection-bound HTTP authentication and application-specific session handling.
3. Impact appears when the browser can reach the privileged portal and expose secrets, but the session becomes unreliable or collapses under concurrent requests or kernel-auth checks.

Breaches seen in the wild

• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser-based NTLM relay exposes a control assumption gap, not just a tooling gap. Relay workflows built around sequential request tools assume the client will serialize access to one authenticated session. Browsers violate that assumption by design, so the failure is structural rather than incidental. The implication is that teams should treat interactive web access over relayed identity as a distinct governance problem, not as a minor transport variant.

Kernel-mode authentication creates a hidden enforcement layer that many access reviews do not model. When HTTP.sys enforces Windows authentication before the application layer, the visible portal and the real identity boundary are not the same thing. That means a privileged web app can appear session-friendly while still rejecting replay at the kernel boundary. Practitioners need to understand that the effective control point may sit below the application they think they are governing.

Session replay becomes brittle when browser state, relay state, and application state diverge. The browser may carry cookies and headers, the relay may hold one authenticated socket, and the target may expect its own session lifecycle. That three-way mismatch is why some relayed web portals feel usable for a moment and then collapse. Identity governance for privileged web access has to account for state alignment, not just authentication success.

Privilege in browser-accessible vaults is especially dangerous because the reachable blast radius is operational, not theoretical. Once a relayed session lands in a password vault or similar administrative portal, the attacker is no longer waiting for later lateral movement. The privileged interface itself becomes the access path to keys, secrets, and downstream systems. Treating that portal as ordinary web access understates the identity blast radius that follows a successful relay.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Read next: Token and Session Security Guide

What this signals

Identity blast radius now includes browser-mediated privileged access. When a relayed session can open a vault or admin console, the meaningful unit of control is no longer the password alone. It is the combination of session binding, request ordering, and the amount of privilege exposed through the browser path. Teams should expect privileged portals to be tested as access pathways, not just as applications.

Access reviews often miss this class of exposure because they are built around stable accounts and durable entitlements. A relayed browser session is transient, but the impact is immediate if it reaches a portal that exposes secrets or administrative actions. The control question is not whether the identity exists, but whether the session can be safely constrained before it becomes a broad access bridge.

Session-bound access is the real boundary: once browser state, relay state, and application state disagree, the operating assumption behind replay collapses. That means teams should watch for authentication models that depend on invisible implementation details such as kernel-mode checks, because those details determine whether a privileged session can be reused or must be treated as one-shot access.

For practitioners

• Map browser-accessible privileged portals separately Inventory web apps that rely on Windows authentication, especially vaults, admin consoles, and internal management portals. Classify them as browser-driven privileged access paths rather than generic web applications.
• Test for kernel-authenticated paths Validate whether protected endpoints are enforced by HTTP.sys or by an application session layer, because cookie replay and relayed browsing behave differently in each case.
• Preserve request context during relay testing Use tooling and lab setups that keep browser headers, session affinity, and request ordering intact so you can see whether the target really supports interactive browsing through a relayed session.
• Limit the secrets reachable from any one privileged portal Reduce the number of secrets, administrative functions, and downstream systems exposed through a single browser-authenticated account so a successful relay cannot collapse into broad vault access.

Key takeaways

• Browser-mediated NTLM relay can expose privileged web portals even when the same technique fails cleanly against command-line tools.
• The main failure mode is not just authentication, but state mismatch across the browser, the relay socket, and kernel-enforced web access.
• Privileged portals that surface secrets or admin functions need to be governed as high-blast-radius identity paths, not ordinary internal sites.

Related NHI Mgmt Group resources: Token and Session Security Guide · Privileged Access Management Guide · Identity Provider and SSO Security Guide · Session Hijacking and Cookie Theft Guide

Key terms

• NTLM Relay: NTLM relay is an attack technique where an authenticated challenge-response session is captured and forwarded to another service that accepts it as legitimate. The attacker does not need the password itself, only a reusable authentication exchange that the target will trust.
• Kernel-Mode Authentication: Kernel-Mode Authentication is authentication handled by the operating system kernel rather than by user-mode code. It is used to validate logon credentials and establish a security context before user processes run, which can affect how tokens, sessions, and integrated sign-in are enforced.
• Session Binding: A control that ties an authenticated session to the device, connection, or risk context that created it. When applied well, it makes stolen cookies harder to reuse from an untrusted endpoint or a different network context.
• Browser Session Hijacking: Browser session hijacking is the theft or misuse of an active web session so an attacker can act as the authenticated user without knowing the password. Technically, it exploits session cookies, tokens, or browser state through malware, phishing, insecure networks, or cross-site attacks, bypassing normal IAM controls and user verification.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.