Overview

8,975accounts have an attack path to Tier ZeroEnabled users and computers outside Tier Zero with a full path to it. Each one is a way to take over the domain. They are 39.91% of 22,489 active accounts.

down 47 since the last run

39.91%The accounts with an attack path to Tier Zero out of the active users and computers outside it: those that logged on in the 90 days before the collection, and any with a path. Lower is better.of 22,489 active accounts
down 14,249How many fewer accounts have an attack path to Tier Zero than at the first of the runs in the chart: 23,224 on Oct 1, 8,975 now.since Oct 1 (from 23,224)

Accounts with an attack path to Tier Zero

last 5 runs · lower is better

020k40k23,2248,975Oct 1Nov 2
Choke pointsThe points many attack paths pass through: fixing these closes every path to Tier Zero, the one that cuts the most first (the remediation path). They cut paths; weak accounts and hygiene still need their own fix.5Start: sign DA-ADMIN24 out of R01S01-SRV0001 and stop using it there (cuts 4,262)
down 10 since the last run
Open findingsFindings not fixed or accepted as a risk. Attack path findings are on a path to Tier Zero; hygiene findings are weaknesses that are not, yet.6359 on attack paths · 4 hygiene
down 1 since the last run
Tier Zero protectedThe share of Tier Zero objects that no open attack path finding leads to.89.83%53 of 59 objects
up 2.95 pts since the last run
CollectionThe share of active computers whose sessions and local groups were collected. When it is low, paths can be missing and the counts read low.88.16%of member computers with local groups · sessions 88.18%

What changed since Oct 25, 2026This report compared with the last run of the same environment in the run history: the lines pathwarden history prints. Counts measured another way (an older exposure basis) are not compared. A run is compared with the last run that targeted the same sessions and local groups; when there is none, with the run just before, and then it says its counts are not compared.

ChangeWhatBefore → now
Worse: 2
new findingsPW-004 DA-ADMIN21@SCALE.LOCAL is logged on to 1 non-Tier Zero host +1 more
  • PW-004 DA-ADMIN21@SCALE.LOCAL is logged on to 1 non-Tier Zero host
  • PW-022 R01S03-U00734@SCALE.LOCAL has GenericWrite on R01S03-SERVERADMINS@SCALE.LOCAL (zone R01 servers)
Worse: 1
new path into Tier ZeroR00S03-SRV0009 HasSession DA-ADMIN21
Worse: 1
new path into R01 serversR01S03-U00734 GenericWrite R01S03-SERVERADMINS
  • R01S03-U00734@SCALE.LOCAL GenericWrite R01S03-SERVERADMINS@SCALE.LOCAL no plan step
