PW-003Attack pathControl and privilege paths

Account or group outside Tier Zero controls a Tier Zero object

A user, group or computer outside Tier Zero has a permission or relationship that gives it control of a Tier Zero object.

Category: Attack Path
Severity: At least High.
Typical owner: AD / identity team (server team for local rights, PKI team for ManageCA)
Data needed: Any collection. Control through local administrator rights or sessions needs session and local group data (SharpHound, or the built-in collector^* with --user --scope all); control through SYSVOL folder permissions^* needs the built-in collector^* run as the current Windows user.

MITRE ATT&CKT1098

Most useful toDefensive engineers Identity and access engineers Offensive operators Auditors

On this page

In plain language

In Active Directory, permissions are themselves an attack surface. If a helpdesk group can reset a Domain Admin's password, or a service account can add members to a privileged group, then whoever compromises that group or account controls Tier Zero.

Pathwarden reports each pair of "who" and "what" once, with every right involved, so one finding is one change. Rights that SDProp copies from AdminSDHolder onto every protected account are reported once, on AdminSDHolder, where the fix belongs.

What Pathwarden flags

An account or group outside Tier Zero holds a permission or relationship over a Tier Zero object (a privileged account or group, a domain controller, a Tier Zero GPO or OU, a certificate authority). Whoever controls that account or group can take over the Tier Zero object, so Tier Zero is only as safe as the weaker account or group.

How attackers use it

Attackers chain these relationships: compromise a helpdesk account, use its GenericAll on a Domain Admin to reset the password (T1098, Account Manipulation), or its local admin rights on a server where an admin is logged on. Each relationship kind has a known, tool-supported abuse; BloodHound shows them all in one graph.

Find it with Pathwarden

Data needed: Any collection. Control through local administrator rights or sessions needs session and local group data (SharpHound, or the built-in collector^* with --user --scope all); control through SYSVOL folder permissions^* needs the built-in collector^* run as the current Windows user.

In the web UI or the HTML report, open the Findings tab and expand PW-003: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:

Shell

# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-003
# the step-by-step guide on this page, offline
pathwarden guide PW-003
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-003

Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.

Before you change anything

Check whether the permission is inherited: the finding names the container to fix if so. Removing it there also removes it from every object below.
Find out who uses it: Directory Service Changes auditing (event 5136) on the target shows modifications; for local rights check logon events 4624 on the computer.
Back up the security descriptor before editing: (Get-Acl "AD:\<TargetDN>").Sddl | Out-File .\acl-backup.txt

How to fix it

Option A: Remove the relationship (recommended)

Use the table for the relationship in the finding.

Relationship	Fix
GenericAll, GenericWrite, WriteDacl, WriteOwner, AllExtendedRights, AddMember, AddSelf, ForceChangePassword, AddKeyCredentialLink, AddAllowedToAct, WriteSPN, WriteAccountRestrictions, WriteGPLink, ReadLAPSPassword, ReadGMSAPassword, SyncLAPSPassword	ADUC (Advanced Features) > target Properties > Security > Advanced > remove the entry (on the parent if inherited, then check inheritance on the objects below it). On a GPO these are its Group Policy security permissions: GPMC > the GPO > Delegation > Advanced. Authenticated Users and Domain Computers keep Read (and Apply group policy where Security Filtering uses it): remove only the write rights
Owns	Same dialog > Owner: Change to Domain Admins (Enterprise Admins for certificate templates and CA objects). The owner can always change the permissions
WriteGPOFiles	SYSVOL folder permissions, not the GPO's own: open the GPO in GPMC and accept its offer to make SYSVOL match, or use the `icacls` commands in the finding. Broad groups keep Read & Execute (see PW-027)
GPLink	GPMC: restrict who can edit the GPO, or unlink it from the Tier Zero OU
AdminTo, CanRDP, ExecuteDCOM, CanPSRemote	Remove the account or group from the local group on the computer or from the GPO that adds it. When several GPOs are linked to the OU or domain, the fix lists them: the collected data does not say which one adds it. When more than one OU or domain adds it, remove it at each
AllowedToDelegate	Target Properties > Delegation: remove the Tier Zero service from the list
AllowedToAct	Clear the account from `msDS-AllowedToActOnBehalfOfOtherIdentity`
HasSIDHistory	Clear `sIDHistory` on the account
ManageCA	certsrv.msc > CA Properties > Security > remove Manage CA

Option B: Move the account or group into Tier Zero

If the account or group genuinely administers Tier Zero, add it under Additional Tier Zero in Settings and protect it like Tier Zero (dedicated admin account, Tier Zero logon restrictions). Use this only for real Tier Zero administrators.

PowerShell

Import-Module ActiveDirectory
$dn  = (Get-ADObject -Identity "<TargetDN>").DistinguishedName
$acl = Get-Acl -Path "AD:\$dn"

# Show the account's entries
$acl.Access | Where-Object { $_.IdentityReference -like "*<Account>" } |
    Select-Object ActiveDirectoryRights, ObjectType, IsInherited

# Remove explicit entries for the account. This removes its read entries too:
# for Authenticated Users or Domain Computers on a GPO, use GPMC's Delegation tab instead
$acl.Access | Where-Object { $_.IdentityReference -like "*<Account>" -and -not $_.IsInherited } |
    ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl -Path "AD:\$dn" -AclObject $acl

# Owns: hand ownership back to Domain Admins
$acl = Get-Acl -Path "AD:\$dn"
$acl.SetOwner([System.Security.Principal.NTAccount]"<Domain>\Domain Admins")
Set-Acl -Path "AD:\$dn" -AclObject $acl

# HasSIDHistory: clear SID history
Set-ADUser -Identity "<Account>" -Clear sIDHistory

# AllowedToAct: clear resource-based constrained delegation on the target computer
Set-ADComputer -Identity "<Computer>" -PrincipalsAllowedToDelegateToAccount $null

Verify the fix

Re-run the "Show the account's entries" query on the target (and on the parent if inherited); it should return nothing. Collect again (or use Retest on the finding) and confirm the finding ID is gone.

Roll back

Restore the saved descriptor: $acl = Get-Acl "AD:\$dn"; $acl.SetSecurityDescriptorSddlForm((Get-Content .\acl-backup.txt)); Set-Acl "AD:\$dn" $acl. For local group or delegation changes, re-add the removed entry.

References

SpecterOps: BloodHound documentationbloodhound.specterops.io
Microsoft: Best practices for securing Active Directorylearn.microsoft.com
SpecterOps BloodHound docs: WriteDaclbloodhound.specterops.io
SpecterOps BloodHound docs: ForceChangePasswordbloodhound.specterops.io
SpecterOps BloodHound docs: AddMemberbloodhound.specterops.io
Microsoft: Appendix C, protected accounts and groups in Active Directory (AdminSDHolder)learn.microsoft.com
MITRE ATT&CK T1098: Account Manipulationattack.mitre.org

Very new and undergoing testing. These features haven't received a lot of testing yet. Try them out and let us know what's working.