Offensive Security

Obtaining LAPS Passwords Through LDAP Relaying Attacks

Overview

Praetorian recently contributed additional functionality to the Impacket ntlmrelayx utility to support the dumping of Microsoft LAPS passwords through Lightweight Directory Access Protocol (LDAP) relaying attacks. This functionality is now available within the upstream Impacket master branch repository on GitHub. This article covers the motivation behind developing this functionality, provides usage instructions on leveraging this functionality, and provides actionable guidance on steps to detect as well as prevent these types of attacks.

LAPS Password Dumping Feature Motivations

During a recent red team security assessment, we installed a physical drop device within a conference room as part of a physical intrusion into an office building. Operators then remotely utilized the physical drop device to perform standard network spoofing and poisoning attacks, such as LLMNR/NBNS poisoning using Responder, to obtain domain user credentials in the form of NetNTLMv2 challenge-response hashes.

Immediately we noticed repeated authentications by a helpdesk user that was a member of the “Account Operators” ldap group within Active Directory. The organization leveraged this built-in group to allow helpdesk users to reset passwords for user accounts. In this case, we had repeated HTTP authentication attempts using NetNTLMv2 challenge-response authentication from a user within the “Account Operators” group [1]. From previous experience, we knew that users in the “Account Operators” group by default have read and write access to the majority of computer account object attributes within Active Directory, including the “ms-MCS-AdmPwd” attribute. The “ms-MCS-AdmPwd” contains the local administrator password for the computer in environments where LAPS is deployed.

Unfortunately, attempts to crack the captured NetNTLMv2 hash were unsuccessful. However, we realized that since the authentication attempt was over HTTP as opposed to an SMB session, it was possible to relay this account credential to the LDAP service on a domain controller. Normally relaying SMB to LDAP is not possible due to the NTLMSSP_NEGOTIATE_SIGN attribute sent within the MIC attribute during NTLM authentication using SMB [4]. Since this capability to dump LAPS passwords did not presently exist within ntlmrelayx, we decided to add this functionality to the tool.

Why is this Tool Useful?

Systems administrators commonly deploy the LAPS solution to mitigate the risk of local administrator password reuse. For example, in network environments where the local administrator password is reused, it is often possible for an attacker who has compromised a single system to perform a pass the hash attack to compromise other hosts leveraging the same local administrator password. The Local Administrator Password Solution (LAPS) is a free solution provided by Microsoft that addresses this vulnerability by assigning a unique password to every computer that is automatically rotated. This password can then be queried by IT personnel assigned access to these passwords via LDAP.

An attacker that is able to trick an IT administrator into authenticating to their malicious HTTP service via NetNTLMv2 could relay this authentication to the LDAP service to dump any LAPS passwords readable by the relayed user. This would allow the attacker to then compromise those systems.

Using the Modified NTLMRelayX Tool

In this section we cover the usage instructions for the added LAPS password dumping functionality within Impacket. On a Debian or Ubuntu-based system, the following commands can be used to install Impacket.

sudo apt -y install build-essential git python3 python3-pip
git clone https://github.com/SecureAuthCorp/impacket.git
cd impacket
sudo pip3 install -r requirements.txt
sudo python3 setup.py install

Now that Impacket has been installed, we can use the command given below to launch ntlmrelayx. In this instance, we are targeting a domain controller at 192.168.184.154. We specify the “–dump-laps” option to specify that for any accounts we successfully relay to the LDAP service, we should attempt to dump any LAPS passwords that are readable by that particular user.

sudo python3 examples/ntlmrelayx.py - t ldaps://192.168.184.154 --dump-laps

The image given below shows the expected output upon starting the server.

We then trigger a NetNTLMv2 authentication from the “helpdesk” user over HTTP and relay the authentication to the LDAP server on a domain controller. As you can see in the image below, the “contosohelpdesk” user is relayed successfully and used to dump the LAPS password of a single computer account within Active Directory.

The dumped passwords were written to a file named “laps-dump-$USERNAME-$RANDOMNUMBER. In this case, the file is called “laps-dump-HELPDESK-30372”. The image below shows the format of the dumped LAPS passwords when written to disk.

Executing the Attack Through Beacon

