LDAP Bind Credentials - AD Credential Hunting
Short blog on LDAP Bind Credential hunting in and AD environment
In this blog we will take a look at how LDAP Authentication works in an AD Environment. Then we will learn what is LDAP Pass-Back attack is and how to perform the attack. Also we will setup our own rogue LDAP server to hunt for credentials.
To demonstrate our practical part, we will refer to the Tryhackme room called Breaching_AD. Although that room demonstrates many other techniques for credential hunting. For this blog we will focus on the LDAP Bind Credentials part.
What is LDAP ?
From the digital ocean page, LDAP, or Lightweight Directory Access Protocol, is an open protocol used to store and retrieve data from a hierarchical directory structure. Commonly used to store information about an organization and its assets and users, LDAP is a flexible solution for defining any type of entity and its qualities.
LDAP, or lightweight directory access protocol, is a communications protocol that defines the methods in which a directory service can be accessed. More broadly speaking, LDAP shapes the way that the data within a directory service should be represented to users, defines requirements for the components used to create data entries within a directory service, and outlines the way that different primitive elements are used to compose entries
LDAP operates on port 389
LDAP Authentication
LDAP authentication is similar to NTLM authentication. However, with LDAP authentication, the application directly verifies the user's credentials. The application has a pair of AD credentials that it can use first to query LDAP and then verify the AD user's credentials.
LDAP authentication is a popular mechanism with third-party (non-Microsoft) applications that integrate with AD. These include applications and systems such as:
Gitlab
Jenkins
Custom-developed web applications
Printers
VPNs
If any of these applications or services are exposed on the internet, the same type of attacks as those leveraged against NTLM authenticated systems can be used. However, since a service using LDAP authentication requires a set of AD credentials, it opens up additional attack avenues. In essence, we can attempt to recover the AD credentials used by the service to gain authenticated access to AD.
The process of authentication through LDAP is shown below
The steps are self explanatory. If you could gain a foothold on the correct host, such as a Gitlab server, it might be as simple as reading the configuration files to recover these AD credentials. These credentials are often stored in plain text in configuration files since the security model relies on keeping the location and storage configuration file secure rather than its contents
LDAP Pass-back Attack
One other very interesting attack can be performed against LDAP authentication mechanisms, called an LDAP Pass-back attack. This is a common attack against network devices, such as printers, when you have gained initial access to the internal network, such as plugging in a rogue device in a boardroom.
LDAP Pass-back attacks can be performed when we gain access to a device's configuration where the LDAP parameters are specified. This can be, for example, the web interface of a network printer. Usually, the credentials for these interfaces are kept to the default ones, such as admin:admin
or admin:password
. Here, we won't be able to directly extract the LDAP credentials since the password is usually hidden. However, we can alter the LDAP configuration, such as the IP or hostname of the LDAP server. In an LDAP Pass-back attack, we can modify this IP to our IP and then test the LDAP configuration, which will force the device to attempt LDAP authentication to our rogue device. We can intercept this authentication attempt to recover the LDAP credentials.
Practical Scenario #1
As mentioned above we will referring the Tryhackme room.
Here we will act as an adversary that has already breached inside the network. This is an assume breach scenario
Here is the AD map of the room
Domain name - za.tryhackme.com
For this scenario our target machine will be printer.za.tryhackme.com (highlighted in red) which is a network printer.
Navigate to http://printer.za.tryhackme.com/settings.aspx to find the settings page of the printer
Using browser inspection to check the credential
The printer website was at least secure enough to not just send the LDAP password back to the browser. So we have the username, but not the password. However, when we press test settings, we can see that an authentication request is made to the domain controller to test the LDAP credentials. Let's try to exploit this to get the printer to connect to us instead, which would disclose the credentials. To do this, let's use a simple Netcat listener to test if we can get the printer to connect to us. Since the default port of LDAP is 389.
Checking back the listener.
We can see that we didn't got any credential relayed to us. Instead we get "objectclass0�supportedCapabilities" error
Why the attack failed ?
The supportedCapabilities
response tells us we have a problem. Essentially, before the printer sends over the credentials, it is trying to negotiate the LDAP authentication method details. It will use this negotiation to select the most secure authentication method that both the printer and the LDAP server support. If the authentication method is too secure, the credentials will not be transmitted in cleartext. With some authentication methods, the credentials will not be transmitted over the network at all! So we can't just use normal Netcat to harvest the credentials.
Practical Scenario #2
To resolve the error above, we will need to create a rogue LDAP server and configure it insecurely to ensure that the credentials are sent in plaintext.
First we need to setup a rogue LDAP server.
There are several ways to host a rogue LDAP server, but we will use OpenLDAP for this example. Install the following
We will start by re-configuring the LDAP server using the following command
Make sure to press when requested if you want to skip server configuration
For the DNS domain name, you want to provide our target domain, which is za.tryhackme.com
Use this same name for the Organisation name as well
Provide any Administrator password
Select MDB as the LDAP database to use
Ensure the database is not removed when purged.
Move old database files before a new one is created.
Before using the rogue LDAP server, we need to make it vulnerable by downgrading the supported authentication mechanisms. We want to ensure that our LDAP server only supports PLAIN and LOGIN authentication methods. To do this, we need to create a new ldif file name it as olcSaslSecProps.ldif
The file has the following properties:
olcSaslSecProps: Specifies the SASL security properties
noanonymous: Disables mechanisms that support anonymous login
minssf: Specifies the minimum acceptable security strength with 0, meaning no protection.
Now we can use the ldif file to patch our LDAP server using the following.
We can verify that our rogue LDAP server's configuration has been applied using the following command.
Our rogue LDAP server has now been configured. When we click the "Test Settings" at http://printer.za.tryhackme.com/settings.aspx, the authentication will occur in clear text. If you configured your rogue LDAP server correctly and it will downgrade the communication.
To catch the credentials we can use tcpdump.
We can see that our rogue LDAP server has successfully fetched the password -> tryhackmeldappass@
Mitigation
Here are some mitigation to prevent the attack
Ensure you’re adequately preventing printer vulnerabilities by updating the printer software.
Develop a process in which vendors must get written consent to perform routine maintenance on your devices; nobody should be touching these hosts without your team being aware of the date and time of their arrival and departure from the building or network.
When the maintenance is complete, make sure your devices are hardened again with a strong administrator password.
Ensure service accounts are given only their minimum required privileges for operation. Avoid running them as Domain Admins or administrator user
Disable any necessary features on these devices that are not needed.
Avoid using insecure connection and use SSL encryption if the device supports that
Last updated