Background
In our previous post about the LDAP Firewall, we discussed how it can be used to prevent many forms of LDAP attacks. However, one attack type we didn’t touch on is the glaring issue of how LDAP is routinely used by attackers for internal discovery and reconnaissance. While there are methodologies out there aimed at detecting malicious LDAP recon, we believe they are severely lacking and impractical for most organizations.
To finally “leash” the various LDAP hounds (SharpHound, SOAPHound and many other tools), a new approach is needed, which we delve into in this post. We also provide a useful script to collect LDAP logs into csv file, along with a handy configuration template that can be used as a basis for creating better LDAP protections.
A Short Primer on LDAP Searches
The most common LDAP operation is the search operation. As the name suggests, it searches for an object in the directory, and returns certain attributes of the object to the caller. The parameters of the search operations are:
Base DN: what is the distinguished name used as a root of the search. Only child objects to this DN are searched.
Scope: suggests how “deep” in the LDAP tree the search goes, can be either base, one level or subtree.
Filter: can be used to filter objects based on some criteria.
Attributes: which object fields should be returned from the LDAP search.
It is important to note that there are infinite combinations of attributes, filters and base DNs to use when performing searches, which can yield the same results. For example, an LDAP search with a filter "(!(department=fakedepartment))" (“!” representing a NOT filter) will yield the same results as “(department=*)”.
Why the LDAP Hounds are Running Wild
The first thing an attacker does once a foothold is established inside a network is internal reconnaissance. Almost always, the domain controller is targeted as it contains a wealth of information – most of which is exposed via LDAP – including accounts, computers, services, groups, DNS data, GPO policies, CA data and much more. Attackers don’t need to develop special capabilities, as there is a wealth of methods and tools out there to get all the information they need. Some of the most popular tools are probably SharpHound and (recently) SOAPHound, but there are many other tools such as PowerView, AD Explorer, AD Recon, Adalanche, ldapsearch and more.
For defenders, the situation is reversed. Mitigating against LDAP recon is not trivial. The main difficulties organizations encounter when they try to mitigate such attacks are:
Unreliable telemetry from clients: client LDAP telemetry is not easy to collect, and is unreliable at best, as a compromised client cannot be relied upon to send credible LDAP telemetry.
Overwhelming telemetry from DCs: LDAP queries from domain controllers can be overwhelming. Collecting such logs may have a negative impact on performance, storing them and performing queries on of them may also be challenging to most organizations without the proper infrastructure.
Detections can be easily circumvented: Even when advanced security tools such as Windows Defender are deployed, their detection can be circumvented as shown by @domchell in Active Directory for Red Teams.
Detections are too late: once malicious LDAP activity is detected, whether by collecting the necessary LDAP logs, or by even planting decoy objects as described in this post, by the time a detection is made it is already too late. The attacker could already have compromised additional accounts and assets.
Doing it Better with the LDAP Firewall
LDAP Firewall is an open-source tool, developed by the Zero Labs team (join our Slack channel to discuss OSS with the community). It enables security teams to not only have a better audit of LDAP activity, but also create LDAP firewall rules to prevent LDAP attacks, including reconnaissance attacks. For more information about LDAP and the LDAP Firewall, please read our first post about LDAPFW.
Using the LDAP Firewall, we suggest a new approach for dealing with recon attacks, which is much better than colleting native LDAP logs or even using advanced security tools:
Granular Audit: the LDAP Firewall can be easily configured to capture only LDAP activity we deem interesting, the rest is discarded.
No Performance Impact: because the LDAPFW integrates directly into the LDAP service, there is no performance penalty.
Granular Protection: applying a least-privileges methodology for LDAP is challenging with native tools. The LDAP Firewall allows teams to set limitations on which operations and what data clients can access, based on the source IP, user (or group of users), and even based on the search parameters itself.
Client Agnostic: because the LDAPFW is installed on the DC, it does not rely on telemetry coming from clients, which could be compromised, unable to provide LDAP client data, or otherwise give unreliable information.
Hard to Bypass by Attackers: LDAP protections can rely on a baseline, making them much harder to circumvent. An attacker can easily make a mistake which will block their attack, giving the security team an edge.
Enough with the teasing, let’s pull up our sleeves and see exactly how this could be done.
Step 1: Ignoring Local Activity
If an attacker already controls your LDAP server, discovery is probably the least of your worries. We assume that discovery attacks are coming from remote IP addresses and from non-local accounts. We should caveat this by mentioning that in some situations – such as with SOAPHound – the Active Directory Web Services can be used to perform LDAP recon. In these cases, we will see unknown or a local IP address. We will take this into consideration when we build the LDAPFW configuration templates.
First, we start by filtering out local LDAP queries – preferably in a lab, where we can minimize noise. This will enable us to focus solely on the malicious activity VS normal remote LDAP activity (it may be surprising, but in some environments the local LDAP activities can surpass the remote ones). To do this we can use the following config template:
The above configuration will filter most local LDAP activities coming from system services using local system account or the local DC computer account. The remaining captured LDAP activities will be those coming from remote hosts.
Step 2: Fingerprinting Remote Malicious Activity
Now we can start capturing remote LDAP traffic coming from various malicious tools. In the lab, we ran SharpHound and SOAPHound to create fingerprints of their unique characteristics when they perform search operations.
We ended up with a lot of event logs in the application LDAPFW log on the host. To better analyze these logs without needing a SIEM or any other complicated log consumer, we used the following PowerShell script which can parse the LDAPFW log events and dump them into a CSV file, making data analysis simpler.
From what we observed in our lab, we noticed that SharpHound performs search operations with filters for samaccounttype=
It should be noted that there are significant limitations to fingerprinting. While it would work against anyone “blindly” using LDAP enumeration tools, it could be easily circumvented. Recompiling the tools with modified LDAP queries, or simply using tools which allow more granular control of the LDAP query would circumvent these protections.
Finally, note that the configuration is set to action: allow. Once we are convinced that our configuration is customized to our environment, we can change this to action: block to stop such attacks.
Step 3: Creating a Baseline
A not-too-sophisticated pen-tester or threat actor will find it trivial to circumvent these preventions. So how can we still protect against a more sophisticated enumeration attack?
First, we need to understand that in order to enumerate the directory, an attacker will need to “walk” this directory tree. This requires the attacker to perform search operations with a scope of either “one level” or “base”. Given this information, we can capture LDAP activity of only remote LDAP search queries for the “one level” and “subtree” scopes and create a baseline for those.
Capturing normal activity for the baseline could be done using the following configuration (of course, the DC name will depend on your environment):
By looking at remote LDAP activities in several environments, we noticed that the majority of user and computer accounts perform the same types of LDAP queries in these scopes. For example, windows hosts seem to keep searching for themselves with their sAMAccountName=
Final Step: Combining Approaches
Once we have a baseline of well-known LDAP queries, along with signatures of known malicious LDAP activities, we can combine them into a single configuration file for the LDAP Firewall. Because LDAP firewall rules take precedence based on their order in the configuration file, we need to put the known signatures first, and the baseline after.
From what we observed in several environments where the LDAP Firewall was deployed, we created a starting template which can be used as a basis. Please note that this template only audits potentially malicious activity and doesn’t block it. Once the configuration is validated, you can change the actions to block, so malicious activity is not only logged, but also prevented.
Be Unique, but Get Involved
Combining the experience of many security practitioners can make LDAP Firewall even more awesome. If you wish to help improve our template, or have code suggestions, please join our Slack channel to discuss ideas with the security community.
The power of community is important, but it is also important to customize your LDAP defenses with your own baselines. The more the defense is tailored to your environment, the harder it is to circumvent attackers.