Some interesting operational issues arise when attempting to leverage this type of capability through a “beacon” agent or a “reverse shell” type implant as opposed to a full-fledged Linux system. Running ntlmrelayx requires that Python, along with the necessary Python package dependencies, are installed. Additionally, tooling written in C# or PowerShell that is easier to deploy typically lacks the breadth of functionality available within Impacket’s ntlmrelayx.

A novel solution exists that allows an operator to run ntlmrelayx through Cobalt Strike or another implant installed on a Windows machine without requiring Python or other tools to be installed on the host. This solution works by installing a device driver such as the WinPCAP driver to capture layer two traffic sent to the compromised host’s network interface card. Layer two traffic gets transported over the internet to the L2 pivoting server. Next, the pivoting server exposes a virtual network interface card to link the L2 connection with the physical NIC on the compromised host.

Ultimately this allows the attacker to utilize standard Python or Linux-based tooling such as Impacket’s ntlmrelayx through a compromised windows host. Raphael Mudge, the creator of Cobalt Strike, has several blog posts discussing his implementation of Layer 2 pivoting titled “Covert VPN – Layer 2 Pivoting for Cobalt Strike” [3] and “How VPN Pivoting Works (with Source Code)” [2] respectively. These posts are invaluable for those looking to leverage L2 pivoting during a red team exercise.

Mitigations and Detection

Several non-default Active Directory security settings can be enabled to mitigate the risk of LDAP relaying attacks. According to an article by Preempt titled “New LDAP & RDP Relay Vulnerabilities in NTLM” [6], it is possible to mitigate this attack by enabling the “Require LDAP Signing” option via Group Policy. When enabling this option, careful testing is required to ensure that issues do not arise due to issues with third-party applications that do not support LDAP signing.

Another option to address this issue is to implement controls to ensure accounts that are members of privileged groups cannot authenticate using NTLM authentication to an attacker-controlled host. One way to implement this in Active Directory domains with a functional level of Windows Server 2012 R2 or higher is to place these users into the “Protected Users” ldap group [7]. According to an article by Microsoft titled “Protected Users Security Group” [8] members of the “Protected Users” group are not allowed to authenticate using NTLM based network authentication. Placing the privileged helpdesk user accounts into the “Protected Users” group would have prevented these accounts from being tricked into authenticating to an attacker-controlled host using NTLM authentication. Instead, only the Kerberos authentication protocol would be utilized for authentication with the NTLMv2 fallback mechanism disabled. The one caveat with this approach is that the Kerberos protocol relies on service principal names (SPNs) for authentication. In some cases disabling the NTLMv2 network authentication protocol will break authentication when an IP address or DNS alias is specified that cannot be mapped back to the appropriate SPN by the client.

Marina Simakov and Yaron Zinar outline an ingenious method for detecting NTLM relaying attacks in their presentation titled “Finding a Needle in an Encrypted Haystack” [9]. During NTLM challenge-response authentication, the client sets a “Target Name” attribute that is protected by the “NTProofStr” attribute such that an attacker cannot modify this attribute. An agent can be installed on domain controllers to monitor for NTLM authentication requests, and it can compare the “Target Name” attribute with the host sending the authentication response to the domain controller. If these hosts differ, a relay attack is detected, and the solution can then block the authentication. This process is shown in a diagram given below, taken from slide 49 of their fantastic presentation. The Preempt Active Directory monitoring solution supports this functionality by leveraging an agent-based solution to monitor traffic destined for domain controllers according to a recent post on the Preempt blog [5].

Conclusion

The application of LDAP relaying and other L2 poisoning attacks provides a unique set of capabilities to red team operators. The difficulty in leveraging these techniques in practice often arises due to the difficulty of leveraging these tools through a reverse shell or “beacon” implant on a Windows machine. L2 pivoting serves as a sort of “compatibility layer” allowing these tools to be bridged into the network of a target through a “reverse shell” or “beacon” agent.

Because of the scope of the privileges assigned to built-in Active Directory groups, the usage of these groups can lead to unintended consequences when system administrators do not fully understand the permissions assigned to these groups. An administrator might not realize that assigning a helpdesk user account to the “Account Operators” group gives these users the privileges required to access the local administrator passwords for a large number of computers.

Additionally, penetration testers and red team operators can now leverage Impacket’s ntlmrelayx to dump cleartext LAPS passwords, without requiring the plaintext password for the relayed account, by relaying the NTLM authentication protocol in scenarios where “LDAP Signing” is not enforced.