o 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.
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.
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:
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.
Once you have access rights there is 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 to 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:
Sign up for the full blog series to be notified when each new installment posts, here.
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 – now part of Netwrix, 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© 2021 Stealthbits Technologies, Inc.
Leave a Reply