NTLM Relaying to ADCS HTTP Endpoints
AD CS services support HTTP enrolment methods and even includes a GUI. This endpoint is usually found at http[s]://<hostname>/certsrv.
\
\
If NTLM authentication is enabled, these endpoints are vulnerable to NTLM relay attacks. A common abuse method is to coerce a domain controller to authenticate to an attacker-controlled location, relay the request to a CA to obtain a certificate for that DC, and then use it to obtain a TGT.
An important aspect to be aware of is that you cannot relay NTLM authentication back to the originating machine. We therefore wouldn't be able to relay a DC to a CA if those services were running on the same machine. This is indeed the case in the RTO lab, as each CA is running on a DC.
Another good way to abuse this primitive is by gaining access to a machine configured for unconstrained delegation.
We already have access to WEB as jking, but this is another way of achieving the same end.
\
To achieve this, we need:
PortBender on Workstation 2 to capture traffic on port 445 and redirect it to port 8445.
A reverse port forward to forward traffic hitting port 8445 to the team server on port 445.
A SOCKS proxy for ntlmrelayx to send traffic back into the network.
\
The ntlmrelayx command needs to target the certfnsh.asp page on the ADCS server.
\
Then force the authentication to occur from WEB to WKSTN-2.
\
The S4U2Self trick can be used to obtain usable TGS's to move laterally to it.
Last updated
