Skip to main content

​
Summary

Certain SCCM accounts unintentionally inherit privileges such that they become highly overprivileged over time. The canonical example of this is task sequence domain join account. When an account joins a computer to the domain, the account gains ownership over the computer. Ownership allows the owner to modify the security description on the object, regardless of the explicit permissions in the object’s DACL. Therefore, the account can modify the DACL on the object and grant itself any privilege (i.e., full control of the object). When combined with CRED-1, this becomes extremely dangerous, as an attacker could potentially retrieve the task sequence domain join account credentials and takeover any computer it owns. This can be abused to grant the account the ability to read LAPS passwords, perform Kerberos resource-based constrained delegation, and various other attacks. At SpecterOps, we’ve seen this account have ownership over hundreds of thousands of computers, including domain controllers. We recommend auditing the permissions of the task sequence domain join account, and any other SCCM account as outlined in PREVENT-10. Remove computer ownership from the domain join account and assign it to the Domain Admins group. We can use the following PowerShell script to:
  1. Create the necessary System.Security.Principal.NTAccount object for SetOwner
  2. Enumerate all computers with a name like win11*
  3. Iterate over each computer, creating an ACL variable for each
  4. Set the owner on each ACL to the account specificed in $user
$user = New-Object System.Security.Principal.NTAccount("contoso\djoin")
Get-ADComputer -filter 'name -like "win11*"' |
foreach{
    $acl = Get-Acl -Path "AD:$($_.DistinguishedName)"
    $acl.SetOwner($user)
    Set-Acl -Path "AD:$($_.DistinguishedName)" $acl
    }

​
Linked Defensive IDs

​
Associated Offensive IDs

​
References