Topic starter
06/11/2026 6:36 pm
TL;DR: NTLM relay SOCKS workflows can break down in browsers because HTTP requests are parallel, stateful, and often kernel-authenticated, making web apps like password vaults fragile even after relay succeeds, according to SpecterOps. The control assumption is wrong: a relayed session is not necessarily browsable or reusable like a command-line socket.
Editorial analysis by NHI Mgmt Group, based on content published by SpecterOps: “ghostsurf: From NTLM Relay to Browser Session Hijacking”.
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.
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.
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.
Practitioner guidance
- Map browser-accessible privileged portals separately Inventory web apps that rely on Windows authentication, especially vaults, admin consoles, and internal management portals.
- 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.
Bottom line: Browser-mediated NTLM relay can expose privileged web portals even when the same technique fails cleanly against command-line tools.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:42 pm
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.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Browser session hijacking exposes NTLM relay limits in web apps