TL;DR
Megan Nilsen and Andrew Schwartz of TrustedSec published a series of great blog posts dealing with detecting AD attacks using Windows audit logs. In their setup, they created a GPO to enable extra Windows log events, performed SACL configuration, and used Splunk to ingest the logs and write custom detection queries.
In this article, we wanted to see if we could build upon their research and move from detection toward prevention, using just the LDAP Firewall. Our goal is to eliminate the setup complexity and provide a solution that stops DACL-based attacks before they happen, instead of alerting on them after the fact.
We also encourage you to read our Leash the Hounds blog post, where we covered how to block the LDAP-based reconnaissance performed by the different BloodHound variants. Combining the approaches from that article with the configuration presented below will yield a tight LDAP security posture.
Background
In Windows, Discretionary Access Control Lists (DACL) are used to specify the principles (e.g. users, groups) that are allowed or denied access to an object. As AD environments keep changing (entities are added, permissions are modified, etc.), and because they are difficult to audit and control, DACLs often become stagnant and misconfigured.
Attackers often take advantage of this fact to perform lateral movement and/or privilege escalation. This is done as stealthy reconnaissance (for example, understanding which user is allowed to add members to a sensitive group), or more proactively (such as adding Key Credentials during a Shadow Credentials attack). DACLs are used in attacks such as DCSync, Kerberoasting, and Evil GPOs, and some commonly used tools that exploit them include BloodHound, PowerSploit, Powermad, and Impacket modules.
For more information about DACL-based attacks, check out the DACL Abuse article (and the mind map in particular) created by The Hacker Recipes.
What DACL Attacks Have in Common
Going over online resources about DACL attacks, we found that most of the attacks were based on performing LDAP requests for one of the following purposes:
Searching the entire schema and reading AD object attributes that contain sensitive information
Modifying an attribute of an existing AD object
Some examples of these include modifying the KeyCredentialLink attribute during a Shadow Credentials attack or sAMAccountName in a sAMAccountName spoofing attack, and reading LAPS passwords which are stored in the ms-MCS-AdmPwd attribute. We will not go over all the different attributes in detail (as Megan and Andrew already covered these in length for their blog posts), but instead, we will focus on how to configure the LDAP Firewall to detect and block any requests that attempt to make these changes illegitimately.
Protecting Against DACL Attacks with the LDAP Firewall
Our approach to blocking DACL-based attacks includes 3 main steps. First, we need to compile a list of the sensitive attributes used in attacks. Then, we set up an audit configuration to log suspicious LDAP requests, which allows us to better understand our environment. Once we figure out which of the logged LDAP requests are legitimate, we can move on to an active prevention configuration, making sure to add rules that allow legitimate sources to continue functioning correctly.
At the end of the article, we will also run some LDAP-based attack tools and demonstrate that our configuration is successful in blocking them.
Step 1 – Researching DACL Attacks
Our first step was to go over the attacks listed in the previously mentioned articles and create a mapping of each operation type and the attributes that are used with each one. TrustedSec’s articles were a useful starting point, as they have already done much of this work for us. For example, if we look at section 5.5 of their first article, they explain that this attack changes the path to a logon script (allowing for remote code execution) by modifying the scriptPath LDAP attribute. We will use this information later to add an LDAP Firewall rule that blocks remote modifications of this attribute.
For other DACL attack techniques, where clear documentation like this was not available, we needed to research further. This could be done either by reading the source code of the attack tools to find out which attributes are used or by manually running the tool in a lab with LDAP Firewall installed to see what queries were being generated. Let’s look at some examples of analyzing these attacks.
Reading the Source Code - GPO Abuse
A GPO Abuse attack allows for remote code execution by creating an immediate scheduled task that runs on remote hosts instantly. WithSecure Labs has a blog post that includes some details on how the SharpGPOAbuse tool works, but in this case, it was easier to follow the source code of the Python implementation of the tool (pyGPOAbuse). Here we can see the two attributes that are being modified (gPCUserExtensionNames and gPCMachineExtensionNames), which we can add to our list of Modify attributes to block.
LDAP attributes used in GPO Abuse attacks (pyGPOAbuse source code)
LDAP Firewall Auditing
For this stage, it is also useful to put the LDAP Firewall in full audit mode on a lab DC. This allows us to run the attacks in a lab environment and check the LDAPFW Event Logs to see what the queries look like. To achieve this, the following configuration can be used:
Note: the
As this configuration might generate a lot of events (especially search requests), it is only recommended for use in a lab environment. The first rule ignores local queries, as they are common and are less relevant to our purpose, and the second rule allows and audits all other operations.
Once we have this configuration running on our test DC, we can run some attacks and view the queries being generated in our Event Log. In this case, we used Powermad’s Set-MachineAccountAttribute to change the machine’s msDS-AllowedToDelegateTo attribute.
Going to the Event Logs in our lab DC, we can see that running this command generated a Modify operation, with the DN set to our target host (pc01) and the entry list containing our specified value (dc01$) for the attribute.
Step 2 – Auditing Suspicious Operations
Now that we have our mapping of LDAP operations and sensitive attributes, we can create an LDAP Firewall configuration that audits all LDAP requests we suspect to be DACL-based attacks. This configuration can be used in production environments to see if any of the LDAP operations we intend to block are used legitimately in our environment.
Here is the example config on our Git repository.