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:
Seems pretty simple, right? Let’s try it out.
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.
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)
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.
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:
Jeff Warren is Stealthbits’ General Manager of Products. Jeff has held multiple roles within the Technical Product Management group since joining the organization in 2010, initially building Stealthbits’ SharePoint management offerings before shifting focus to the organization’s Data Access Governance solution portfolio as a whole. Before joining Stealthbits, Jeff was a Software Engineer at Wall Street Network, a solutions provider specializing in GIS software and custom SharePoint development.
With deep knowledge and experience in technology, product and project management, Jeff and his teams are responsible for designing and delivering Stealthbits’ high quality, innovative solutions.
Jeff holds a Bachelor of Science degree in Information Systems from the University of Delaware.
Learn why Active Directory security should be a priority for your organization and ways to mitigate against a data breach with this free white paper!Read more
Start a Free Stealthbits Trial!
No risk. No obligation.