Creating Persistence with DCShadow

Now that we understand the basics of the DCShadow feature, let’s look at some ways in which attackers can leverage DCShadow in a real world attack scenario.  As we learned, DCShadow requires elevated rights such as Domain Admin, so you can assume an attacker leveraging this already has complete control of your environment.  So why would an attacker want to or need to use DCShadow?

One real world scenario would be for an attacker to create persistence within the domain so they cannot lose their foothold, even if they lose access to the admin account they have compromised.  Also, they may not wish to use a domain administrator account for data exfiltration as these accounts are more closely monitored and can trigger alarms more easily.

There are plenty of ways Domain Administrators can create persistence for themselves so that they can regain administrative rights at any time.  One persistence technique we have covered in the past leverages the AdminSDHolder container.

By manipulating the ACL of this container in AD, an attacker can have permissions to all protected objects, such as Domain Admins and Enterprise Admins.  This would easily allow them to regain administrative access if they ever lost it.

Obviously an administrator can make this change without DCShadow, but the chances of detection are higher.  DCShadow enables this change to be made without events being logged, reducing the risk of triggering any alarms.

Let’s take a look at how this would work with DCShadow. The basic workflow is as follows:

1. Grab the current permissions of the AdminSDHolder permissions
2. Modify the permissions (via SDDL) to add our new user of preference
3. Apply the updated permissions via DCShadow

Seems pretty simple, right?  Let’s try it out.

Grab the Current Permissions of AdminSDHolder

To get the current permissions we will use some basic PowerShell:

$AdminSDHolder = [adsi]'LDAP://CN=AdminSDHolder,CN=System,DC=JEFFLAB,DC=local'
$SDDL = $AdminSDHolder.ObjectSecurity.Sddl 

If we look at the results of that we will see the current permissions of the AdminSDHolder container in SDDL format as shown below:

If that doesn’t make a whole lot of sense to you, you can read up on SDDL here.  Even better, you can convert that string to a more readable format using the ConvertFrom-SDDLString command.   That will provide you with a simpler view:

Okay, so we know the current permissions of AdminSDHolder, now let’s modify them.

Modify the AdminSDHolder Permissions

For us to create persistence, we need to add an account to the AdminSDHolder permissions. To do that we will need to modify the SDDL string and reapply it.  The first thing we need is to grab the object SID of the user we wish to apply.  All we need to know is the distinguished name of the object and we can get that with some more basic PowerShell:

$UserToAdd = [adsi]'LDAP://CN=Bob Loblaw,OU=Business,OU=Users,OU=JEFFLAB,DC=JEFFLAB,DC=local'
$UserSid  = New-Object System.Security.Principal.SecurityIdentifier($UserToAdd.objectSid[0], 0) 

If we inspect the object we have, we can see we have the domain and object SIDs for that user:

Now we can update our SDDL and add Full Control permissions to that user with the following PowerShell command:

$NewSDDL = $SDDL + "(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;" + $UserSid.Value + ")" 

If we take a look at our new SDDL we will see the user as the last entry:

We are ready to apply our new SID!  Finally, time for DCShadow.

Update Permissions with DCShadow

Now that we have the new permissions in the form of an attribute value, it is very easy to apply them with DCShadow.  Our first post covered the basic steps of running DCShadow, so following that we will craft a change for the AdminSDHolder container and set a new ACL.  Once I am running as SYSTEM I can use the following command in Mimikatz to craft the desired change:

.mimikatz.exe "lsadump::dcshadow /object:CN=AdminSDHolder,CN=System,DC=JEFFLAB,DC=local /attribute:ntsecuritydescriptor /value:[NEW SDDL FROM ABOVE]” 

Which looks something like this:

Here you can see the change is ready to be replicated:

After that I will use the lsadump::dcshadow/push command to trigger the replication and commit the changes.

I can now see the updated AdminSDHolder value with my user added, which will soon be on every protected group in the domain.

This change illustrates just one way using the current capabilities of DCShadow can create persistence for an attacker by setting attributes.  In my next post, we will look at other techniques that DCShadow enables.

Blog posts in the series:

• Post #1 – DCShadow: Attacking Active Directory with Rogue DCs

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:

Name

Email*