🔨LDAP Relay
Description
LDAP Relay attacks make use of NTLM authentication where an NTLM authentication request is performed and an attacker captures the credentials and relays them to a Domain Controller and leverages this against LDAP.
By default without LDAP signing and channel binding this attack is possible.
Scenario #1 [ntlmrelayx]
Domain Controller - 10.10.10.10 - Windows Server 2019
Admin-PC 10.10.10.7 - Windows 10 21H1
Attacker-PC 10.10.10.6 - Kali Linux
We already have credentials for the user Dave
This scenario also assumes we have valid credentials for a Domain user.
Attacker-PC
Firstly, ntlmrelayx.py it started on the attacking machine with the --escalate-user switch.
Admin-PC
Through means of phishing or placing a malicious file locally from some other method we are able to trick the Domain Administrator user who is currently logged into Admin-PC into browsing to http://10.10.10.6/.
Attacker-PC
Where credentials are requested and the Domain Administrator successfully submits them. ntlmrelayx.py receives the credentials and relays them to the Domain Controller on 10.10.10.10.
Successfully giving the user Dave DCSync rights which can be used to dump hashes for the Domain with secretsdump.py.
The hashes can then either be taken for password cracking or can be used for authentication. By default Domain Contollers run the WinRM service on port 5985. This can be used alongside Evil-WinRM to authenticate with hashes.
Below is a example of the dumped hashed for the Domain Administrator being used for access over WinRM to the Domain Controller DC01.
Scenario #2 [Intercept-ng]
Domain Controller - 10.10.10.10
Admin-PC - 10.10.10.7
Attacker-PC 10.10.10.5
Attacker-PC
This first example shows the LDAP Relay attack using Intercept-ng on a Windows 10 host. Intercept-ng is started on the system Attacker-PC and an administrator PC 'Admin-PC' is quickly identified.
The system is then added to the target list on Intercept-ng. From here Expert mode is then used on Intercept-ng to enable LDAP relay and enter the Domain name as shown below.
Then under the MiTM options LDAP relay is checked and the Domain Controller and Gateway fields are populated with the expected information.
From here the MiTM attack is started and active sniffing begins. As shown below we are given the Inject URL which is http://Attacker-PC:62222/.
Admin-PC
Through means of phishing or placing a malicious file locally from some other method we are able to trick the Domain Administrator user who is currently logged into Admin-PC into browsing to http://Attacker-PC:62222/.
Attacker-PC
Once this Domain Administrator on Admin-PC clicks the malicious link we see Intercept-ng relays the credentials to the Domain Controller and creates a new user called 'cepter'.
Domain Controller - DC01
Over on our Windows Server 2019 Domain Controller we now see the user 'cepter' exists and is a member of the Domain Admins Group.
Limitations
Unfortunately though this method Intercept-ng is unable to create the new user account with a password. One way which this can be leveraged however is through connecting to an RDP session to provide the opportunity for a password reset.
Changing the password from here will provide the new Domain Administrator account with a valid password we can use across the network. The limitation in this regard is that Remote Desktop Network Level Authentication needs to be disabled on the RDP host as shown below.
Mitigations
LDAP Channel Binding
[WIP]
LDAP Signing
LDAP signing is the digital signing of LDAP traffic by the source. The digital signing of LDAP traffic guarantees the authenticity and integrity of the contents of the LDAP traffic has not been altered in transit and allows the receiving party to verify the origin of the LDAP traffic. The LDAP signing configuration can be done by using specific group policies or by using registry keys. It is important to note that LDAP signing must be configured on both the domain controllers and clients:
How to set the server LDAP signing requirement Group Policy Object
Select Default Domain Controller Policy > Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies, and then select Security Options.
Right-click Domain controller: LDAP server signing requirements, and then select Properties.
In the Domain controller: LDAP server signing requirements Properties dialog box, enable Define this policy setting, select Require signing in the Define this policy setting list, and then select OK.
In the Confirm Setting Change dialog box, select Yes.
**How to set the client LDAP signing requirement by using local computer policy **
Select Local Computer Policy > Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies, and then select Security Options.
Right-click Network security: LDAP client signing requirements, and then select Properties.
In the Network security: LDAP client signing requirements Properties dialog box, select Require signing in the list, and then select OK.
In the Confirm Setting Change dialog box, select Yes.
How to set the client LDAP signing requirement by using a domain Group Policy Object
Select Default Domain Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies, and then select Security Options.
In the Network security: LDAP client signing requirements Properties dialog box, select Require signing in the list, and then select OK.
In the Confirm Setting Change dialog box, select Yes.
Verifying changes: Confirming with a simple Bind
How to verify configuration changes
Sign in to a computer that has the AD DS Admin Tools installed.
Select Start > Run, type ldp.exe, and then select OK.
Select Connection > Connect.
In Server and in Port, type the server name and the non-SSL/TLS port of your directory server, and then select OK.
Note
For an Active Directory Domain Controller, the applicable port is 389.
After a connection is established, select Connection > Bind.
Under Bind type, select Simple bind.
Type the user name and password, and then select OK.
If you receive the following error message, you have successfully configured your directory server:
Ldap_simple_bind_s() failed: Strong Authentication Required
Verifying changes: Attack perspective
Attempting the same attack again after the required Group Policy changes for LDAP signing have been made produces the following result on the attackers system.
Resources:
Last updated
