Where This Started

On a recent assessment, the target environment used CyberArk Privileged Access Manager. The intended workflow for both users and admins was to browse to an internally hosted web interface where they automatically authenticated via windows logon session and copy-pasted passwords from the browser. We compromised a relay position and captured NTLM authentication for a privileged domain account (not crackable). If we could browse CyberArk as this user, we’d have access to every secret this account was provisioned, and could pivot deeper into the environment with our choice of a vast array of services. ntlmrelayx from the Impacket suite has a SOCKS proxy feature for scenarios like this.

After relaying NTLM authentication, it opens a SOCKS5 proxy that lets you route traffic through the authenticated session. This works well for protocols like SMB and MSSQL, where you can point tools like smbclient or mssqlclient through the proxy and attack the target interactively. But when we configured our browser’s SOCKS proxy and navigated to CyberArks’s web interface, we were met with confusion. Basic auth prompts, the connection would hang, partial responses came back corrupted, pages never fully rendered…after extensive searching and conversations with colleagues, a few experienced this but none had solutions. I spent time troubleshooting proxy settings, trying different browsers, and adjusting connection timing.

None of it helped. So I started reading the ntlmrelayx HTTP SOCKS plugin code to understand what was actually happening on the wire, and that’s where things got interesting. Before we dive into implementation, let’s take a look at some background.