Background
In our previous blog post, we talked about the recently-published DFSCoerce utility which is useful for forcing NTLM or Kerberos authentication by interacting with the Distributed File Service (DFS) over Remote Procedure Calls (RPC) on Windows. This forces the victim to authenticate into the attacker’s machine, very much like authentication coercion tools like PetitPotam and SpoolSample. The coerced authentication would then yield victim’s hashes which the attacker can then use to crack or relay to move laterally within the network and escalate privileges.
Praetorian has been actively leveraging DFSCoerce to elevate privileges within customer environments during red teams and penetration tests for various real-world client environments.
We have covered how to detect forced authentication attacks from DFSCoerce. Let’s talk about how attackers in the real world may utilize this tool, coupled with a bunch of other techniques, to gain elevated access into networks.
How to leverage DFSCoerce
DFS runs on default in Windows Active Directory environments, because domain controllers use it to communicate SYSVOL shares. While DFSCoerce is not a major vulnerability in itself, since it requires certain other configurations to be insecure in order to be leveraged, it can be a very dangerous helper in advancing through many different attack paths. Many primitive attack paths that are security vulnerabilities on their own also could work with DFSCoerce. This tool leverages the existing vulnerabilities within the Active Directory environment, such as disabled LDAP and SMB signing, while NTLMv1 remains in use along with Active Directory Certificate Services (ADCS) web enrollment misconfigurations.
To use the tool, the attacker must possess a valid set of domain user credentials in order to force authentication from the domain controller or any high-privileged target account. The success of leveraging DFSCoerce also relies heavily on the default NTLM authentication configuration within Windows Active Directory.
Possible Attack Paths
ADCS Web Services Relaying
Relaying attacks can be directed towards Active Directory Certificate Services (ADCS) Web Services in order to request default “Domain Controller” certificates. This relaying path requires the ADCS Web Enrollment to be enabled by browsing to the default web endpoint for the ADCS Web Enrollment, where users can sign in with domain credentials to request certificates – “<Certificate Authority server >/certsrv/certfnsh.asp”. If there is indeed a login portal for a user to request a certificate from the server, the ADCS environment most likely is vulnerable to this relaying attack.
From here, the attacker can utilize Impacket’s ntlmrelayx.py script to relay NetNTLMv1/NetNTLMv2 to ADCS Web Enrollment endpoint to obtain the default Domain Controller certificate once authentication is forced on the domain controller from DFSCoerce with valid low-privilege user credentials. After completing the NTLM relay, the attacker can obtain the base64 encoded blob for the domain controller. They then can use utilities like PKINITTools to obtain the Kerberos Ticket-Granting-Ticket (TGT) when passed through PKINIT. PKINIT is a Kerberos pre-authentication mechanism to authenticate to Kerberos Key Distribution Center (KDC) which grants the TGT. Once an attacker obtains the TGT for any of the domain controllers, they then can leverage it to create Silver and Golden Tickets to ensure persistent access into the network. This approach essentially gives the attacker complete control over the Active Directory domain.
Praetorian recently used this technique in a real-world internal penetration test to force authentication from the Domain Controller, and relayed NTLM to ADCS web services. We eventually obtained the Kerberos Ticket-Granting-Ticket (TGT) for the domain controller account, which gave Praetorian full control over the domain. [NOTE: Praetorian does not recommend leveraging this attack path in the real world as it could lead to unwanted remaining access into internal networks.]
For more information and technical details on how to exploit this relaying attack, see this article. Official Windows advisory for mitigating relaying attacks into ADCS Web Services also recommends enabling Extended Protection on Web Services and Enrollment as well as disabling HTTP connections with enabling SSL.
NTLMv1 Downgrade Attacks
An attacker can also leverage DFSCoerce (or another forced authentication primitive) to trigger an NTLM authentication over SMB from a victim computer account to an attacker-controlled SMB server. The malicious SMB server then can request that the client downgrade to the legacy NTLMv1 authentication protocol. This will only work if the client is configured to support NTLMv1 authentication through the LmCompatabilityLevel setting. Surprisingly, support for NTLMv1 authentication is still enabled within many environments, which is unfortunate since the security of NTLMv1 is fundamentally dependent on the security of the DES encryption algorithm which leverages 56-bit keys that can be cracked with modern hardware.
Authentication using NTLMv1 occurs through a challenge response protocol where the client encrypts a challenge sent by the server using the DES encryption algorithm. We accomplished this by splitting the client’s NTLM hash into three separate 56-bit DES keys. We generated the first key using bytes one through seven of the NTLM hash, the second key using bytes eight through fourteen, and the third key using the remaining fifteenth and sixteenth bytes padded with five zeros at the end. The three DES keys each separately encrypt the server challenge, and the three corresponding ciphertext blocks concatenate to obtain a twenty-four byte value. The client sends this value, the NtChallengeResponse, to the server as part of the NTLM AUTHENTICATE_MESSAGE to complete authentication.
Figure 1 shows an excerpt from the NTLM specification detailing how the three DES keys are generated, used to encrypt the server challenge, and then concatenated to return a twenty-four byte value.
Figure 1: An excerpt from the NTLM specification detailing how the victim’s NTLM hash generates three DES keys which then encrypt the same piece of data.
Now, we must figure out how to crack these DES keys to obtain the victim’s original NTLM hash. The third key is trivial to crack since it only contains two bytes of entropy. The first and second key appear to pose a bit more of a challenge as this requires cracking the full 56-bit DES keys. However, using a free service called “crack.sh” this is actually much easier than we originally thought. The creators of this service have created a rainbow table of all the possible NTLM hashes corresponding to an encrypted ciphertext challenge for a server challenge of 1122334455667788. As an attacker, we can have our malicious NTLM implementation always return a fixed server challenge of this value. We then can submit the obtained NtChallengeResponse value to the crack.sh service to obtain the client’s original NTLM hash.
For example, during a recent internal penetration test, Praetorian leveraged DFSCoerce to obtain an NTLMv1 NtChallengeResponse value from a domain controller. We then could have brute forced it using the crack.sh service to obtain the domain controller’s computer account’s NTLM hash. Praetorian could have then leveraged the obtained NTLM hash to perform a DCSync attack and compromise the customer’s Active Directory domain. Matthew Creel has an excellent article titled “Elevating with NTLMv1 and the Printer Bug” which describes in detail the step by step process required to use this method. [NOTE: Praetorian does not recommend submitting anything other than dummy data from a lab environment to this service to avoid exposing the NTLM hash of the victim user or computer account to a third party. Currently, we are investigating alternative methods of performing this attack that do not rely on a third-party service.]
Workstation Compromise Leveraging RBCD
In instances where the WebClient service runs on a remote host, Praetorian has been able to leverage these forced authentication primitives, such as the PetitPotam primitive, to obtain remote code execution. We have accomplished this by triggering an HTTP NTLM authentication from the victim computer account and then relaying this authentication to the LDAP service (assuming signing and channel binding are not set to required). We subsequently configure resource based constrained delegation using LDAP, and compromise the underlying system by requesting a TGS ticket for a user with administrative privileges to the victim computer. A GitHub gist published by gladiatxOr called “From RPC to RCE – Workstation Takeover via RBCD and MS-RPChoose-Your-Own-Adventure” describes the process for exploiting this issue in detail.
Computer AdminTo Computer Attacks
Praetorian also frequently encounters scenarios where computers are granted administrative rights to other computer accounts within Active Directory. In this scenario, Praetorian often can leverage a forced computer account authentication primitive to perform a relaying attack between these computers to gain additional access within the environment. Praetorian has previously published a two part series on this topic (Part 1, Part 2).
Exploiting Kerberos Unconstrained Delegation
Praetorian also has leveraged various authentication primitives, such as the PrinterBug method, to elevate privileges to domain administrator after compromising a system with Kerberos unconstrained delegation enabled. We did this by leveraging the forced authentication primitive to induce the client into authenticating to an attacker controlled SMB server using Kerberos authentication. Since the computer account supported unconstrained delegation, the victim computer sent a copy of its TGT when authenticating to the attacker system. The attacker then can leverage the victim’s TGT to authenticate as that system.
When exploiting this issue, we commonly compromise a system with unconstrained delegation enabled and then induce a domain controller into authenticating to the compromised system. This then allows Praetorian to obtain a TGT for the domain controller which we then can leverage to perform a DCSync attack and compromise the entire Active Directory environment. Riccardo Ancarani has published an article titled “Exploiting Unconstrained Delegation” that does an excellent job of describing the process of how an attacker can exploit this issue within a real world environment.
Recommendations & Next Steps
Much like we have discussed in our detection article, the best way of securing your internal network is through prevention, which you can achieve with accurate and timely detection. Praetorian recognizes disabling NTLM authentication could present business and technical challenges to companies. Until your organization can disable NTLM, the best course of action is to detect and alert on any anomalous attempts to add or remove DFS namespaces. For more detailed information on what events and triggers to look out for in logs, check out our previous blog post on MS-DFS detection.
Keep in mind that DFSCoerce does not exploit a vulnerability in itself, but leverages existing network misconfigurations to relay and steal hashes. The best way to prevent authentication coercion is to eliminate the underlying vulnerabilities by requiring Extended Protection on Active Directory Certificate Services Web Services or disabling it entirely, requiring LDAP and SMB signing, disabling NTLMv1 authentication, and limiting Kerberos unconstrained delegation.
