PW-022Attack pathControl and privilege paths

Account or group outside a Privilege Zone controls a zone object

An account or group outside one of your Privilege Zones controls an object inside it, so the zone's boundary doesn't hold.

Category: Attack Path
Severity: From exposure.
Typical owner: Owner of the Privilege Zone (for example the server team for "Tier 1 servers"), with the AD team for permissions
Data needed: Any collection, plus Privilege Zones defined in pathwarden.toml or on the app's Zones page.

MITRE ATT&CKT1098 T1021

Most useful toDefensive engineers Identity and access engineers

On this page

In plain language

Tier Zero isn't the only thing worth protecting. Your Privilege Zones are the other sets of systems you have decided to defend the same way, such as Tier 1 servers or finance applications.

This finding is the zone version of PW-003: someone outside the zone (and outside Tier Zero) has a right over something inside it. If the zone is meant to be a boundary, that right is a hole in it.

What Pathwarden flags

An account or group that is neither in the named Privilege Zone nor in Tier Zero has a right over an object inside the zone. That could be an AD permission (GenericAll, WriteDacl, WriteOwner, ForceChangePassword, AddMember, ...), local administrator or remote access rights on a zone computer, delegation rights, or a GPO link. Whoever controls that account or group can take over the zone object, so the zone boundary your tiering model assumes does not hold.

How attackers use it

Attackers rarely go for the target directly. They compromise whatever is easiest (a helpdesk account, an old service account, a workstation) and follow permissions from there. A single leftover delegation, for example a support group with local admin rights on a sensitive server, turns any compromise of that support group into a compromise of the zone (Account Manipulation, MITRE ATT&CK T1098, and Remote Services, T1021). The finding's exposure figure shows how many users and computers can reach the controlling account or group.

Find it with Pathwarden

Data needed: Any collection, plus Privilege Zones defined in pathwarden.toml or on the app's Zones page.

In the web UI or the HTML report, open the Findings tab and expand PW-022: 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-022
# the step-by-step guide on this page, offline
pathwarden guide PW-022
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-022

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

Decide whether the account or group should administer the zone. If it should, the right answer is to add it to the zone on the Privilege Zones page (and protect it like the zone). Do not remove the permission.
Find what uses the right: for local admin rights, check 4624 logon events (type 3/10) on the computer. For AD permissions, check the account's role with its owner.
If the finding says the permission is inherited, change it on the parent OU or container. That change affects every object below it, so review those objects too.

How to fix it

Option A: Remove the right (recommended)

The finding's "fix" line names the relationship. Common cases:

AD permission (ACE): In Active Directory Users and Computers, enable View > Advanced Features, open the object (or the parent OU for inherited ACEs) > Security > Advanced, select the entry for the account or group and click Remove.
Local Administrators / Remote Desktop Users: remove the account or group from the local group on the computer, or from the GPO / Intune policy that adds it (Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups, or Restricted Groups).
Group membership (AddMember on a zone group): remove the permission from the group's Security tab as in step 1.
GPO link / GPO edit rights: restrict who can edit the linked GPO (Group Policy Management > GPO > Delegation), or unlink it from the zone OU.

Option B: Bring the account or group into the zone

If the account or group legitimately manages the zone, add it to the zone on the Privilege Zones page. Then manage it with the same controls as the zone: no use from lower-tier computers, and admin accounts dedicated to this tier.

PowerShell

Import-Module ActiveDirectory

# Show ACEs for the account or group on a zone object
$dn = (Get-ADObject -Filter "Name -eq '<Object>'").DistinguishedName
(Get-Acl "AD:$dn").Access | Where-Object { $_.IdentityReference -like "*<Account>*" } |
    Select-Object IdentityReference, ActiveDirectoryRights, IsInherited

# Remove those ACEs (explicit ones only; fix inherited ones on the parent)
$acl = Get-Acl "AD:$dn"
$acl.Access | Where-Object { $_.IdentityReference -like "*<Account>*" -and -not $_.IsInherited } |
    ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl -Path "AD:$dn" -AclObject $acl

# Local admin rights on a zone computer (run on that computer)
Remove-LocalGroupMember -Group "Administrators" -Member "<Domain>\<Account>"

Verify the fix

Re-run the Get-Acl command above, or Get-LocalGroupMember -Group "Administrators" on the computer, and confirm the account or group is gone. Collect again (or use Retest on the finding) and confirm the finding ID is gone. The zone's row in the report shows the accounts that still have an attack path to the zone.

Roll back

Before removing an ACE, export it: (Get-Acl "AD:$dn").Sddl | Out-File acl-backup.txt. Restore it with $acl.SetSecurityDescriptorSddlForm((Get-Content acl-backup.txt)) followed by Set-Acl. Re-add local group members with Add-LocalGroupMember.

References

Microsoft: Enterprise access modellearn.microsoft.com
SpecterOps BloodHound docs: Privilege Zonesbloodhound.specterops.io
MITRE ATT&CK T1098: Account Manipulationattack.mitre.org
MITRE ATT&CK T1021: Remote Servicesattack.mitre.org