PetitPotam attack allows Windows domain takeover

Windows[German]There is a new attack vector called PetitPotam. This enables a threat actor to launch an NTLM relay attack on domain controllers. Ultimately, this can be used to take over entire domains. Since many organizations run domain controllers with Microsoft Active Directory Certificate Services, a correspondingly large number of systems are likely to be at risk. Here is a short overview of what I know in the meantime.


Advertising

I already came across the issue on Thursday via the following tweet from Kevin Beaumont, but I haven't had time to go through it more intensively yet. The whole thing was made public on GitHub by French security researcher Gilles Lionel (alias Topotam).

PetitPotam-Angriff erlaubt Windows Domain-Übernahme

This night Lawrence Abrams on Bleeping Computer then took up the topic. So I'll try to briefly summarize the information.

Windows Domain Takeover with PetitPotam

Many organizations use Microsoft Active Directory Certificate Services, a public key infrastructure (PKI) server that can be used to authenticate users, services and machines in a Windows domain. Security researchers had come across a method to force a domain controller to authenticate to a malicious NTLM relay. That entity then forwarded the request over HTTP to a domain's Active Directory certificate services. Ultimately, the attacker receives a Kerberos ticket (TGT) that could be used to assume the identity of any device on the network, including a domain controller.

The only problem is to force a machine to authenticate to a remote server. One way would be to use the RpcRemoteFindFirstPrinterChangeNotification function of the MS-RPRN printing API. An attacker controlling a domain user/computer can use a specific RPC call to trigger the spooler service of a target it is running on and get it to authenticate to a target of its choice," Hacker.recipes reveals in a blog post.


Advertising

However, the attacker needs access to the domain (i.e., a compromised account) for this attack to work. This is because an RPC call in the SMB "pipe" via the IPC$ share is required for the attack to work. This vulnerability cannot be closed in principle and is enabled by default in all Windows environments, it says. Since this attack became known, many organizations have disabled MS-RPRN to block the attack vector.

On the other hand, if such an attack is successful, the attacker could take over the domain controller and execute any command, effectively taking over the Windows domain.

The PeitPotam PoC on GitHub

This is exactly what the PeitPotam PoC on GitHub seems to pick up on. Topotam writes that he provides a proof of concept tool that can be used to force Windows hosts to authenticate themselves to other machines via the MS EFSRPC function EfsRpcOpenFileRaw. This is also possible via other protocols and functions The tools posted on GitHub used the LSARPC named pipe with the inteface c681d488-d850-11d0-8c52-00c04fd90f7e because it is more widely used.

It is possible to trigger the vulnerability with the EFSRPC named pipe and the interface df1941c5-fe89-4e79-bf10-463657acf44d, he said. It does not need credentials for a domain controller to do so, he said. And disabling the Encrypting File System (EFS) service doesn't seem to mitigate the "feature."

Lionel posted on GitHub a proof-of-concept script for the PetitPotam technique, which can be used to force a domain controller to authenticate against a remote NTLM under the control of an attacker via the MS EFSRPC API. He then contacted Bleeping Computer, who rehashed the whole thing in the aforementioned article. Lionel is quoted by Abrams in the Bleeping Computer article as saying:

In my eyes, this is not a vulnerability, but an abuse of a legitimate function. A function that should not use the machine account for authentication, such as in the Printer bug.

Besides the attack by forwarding SMB authentication to an HTTP certificate enrollment server (For the purpose of completely taking over the domain controller), this PoC can also be used for other attacks. These include, for example, NTLMv1 downgrade and forwarding machine accounts to computers where that machine account is the local administrator (SCCM, Exchange Server, are examples where this occurs).

According to the security researcher, the only way to mitigate the issue is to disable NTLM authentication or enable protections such as SMB signing, LDAP signing and channel binding. Unfortunately, there is no known way to disable the use of EfsRpcOpenFileRaw to forward authentication requests. Stopping the EFS service does not prevent such attacks.

First assessments

I don't know anything about PetitPotam from Microsoft yet – Bleeping Computer had asked about it, but probably didn't receive an answer yet. Since the PoC has been published on Github, some security researchers have taken a look at it. Kevin Beaumont had already pointed out in the above linked tweet that this would be a big problem. Benjamin Delpy, who has disclosed some vulnerabilities in the print spooler service (PrintNightmare) in recent weeks, picks up on this in the following tweet.

Bleeping Computer cites this tweet from security researcher Rémi Escourrou (had even seen it, but didn't link to PetitPotam based on the image used).

PetitPotam-Einschätzung

Here the security researcher describes some necessary steps. In discussion with other users, someone here points out that in their default configuration domain controllers are not allowed to use workstation templates. Then the approach used by the tester doesn't seem to work. But there are other ways for the attack.

I myself do not have the knowledge to definitively classify the whole thing, especially since I have no activities in the field of AD administration. In the above text, however, the most important sources and assessments of security researchers are summarized, so that affected administrators can make up their own minds. Whether and when the whole thing will be exploited for the first time, we have to wait and see.


Cookies helps to fund this blog: Cookie settings
Advertising


##1

This entry was posted in Security, Windows and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *