Last updated
Last updated
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.