Better: 47
fewer accounts with an attack path to Tier Zero2 now reach it · 49 no longer do
Now reach Tier Zero 2Now reach: accounts with an attack path to Tier Zero that had none in the last run that targeted the same. No longer reach: the reverse, with why, and each one's path then when that run is kept in full.
    No longer reach Tier Zero 49
      9,022 → 8,975
      Better: 47fewer accounts with an attack path to R01 servers8,991 → 8,944
      Better: 10fewer choke points15 → 5
      Better: 3
      findings fixedPW-003 R00-HELPDESK@SCALE.LOCAL has ForceChangePassword on R00S00-U00010@SCALE.LOCAL +2 more
      • PW-003 R00-HELPDESK@SCALE.LOCAL has ForceChangePassword on R00S00-U00010@SCALE.LOCAL
      • PW-004 DA-ADMIN03@SCALE.LOCAL is logged on to 9 non-Tier Zero hosts
      • PW-004 R00S00-U00010@SCALE.LOCAL is logged on to 1 non-Tier Zero host
      Better: 3
      findings lost 4 objectsPW-008 41 Tier Zero accounts in SCALE.LOCAL can be delegated: -2 +2 more
      • PW-008 41 Tier Zero accounts in SCALE.LOCAL can be delegated: -2
      • PW-009 2 stale Tier Zero accounts in SCALE.LOCAL: -1
      • PW-010 25 Tier Zero passwords older than 365 days in SCALE.LOCAL: -1
      Better: 2members left Tier Zero
      Better: 13paths into Tier Zero gone

      Tiers

      Tier or zoneStatusAccounts with an attack pathProtected
      Tier ZeroCritical8,975 accounts with an attack path down 4753 of 59 objects (89.83%) protected
      R01 servers · zoneHigh8,944 accounts with an attack path down 470 of 36 objects (0%) protected

      Collected Oct 1: sessions from 88.18% of active computers, local groups from 88.16%. Enough to trust these counts.

      All definitions
      Tier Zero
      The accounts, groups and servers that control the whole domain: domain controllers, Domain Admins and similar groups, the AD CS servers, and the GPOs and containers above them. Whoever controls one of them controls everything.
      Status
      Critical: a group that holds nearly every account (Domain Users, Authenticated Users, Everyone) can reach Tier Zero, or a critical finding is open. High: at least one account outside Tier Zero can reach it. Moderate: no account can, but findings at medium or above are open. Low: no account can, and nothing at medium or above is open. Any path into Tier Zero is a way to take over the domain, so the status is never Low while one is open, however small a share of the domain it is. The line under it says why, as what an attacker can do.
      Accounts with an attack path to Tier Zero
      Enabled users and computers outside Tier Zero with a full path to it. Each is a way in: an attacker who takes over any one of them can take over the domain.
      Share of active accounts
      The same accounts as a share of the active users and computers (enabled, outside Tier Zero, logged on in the last 90 days before the collection, or with a path). Accounts nobody has used in that time count only if they have a path, so old objects can't dilute it. It shows how widely exposure is spread; on a large domain it stays small even with hundreds of ways in, so it doesn't set the status.
      Choke points
      The points many attack paths pass through: fixing these closes every path to Tier Zero, the one that cuts the most first (the remediation path). They cut paths; they do not fix weak accounts or hygiene on its own.
      Open findings
      Findings not fixed or accepted as a risk. Attack path findings are on a path to Tier Zero and are rated by how many users and computers can use them; hygiene findings are weaknesses that are not, yet.
      Tier Zero protected
      The share of Tier Zero objects that no open attack path finding leads to. A Privilege Zone has its own.
      Collection
      The share of active computers whose sessions and local groups were collected. Paths through logged-on sessions and local administrator rights are only as complete as these numbers; below 80% for a domain, the counts can read low. Not targeted means the collector was not asked to read them. A Quick collection reads the directory only, so its counts are compared only with runs that also didn't read them.
      Tiers
      Tier Zero and each Privilege Zone in the settings: its status, the accounts outside it (and outside Tier Zero) with an attack path to it, and how many of its objects are protected. With a run history, a status that changed says what it was the run before. Choke points are worked out for Tier Zero only; a zone shows its count.
      Since the last run
      The change from the previous run of the same environment in the run history, when there is one, compared as pathwarden history compares them; "What changed" lists it line by line. Besides the counts, it names what they don't show: older findings that gained or lost objects, new members of Tier Zero and the zones, and paths into them that appeared or went. Counts measured another way (an older exposure basis) are not compared. A run is compared with the last run that targeted the same sessions and local groups; when there is none, with the run just before, and then it says its counts are not compared.
      Introduced
      Net new over a period: a finding first seen in it (New), a finding fixed before and back in it (Back), an older finding that gained objects in it (+N objects), a new member of Tier Zero or a zone, or a new path into one. The Findings tab filters by it; pathwarden changes --since and pathwarden findings --introduced list the same.
      First seen
      When Pathwarden first found a finding, an object in it, a member or a path: the date of that run ("first seen Oct 18 (run 3)"), not when the change was made in the directory. Objects, members and paths are dated from the first run that began dating them; one that left and returned is "back".
      New paths and members
      A new member: an object that joined Tier Zero or a Privilege Zone, such as a user added to Domain Admins. A new path: an edge into Tier Zero or a zone from outside it (a permission, an admin right, a session) that wasn't there at the run before. A zone with more than 50,000 of either is counted, not dated.

      More terms in the glossary.

      Remediation path

      8,975can reach Tier Zero today
      5changes
      0left afterwards

      This plan lowers Tier Zero exposure from 39.91% to 0%, a 39.9-point drop, as a fresh run after the fixes would count it. These 5 changes close every attack path to Tier Zero. They also cut the paths of 9 weak accounts (Kerberoastable or AS-REP roastable), which still need their own fix and are listed below. 49 other open findings are not on any path the plan cuts, and each needs its own fix; see below. Steps that cut off the most users and computers come first; open a step to see exactly what to change and which findings it closes.

      1Sign DA-ADMIN24 out of R01S01-SRV0001 and stop using it thereR01S01-SRV0001.SCALE.LOCAL HasSession DA-ADMIN24@SCALE.LOCAL4,262 exposed 1 new

      Stop DA-ADMIN24@SCALE.LOCAL from logging on to R01S01-SRV0001.SCALE.LOCAL, then log off or reboot R01S01-SRV0001.SCALE.LOCAL to clear its cached credentials.

      Accounts it cuts off 4,262 1 new since the last runAccounts with an attack path to Tier Zero through this step. Some also have other paths, which other steps cut. New: no path to Tier Zero in the last run that targeted the same.

        Findings this step closes

        2Sign DA-ADMIN18 out of R01S03-SRV0008 and stop using it thereR01S03-SRV0008.SCALE.LOCAL HasSession DA-ADMIN18@SCALE.LOCAL4,262 exposed 1 new

        Stop DA-ADMIN18@SCALE.LOCAL from logging on to R01S03-SRV0008.SCALE.LOCAL, then log off or reboot R01S03-SRV0008.SCALE.LOCAL to clear its cached credentials.

        Accounts it cuts off 4,262 1 new since the last runAccounts with an attack path to Tier Zero through this step. Some also have other paths, which other steps cut. New: no path to Tier Zero in the last run that targeted the same.

          Findings this step closes

          3Sign DA-ADMIN39 out of R02S02-SRV0014 and stop using it thereR02S02-SRV0014.SCALE.LOCAL HasSession DA-ADMIN39@SCALE.LOCAL2,395 exposed 1 new

          Stop DA-ADMIN39@SCALE.LOCAL from logging on to R02S02-SRV0014.SCALE.LOCAL, then log off or reboot R02S02-SRV0014.SCALE.LOCAL to clear its cached credentials.

          Accounts it cuts off 2,395 1 new since the last runAccounts with an attack path to Tier Zero through this step. Some also have other paths, which other steps cut. New: no path to Tier Zero in the last run that targeted the same.

            Findings this step closes

            4Sign DA-ADMIN21 out of R00S03-SRV0009 and stop using it thereR00S03-SRV0009.SCALE.LOCAL HasSession DA-ADMIN21@SCALE.LOCAL2,335 exposed 2 new
            5Take away the right of SVC-ADSYNC to replicate passwords from SCALE.LOCALSVC-ADSYNC@SCALE.LOCAL DCSync SCALE.LOCAL1 exposed

            Remove the 'Replicating Directory Changes' and 'Replicating Directory Changes All' rights granted to SVC-ADSYNC@SCALE.LOCAL on SCALE.LOCAL, or remove SVC-ADSYNC@SCALE.LOCAL from the group that grants them.

            Accounts it cuts off 1Accounts with an attack path to Tier Zero through this step. Some also have other paths, which other steps cut. New: no path to Tier Zero in the last run that targeted the same.

              Findings this step closes

              Not closed by this plan

              No step above closes these: weak accounts (even where a step cuts their path), hygiene, and paths that start inside Tier Zero. Each needs its own fix. Most severe first.

              Findings

              First seen by Pathwarden: each finding, object and path carries the date of the run that found it, not when it changed in the directory. New: first seen in the period. Back: fixed before, back in it. +N objects: an older finding that gained objects in it.
              CriticalPW-006Kerberoastable account with Tier Zero access10 findings
              How to fix this kind of findingstep-by-step guide

              Category: Attack path Typical owner: AD / identity team with the service owner

              What this finding means

              A user account with a service principal name (SPN) is in Tier Zero or has a path to it. Any domain user can request a Kerberos service ticket for it, and that ticket is encrypted with a key derived from the account's password.

              Group and standalone managed service accounts (gMSA, sMSA) are not reported: the domain gives them a 240-byte (120-character) random password and rotates it, so their tickets can't be cracked. In SharpHound collections Pathwarden recognises them from the gmsa and msa flags; in RustHound-CE and built-in collections, which have no such flag, from the computer-account bit (userAccountControl 0x1000) on a user object. In those collections a user account an administrator gave the computer-account bit by hand, which still has a human-set password, is treated as managed and not reported: check SPN accounts with that bit (Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=4096)") if you collect with RustHound-CE or the built-in collector.

              Why attackers care

              Kerberoasting (Steal or Forge Kerberos Tickets: Kerberoasting, T1558.003) needs only a normal domain account: request tickets for every SPN, take them offline and crack the passwords. Service account passwords are often old, human-chosen and never rotated, and RC4 tickets crack quickly. A cracked privileged service account means domain compromise without any alert on the target.

              Before you change anything

              • Identify the service using the SPN (setspn -L <Account>), the hosts running it, and who owns it.
              • Check whether the SPN is still used: event 4769 on domain controllers shows service ticket requests for the account. No requests over weeks often means a stale SPN.
              • If the account is privileged only because of a group it does not need (common for old SQL service accounts in Domain Admins), removing that membership is part of the fix.

              Fix

              Option A: Move the service to a group Managed Service Account (recommended)
              1. Create a gMSA (New-ADServiceAccount) allowed for the service's hosts.
              2. Install it on the hosts (Install-ADServiceAccount) and change the service to run as <Domain>\<gMSA>$ with an empty password.
              3. Move the SPNs to the gMSA, then disable the old account. gMSA passwords are 240-byte (120-character) random values rotated automatically: not crackable.
              Option B: Remove unneeded SPNs or privileges

              Remove stale SPNs with setspn -D, and remove the account from privileged groups it does not need.

              Option C: If the account must stay

              Set a random password of 25+ characters, enable AES-only Kerberos for the account ("This account supports Kerberos AES 128/256 bit encryption" in ADUC Account tab), and rotate the password on a schedule.

              PowerShell
              Import-Module ActiveDirectory
              
              # Kerberoastable user accounts
              Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName, PasswordLastSet, MemberOf
              
              # Option A: create a gMSA (needs a KDS root key in the forest)
              New-ADServiceAccount -Name "<gMSA>" -DNSHostName "<gMSA>.<Domain>" `
                  -PrincipalsAllowedToRetrieveManagedPassword "<ServerGroup>"
              Install-ADServiceAccount -Identity "<gMSA>"     # run on each service host
              
              # Option B: remove a stale SPN
              setspn -D <SPN> <Account>
              
              # Option C: AES only (0x18 = AES128 + AES256), then reset the password
              Set-ADUser -Identity "<Account>" -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 }
              Set-ADAccountPassword -Identity "<Account>" -Reset -NewPassword (Read-Host -AsSecureString "New password")
              

              Verify

              Get-ADUser "<Account>" -Properties ServicePrincipalName shows no SPNs (Options A/B), or msDS-SupportedEncryptionTypes is 24 and PasswordLastSet is recent (Option C). Collect again (or use Retest in the app, or pathwarden retest on the CLI) and confirm the finding ID is gone.

              Rollback

              Re-register an SPN with setspn -S <SPN> <Account>; switch the service back to the old account in the Services console. Keep the old account disabled, not deleted, until the gMSA has run cleanly for a while.

              References

              • https://attack.mitre.org/techniques/T1558/003/
              • https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview
              CriticalKerberoastable account SVC-00000@SCALE.LOCAL is Tier Zerofirst seen Oct 1 (run 1)Fix directlypassword 2,594 days old
              Category
              Attack Path
              Exposure
              100% (24,414 of 24,414 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-006-1bbba15126c6fc31

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              SVC-00000@SCALE.LOCAL has a service principal name, so any domain user can request a ticket encrypted with its password and crack it offline, and it is Tier Zero. Its password was last set 2594 days ago.

              User 1
              • SVC-00000

              How to fix it

              Remove unneeded SPNs from SVC-00000@SCALE.LOCAL, or move the service to a group Managed Service Account (gMSA). If the SPN must stay, set a random password of 25+ characters and allow only AES Kerberos encryption for the account.

              CriticalKerberoastable account SVC-00040@SCALE.LOCAL has a path to Tier Zerofirst seen Oct 1 (run 1)Path cut: step 4password 2,488 days old
              Category
              Attack Path
              Exposure
              100% (24,414 of 24,414 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-006-5ca8fbd0a56628a3

              Its attack path is cut by remediation step 4. The account itself stays weak until it is fixed (see How to fix it), and could become a path again.

              Why it matters

              SVC-00040@SCALE.LOCAL has a service principal name, so any domain user can request a ticket encrypted with its password and crack it offline, and it has a path to Tier Zero. Its password was last set 2488 days ago.

              How to fix it

              Remove unneeded SPNs from SVC-00040@SCALE.LOCAL, or move the service to a group Managed Service Account (gMSA). If the SPN must stay, set a random password of 25+ characters and allow only AES Kerberos encryption for the account.

              Attack path

              MemberOfAdminToHasSessionMemberOfAdminToHasSessionSVC-00040@SCALE.LOCAL (User)SVC-00040User · SCALE.LOCALSQL-ADMINS@SCALE.LOCAL (Group)SQL-ADMINSGroup · SCALE.LOCALR00S03-SRV0000.SCALE.LOCAL (Computer)R00S03-SRV0000Computer · SCALE.LOCALR00S03-U00282@SCALE.LOCAL (User)R00S03-U00282User · SCALE.LOCALR00S03-SERVERADMINS@SCALE.LOCAL (Group)R00S03-SERVERADMINSGroup · SCALE.LOCALR00S03-SRV0009.SCALE.LOCAL (Computer)R00S03-SRV0009Computer · SCALE.LOCALDA-ADMIN21@SCALE.LOCAL (User)DA-ADMIN21User · SCALE.LOCAL

              start target

              Path as text
              1. SVC-00040@SCALE.LOCAL (User)
              2. MemberOf SQL-ADMINS@SCALE.LOCAL (Group)
              3. AdminTo R00S03-SRV0000.SCALE.LOCAL (Computer)
              4. HasSession R00S03-U00282@SCALE.LOCAL (User)
              5. MemberOf R00S03-SERVERADMINS@SCALE.LOCAL (Group)
              6. AdminTo R00S03-SRV0009.SCALE.LOCAL (Computer)
              7. HasSession DA-ADMIN21@SCALE.LOCAL (User)
              Affected objects (1)
              User 1
              • SVC-00040
              CriticalKerberoastable account SVC-00005@SCALE.LOCAL has a path to Tier Zerofirst seen Oct 1 (run 1)Path cut: step 4password 2,378 days old
              Category
              Attack Path
              Exposure
              100% (24,414 of 24,414 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-006-1ba3d75126b2c612

              Its attack path is cut by remediation step 4. The account itself stays weak until it is fixed (see How to fix it), and could become a path again.

              Why it matters

              SVC-00005@SCALE.LOCAL has a service principal name, so any domain user can request a ticket encrypted with its password and crack it offline, and it has a path to Tier Zero. Its password was last set 2378 days ago.

              How to fix it

              Remove unneeded SPNs from SVC-00005@SCALE.LOCAL, or move the service to a group Managed Service Account (gMSA). If the SPN must stay, set a random password of 25+ characters and allow only AES Kerberos encryption for the account.

              Attack path

              MemberOfAdminToHasSessionMemberOfAdminToHasSessionSVC-00005@SCALE.LOCAL (User)SVC-00005User · SCALE.LOCALSQL-ADMINS@SCALE.LOCAL (Group)SQL-ADMINSGroup · SCALE.LOCALR00S03-SRV0000.SCALE.LOCAL (Computer)R00S03-SRV0000Computer · SCALE.LOCALR00S03-U00282@SCALE.LOCAL (User)R00S03-U00282User · SCALE.LOCALR00S03-SERVERADMINS@SCALE.LOCAL (Group)R00S03-SERVERADMINSGroup · SCALE.LOCALR00S03-SRV0009.SCALE.LOCAL (Computer)R00S03-SRV0009Computer · SCALE.LOCALDA-ADMIN21@SCALE.LOCAL (User)DA-ADMIN21User · SCALE.LOCAL

              start target

              Path as text
              1. SVC-00005@SCALE.LOCAL (User)
              2. MemberOf SQL-ADMINS@SCALE.LOCAL (Group)
              3. AdminTo R00S03-SRV0000.SCALE.LOCAL (Computer)
              4. HasSession R00S03-U00282@SCALE.LOCAL (User)
              5. MemberOf R00S03-SERVERADMINS@SCALE.LOCAL (Group)
              6. AdminTo R00S03-SRV0009.SCALE.LOCAL (Computer)
              7. HasSession DA-ADMIN21@SCALE.LOCAL (User)
              Affected objects (1)
              User 1
              • SVC-00005
              CriticalKerberoastable account SVC-00025@SCALE.LOCAL has a path to Tier Zerofirst seen Oct 1 (run 1)Path cut: step 4password 2,355 days old
              Category
              Attack Path
              Exposure
              100% (24,414 of 24,414 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-006-6cfd0fd0ae5d98f6

              Its attack path is cut by remediation step 4. The account itself stays weak until it is fixed (see How to fix it), and could become a path again.

              Why it matters

              SVC-00025@SCALE.LOCAL has a service principal name, so any domain user can request a ticket encrypted with its password and crack it offline, and it has a path to Tier Zero. Its password was last set 2355 days ago.

              How to fix it

              Remove unneeded SPNs from SVC-00025@SCALE.LOCAL, or move the service to a group Managed Service Account (gMSA). If the SPN must stay, set a random password of 25+ characters and allow only AES Kerberos encryption for the account.

              Attack path

              MemberOfAdminToHasSessionMemberOfAdminToHasSessionSVC-00025@SCALE.LOCAL (User)SVC-00025User · SCALE.LOCALSQL-ADMINS@SCALE.LOCAL (Group)SQL-ADMINSGroup · SCALE.LOCALR00S03-SRV0000.SCALE.LOCAL (Computer)R00S03-SRV0000Computer · SCALE.LOCALR00S03-U00282@SCALE.LOCAL (User)R00S03-U00282User · SCALE.LOCALR00S03-SERVERADMINS@SCALE.LOCAL (Group)R00S03-SERVERADMINSGroup · SCALE.LOCALR00S03-SRV0009.SCALE.LOCAL (Computer)R00S03-SRV0009Computer · SCALE.LOCALDA-ADMIN21@SCALE.LOCAL (User)DA-ADMIN21User · SCALE.LOCAL

              start target

              Path as text
              1. SVC-00025@SCALE.LOCAL (User)
              2. MemberOf SQL-ADMINS@SCALE.LOCAL (Group)
              3. AdminTo R00S03-SRV0000.SCALE.LOCAL (Computer)
              4. HasSession R00S03-U00282@SCALE.LOCAL (User)
              5. MemberOf R00S03-SERVERADMINS@SCALE.LOCAL (Group)
              6. AdminTo R00S03-SRV0009.SCALE.LOCAL (Computer)
              7. HasSession DA-ADMIN21@SCALE.LOCAL (User)
              Affected objects (1)
              User 1
              • SVC-00025
              CriticalKerberoastable account SVC-00020@SCALE.LOCAL has a path to Tier Zerofirst seen Oct 1 (run 1)Path cut: step 4password 2,322 days old
              Category
              Attack Path
              Exposure
              100% (24,414 of 24,414 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-006-6d14d9d0ae71cf15

              Its attack path is cut by remediation step 4. The account itself stays weak until it is fixed (see How to fix it), and could become a path again.

              Why it matters

              SVC-00020@SCALE.LOCAL has a service principal name, so any domain user can request a ticket encrypted with its password and crack it offline, and it has a path to Tier Zero. Its password was last set 2322 days ago.

              How to fix it

              Remove unneeded SPNs from SVC-00020@SCALE.LOCAL, or move the service to a group Managed Service Account (gMSA). If the SPN must stay, set a random password of 25+ characters and allow only AES Kerberos encryption for the account.

              Attack path

              MemberOfAdminToHasSessionMemberOfAdminToHasSessionSVC-00020@SCALE.LOCAL (User)SVC-00020User · SCALE.LOCALSQL-ADMINS@SCALE.LOCAL (Group)SQL-ADMINSGroup · SCALE.LOCALR00S03-SRV0000.SCALE.LOCAL (Computer)R00S03-SRV0000Computer · SCALE.LOCALR00S03-U00282@SCALE.LOCAL (User)R00S03-U00282User · SCALE.LOCALR00S03-SERVERADMINS@SCALE.LOCAL (Group)R00S03-SERVERADMINSGroup · SCALE.LOCALR00S03-SRV0009.SCALE.LOCAL (Computer)R00S03-SRV0009Computer · SCALE.LOCALDA-ADMIN21@SCALE.LOCAL (User)DA-ADMIN21User · SCALE.LOCAL

              start target

              Path as text
              1. SVC-00020@SCALE.LOCAL (User)
              2. MemberOf SQL-ADMINS@SCALE.LOCAL (Group)
              3. AdminTo R00S03-SRV0000.SCALE.LOCAL (Computer)
              4. HasSession R00S03-U00282@SCALE.LOCAL (User)
              5. MemberOf R00S03-SERVERADMINS@SCALE.LOCAL (Group)
              6. AdminTo R00S03-SRV0009.SCALE.LOCAL (Computer)
              7. HasSession DA-ADMIN21@SCALE.LOCAL (User)
              Affected objects (1)
              User 1
              • SVC-00020
              CriticalKerberoastable account SVC-00035@SCALE.LOCAL has a path to Tier Zerofirst seen Oct 1 (run 1)Path cut: step 4password 1,428 days old
              Category
              Attack Path
              Exposure
              100% (24,414 of 24,414 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-006-75dcead0b373ca31

              Its attack path is cut by remediation step 4. The account itself stays weak until it is fixed (see How to fix it), and could become a path again.

              Why it matters

              SVC-00035@SCALE.LOCAL has a service principal name, so any domain user can request a ticket encrypted with its password and crack it offline, and it has a path to Tier Zero. Its password was last set 1428 days ago.

              How to fix it

              Remove unneeded SPNs from SVC-00035@SCALE.LOCAL, or move the service to a group Managed Service Account (gMSA). If the SPN must stay, set a random password of 25+ characters and allow only AES Kerberos encryption for the account.

              Attack path

              MemberOfAdminToHasSessionMemberOfAdminToHasSessionSVC-00035@SCALE.LOCAL (User)SVC-00035User · SCALE.LOCALSQL-ADMINS@SCALE.LOCAL (Group)SQL-ADMINSGroup · SCALE.LOCALR00S03-SRV0000.SCALE.LOCAL (Computer)R00S03-SRV0000Computer · SCALE.LOCALR00S03-U00282@SCALE.LOCAL (User)R00S03-U00282User · SCALE.LOCALR00S03-SERVERADMINS@SCALE.LOCAL (Group)R00S03-SERVERADMINSGroup · SCALE.LOCALR00S03-SRV0009.SCALE.LOCAL (Computer)R00S03-SRV0009Computer · SCALE.LOCALDA-ADMIN21@SCALE.LOCAL (User)DA-ADMIN21User · SCALE.LOCAL

              start target

              Path as text
              1. SVC-00035@SCALE.LOCAL (User)
              2. MemberOf SQL-ADMINS@SCALE.LOCAL (Group)
              3. AdminTo R00S03-SRV0000.SCALE.LOCAL (Computer)
              4. HasSession R00S03-U00282@SCALE.LOCAL (User)
              5. MemberOf R00S03-SERVERADMINS@SCALE.LOCAL (Group)
              6. AdminTo R00S03-SRV0009.SCALE.LOCAL (Computer)
              7. HasSession DA-ADMIN21@SCALE.LOCAL (User)
              Affected objects (1)
              User 1
              • SVC-00035
              CriticalKerberoastable account SVC-00015@SCALE.LOCAL has a path to Tier Zerofirst seen Oct 1 (run 1)Path cut: step 4password 1,325 days old
              Category
              Attack Path
              Exposure
              100% (24,414 of 24,414 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-006-24ba12512bf729dd

              Its attack path is cut by remediation step 4. The account itself stays weak until it is fixed (see How to fix it), and could become a path again.

              Why it matters

              SVC-00015@SCALE.LOCAL has a service principal name, so any domain user can request a ticket encrypted with its password and crack it offline, and it has a path to Tier Zero. Its password was last set 1325 days ago.

              How to fix it

              Remove unneeded SPNs from SVC-00015@SCALE.LOCAL, or move the service to a group Managed Service Account (gMSA). If the SPN must stay, set a random password of 25+ characters and allow only AES Kerberos encryption for the account.

              Attack path

              MemberOfAdminToHasSessionMemberOfAdminToHasSessionSVC-00015@SCALE.LOCAL (User)SVC-00015User · SCALE.LOCALSQL-ADMINS@SCALE.LOCAL (Group)SQL-ADMINSGroup · SCALE.LOCALR00S03-SRV0000.SCALE.LOCAL (Computer)R00S03-SRV0000Computer · SCALE.LOCALR00S03-U00282@SCALE.LOCAL (User)R00S03-U00282User · SCALE.LOCALR00S03-SERVERADMINS@SCALE.LOCAL (Group)R00S03-SERVERADMINSGroup · SCALE.LOCALR00S03-SRV0009.SCALE.LOCAL (Computer)R00S03-SRV0009Computer · SCALE.LOCALDA-ADMIN21@SCALE.LOCAL (User)DA-ADMIN21User · SCALE.LOCAL

              start target

              Path as text
              1. SVC-00015@SCALE.LOCAL (User)
              2. MemberOf SQL-ADMINS@SCALE.LOCAL (Group)
              3. AdminTo R00S03-SRV0000.SCALE.LOCAL (Computer)
              4. HasSession R00S03-U00282@SCALE.LOCAL (User)
              5. MemberOf R00S03-SERVERADMINS@SCALE.LOCAL (Group)
              6. AdminTo R00S03-SRV0009.SCALE.LOCAL (Computer)
              7. HasSession DA-ADMIN21@SCALE.LOCAL (User)
              Affected objects (1)
              User 1
              • SVC-00015
              CriticalKerberoastable account SVC-00030@SCALE.LOCAL has a path to Tier Zerofirst seen Oct 1 (run 1)Path cut: step 4password 995 days old
              Category
              Attack Path
              Exposure
              100% (24,414 of 24,414 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-006-75c520d0b35f9412

              Its attack path is cut by remediation step 4. The account itself stays weak until it is fixed (see How to fix it), and could become a path again.

              Why it matters

              SVC-00030@SCALE.LOCAL has a service principal name, so any domain user can request a ticket encrypted with its password and crack it offline, and it has a path to Tier Zero. Its password was last set 995 days ago.

              How to fix it

              Remove unneeded SPNs from SVC-00030@SCALE.LOCAL, or move the service to a group Managed Service Account (gMSA). If the SPN must stay, set a random password of 25+ characters and allow only AES Kerberos encryption for the account.

              Attack path

              MemberOfAdminToHasSessionMemberOfAdminToHasSessionSVC-00030@SCALE.LOCAL (User)SVC-00030User · SCALE.LOCALSQL-ADMINS@SCALE.LOCAL (Group)SQL-ADMINSGroup · SCALE.LOCALR00S03-SRV0000.SCALE.LOCAL (Computer)R00S03-SRV0000Computer · SCALE.LOCALR00S03-U00282@SCALE.LOCAL (User)R00S03-U00282User · SCALE.LOCALR00S03-SERVERADMINS@SCALE.LOCAL (Group)R00S03-SERVERADMINSGroup · SCALE.LOCALR00S03-SRV0009.SCALE.LOCAL (Computer)R00S03-SRV0009Computer · SCALE.LOCALDA-ADMIN21@SCALE.LOCAL (User)DA-ADMIN21User · SCALE.LOCAL

              start target

              Path as text
              1. SVC-00030@SCALE.LOCAL (User)
              2. MemberOf SQL-ADMINS@SCALE.LOCAL (Group)
              3. AdminTo R00S03-SRV0000.SCALE.LOCAL (Computer)
              4. HasSession R00S03-U00282@SCALE.LOCAL (User)
              5. MemberOf R00S03-SERVERADMINS@SCALE.LOCAL (Group)
              6. AdminTo R00S03-SRV0009.SCALE.LOCAL (Computer)
              7. HasSession DA-ADMIN21@SCALE.LOCAL (User)
              Affected objects (1)
              User 1
              • SVC-00030
              CriticalKerberoastable account SVC-00045@SCALE.LOCAL has a path to Tier Zerofirst seen Oct 1 (run 1)Path cut: step 4password 831 days old
              Category
              Attack Path
              Exposure
              100% (24,414 of 24,414 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-006-5c8399d0a54665e0

              Its attack path is cut by remediation step 4. The account itself stays weak until it is fixed (see How to fix it), and could become a path again.

              Why it matters

              SVC-00045@SCALE.LOCAL has a service principal name, so any domain user can request a ticket encrypted with its password and crack it offline, and it has a path to Tier Zero. Its password was last set 831 days ago.

              How to fix it

              Remove unneeded SPNs from SVC-00045@SCALE.LOCAL, or move the service to a group Managed Service Account (gMSA). If the SPN must stay, set a random password of 25+ characters and allow only AES Kerberos encryption for the account.

              Attack path

              MemberOfAdminToHasSessionMemberOfAdminToHasSessionSVC-00045@SCALE.LOCAL (User)SVC-00045User · SCALE.LOCALSQL-ADMINS@SCALE.LOCAL (Group)SQL-ADMINSGroup · SCALE.LOCALR00S03-SRV0000.SCALE.LOCAL (Computer)R00S03-SRV0000Computer · SCALE.LOCALR00S03-U00282@SCALE.LOCAL (User)R00S03-U00282User · SCALE.LOCALR00S03-SERVERADMINS@SCALE.LOCAL (Group)R00S03-SERVERADMINSGroup · SCALE.LOCALR00S03-SRV0009.SCALE.LOCAL (Computer)R00S03-SRV0009Computer · SCALE.LOCALDA-ADMIN21@SCALE.LOCAL (User)DA-ADMIN21User · SCALE.LOCAL

              start target

              Path as text
              1. SVC-00045@SCALE.LOCAL (User)
              2. MemberOf SQL-ADMINS@SCALE.LOCAL (Group)
              3. AdminTo R00S03-SRV0000.SCALE.LOCAL (Computer)
              4. HasSession R00S03-U00282@SCALE.LOCAL (User)
              5. MemberOf R00S03-SERVERADMINS@SCALE.LOCAL (Group)
              6. AdminTo R00S03-SRV0009.SCALE.LOCAL (Computer)
              7. HasSession DA-ADMIN21@SCALE.LOCAL (User)
              Affected objects (1)
              User 1
              • SVC-00045
              CriticalKerberoastable account SVC-00010@SCALE.LOCAL has a path to Tier Zerofirst seen Oct 1 (run 1)Path cut: step 4password 769 days old
              Category
              Attack Path
              Exposure
              100% (24,414 of 24,414 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-006-24d8a8512c11264e

              Its attack path is cut by remediation step 4. The account itself stays weak until it is fixed (see How to fix it), and could become a path again.

              Why it matters

              SVC-00010@SCALE.LOCAL has a service principal name, so any domain user can request a ticket encrypted with its password and crack it offline, and it has a path to Tier Zero. Its password was last set 769 days ago.

              How to fix it

              Remove unneeded SPNs from SVC-00010@SCALE.LOCAL, or move the service to a group Managed Service Account (gMSA). If the SPN must stay, set a random password of 25+ characters and allow only AES Kerberos encryption for the account.

              Attack path

              MemberOfAdminToHasSessionMemberOfAdminToHasSessionSVC-00010@SCALE.LOCAL (User)SVC-00010User · SCALE.LOCALSQL-ADMINS@SCALE.LOCAL (Group)SQL-ADMINSGroup · SCALE.LOCALR00S03-SRV0000.SCALE.LOCAL (Computer)R00S03-SRV0000Computer · SCALE.LOCALR00S03-U00282@SCALE.LOCAL (User)R00S03-U00282User · SCALE.LOCALR00S03-SERVERADMINS@SCALE.LOCAL (Group)R00S03-SERVERADMINSGroup · SCALE.LOCALR00S03-SRV0009.SCALE.LOCAL (Computer)R00S03-SRV0009Computer · SCALE.LOCALDA-ADMIN21@SCALE.LOCAL (User)DA-ADMIN21User · SCALE.LOCAL

              start target

              Path as text
              1. SVC-00010@SCALE.LOCAL (User)
              2. MemberOf SQL-ADMINS@SCALE.LOCAL (Group)
              3. AdminTo R00S03-SRV0000.SCALE.LOCAL (Computer)
              4. HasSession R00S03-U00282@SCALE.LOCAL (User)
              5. MemberOf R00S03-SERVERADMINS@SCALE.LOCAL (Group)
              6. AdminTo R00S03-SRV0009.SCALE.LOCAL (Computer)
              7. HasSession DA-ADMIN21@SCALE.LOCAL (User)
              Affected objects (1)
              User 1
              • SVC-00010
              HighPW-004Tier Zero account logged on to non-Tier Zero hosts4 findings · 8 objects
              How to fix this kind of findingstep-by-step guide

              Category: Attack path Typical owner: AD / identity team together with the admins who own the account

              What this finding means

              A Tier Zero account (for example a Domain Admin) had a session on servers or workstations outside Tier Zero. While logged on, and often afterwards, its credentials are in that host's memory, so anyone with admin rights on the host can take them.

              Why attackers care

              Attackers who gain local admin on any listed host dump LSASS or steal Kerberos tickets (OS Credential Dumping: LSASS Memory, T1003.001) and immediately become Domain Admin. This is one of the most common paths in real intrusions and pentests, and usually the biggest choke point in pathwarden plan.

              Before you change anything

              • Ask the account owner why they log on to those hosts (RDP, scheduled task, service, mapped drive). Event 4624 on the host shows logon type: 2/10 interactive or RDP, 3 network, 4 batch, 5 service.
              • Services or scheduled tasks running as a Tier Zero account must be moved to a dedicated, non-privileged service account (or gMSA) first, or they will break.
              • Make sure each admin has a separate, non-Tier Zero account for daily work.

              Fix

              Option A: Separate accounts per tier and deny Tier Zero logon elsewhere (recommended)
              1. Give the admin a normal account for workstations and a Tier 1 account for servers if needed.
              2. In Group Policy Management, edit a GPO linked to all non-Tier Zero computers: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
              3. Add the Tier Zero groups (Domain Admins, Enterprise Admins, Schema Admins) to Deny log on locally, Deny log on through Remote Desktop Services, Deny log on as a batch job and Deny log on as a service.
              4. Log off the account on the listed hosts, or reboot them, to clear cached credentials.
              Option B: Authentication Policy Silos
              1. In Active Directory Administrative Center > Authentication, create an authentication policy and silo that allows Tier Zero accounts to authenticate only from Tier Zero hosts (requires Windows Server 2012 R2+ domain functional level).
              2. Assign the accounts and Tier Zero hosts to the silo; test in audit mode first.
              Option C: Protected Users

              Add the account to Protected Users: no NTLM, no delegation, no cached credentials, 4-hour TGTs. Test first: it breaks NTLM-only apps for that account.

              PowerShell
              Import-Module ActiveDirectory
              
              # Where has the account logged on recently? (run on a host from the finding)
              Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4624 } -MaxEvents 2000 |
                  Where-Object { $_.Properties[5].Value -eq '<Account>' } |
                  Select-Object TimeCreated, @{ n = 'LogonType'; e = { $_.Properties[8].Value } }
              
              # Services and scheduled tasks running as the account on a host
              Get-CimInstance Win32_Service -ComputerName <Computer> | Where-Object StartName -like '*<Account>*'
              Get-ScheduledTask -CimSession <Computer> | Where-Object { $_.Principal.UserId -like '*<Account>*' }
              
              # Add the account to Protected Users (after testing)
              Add-ADGroupMember -Identity "Protected Users" -Members "<Account>"
              

              Verify

              After the deny rights apply (gpupdate /force, or the next refresh), a logon attempt by the Tier Zero account on a listed host must fail. Collect again (or use Retest in the app, or pathwarden retest on the CLI) and confirm the finding ID is gone.

              Rollback

              Remove the groups from the Deny user rights in the GPO (or unlink it) and run gpupdate /force; remove the account from Protected Users with Remove-ADGroupMember "Protected Users" -Members "<Account>".

              References

              • https://attack.mitre.org/techniques/T1003/001/
              • https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
              • https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos
              HighDA-ADMIN18@SCALE.LOCAL is logged on to 1 non-Tier Zero hostfirst seen Oct 1 (run 1)Closed: step 219.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-004-cebd78dc4c40ae72

              Closed by remediation step 2.

              Why it matters

              Tier Zero account DA-ADMIN18@SCALE.LOCAL had sessions on R01S03-SRV0008.SCALE.LOCAL. Anyone with admin rights on those hosts can take its credentials from memory.

              User 1
              • DA-ADMIN18
              Computer 1
              • R01S03-SRV0008

              How to fix it

              Use a separate admin account per tier so DA-ADMIN18@SCALE.LOCAL only logs on to Tier Zero systems. Enforce it with 'Deny log on' user rights or Authentication Policy Silos, add the account to Protected Users, and log off or reboot the listed hosts to clear cached credentials.

              HighNewDA-ADMIN21@SCALE.LOCAL is logged on to 1 non-Tier Zero hostfirst seen Nov 2 (run 5)Closed: step 410.84% exposed
              Category
              Attack Path
              Exposure
              10.84% (2,335 of 21,548 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Nov 2 (run 5)
              Finding ID
              PW-004-ceba12dc4c3dcb49

              Closed by remediation step 4.

              Why it matters

              Tier Zero account DA-ADMIN21@SCALE.LOCAL had sessions on R00S03-SRV0009.SCALE.LOCAL. Anyone with admin rights on those hosts can take its credentials from memory.

              User 1
              • DA-ADMIN21
              Computer 1
              • R00S03-SRV0009

              How to fix it

              Use a separate admin account per tier so DA-ADMIN21@SCALE.LOCAL only logs on to Tier Zero systems. Enforce it with 'Deny log on' user rights or Authentication Policy Silos, add the account to Protected Users, and log off or reboot the listed hosts to clear cached credentials.

              HighDA-ADMIN24@SCALE.LOCAL is logged on to 1 non-Tier Zero hostfirst seen Oct 1 (run 1)Closed: step 119.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-004-cec444dc4c4674c4

              Closed by remediation step 1.

              Why it matters

              Tier Zero account DA-ADMIN24@SCALE.LOCAL had sessions on R01S01-SRV0001.SCALE.LOCAL. Anyone with admin rights on those hosts can take its credentials from memory.

              User 1
              • DA-ADMIN24
              Computer 1
              • R01S01-SRV0001

              How to fix it

              Use a separate admin account per tier so DA-ADMIN24@SCALE.LOCAL only logs on to Tier Zero systems. Enforce it with 'Deny log on' user rights or Authentication Policy Silos, add the account to Protected Users, and log off or reboot the listed hosts to clear cached credentials.

              HighDA-ADMIN39@SCALE.LOCAL is logged on to 1 non-Tier Zero hostfirst seen Oct 1 (run 1)Closed: step 311.11% exposed
              Category
              Attack Path
              Exposure
              11.11% (2,395 of 21,562 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-004-df3a54dc555ac4b1

              Closed by remediation step 3.

              Why it matters

              Tier Zero account DA-ADMIN39@SCALE.LOCAL had sessions on R02S02-SRV0014.SCALE.LOCAL. Anyone with admin rights on those hosts can take its credentials from memory.

              User 1
              • DA-ADMIN39
              Computer 1
              • R02S02-SRV0014

              How to fix it

              Use a separate admin account per tier so DA-ADMIN39@SCALE.LOCAL only logs on to Tier Zero systems. Enforce it with 'Deny log on' user rights or Authentication Policy Silos, add the account to Protected Users, and log off or reboot the listed hosts to clear cached credentials.

              HighPW-002Non-Tier Zero principal can DCSync1 finding · 2 objects
              How to fix this kind of findingstep-by-step guide

              Category: Attack path Typical owner: AD / identity team

              What this finding means

              A user, computer or group outside Tier Zero holds both directory replication rights on the domain object: "Replicating Directory Changes" and "Replicating Directory Changes All" (directly or through group membership). Together they let it ask a domain controller for the password hash of any account.

              Why attackers care

              DCSync (OS Credential Dumping: DCSync, T1003.006) lets an attacker who controls this principal pull the krbtgt hash and every admin hash remotely, without touching a domain controller's disk. With the krbtgt hash they can forge golden tickets and keep domain access until krbtgt is rotated twice. Tools such as Mimikatz and Impacket secretsdump do this in one command.

              Before you change anything

              • Identify what the principal is. Legitimate holders besides domain controllers are rare: Entra Connect (MSOL_ / AAD sync) accounts, some identity governance, backup or password-sync products.
              • Check whether it actually replicates: on domain controllers, audit "Directory Service Access" and look for event 4662 with the replication GUIDs 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 and 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 and the principal as subject.
              • If it is a sync account that must keep the rights, do not remove them: treat the account and its server as Tier Zero instead (Option B).

              Fix

              Option A: Remove the replication rights (recommended when not needed)
              1. In Active Directory Users and Computers, enable View > Advanced Features.
              2. Right-click the domain, Properties > Security > Advanced.
              3. Find entries for the principal (or the group that grants it) with "Replicating Directory Changes" / "Replicating Directory Changes All".
              4. Select each and click Remove, then OK.
              5. If the right comes through a group, remove the principal from that group instead.
              Option B: Keep the rights, manage the principal as Tier Zero
              1. Add the account and the server it runs on to tier_zero in pathwarden.toml.
              2. Restrict logon to that server to Tier Zero admins, protect the account (long random password or gMSA where the product supports it), and monitor event 4662 for replication from any other source.
              PowerShell
              Import-Module ActiveDirectory
              $domainDN = (Get-ADDomain).DistinguishedName
              $acl = Get-Acl -Path "AD:\$domainDN"
              
              # Replication extended rights
              $getChanges    = [Guid]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"
              $getChangesAll = [Guid]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"
              
              # Show who holds them
              $acl.Access | Where-Object { $_.ObjectType -in $getChanges, $getChangesAll } |
                  Select-Object IdentityReference, ObjectType, IsInherited
              
              # Save the current descriptor, then remove the principal's entries
              $acl.Sddl | Out-File ".\domain-acl-backup.txt"
              $acl.Access | Where-Object {
                  $_.ObjectType -in $getChanges, $getChangesAll -and $_.IdentityReference -like "*<Account>"
              } | ForEach-Object { [void]$acl.RemoveAccessRule($_) }
              Set-Acl -Path "AD:\$domainDN" -AclObject $acl
              

              Verify

              Re-run the "Show who holds them" query; only domain controllers, Enterprise Domain Controllers, Administrators and intended sync accounts should remain. Collect again (or use Retest in the app, or pathwarden retest on the CLI) and confirm the finding ID is gone.

              Rollback

              Restore the saved descriptor: $acl = Get-Acl "AD:\$domainDN"; $acl.SetSecurityDescriptorSddlForm((Get-Content .\domain-acl-backup.txt)); Set-Acl "AD:\$domainDN" $acl

              References

              • https://attack.mitre.org/techniques/T1003/006/
              • https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-configure-ad-ds-connector-account
              • https://bloodhound.specterops.io/
              HighSVC-ADSYNC@SCALE.LOCAL can DCSync SCALE.LOCALfirst seen Oct 1 (run 1)Closed: step 5<0.01% exposed
              Category
              Attack Path
              Exposure
              <0.01% (1 of 21,233 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-002-d584a9162639fa4a

              Closed by remediation step 5.

              Why it matters

              SVC-ADSYNC@SCALE.LOCAL holds both directory replication rights on SCALE.LOCAL. It can request the password hash of any account, including krbtgt, which is full domain compromise.

              How to fix it

              Remove the 'Replicating Directory Changes' and 'Replicating Directory Changes All' rights granted to SVC-ADSYNC@SCALE.LOCAL on SCALE.LOCAL, or remove SVC-ADSYNC@SCALE.LOCAL from the group that grants them. Only domain controllers need these rights. If this is an Entra Connect or similar sync account, keep the rights but manage the account and its server as Tier Zero (--tier-zero).

              Attack path

              DCSyncSVC-ADSYNC@SCALE.LOCAL (User)SVC-ADSYNCUser · SCALE.LOCALSCALE.LOCAL (Domain)SCALE.LOCALDomain

              start target

              Path as text
              1. SVC-ADSYNC@SCALE.LOCAL (User)
              2. DCSync SCALE.LOCAL (Domain)
              Affected objects (2)
              User 1
              • SVC-ADSYNC
              Domain 1
              • SCALE.LOCAL
              MediumPW-008Tier Zero accounts without delegation protection1 finding · 41 users
              How to fix this kind of findingstep-by-step guide

              Category: Hygiene Typical owner: AD / identity team

              What this finding means

              These Tier Zero user accounts are neither members of the Protected Users group nor marked "Account is sensitive and cannot be delegated". Their credentials can therefore be cached on the machines they log on to, and their Kerberos tickets can be forwarded by any service trusted for delegation.

              Why attackers care

              An attacker who controls a server trusted for unconstrained or constrained delegation can impersonate any delegatable account that authenticates to it, including Domain Admins (Kerberos delegation abuse, MITRE ATT&CK T1558). Accounts outside Protected Users also leave NTLM hashes and long-lived credentials in LSASS memory, which tools like Mimikatz extract (OS Credential Dumping, T1003.001). Protected Users removes both of these options for its members.

              Before you change anything

              • Protected Users members cannot use NTLM, DES or RC4 Kerberos encryption, Kerberos delegation, or cached (offline) logons, and their Kerberos TGTs last 4 hours. Anything that relies on these will break for the account.
              • Never add service accounts or computer accounts to Protected Users. Use the "sensitive and cannot be delegated" flag (Option B) for service accounts that are Tier Zero.
              • Check for NTLM use by the account first: enable NTLM auditing ("Network security: Restrict NTLM: Audit NTLM authentication in this domain") and review event 8004 on domain controllers, or 4624 events with Authentication Package NTLM.
              • Make sure the domain functional level is Windows Server 2012 R2 or later. Protected Users only takes full effect from that level.
              • Keep at least one break-glass account outside Protected Users in case Kerberos fails. Store its password offline.

              Fix

              Option A: Add Tier Zero user accounts to Protected Users (recommended)
              1. Open Active Directory Users and Computers (dsa.msc).
              2. Go to the Users container and open the Protected Users group.
              3. Members tab > Add. Add one test admin account first.
              4. Sign out and sign back in with that account. Confirm your admin tools still work.
              5. Add the remaining interactive Tier Zero admin accounts listed in the finding.
              Option B: Mark the account "sensitive and cannot be delegated"

              Use this for accounts that cannot join Protected Users, such as Tier Zero service accounts.

              1. In dsa.msc, open the account > Account tab.
              2. Under Account options, tick Account is sensitive and cannot be delegated.
              3. Click OK.
              PowerShell
              Import-Module ActiveDirectory
              
              # Option A: add an interactive admin account to Protected Users
              Add-ADGroupMember -Identity "Protected Users" -Members "<Account>"
              
              # Option B: block delegation for an account that cannot join Protected Users
              Set-ADUser -Identity "<Account>" -AccountNotDelegated $true
              

              Verify

              # Members of Protected Users
              Get-ADGroupMember -Identity "Protected Users" | Select-Object SamAccountName
              
              # Accounts flagged as not delegatable
              Get-ADUser -Identity "<Account>" -Properties AccountNotDelegated |
                  Select-Object SamAccountName, AccountNotDelegated
              

              Collect again (or use Retest in the app, or pathwarden retest on the CLI) and confirm the finding ID is gone (or lists fewer accounts).

              Rollback

              • Remove the account from the group: Remove-ADGroupMember -Identity "Protected Users" -Members "<Account>". The change applies at the account's next logon. Existing tickets expire within 4 hours.
              • Clear the flag: Set-ADUser -Identity "<Account>" -AccountNotDelegated $false.

              References

              • https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
              • https://attack.mitre.org/techniques/T1558/
              • https://attack.mitre.org/techniques/T1003/001/
              Medium41 Tier Zero accounts in SCALE.LOCAL can be delegatedfirst seen Oct 1 (run 1)Fix directly
              Category
              Hygiene
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-008-33a491c0476985ce

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              41 Tier Zero accounts are neither in Protected Users nor marked 'sensitive and cannot be delegated', so their credentials can be cached on other systems or delegated to them.

              Users 41
              • DA-ADMIN00
              • DA-ADMIN01
              • DA-ADMIN02
              • DA-ADMIN03
              • DA-ADMIN04
              • DA-ADMIN05
              • DA-ADMIN06
              • DA-ADMIN07
              • DA-ADMIN08
              • DA-ADMIN09
              • DA-ADMIN10
              • DA-ADMIN11
              Show 29 more
              • DA-ADMIN12
              • DA-ADMIN13
              • DA-ADMIN14
              • DA-ADMIN15
              • DA-ADMIN16
              • DA-ADMIN17
              • DA-ADMIN18
              • DA-ADMIN19
              • DA-ADMIN20
              • DA-ADMIN21
              • DA-ADMIN22
              • DA-ADMIN23
              • DA-ADMIN24
              • DA-ADMIN25
              • DA-ADMIN26
              • DA-ADMIN27
              • DA-ADMIN28
              • DA-ADMIN29
              • DA-ADMIN30
              • DA-ADMIN31
              • DA-ADMIN32
              • DA-ADMIN33
              • DA-ADMIN34
              • DA-ADMIN35
              • DA-ADMIN36
              • DA-ADMIN37
              • DA-ADMIN38
              • DA-ADMIN39
              • SVC-00000

              How to fix it

              Add Tier Zero user accounts to the Protected Users group (test service accounts first), or at minimum set 'Account is sensitive and cannot be delegated'.

              MediumPW-009Stale Tier Zero accounts1 finding · 2 users
              How to fix this kind of findingstep-by-step guide

              Category: Hygiene Typical owner: AD / identity team

              What this finding means

              These accounts are enabled and hold Tier Zero privileges, but they have not logged on within the configured period (90 days by default) or have never logged on at all. Nobody appears to use them, yet they could still take over the domain.

              Why attackers care

              Dormant privileged accounts are ideal targets. Their passwords are often old or reused, and nobody notices when they are used again. An attacker who guesses, sprays or cracks such a password gets Tier Zero access through a legitimate account (Valid Accounts: Domain Accounts, MITRE ATT&CK T1078.002). Unused accounts also tend to sit outside monitoring and MFA rollouts.

              Before you change anything

              • Confirm with the account owner (from the description, the manager attribute or your IAM system) that the account is not needed.
              • Service accounts may authenticate without updating lastLogonTimestamp the way you expect. Check for recent 4624 / 4768 / 4769 events for the account on domain controllers before disabling.
              • lastLogonTimestamp replicates with up to a 14-day lag. Treat dates as approximate.
              • For break-glass accounts that are meant to be unused, document them and suppress the finding in pathwarden.toml with an expiry date instead of disabling them.

              Fix

              Option A: Disable the account (recommended)
              1. Open Active Directory Users and Computers (dsa.msc).
              2. Find the account, right-click > Disable Account.
              3. Add a note in the Description field (date, ticket number) and leave it disabled for a grace period (for example 30 days) before deleting it.
              Option B: Remove the privileged group memberships

              If the account must stay enabled, for example for a rarely used process:

              1. Open the account > Member Of tab.
              2. Remove Domain Admins, Enterprise Admins, Administrators and any other Tier Zero group.
              3. Grant only the specific rights the process needs.
              PowerShell
              Import-Module ActiveDirectory
              
              # Review last logon and group memberships first
              Get-ADUser -Identity "<Account>" -Properties LastLogonDate, MemberOf, Description |
                  Select-Object SamAccountName, LastLogonDate, Description, MemberOf
              
              # Option A: disable and annotate
              Disable-ADAccount -Identity "<Account>"
              Set-ADUser -Identity "<Account>" -Description "Disabled <date> - stale Tier Zero account, ticket <ID>"
              
              # Option B: remove from a privileged group instead
              Remove-ADGroupMember -Identity "Domain Admins" -Members "<Account>" -Confirm:$false
              

              Verify

              Get-ADUser -Identity "<Account>" -Properties Enabled, MemberOf |
                  Select-Object SamAccountName, Enabled, MemberOf
              

              Collect again (or use Retest in the app, or pathwarden retest on the CLI) and confirm the finding ID is gone (or lists fewer accounts).

              Rollback

              • Re-enable the account with Enable-ADAccount -Identity "<Account>".
              • Re-add removed group memberships with Add-ADGroupMember. Record the original memberships (the review command above) before removing them.

              References

              • https://attack.mitre.org/techniques/T1078/002/
              • https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models
              Medium2 stale Tier Zero accounts in SCALE.LOCALfirst seen Oct 1 (run 1)Fix directly
              Category
              Hygiene
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-009-c76a7235b7c3c407

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              2 enabled Tier Zero accounts have not logged on in over 90 days, or never. Unused privileged accounts are attack surface nobody is watching.

              Users 2
              • DA-ADMIN16last logon 3 months ago
              • DA-ADMIN35last logon 3 months ago

              How to fix it

              Disable these accounts, or remove them from privileged groups if they are still needed.

              MediumPW-010Old Tier Zero passwords1 finding · 25 users
              How to fix this kind of findingstep-by-step guide

              Category: Hygiene Typical owner: AD / identity team (service account owners for service accounts)

              What this finding means

              These Tier Zero accounts have passwords older than the configured limit (365 days by default). The longer a privileged password lives, the more places it may have leaked to: old backups, scripts, memory dumps, password managers of former staff, or earlier breaches.

              Why attackers care

              Attackers routinely recover old credential material, such as NTDS.dit backups, LSASS dumps from decommissioned servers and cracked hashes from earlier intrusions. A password that has not changed since then still works (Valid Accounts: Domain Accounts, MITRE ATT&CK T1078.002). If an attacker has the NTLM hash of an unchanged account, pass-the-hash keeps working until the password changes (Use Alternate Authentication Material: Pass the Hash, T1550.002).

              Before you change anything

              • For service accounts, find every place the password is configured (services, scheduled tasks, IIS application pools, application config files, scripts) before rotating. Check 4625 failures on domain controllers right after the change to catch anything you missed.
              • Check for "password never expires": Get-ADUser <Account> -Properties PasswordNeverExpires.
              • Interactive admins should change their own password so they choose and store it securely.
              • Prefer migrating service accounts to group Managed Service Accounts (gMSA), which rotate automatically.

              Fix

              Option A: Rotate the password now (recommended)
              1. Open Active Directory Users and Computers (dsa.msc).
              2. Right-click the account > Reset Password.
              3. Set a long random password (25+ characters for service accounts) and store it in your privileged access vault.
              4. For service accounts, update every place that uses the password, then restart the dependent services.
              Option B: Move service accounts to a gMSA
              1. Create a gMSA (New-ADServiceAccount) that the hosts running the service are allowed to use.
              2. Install it on those hosts (Install-ADServiceAccount) and reconfigure the service to run as <Domain>\<gMSA>$ with an empty password.
              3. Disable the old account once the service runs under the gMSA.
              PowerShell
              Import-Module ActiveDirectory
              
              # Review password age
              Get-ADUser -Identity "<Account>" -Properties PasswordLastSet, PasswordNeverExpires |
                  Select-Object SamAccountName, PasswordLastSet, PasswordNeverExpires
              
              # Reset the password (prompts for the new value without echoing it)
              Set-ADAccountPassword -Identity "<Account>" -Reset -NewPassword (Read-Host -AsSecureString "New password")
              
              # Optional: let the normal password policy apply again
              Set-ADUser -Identity "<Account>" -PasswordNeverExpires $false
              

              Verify

              Get-ADUser -Identity "<Account>" -Properties PasswordLastSet |
                  Select-Object SamAccountName, PasswordLastSet
              

              Collect again (or use Retest in the app, or pathwarden retest on the CLI) and confirm the finding ID is gone (or lists fewer accounts).

              Rollback

              A password cannot be "un-rotated". If a service breaks, set the new password wherever the service is configured (or reset again to a value you control and update the service), then restart the service. Check 4625 events to find the failing host.

              References

              • https://attack.mitre.org/techniques/T1078/002/
              • https://attack.mitre.org/techniques/T1550/002/
              • https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview
              Medium25 Tier Zero passwords older than 365 days in SCALE.LOCALfirst seen Oct 1 (run 1)Fix directly
              Category
              Hygiene
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-010-50b46fb4238f69a1

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              25 Tier Zero accounts have passwords older than 365 days. Old passwords are more likely to have been exposed in past breaches, backups or memory dumps.

              Users 25
              • DA-ADMIN01password set 20 months ago
              • DA-ADMIN03password set 13 months ago
              • DA-ADMIN04password set 20 months ago
              • DA-ADMIN05password set 24 months ago
              • DA-ADMIN06password set 16 months ago
              • DA-ADMIN08password set 2 years ago
              • DA-ADMIN09password set 18 months ago
              • DA-ADMIN10password set 16 months ago
              • DA-ADMIN11password set 18 months ago
              • DA-ADMIN13password set 23 months ago
              • DA-ADMIN14password set 2 years ago
              • DA-ADMIN15password set 2 years ago
              Show 13 more
              • DA-ADMIN16password set 2 years ago
              • DA-ADMIN19password set 20 months ago
              • DA-ADMIN20password set 2 years ago
              • DA-ADMIN22password set 21 months ago
              • DA-ADMIN23password set 2 years ago
              • DA-ADMIN24password set 14 months ago
              • DA-ADMIN27password set 2 years ago
              • DA-ADMIN28password set 13 months ago
              • DA-ADMIN32password set 19 months ago
              • DA-ADMIN34password set 23 months ago
              • DA-ADMIN35password set 2 years ago
              • DA-ADMIN36password set 19 months ago
              • SVC-00000password set 7 years ago

              How to fix it

              Rotate these passwords. For service accounts, migrate to gMSAs so rotation is automatic.

              MediumPW-011Computers without LAPS1 finding · 538 computers
              How to fix this kind of findingstep-by-step guide

              Category: Hygiene Typical owner: Desktop / server team, with the AD team for schema and permissions

              What this finding means

              These enabled computers (domain controllers excluded) do not have their local administrator password managed by LAPS. Their built-in local Administrator password is probably set by an image or a script, and is often identical across many machines.

              Standalone managed service accounts (sMSA) are not reported: they appear as computer-like objects but have no interactive local administrator, so LAPS doesn't apply. Pathwarden recognises them from SharpHound's msa flag, and in RustHound-CE or built-in collections (which type an sMSA as a computer with no flag) from its membership of the domain's Managed Service Accounts container.

              Why attackers care

              After compromising one computer, an attacker dumps the local Administrator hash from the SAM and tries it everywhere. If the password is shared, every computer with the same password falls (Use Alternate Authentication Material: Pass the Hash, MITRE ATT&CK T1550.002, and Lateral Movement via SMB/Windows Admin Shares, T1021.002). This is one of the most common ways a single phished workstation turns into domain-wide compromise during a pentest.

              Before you change anything

              • Windows LAPS is built into Windows 10/11 and Windows Server 2019 and later with the April 2023 update. Older systems need legacy Microsoft LAPS, or an upgrade.
              • Decide who may read passwords. By default only Domain Admins can. Grant read access to a dedicated helpdesk/desktop group per OU, never to broad groups.
              • Check for tooling that relies on the shared local admin password (deployment scripts, remote support tools) and move it to LAPS retrieval or domain accounts first.
              • The schema update is forest-wide and needs Schema Admins rights. Plan it with the AD team.

              Fix

              Option A: Deploy Windows LAPS by Group Policy (recommended)
              1. Extend the schema once: run Update-LapsADSchema as a Schema Admin.
              2. Let computers write their own password: Set-LapsADComputerSelfPermission -Identity "<OU>".
              3. Grant read access to the support group: Set-LapsADReadPasswordPermission -Identity "<OU>" -AllowedPrincipals "<Domain>\<SupportGroup>".
              4. In Group Policy Management, create a GPO linked to the OU and open Computer Configuration > Policies > Administrative Templates > System > LAPS.
              5. Enable Configure password backup directory = Active Directory, and set Password Settings (complexity, length 15+, age 30 days).
              6. Run gpupdate /force on a test computer and check that a password appears (see Verify).
              7. Widen the GPO to the remaining OUs in the finding.
              Option B: Intune (for Entra-joined or co-managed devices)

              Use an Intune Endpoint security > Account protection > Local admin password solution policy with the backup directory set to Active Directory (for hybrid-joined) or Entra ID.

              PowerShell
              # One-time forest preparation (Schema Admins)
              Update-LapsADSchema
              
              # Per OU: allow computers to update their own password attributes
              Set-LapsADComputerSelfPermission -Identity "<OU>"
              
              # Per OU: allow the support group to read passwords
              Set-LapsADReadPasswordPermission -Identity "<OU>" -AllowedPrincipals "<Domain>\<SupportGroup>"
              
              # After GPO deployment: confirm a computer has a managed password
              Get-LapsADPassword -Identity "<Computer>" -AsPlainText
              

              Verify

              Get-LapsADPassword -Identity "<Computer>" returns a password and an expiration time. On the client, the event log Applications and Services Logs > Microsoft > Windows > LAPS > Operational shows successful password updates. Collect again (or use Retest in the app, or pathwarden retest on the CLI) and confirm the finding ID is gone (or lists fewer computers).

              Rollback

              Unlink or disable the LAPS GPO. Computers keep their last LAPS-set password, so retrieve it with Get-LapsADPassword before removing read permissions. The schema extension is permanent but harmless.

              References

              • https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview
              • https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-windows-server-active-directory
              • https://attack.mitre.org/techniques/T1550/002/
              Medium538 computers in SCALE.LOCAL without LAPSfirst seen Oct 1 (run 1)Fix directly
              Category
              Hygiene
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-011-021381e29c52fef8

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              538 computers have local administrator passwords that LAPS doesn't manage. Unmanaged local admin passwords are often the same across machines, so one compromise spreads to the others.

              Computers 538
              • R00S00-SRV0008
              • R00S00-SRV0009
              • R00S00-SRV0010
              • R00S00-WS00006
              • R00S00-WS00027
              • R00S00-WS00041
              • R00S00-WS00059
              • R00S00-WS00093
              • R00S00-WS00124
              • R00S00-WS00127
              • R00S00-WS00149
              • R00S00-WS00161
              Show 526 more
              • R00S00-WS00184
              • R00S00-WS00216
              • R00S00-WS00221
              • R00S00-WS00227
              • R00S00-WS00228
              • R00S00-WS00242
              • R00S00-WS00294
              • R00S00-WS00304
              • R00S00-WS00321
              • R00S00-WS00325
              • R00S00-WS00340
              • R00S00-WS00341
              • R00S00-WS00346
              • R00S00-WS00353
              • R00S00-WS00367
              • R00S00-WS00417
              • R00S00-WS00418
              • R00S00-WS00442
              • R00S00-WS00466
              • R00S01-SRV0014
              • R00S01-WS00023
              • R00S01-WS00027
              • R00S01-WS00030
              • R00S01-WS00031
              • R00S01-WS00062
              • R00S01-WS00143
              • R00S01-WS00187
              • R00S01-WS00222
              • R00S01-WS00232
              • R00S01-WS00240
              • R00S01-WS00241
              • R00S01-WS00244
              • R00S01-WS00252
              • R00S01-WS00278
              • R00S01-WS00288
              • R00S01-WS00290
              • R00S01-WS00313
              • R00S01-WS00315
              • R00S01-WS00331
              • R00S01-WS00334
              • R00S01-WS00343
              • R00S01-WS00361
              • R00S01-WS00365
              • R00S01-WS00374
              • R00S01-WS00381
              • R00S01-WS00411
              • R00S01-WS00454
              • R00S01-WS00472
              • R00S02-SRV0013
              • R00S02-WS00002
              • R00S02-WS00003
              • R00S02-WS00004
              • R00S02-WS00037
              • R00S02-WS00054
              • R00S02-WS00074
              • R00S02-WS00081
              • R00S02-WS00139
              • R00S02-WS00170
              • R00S02-WS00190
              • R00S02-WS00207
              • R00S02-WS00221
              • R00S02-WS00240
              • R00S02-WS00278
              • R00S02-WS00312
              • R00S02-WS00316
              • R00S02-WS00329
              • R00S02-WS00400
              • R00S02-WS00415
              • R00S02-WS00428
              • R00S02-WS00440
              • R00S02-WS00442
              • R00S02-WS00453
              • R00S02-WS00471
              • R00S02-WS00472
              • R00S02-WS00475
              • R00S02-WS00481
              • R00S03-SRV0010
              • R00S03-WS00009
              • R00S03-WS00030
              • R00S03-WS00039
              • R00S03-WS00048
              • R00S03-WS00051
              • R00S03-WS00063
              • R00S03-WS00083
              • R00S03-WS00139
              • R00S03-WS00141
              • R00S03-WS00180
              • R00S03-WS00221
              • R00S03-WS00229
              • R00S03-WS00248
              • R00S03-WS00250
              • R00S03-WS00263
              • R00S03-WS00266
              • R00S03-WS00316
              • R00S03-WS00321
              • R00S03-WS00330
              • R00S03-WS00400
              • R00S03-WS00402
              • R00S03-WS00408
              • R00S03-WS00439
              • R01S00-WS00004
              • R01S00-WS00022
              • R01S00-WS00056
              • R01S00-WS00057
              • R01S00-WS00065
              • R01S00-WS00072
              • R01S00-WS00087
              • R01S00-WS00102
              • R01S00-WS00109
              • R01S00-WS00134
              • R01S00-WS00136
              • R01S00-WS00150
              • R01S00-WS00156
              • R01S00-WS00157
              • R01S00-WS00168
              • R01S00-WS00171
              • R01S00-WS00173
              • R01S00-WS00190
              • R01S00-WS00250
              • R01S00-WS00263
              • R01S00-WS00264
              • R01S00-WS00268
              • R01S00-WS00326
              • R01S00-WS00347
              • R01S00-WS00477
              • R01S01-SRV0004
              • R01S01-WS00000
              • R01S01-WS00036
              • R01S01-WS00041
              • R01S01-WS00084
              • R01S01-WS00089
              • R01S01-WS00121
              • R01S01-WS00141
              • R01S01-WS00145
              • R01S01-WS00161
              • R01S01-WS00169
              • R01S01-WS00194
              • R01S01-WS00201
              • R01S01-WS00217
              • R01S01-WS00233
              • R01S01-WS00257
              • R01S01-WS00303
              • R01S01-WS00313
              • R01S01-WS00324
              • R01S01-WS00333
              • R01S01-WS00334
              • R01S01-WS00354
              • R01S01-WS00356
              • R01S01-WS00359
              • R01S01-WS00370
              • R01S01-WS00383
              • R01S01-WS00403
              • R01S01-WS00427
              • R01S01-WS00437
              • R01S01-WS00439
              • R01S02-SRV0005
              • R01S02-SRV0006
              • R01S02-WS00003
              • R01S02-WS00012
              • R01S02-WS00058
              • R01S02-WS00062
              • R01S02-WS00065
              • R01S02-WS00095
              • R01S02-WS00096
              • R01S02-WS00098
              • R01S02-WS00100
              • R01S02-WS00134
              • R01S02-WS00137
              • R01S02-WS00143
              • R01S02-WS00145
              • R01S02-WS00162
              • R01S02-WS00163
              • R01S02-WS00190
              • R01S02-WS00198
              • R01S02-WS00210
              • R01S02-WS00245
              • R01S02-WS00266
              • R01S02-WS00273
              • R01S02-WS00276
              • R01S02-WS00284
              • R01S02-WS00292
              • R01S02-WS00316
              • R01S02-WS00322
              • R01S02-WS00371
              • R01S02-WS00381
              • R01S02-WS00396
              • R01S02-WS00399
              • R01S02-WS00402
              • R01S02-WS00434
              • R01S02-WS00448
              • R01S02-WS00471
              • R01S03-WS00012
              • R01S03-WS00032
              • R01S03-WS00045
              • R01S03-WS00049
              • R01S03-WS00086
              • R01S03-WS00101
              • R01S03-WS00119
              • R01S03-WS00122
              • R01S03-WS00128
              • R01S03-WS00144
              • R01S03-WS00170
              • R01S03-WS00176
              • R01S03-WS00181
              • R01S03-WS00182
              • R01S03-WS00245
              • R01S03-WS00250
              • R01S03-WS00269
              • R01S03-WS00297
              • R01S03-WS00306
              • R01S03-WS00308
              • R01S03-WS00364
              • R01S03-WS00368
              • R01S03-WS00396
              • R01S03-WS00397
              • R01S03-WS00428
              • R01S03-WS00445
              • R01S03-WS00465
              • R02S00-WS00120
              • R02S00-WS00129
              • R02S00-WS00159
              • R02S00-WS00164
              • R02S00-WS00250
              • R02S00-WS00277
              • R02S00-WS00278
              • R02S00-WS00281
              • R02S00-WS00283
              • R02S00-WS00299
              • R02S00-WS00306
              • R02S00-WS00316
              • R02S00-WS00327
              • R02S00-WS00373
              • R02S00-WS00415
              • R02S00-WS00422
              • R02S00-WS00426
              • R02S00-WS00449
              • R02S00-WS00460
              • R02S00-WS00463
              • R02S01-SRV0003
              • R02S01-SRV0005
              • R02S01-SRV0011
              • R02S01-WS00046
              • R02S01-WS00051
              • R02S01-WS00063
              • R02S01-WS00099
              • R02S01-WS00171
              • R02S01-WS00184
              • R02S01-WS00194
              • R02S01-WS00260
              • R02S01-WS00267
              • R02S01-WS00274
              • R02S01-WS00276
              • R02S01-WS00277
              • R02S01-WS00299
              • R02S01-WS00333
              • R02S01-WS00384
              • R02S01-WS00391
              • R02S01-WS00435
              • R02S01-WS00449
              • R02S02-WS00008
              • R02S02-WS00015
              • R02S02-WS00018
              • R02S02-WS00033
              • R02S02-WS00069
              • R02S02-WS00100
              • R02S02-WS00109
              • R02S02-WS00130
              • R02S02-WS00134
              • R02S02-WS00137
              • R02S02-WS00169
              • R02S02-WS00187
              • R02S02-WS00219
              • R02S02-WS00237
              • R02S02-WS00247
              • R02S02-WS00264
              • R02S02-WS00284
              • R02S02-WS00297
              • R02S02-WS00302
              • R02S02-WS00325
              • R02S02-WS00351
              • R02S02-WS00375
              • R02S02-WS00412
              • R02S02-WS00417
              • R02S02-WS00436
              • R02S02-WS00456
              • R02S02-WS00461
              • R02S03-WS00004
              • R02S03-WS00013
              • R02S03-WS00027
              • R02S03-WS00035
              • R02S03-WS00060
              • R02S03-WS00088
              • R02S03-WS00115
              • R02S03-WS00131
              • R02S03-WS00133
              • R02S03-WS00146
              • R02S03-WS00156
              • R02S03-WS00157
              • R02S03-WS00161
              • R02S03-WS00169
              • R02S03-WS00219
              • R02S03-WS00239
              • R02S03-WS00242
              • R02S03-WS00244
              • R02S03-WS00249
              • R02S03-WS00259
              • R02S03-WS00261
              • R02S03-WS00292
              • R02S03-WS00314
              • R02S03-WS00363
              • R02S03-WS00401
              • R02S03-WS00416
              • R02S03-WS00425
              • R03S00-SRV0002
              • R03S00-SRV0003
              • R03S00-WS00009
              • R03S00-WS00020
              • R03S00-WS00044
              • R03S00-WS00060
              • R03S00-WS00085
              • R03S00-WS00094
              • R03S00-WS00100
              • R03S00-WS00107
              • R03S00-WS00108
              • R03S00-WS00112
              • R03S00-WS00114
              • R03S00-WS00116
              • R03S00-WS00117
              • R03S00-WS00199
              • R03S00-WS00206
              • R03S00-WS00222
              • R03S00-WS00266
              • R03S00-WS00301
              • R03S00-WS00339
              • R03S00-WS00342
              • R03S00-WS00346
              • R03S00-WS00349
              • R03S00-WS00380
              • R03S00-WS00396
              • R03S00-WS00425
              • R03S00-WS00461
              • R03S00-WS00483
              • R03S01-SRV0012
              • R03S01-WS00005
              • R03S01-WS00031
              • R03S01-WS00040
              • R03S01-WS00050
              • R03S01-WS00060
              • R03S01-WS00091
              • R03S01-WS00103
              • R03S01-WS00109
              • R03S01-WS00133
              • R03S01-WS00161
              • R03S01-WS00175
              • R03S01-WS00181
              • R03S01-WS00183
              • R03S01-WS00198
              • R03S01-WS00200
              • R03S01-WS00202
              • R03S01-WS00221
              • R03S01-WS00226
              • R03S01-WS00229
              • R03S01-WS00239
              • R03S01-WS00244
              • R03S01-WS00257
              • R03S01-WS00265
              • R03S01-WS00278
              • R03S01-WS00325
              • R03S01-WS00352
              • R03S01-WS00366
              • R03S01-WS00368
              • R03S01-WS00373
              • R03S01-WS00380
              • R03S01-WS00405
              • R03S01-WS00413
              • R03S01-WS00423
              • R03S01-WS00428
              • R03S01-WS00461
              • R03S02-WS00003
              • R03S02-WS00008
              • R03S02-WS00034
              • R03S02-WS00070
              • R03S02-WS00071
              • R03S02-WS00082
              • R03S02-WS00094
              • R03S02-WS00133
              • R03S02-WS00188
              • R03S02-WS00217
              • R03S02-WS00218
              • R03S02-WS00220
              • R03S02-WS00251
              • R03S02-WS00256
              • R03S02-WS00286
              • R03S02-WS00294
              • R03S02-WS00315
              • R03S02-WS00317
              • R03S02-WS00327
              • R03S02-WS00337
              • R03S02-WS00360
              • R03S02-WS00369
              • R03S02-WS00372
              • R03S02-WS00374
              • R03S02-WS00423
              • R03S02-WS00467
              • R03S03-SRV0010
              • R03S03-SRV0011
              • R03S03-WS00003
              • R03S03-WS00012
              • R03S03-WS00015
              • R03S03-WS00022
              • R03S03-WS00043
              • R03S03-WS00061
              • R03S03-WS00113
              • R03S03-WS00158
              • R03S03-WS00160
              • R03S03-WS00226
              • R03S03-WS00283
              • R03S03-WS00293
              • R03S03-WS00298
              • R03S03-WS00334
              • R03S03-WS00420
              • R03S03-WS00434
              • R03S03-WS00444
              • R03S03-WS00445
              • R03S03-WS00477
              • R03S03-WS00481
              • R04S00-SRV0014
              • R04S00-WS00040
              • R04S00-WS00057
              • R04S00-WS00073
              • R04S00-WS00112
              • R04S00-WS00130
              • R04S00-WS00141
              • R04S00-WS00146
              • R04S00-WS00154
              • R04S00-WS00171
              • R04S00-WS00198
              • R04S00-WS00208
              • R04S00-WS00237
              • R04S00-WS00241
              • R04S00-WS00267
              • R04S00-WS00268
              • R04S00-WS00272
              • R04S00-WS00293
              • R04S00-WS00319
              • R04S00-WS00337
              • R04S00-WS00359
              • R04S00-WS00371
              • R04S00-WS00397
              • R04S00-WS00409
              • R04S00-WS00417
              • R04S00-WS00425
              • R04S00-WS00458
              • R04S00-WS00460
              • R04S00-WS00465
              • R04S00-WS00469
              • R04S00-WS00476
              • R04S01-SRV0006
              • R04S01-SRV0014
              • R04S01-WS00002
              • R04S01-WS00044
              • R04S01-WS00051
              • R04S01-WS00063
              • R04S01-WS00070
              • R04S01-WS00082
              • R04S01-WS00088
              • R04S01-WS00098
              • R04S01-WS00113
              • R04S01-WS00115
              • R04S01-WS00143
              • R04S01-WS00160
              • R04S01-WS00169
              • R04S01-WS00178
              • R04S01-WS00188
              • R04S01-WS00197
              • R04S01-WS00205
              • R04S01-WS00272
              • R04S01-WS00299
              • R04S01-WS00304
              • R04S01-WS00330
              • R04S01-WS00348
              • R04S01-WS00377
              • R04S01-WS00458
              • R04S02-SRV0006
              • R04S02-SRV0012
              • R04S02-SRV0014
              • R04S02-WS00016
              • R04S02-WS00053
              • R04S02-WS00093
              • R04S02-WS00103
              • R04S02-WS00135
              • R04S02-WS00142
              • R04S02-WS00180
              • R04S02-WS00182
              • R04S02-WS00185
              • R04S02-WS00196
              • R04S02-WS00205
              • R04S02-WS00233
              • R04S02-WS00238
              • R04S02-WS00283
              • R04S02-WS00291
              • R04S02-WS00329
              • R04S02-WS00342
              • R04S02-WS00387
              • R04S02-WS00393
              • R04S02-WS00418
              • R04S02-WS00454
              • R04S02-WS00466
              • R04S02-WS00469
              • R04S03-WS00028
              • R04S03-WS00078
              • R04S03-WS00111
              • R04S03-WS00156
              • R04S03-WS00162
              • R04S03-WS00176
              • R04S03-WS00200
              • R04S03-WS00243
              • R04S03-WS00244
              • R04S03-WS00257
              • R04S03-WS00276
              • R04S03-WS00332
              • R04S03-WS00379
              • R04S03-WS00380
              • R04S03-WS00450
              • R04S03-WS00467
              • R04S03-WS00474

              How to fix it

              Deploy Windows LAPS to these computers and restrict who can read the stored passwords.

              LowPW-022Principal outside a Privilege Zone controls a zone object44 findings · 88 objects
              How to fix this kind of findingstep-by-step guide

              Category: Attack path Typical owner: Owner of the Privilege Zone (for example the server team for "Tier 1 servers"), with the AD team for permissions

              What this finding means

              A principal 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 principal can take over the zone object, so the zone boundary your tiering model assumes does not hold.

              Why attackers care

              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 principal.

              Before you change anything

              • Decide whether the principal should administer the zone. If it should, the right answer is to add it to the zone definition in pathwarden.toml (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.

              Fix

              Option A: Remove the right (recommended)

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

              1. 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 principal and click Remove.
              2. Local Administrators / Remote Desktop Users: remove the principal 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).
              3. Group membership (AddMember on a zone group): remove the permission from the group's Security tab as in step 1.
              4. 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 principal into the zone

              If the principal legitimately manages the zone, add it to the zone in pathwarden.toml (members, groups or ous). Then manage it with the same controls as the zone: no use from lower-tier machines, and admin accounts dedicated to this tier.

              PowerShell
              Import-Module ActiveDirectory
              
              # Show ACEs for the principal on a zone object
              $dn = (Get-ADObject -Filter "Name -eq '<Object>'").DistinguishedName
              (Get-Acl "AD:$dn").Access | Where-Object { $_.IdentityReference -like "*<Principal>*" } |
                  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 "*<Principal>*" -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>\<Principal>"
              

              Verify

              Re-run the Get-Acl command above, or Get-LocalGroupMember -Group "Administrators" on the computer, and confirm the principal is gone. Collect again (or use Retest in the app, or pathwarden retest on the CLI) and confirm the finding ID is gone. Run pathwarden plan --zone "<Zone>" to see what still reaches the zone.

              Rollback

              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

              • https://attack.mitre.org/techniques/T1098/
              • https://attack.mitre.org/techniques/T1021/
              • https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-access-model
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S00-U00089@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-4e17fe2b0f1749dd

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S00-U00089@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S00-U00089@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S00-U00089@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S00-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S00-U00089@SCALE.LOCAL (User)R01S00-U00089User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S00-U00089@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S00-U00089
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S00-U00223@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-48964b10442e900b

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S00-U00223@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S00-U00223@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S00-U00223@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S00-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S00-U00223@SCALE.LOCAL (User)R01S00-U00223User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S00-U00223@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S00-U00223
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S00-U00421@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-25825b015b1cd60b

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S00-U00421@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S00-U00421@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S00-U00421@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S00-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S00-U00421@SCALE.LOCAL (User)R01S00-U00421User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S00-U00421@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S00-U00421
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S00-U00444@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-15277b01521f9f66

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S00-U00444@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S00-U00444@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S00-U00444@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S00-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S00-U00444@SCALE.LOCAL (User)R01S00-U00444User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S00-U00444@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S00-U00444
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S00-U00523@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-d65c7109bac06480

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S00-U00523@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S00-U00523@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S00-U00523@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S00-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S00-U00523@SCALE.LOCAL (User)R01S00-U00523User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S00-U00523@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S00-U00523
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S00-U00618@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-ddde60ef885a5650

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S00-U00618@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S00-U00618@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S00-U00618@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S00-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S00-U00618@SCALE.LOCAL (User)R01S00-U00618User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S00-U00618@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S00-U00618
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S00-U00631@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-e6ea69ef8d9610a0

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S00-U00631@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S00-U00631@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S00-U00631@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S00-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S00-U00631@SCALE.LOCAL (User)R01S00-U00631User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S00-U00631@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S00-U00631
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S00-U00697@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-70d2a6f8684f35de

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S00-U00697@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S00-U00697@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S00-U00697@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S00-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S00-U00697@SCALE.LOCAL (User)R01S00-U00697User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S00-U00697@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S00-U00697
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S01-U00008@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-89e133f8763d14a9

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S01-U00008@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S01-U00008@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S01-U00008@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S01-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S01-U00008@SCALE.LOCAL (User)R01S01-U00008User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S01-U00008@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S01-U00008
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S01-U00015@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-829c8ef8728441cf

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S01-U00015@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S01-U00015@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S01-U00015@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S01-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S01-U00015@SCALE.LOCAL (User)R01S01-U00015User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S01-U00015@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S01-U00015
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S01-U00047@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-add7cbe006d4607b

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S01-U00047@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S01-U00047@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S01-U00047@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S01-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S01-U00047@SCALE.LOCAL (User)R01S01-U00047User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S01-U00047@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S01-U00047
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S01-U00207@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-fddf45e67d04bccc

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S01-U00207@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S01-U00207@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S01-U00207@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S01-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S01-U00207@SCALE.LOCAL (User)R01S01-U00207User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S01-U00207@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S01-U00207
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S01-U00296@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-111e455961747085

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S01-U00296@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S01-U00296@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S01-U00296@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S01-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S01-U00296@SCALE.LOCAL (User)R01S01-U00296User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S01-U00296@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S01-U00296
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S01-U00483@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-37b3184a10fb8a35

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S01-U00483@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S01-U00483@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S01-U00483@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S01-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S01-U00483@SCALE.LOCAL (User)R01S01-U00483User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S01-U00483@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S01-U00483
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S01-U00583@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-97ac18508fcf9b34

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S01-U00583@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S01-U00583@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S01-U00583@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S01-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S01-U00583@SCALE.LOCAL (User)R01S01-U00583User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S01-U00583@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S01-U00583
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S01-U00629@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-b9f9a850a32483b6

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S01-U00629@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S01-U00629@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S01-U00629@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S01-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S01-U00629@SCALE.LOCAL (User)R01S01-U00629User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S01-U00629@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S01-U00629
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S02-U00076@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-30a7df8310332a07

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S02-U00076@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S02-U00076@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S02-U00076@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S02-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S02-U00076@SCALE.LOCAL (User)R01S02-U00076User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S02-U00076@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S02-U00076
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S02-U00265@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-c1b9b071b83b2eeb

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S02-U00265@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S02-U00265@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S02-U00265@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S02-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S02-U00265@SCALE.LOCAL (User)R01S02-U00265User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S02-U00265@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S02-U00265
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S02-U00328@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-0c997d9b7f87a816

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S02-U00328@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S02-U00328@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S02-U00328@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S02-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S02-U00328@SCALE.LOCAL (User)R01S02-U00328User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S02-U00328@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S02-U00328
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S02-U00420@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-c69766a3e47b26fa

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S02-U00420@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S02-U00420@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S02-U00420@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S02-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S02-U00420@SCALE.LOCAL (User)R01S02-U00420User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S02-U00420@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S02-U00420
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S02-U00470@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-dfb38ba3f2749269

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S02-U00470@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S02-U00470@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S02-U00470@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S02-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S02-U00470@SCALE.LOCAL (User)R01S02-U00470User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S02-U00470@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S02-U00470
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S02-U00482@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-fb03d4a4024d4a6e

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S02-U00482@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S02-U00482@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S02-U00482@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S02-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S02-U00482@SCALE.LOCAL (User)R01S02-U00482User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S02-U00482@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S02-U00482
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S02-U00663@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-6f39dc85b5fbcac8

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S02-U00663@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S02-U00663@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S02-U00663@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S02-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S02-U00663@SCALE.LOCAL (User)R01S02-U00663User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S02-U00663@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S02-U00663
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S02-U00741@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-6931269fe9a257bf

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S02-U00741@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S02-U00741@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S02-U00741@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S02-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S02-U00741@SCALE.LOCAL (User)R01S02-U00741User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S02-U00741@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S02-U00741
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S03-U00072@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-c472f896ff786c40

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S03-U00072@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S03-U00072@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S03-U00072@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S03-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S03-U00072@SCALE.LOCAL (User)R01S03-U00072User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S03-U00072@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S03-U00072
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S03-U00178@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-a501286d50cde8dd

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S03-U00178@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S03-U00178@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S03-U00178@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S03-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S03-U00178@SCALE.LOCAL (User)R01S03-U00178User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S03-U00178@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S03-U00178
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S03-U00185@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-9bee536d4b8c683b

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S03-U00185@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S03-U00185@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S03-U00185@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S03-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S03-U00185@SCALE.LOCAL (User)R01S03-U00185User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S03-U00185@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S03-U00185
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S03-U00212@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-c7a0486d64681d37

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S03-U00212@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S03-U00212@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S03-U00212@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S03-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S03-U00212@SCALE.LOCAL (User)R01S03-U00212User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S03-U00212@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S03-U00212
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S03-U00218@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-c78be46d6456ca41

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S03-U00218@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S03-U00218@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S03-U00218@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S03-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S03-U00218@SCALE.LOCAL (User)R01S03-U00218User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S03-U00218@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S03-U00218
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S03-U00281@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-1294d264714c87b7

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S03-U00281@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S03-U00281@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S03-U00281@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S03-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S03-U00281@SCALE.LOCAL (User)R01S03-U00281User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S03-U00281@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S03-U00281
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S03-U00465@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-74fdbf7653715de6

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S03-U00465@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S03-U00465@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S03-U00465@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S03-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S03-U00465@SCALE.LOCAL (User)R01S03-U00465User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S03-U00465@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S03-U00465
              Group 1
              • R01-HELPDESK
              LowR01-HELPDESK@SCALE.LOCAL has ForceChangePassword on R01S03-U00618@SCALE.LOCAL (zone R01 servers)first seen Oct 1 (run 1)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 1 (run 1)
              Finding ID
              PW-022-2d538cd2826b39fd

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01-HELPDESK@SCALE.LOCAL is outside the R01 servers zone but has ForceChangePassword on R01S03-U00618@SCALE.LOCAL, which belongs to it. Whoever controls R01-HELPDESK@SCALE.LOCAL controls R01S03-U00618@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the ForceChangePassword permission that R01-HELPDESK@SCALE.LOCAL holds on R01S03-U00618@SCALE.LOCAL. It is inherited, so remove it where it is defined (on R01S03-USERS@SCALE.LOCAL or a container above it); that also removes it from every other object below that container. If R01-HELPDESK@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              ForceChangePasswordR01-HELPDESK@SCALE.LOCAL (Group)R01-HELPDESKGroup · SCALE.LOCALR01S03-U00618@SCALE.LOCAL (User)R01S03-U00618User · SCALE.LOCAL

              start target

              Path as text
              1. R01-HELPDESK@SCALE.LOCAL (Group)
              2. ForceChangePassword R01S03-U00618@SCALE.LOCAL (User)
              Affected objects (2)
              User 1
              • R01S03-U00618
              Group 1
              • R01-HELPDESK
              LowR01S00-U00323@SCALE.LOCAL has GenericWrite on R01S00-SERVERADMINS@SCALE.LOCAL (zone R01 servers)first seen Oct 9 (run 2)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 9 (run 2)
              Finding ID
              PW-022-5c2930c6d0fe0146

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01S00-U00323@SCALE.LOCAL is outside the R01 servers zone but has GenericWrite on R01S00-SERVERADMINS@SCALE.LOCAL, which belongs to it. Whoever controls R01S00-U00323@SCALE.LOCAL controls R01S00-SERVERADMINS@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the GenericWrite permission that R01S00-U00323@SCALE.LOCAL holds on R01S00-SERVERADMINS@SCALE.LOCAL (set on the object itself, or inherited from a parent container). If R01S00-U00323@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              GenericWriteR01S00-U00323@SCALE.LOCAL (User)R01S00-U00323User · SCALE.LOCALR01S00-SERVERADMINS@SCALE.LOCAL (Group)R01S00-SERVERADMINSGroup · SCALE.LOCAL

              start target

              Path as text
              1. R01S00-U00323@SCALE.LOCAL (User)
              2. GenericWrite R01S00-SERVERADMINS@SCALE.LOCAL (Group)
              Affected objects (2)
              User 1
              • R01S00-U00323
              Group 1
              • R01S00-SERVERADMINS
              LowR01S00-U00570@SCALE.LOCAL has GenericWrite on R01S00-SERVERADMINS@SCALE.LOCAL (zone R01 servers)first seen Oct 9 (run 2)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 9 (run 2)
              Finding ID
              PW-022-fe44a6fd0ad905cc

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01S00-U00570@SCALE.LOCAL is outside the R01 servers zone but has GenericWrite on R01S00-SERVERADMINS@SCALE.LOCAL, which belongs to it. Whoever controls R01S00-U00570@SCALE.LOCAL controls R01S00-SERVERADMINS@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the GenericWrite permission that R01S00-U00570@SCALE.LOCAL holds on R01S00-SERVERADMINS@SCALE.LOCAL (set on the object itself, or inherited from a parent container). If R01S00-U00570@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              GenericWriteR01S00-U00570@SCALE.LOCAL (User)R01S00-U00570User · SCALE.LOCALR01S00-SERVERADMINS@SCALE.LOCAL (Group)R01S00-SERVERADMINSGroup · SCALE.LOCAL

              start target

              Path as text
              1. R01S00-U00570@SCALE.LOCAL (User)
              2. GenericWrite R01S00-SERVERADMINS@SCALE.LOCAL (Group)
              Affected objects (2)
              User 1
              • R01S00-U00570
              Group 1
              • R01S00-SERVERADMINS
              LowR01S00-U00609@SCALE.LOCAL has GenericWrite on R01S00-SERVERADMINS@SCALE.LOCAL (zone R01 servers)first seen Oct 25 (run 4)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 25 (run 4)
              Finding ID
              PW-022-565e3284682840b8

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01S00-U00609@SCALE.LOCAL is outside the R01 servers zone but has GenericWrite on R01S00-SERVERADMINS@SCALE.LOCAL, which belongs to it. Whoever controls R01S00-U00609@SCALE.LOCAL controls R01S00-SERVERADMINS@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the GenericWrite permission that R01S00-U00609@SCALE.LOCAL holds on R01S00-SERVERADMINS@SCALE.LOCAL (set on the object itself, or inherited from a parent container). If R01S00-U00609@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              GenericWriteR01S00-U00609@SCALE.LOCAL (User)R01S00-U00609User · SCALE.LOCALR01S00-SERVERADMINS@SCALE.LOCAL (Group)R01S00-SERVERADMINSGroup · SCALE.LOCAL

              start target

              Path as text
              1. R01S00-U00609@SCALE.LOCAL (User)
              2. GenericWrite R01S00-SERVERADMINS@SCALE.LOCAL (Group)
              Affected objects (2)
              User 1
              • R01S00-U00609
              Group 1
              • R01S00-SERVERADMINS
              LowR01S01-U00284@SCALE.LOCAL has GenericWrite on R01S01-SERVERADMINS@SCALE.LOCAL (zone R01 servers)first seen Oct 9 (run 2)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 9 (run 2)
              Finding ID
              PW-022-f921bee751c51377

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01S01-U00284@SCALE.LOCAL is outside the R01 servers zone but has GenericWrite on R01S01-SERVERADMINS@SCALE.LOCAL, which belongs to it. Whoever controls R01S01-U00284@SCALE.LOCAL controls R01S01-SERVERADMINS@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the GenericWrite permission that R01S01-U00284@SCALE.LOCAL holds on R01S01-SERVERADMINS@SCALE.LOCAL (set on the object itself, or inherited from a parent container). If R01S01-U00284@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              GenericWriteR01S01-U00284@SCALE.LOCAL (User)R01S01-U00284User · SCALE.LOCALR01S01-SERVERADMINS@SCALE.LOCAL (Group)R01S01-SERVERADMINSGroup · SCALE.LOCAL

              start target

              Path as text
              1. R01S01-U00284@SCALE.LOCAL (User)
              2. GenericWrite R01S01-SERVERADMINS@SCALE.LOCAL (Group)
              Affected objects (2)
              User 1
              • R01S01-U00284
              Group 1
              • R01S01-SERVERADMINS
              LowR01S01-U00295@SCALE.LOCAL has GenericWrite on R01S01-SERVERADMINS@SCALE.LOCAL (zone R01 servers)first seen Oct 9 (run 2)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 9 (run 2)
              Finding ID
              PW-022-833ffc22b10b77d9

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01S01-U00295@SCALE.LOCAL is outside the R01 servers zone but has GenericWrite on R01S01-SERVERADMINS@SCALE.LOCAL, which belongs to it. Whoever controls R01S01-U00295@SCALE.LOCAL controls R01S01-SERVERADMINS@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the GenericWrite permission that R01S01-U00295@SCALE.LOCAL holds on R01S01-SERVERADMINS@SCALE.LOCAL (set on the object itself, or inherited from a parent container). If R01S01-U00295@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              GenericWriteR01S01-U00295@SCALE.LOCAL (User)R01S01-U00295User · SCALE.LOCALR01S01-SERVERADMINS@SCALE.LOCAL (Group)R01S01-SERVERADMINSGroup · SCALE.LOCAL

              start target

              Path as text
              1. R01S01-U00295@SCALE.LOCAL (User)
              2. GenericWrite R01S01-SERVERADMINS@SCALE.LOCAL (Group)
              Affected objects (2)
              User 1
              • R01S01-U00295
              Group 1
              • R01S01-SERVERADMINS
              LowR01S02-U00403@SCALE.LOCAL has GenericWrite on R01S02-SERVERADMINS@SCALE.LOCAL (zone R01 servers)first seen Oct 9 (run 2)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 9 (run 2)
              Finding ID
              PW-022-fd90846fc313adc9

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01S02-U00403@SCALE.LOCAL is outside the R01 servers zone but has GenericWrite on R01S02-SERVERADMINS@SCALE.LOCAL, which belongs to it. Whoever controls R01S02-U00403@SCALE.LOCAL controls R01S02-SERVERADMINS@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the GenericWrite permission that R01S02-U00403@SCALE.LOCAL holds on R01S02-SERVERADMINS@SCALE.LOCAL (set on the object itself, or inherited from a parent container). If R01S02-U00403@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              GenericWriteR01S02-U00403@SCALE.LOCAL (User)R01S02-U00403User · SCALE.LOCALR01S02-SERVERADMINS@SCALE.LOCAL (Group)R01S02-SERVERADMINSGroup · SCALE.LOCAL

              start target

              Path as text
              1. R01S02-U00403@SCALE.LOCAL (User)
              2. GenericWrite R01S02-SERVERADMINS@SCALE.LOCAL (Group)
              Affected objects (2)
              User 1
              • R01S02-U00403
              Group 1
              • R01S02-SERVERADMINS
              LowR01S02-U00466@SCALE.LOCAL has GenericWrite on R01S02-SERVERADMINS@SCALE.LOCAL (zone R01 servers)first seen Oct 9 (run 2)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 9 (run 2)
              Finding ID
              PW-022-b78be06a759ae2fa

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01S02-U00466@SCALE.LOCAL is outside the R01 servers zone but has GenericWrite on R01S02-SERVERADMINS@SCALE.LOCAL, which belongs to it. Whoever controls R01S02-U00466@SCALE.LOCAL controls R01S02-SERVERADMINS@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the GenericWrite permission that R01S02-U00466@SCALE.LOCAL holds on R01S02-SERVERADMINS@SCALE.LOCAL (set on the object itself, or inherited from a parent container). If R01S02-U00466@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              GenericWriteR01S02-U00466@SCALE.LOCAL (User)R01S02-U00466User · SCALE.LOCALR01S02-SERVERADMINS@SCALE.LOCAL (Group)R01S02-SERVERADMINSGroup · SCALE.LOCAL

              start target

              Path as text
              1. R01S02-U00466@SCALE.LOCAL (User)
              2. GenericWrite R01S02-SERVERADMINS@SCALE.LOCAL (Group)
              Affected objects (2)
              User 1
              • R01S02-U00466
              Group 1
              • R01S02-SERVERADMINS
              LowR01S02-U00543@SCALE.LOCAL has GenericWrite on R01S02-SERVERADMINS@SCALE.LOCAL (zone R01 servers)first seen Oct 9 (run 2)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 9 (run 2)
              Finding ID
              PW-022-9920d4468cd0c78f

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01S02-U00543@SCALE.LOCAL is outside the R01 servers zone but has GenericWrite on R01S02-SERVERADMINS@SCALE.LOCAL, which belongs to it. Whoever controls R01S02-U00543@SCALE.LOCAL controls R01S02-SERVERADMINS@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the GenericWrite permission that R01S02-U00543@SCALE.LOCAL holds on R01S02-SERVERADMINS@SCALE.LOCAL (set on the object itself, or inherited from a parent container). If R01S02-U00543@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              GenericWriteR01S02-U00543@SCALE.LOCAL (User)R01S02-U00543User · SCALE.LOCALR01S02-SERVERADMINS@SCALE.LOCAL (Group)R01S02-SERVERADMINSGroup · SCALE.LOCAL

              start target

              Path as text
              1. R01S02-U00543@SCALE.LOCAL (User)
              2. GenericWrite R01S02-SERVERADMINS@SCALE.LOCAL (Group)
              Affected objects (2)
              User 1
              • R01S02-U00543
              Group 1
              • R01S02-SERVERADMINS
              LowR01S03-U00128@SCALE.LOCAL has GenericWrite on R01S03-SERVERADMINS@SCALE.LOCAL (zone R01 servers)first seen Oct 9 (run 2)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 9 (run 2)
              Finding ID
              PW-022-732e3373b3aeea5a

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01S03-U00128@SCALE.LOCAL is outside the R01 servers zone but has GenericWrite on R01S03-SERVERADMINS@SCALE.LOCAL, which belongs to it. Whoever controls R01S03-U00128@SCALE.LOCAL controls R01S03-SERVERADMINS@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the GenericWrite permission that R01S03-U00128@SCALE.LOCAL holds on R01S03-SERVERADMINS@SCALE.LOCAL (set on the object itself, or inherited from a parent container). If R01S03-U00128@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              GenericWriteR01S03-U00128@SCALE.LOCAL (User)R01S03-U00128User · SCALE.LOCALR01S03-SERVERADMINS@SCALE.LOCAL (Group)R01S03-SERVERADMINSGroup · SCALE.LOCAL

              start target

              Path as text
              1. R01S03-U00128@SCALE.LOCAL (User)
              2. GenericWrite R01S03-SERVERADMINS@SCALE.LOCAL (Group)
              Affected objects (2)
              User 1
              • R01S03-U00128
              Group 1
              • R01S03-SERVERADMINS
              LowR01S03-U00514@SCALE.LOCAL has GenericWrite on R01S03-SERVERADMINS@SCALE.LOCAL (zone R01 servers)first seen Oct 9 (run 2)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 9 (run 2)
              Finding ID
              PW-022-35d0f5c60bf754e3

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01S03-U00514@SCALE.LOCAL is outside the R01 servers zone but has GenericWrite on R01S03-SERVERADMINS@SCALE.LOCAL, which belongs to it. Whoever controls R01S03-U00514@SCALE.LOCAL controls R01S03-SERVERADMINS@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the GenericWrite permission that R01S03-U00514@SCALE.LOCAL holds on R01S03-SERVERADMINS@SCALE.LOCAL (set on the object itself, or inherited from a parent container). If R01S03-U00514@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              GenericWriteR01S03-U00514@SCALE.LOCAL (User)R01S03-U00514User · SCALE.LOCALR01S03-SERVERADMINS@SCALE.LOCAL (Group)R01S03-SERVERADMINSGroup · SCALE.LOCAL

              start target

              Path as text
              1. R01S03-U00514@SCALE.LOCAL (User)
              2. GenericWrite R01S03-SERVERADMINS@SCALE.LOCAL (Group)
              Affected objects (2)
              User 1
              • R01S03-U00514
              Group 1
              • R01S03-SERVERADMINS
              LowR01S03-U00578@SCALE.LOCAL has GenericWrite on R01S03-SERVERADMINS@SCALE.LOCAL (zone R01 servers)first seen Oct 9 (run 2)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Oct 9 (run 2)
              Finding ID
              PW-022-cea1489298a8b296

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01S03-U00578@SCALE.LOCAL is outside the R01 servers zone but has GenericWrite on R01S03-SERVERADMINS@SCALE.LOCAL, which belongs to it. Whoever controls R01S03-U00578@SCALE.LOCAL controls R01S03-SERVERADMINS@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the GenericWrite permission that R01S03-U00578@SCALE.LOCAL holds on R01S03-SERVERADMINS@SCALE.LOCAL (set on the object itself, or inherited from a parent container). If R01S03-U00578@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              GenericWriteR01S03-U00578@SCALE.LOCAL (User)R01S03-U00578User · SCALE.LOCALR01S03-SERVERADMINS@SCALE.LOCAL (Group)R01S03-SERVERADMINSGroup · SCALE.LOCAL

              start target

              Path as text
              1. R01S03-U00578@SCALE.LOCAL (User)
              2. GenericWrite R01S03-SERVERADMINS@SCALE.LOCAL (Group)
              Affected objects (2)
              User 1
              • R01S03-U00578
              Group 1
              • R01S03-SERVERADMINS
              LowNewR01S03-U00734@SCALE.LOCAL has GenericWrite on R01S03-SERVERADMINS@SCALE.LOCAL (zone R01 servers)first seen Nov 2 (run 5)Fix directly19.51% exposed
              Category
              Attack Path
              Exposure
              19.51% (4,262 of 21,849 active or exposed users and computers in SCALE.LOCAL)
              Domain
              SCALE.LOCAL
              First seen
              Nov 2 (run 5)
              Finding ID
              PW-022-2a5d278b75ab45f7

              Not closed by the remediation path. Fix it directly: see How to fix it.

              Why it matters

              R01S03-U00734@SCALE.LOCAL is outside the R01 servers zone but has GenericWrite on R01S03-SERVERADMINS@SCALE.LOCAL, which belongs to it. Whoever controls R01S03-U00734@SCALE.LOCAL controls R01S03-SERVERADMINS@SCALE.LOCAL, so the zone boundary does not hold.

              How to fix it

              Remove the GenericWrite permission that R01S03-U00734@SCALE.LOCAL holds on R01S03-SERVERADMINS@SCALE.LOCAL (set on the object itself, or inherited from a parent container). If R01S03-U00734@SCALE.LOCAL legitimately administers this zone, add it to the zone instead.

              Attack path

              GenericWriteR01S03-U00734@SCALE.LOCAL (User)R01S03-U00734User · SCALE.LOCALR01S03-SERVERADMINS@SCALE.LOCAL (Group)R01S03-SERVERADMINSGroup · SCALE.LOCAL

              start target

              Path as text
              1. R01S03-U00734@SCALE.LOCAL (User)
              2. GenericWrite R01S03-SERVERADMINS@SCALE.LOCAL (Group)
              Affected objects (2)
              User 1
              • R01S03-U00734
              Group 1
              • R01S03-SERVERADMINS

              Environment

              Protected zones1 zone · Tier Zero protected: 53 of 59 objects (89.83%)
              ZoneObjectsExposureProtected
              Tier Zero59 8,975 of 22,489 (39.91%)89.83%
              R01 servers36 8,944 of 22,458 (39.83%)0%

              Protected: the share of a zone's objects that no open attack path finding leads to.

              Collection completenessevery domain at 80% or more

              Computers active in the 14 days before collection. Paths through logged-on sessions and local administrator rights are only as complete as these numbers; without GPO local groups, admin rights granted by Group Policy are missing. Local groups count member computers only: a domain controller's local groups are the domain's BUILTIN groups, already in the directory.

              DomainComputersSessions collectedLocal groups collected (member computers)GPO local groups
              SCALE.LOCAL8120
              7160/8120 (88.18%)
              7151/8111 (88.16%)
              not recorded
              Data sources6 collector files · 26,089 objects
              Collector files
              6
              Objects
              26089
              Domains
              SCALE.LOCAL

              Files

              • 20261001020000_computers.json
              • 20261001020000_domains.json
              • 20261001020000_gpos.json
              • 20261001020000_groups.json
              • 20261001020000_ous.json
              • 20261001020000_users.json