Active Directory DACL Attacks

Active Directory objects such as users and groups have associated permissions. These permissions are enforce using Discretionary Access Control Lists (DACLs). A DACL is composed of a number of Access Control Entries (ACE).

These entries can be configured using Active Directory Users and Computers management console;

The below table shows the access rights and what they enable an adversary to do;

Access Right	Meaning
GENERIC_ALL	All access rights.
GENERIC_READ	Read rights.
GENERIC_WRITE	Write rights.
AllExtendedRights	Grants DS-Replication-Get-Changes and DS-Replication-Get-Changes-All privileges. Allows replicating objects.
User-Force-Change-Password	Ability to reset an accounts password.

A list of extended Active Directory rights is available here.

Identifying DACL Misconfigurations

Run bloodhound-python against the domain. It’s important to use the “-c All” option to ensure ACL information is being collected.

Uploading the Zip file to bloodhound and running the “Shortest Path from Owned Principals”, we get the following graph. The user Alice will be the source of these attacks.

So, there a number of conditions we can exploit here;

• Alice is a transitive member of the EVERYONE group, which has GenericWrite permissions to SERVER2. This server is actually a member of the Domain Admins group, although that is not reflected in the graph.
• Alice is a transitive member of the Authenticated Users group. This group has GenericWrite privileges over the BOB account, which is a member of the Domain Administrators group.
• Being in the Authenticated Users group, Alice also has GenericWrite privileges over the SERVER_ADMIN group which is a member of the Domain Administrators group.

This article will be looking at exploiting the following;

GenericWrite on Computer Accounts

GenericWrite on a User Accounts

GenericAll on User Accounts

GenericWrite on Groups

---

Exploiting GenericWrite on a Computer Account

There are two ways of exploiting GenericWrite on a computer account. Firstly, we can introduce Resource Based Constrained Delegation to the target host to allow us to impersonate users. Further information on Kerberos Delegation Attacks can be found here.

Resource Based Constrained Delegation

Add a Computer Account

Resource Based Constrained Delegation allows a source host to impersonate users on a target. So, to start we need to create a computer account in the domain. By default, each Active Directory user can create 10 accounts;

Add RBCD to the Target

Next, we use impacket-rbcd to add the msDS-AllowedToActOnBehalfOfOtherIdentity property to the target system.

Generate a Kerberos Service Ticket

We can now generate a Kerberos ticket purporting to be any user in the domain.

Import the Ticket

Set the KRB5CCNAME environment variable, and execute klist to ensure the ticket has been imported correctly;

Extract the SAM Database

Using the -k option in impacket tools then lets us authenticate to the target host using Kerberos. We can remotely extract LSA secrets.

Browse the Remote Filesystem

The ticket can also be used to browse the target systems file system, or create a remote session with impacket-psexec.

Shadow Credentials

Shadow Credentials are an alternative way of exploiting a WriteDACL on a target computer account. This attack involves adding the msDS-KeyCredentialLink attribute to the target account, to allow users to authenticate to the host using a certificate. For this to work the functional level of the domain must be at least 2016 (this being the most recent), and a certification authority (AD CS) must be configured in the domain.

We can verify the ticket imported correctly by browsing the systems C$ share;

---

Exploiting GenericWrite on a User Account

With write access to a users account, we can either add an Service Principal Name (SPN). to the account (to allow for Kerberoasting) or change the users logon script for remote code execution.

Targetted Kerberoasting

A script is available here to perform this attack; https://github.com/ShutdownRepo/targetedKerberoast. The script will add an SPN to accounts that we have write access to, Kerberoast the account then remote the SPN. Further information about Kerberoasting attacks is available here.

Logon Script Modification

Alice can add a logon script that runs a command when Bob logs in. This script needs to be stored in the NETLOGON share on the server. By default this share is not writeable by standard users, however administrators may misconfigure the share permissions. In this example, we have a writeable directory called scripts that we place a CobaltStrike beacon inside;

PowerView Set-DomainObject can then be used to set Bob’s logon script to the beacon file;

We can verify the logon script has been changed;

When Bob logs into a system, the beacon will execute.

---

Exploiting GenericAll on a User Account

If we have GenericAll privileges over a user account, we can reset it’s password.

---

Exploiting GenericWrite on a Group

Alice cannot currently DCSync the domain.

However, she can add herself into the SERVER_ADMIN group which is a member of Domain Admins. We can do this using pth-net from Linux;

---

In Conclusion

DACL misconfiguration issues are common, particularly in large Active Directory environments. Products such as Bloodhound Enterprise can assist in identifying these issues.