Privilege Escalation with DCShadow

So far we’ve covered how DCShadow works as well as ways this can enable attackers to create persistence within a domain without detection once they’ve obtained admin credentials.  DCShadow can enable attack scenarios beyond just creating persistence, and can actually be used to elevate access for an attacker.

How can a Domain Admin elevate their access even higher? By obtaining admin rights in other forests.

Leveraging SID History, an attacker can add administrative SIDs to their user account and obtain admin level rights in other trusted domains and forests. In this post, we’ll take a look at how this works.

Discovering Trusts

Once an attacker has administrative rights over one domain, it is possible to spread to trusted domains/forests. The first step is to find out what trusts exist.  There are several ways to do this, but two which I will leverage through PowerShell include the PowerSploit framework and the Active Directory PowerShell Module.

It is important to look for the options related to SID Filtering. If SID Filtering is enabled, than historical SIDs cannot be used to access the forest on the other side of the trust.  However, if it is disabled than we are in business.  Many times this option is left disabled after migrations to ensure users don’t lose access to any systems and data they need. The following PowerShell will discover trusts and enumerate all of the options including SID Filtering:

Get-NetDomainTrust | ForEach-Object{Get-ADTrust –filter * -server $_.TargetName}

Here is the output of this command. You can see I have a trust to a domain gobias.local where SID Filtering is disabled (SidFilteringQuarantined = False), so I can now use historical SIDs to access resources in this domain.

To read more about SID Filtering and trusts you can read this post on TechNet  and an article from one of the authors of PowerSploit here.

Elevating Privileges with SID History

Okay, so now we know there is a trust to another forest and SID History is not filtered. The next step is to add an administrative SID to our user account so we can access resources in that forest.  DCShadow is going to come in handy here for two reasons:

1. You cannot natively change SID History through applications like AD Users & Computers
2. DCShadow will make this change without any detection

We just need to pick a SID to add to our SID History. You should avoid using any well-known SIDs and built-in users/groups such as Administrator and Domain Admins.  There are controls in place to only allow these SIDs to be assigned to their equivalent objects in other domains.  Using domain reconnaissance we should be able to find a domain user or group which we want to add to our access token to gain elevated rights.

In my environment, I am going to target the AD-Admins domain group from the gobias.local forest.

By running the following DCShadow command I am able to add this to my user account:

lsadump::dcshadow /object:"CN=Jeff Warren,OU=Administrators,OU=Users,OU=JEFFLAB,DC=JEFFLAB,DC=local" /attribute:sidhistory /value:S-1-5-21-1722627474-2472677011-3296483304-1113

After running the lsadump::dcshadow /push command you should be able to see your newly added sidhistory value.  To do this you can use the following script:

Get-ADUser Jeff -Properties sIDHistory

We can confirm this all worked by logging in again as this user and running a whoami /groups command to see the new group membership.  My user is only getting this group in its token through SID history.

Using Elevated Privileges

Once you have access rights there are any number of ways to extract the data you need from the trusted forests. One of the most efficient is to use DCSync because it does not require any code be run on the target domain controller.

Before adding SID history to my account if I attempt to run DCSync against the target forest, I get access denied.

After adding the historical SID to my user account I am able to run the same command successfully and obtain the password hash to any account, including the krbtgt Kerberos service account.

So now we’ve seen how DCShadow can be used for privilege escalation across trusted forests. In our next post we’ll explore how to detect DCShadow within your environment.

Blog posts in the series:

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

Sign up for the full blog series to be notified when each new installment posts, here. 

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

Name

Email*