There and Back Again: An Operators Guide on NTLM Relaying Egress

There and Back Again: An Operators Guide on NTLM Relaying Egress
SpecterOps specialists have published a practical guide on the NTLM Relay technique for situations where a conventional attack is impossible due to infrastructure constraints. The researchers propose using outbound NTLM authentication (egress) and a cloud node as an intermediary for receiving and then relaying traffic back into the internal network.
What is the idea? A conventional NTLM Relay attack usually requires the attacker to be on the same network as the target or to be able to receive SMB/WebDAV traffic locally. When operating through C2, this is often impossible: there may be no L2 access, local administrator privileges, or the relay attack may be blocked by a firewall.
The authors propose the following attack chain: • forcing an SMB or WebDAV NTLM authentication attempt; • sending this authentication to an external network; • receiving the traffic on a controlled cloud server; • forwarding the traffic through an SSH tunnel to the Red Team infrastructure; • returning the NTLM session through a SOCKS proxy to the internal network and performing the relay attack against the target service.
Where is this especially effective? The authors examine the two most common scenarios:
  1. AD CS Web Enrollment (ESC8) — relaying authentication to an HTTP endpoint on a certificate authority without Extended Protection for Authentication (EPA), making it possible to obtain a certificate on behalf of a computer or user and then use PKINIT to compromise the account.
  2. LDAP/LDAPS — when LDAP Signing or Channel Binding is not enabled, WebDAV authentication can be relayed to a domain controller, enabling local or domain privilege escalation. To bypass network restrictions, WebDAV over TCP/443 is used because it is much more commonly allowed for outbound traffic than SMB over 445/TCP.
Vendors
Specterops
Products
Ad Cs