Active Directory ACL Abuse with Kali Linux

Active Directory Access Control Lists (ACL), and their associated Access Control Entries (ACE), define the entities and permissions of a specific AD object. If misconfigured, abusing these permissions can be an easy way of escalating privileges within an organization.

Overview

Many of the articles and guides demonstrating Active Directory ACL abuse showcase exploitation from a Windows host. For good reason, PowerShell makes modification of vulnerable objects simple - especially when already connected to the domain.

However, what happens when a vulnerable object is identified and operators are confined to a Linux operating system? Thanks to BloodHound.py, this situation is becoming more common during penetration tests where only network level access is granted or otherwise attained.

This article provides a brief walk through on enumerating and exploiting “GenericAll” permissions against a vulnerable user object to successfully escalate privileges within Active Directory.

Enumeration

As briefly mentioned, BloodHound.py is an ingestor for BloodHound created by dirkjanm. It makes use of the Impacket library to interact with and enumerate Active Directory environments.

Given Active Directorys authentication requirements to retrieve object data, testers must already have a set of credentials.

The following demonstrates enumeration of the demo.local domain from a Kali Linux host. This is being executed as the low-privileged, domain user demo\user01:

bloodhound-python -u user01 -p Password1! -d demo.local -c Acl -dc dc01.demo.local -ns 192.168.1.114

Identifying GenericAll

After running BloodHound.py, which installs as bloodhound-python, the resulting .json reports can be loaded into BloodHounds Neo4j database to map the results.

This is where things get interesting…

When examining our compromised user demo\user01, the “Outbound Object Control” section exposed “GenericalAll” permissions over the demo\service01 account.

GenericAll implies we have full rights over the demo\service01 user object, which also happens to be a member of the privileged demo\Domain Admins group 😈.

Exploitation

To exploit this position, we can leverage our demo\user01 account to reset the password of demo\service01 and escalate privileges to Domain Admin!

While several Linux utilities exist to reset the current users password, I struggled to find a tool that could reset passwords on behalf of another account.

This is when I came across PShlyundins ldap_shell, a fork of Fortras project but designed to execute as a stand-alone program - outside of ntlmrelayx.

As demonstrated below, I leveraged the ldap_shell to initiate a shell on the domain controller over the LDAP protocol as demo\user01. Then abused our allotted permissions to reset the password of demo\service01 via the change_password command:

These changes were confirmed with CrackMapExec to validate administrator privileges on the demo.local domain!

After-Action Review

I wrote this post after encountering ALC abuse in a real-world scenario, and held onto it for a bit (likely too long). Whether it be time passed or the freedom of proper research, I have since found additional methods of forcing password resets on alternate accounts from a Linux host.

For example, thehacker.recipes provides an entire section on DACL abuse and demonstrates exploitation using the Samba suites built-in net utility via net rpc password.

That said, the ability to open an LDAP shell outside of ntlmrelayx is still a good technique to have in your arsenal and provides more functionality than password resets to explore!