PW-028HygieneTrusts, management planes and other systems

Possible management plane: review whether it manages Tier Zero

Something in the directory looks like part of a management system (SCCM, SCOM, WSUS, backup or virtualization): check whether it manages Tier Zero.

Category: Hygiene
Severity: High, Medium or Low, by the evidence.
Typical owner: AD / identity team, with the infrastructure teams that run SCCM, SCOM, backup and virtualization
Data needed: Directory data from any collection: structures the products create, service principal names, and (with the lowest confidence) object names.

MITRE ATT&CKT1072

Most useful toDefensive engineers Identity and access engineers

On this page

In plain language

Whoever controls a management system controls everything it manages. An SCCM or SCOM server can run code on its clients; a backup server holds copies of the domain controllers; a hypervisor admin controls the virtual domain controllers' disks.

The directory alone often can't say whether such a system manages domain controllers, so Pathwarden doesn't guess. It lists what looks like a management plane^*, with how confident it is, and asks you to check. If one does manage Tier Zero, add it to Tier Zero in your configuration.

What Pathwarden flags

Something in the directory looks like part of a management system (SCCM, SCOM, WSUS, backup, virtualization or Entra Connect), but the directory doesn't show whether it manages Tier Zero. Pathwarden doesn't treat it as Tier Zero; it asks you to check. There are three levels:

Inferred (medium): structure the product creates.
- Full Control of CN=System Management,CN=System is granted to SCCM site servers, so the holder is very likely one.
- A MSOMSdkSvc/ service principal name belongs to a SCOM management server or its Data Access account, and MSOMHSvc/ (the Health Service) on a computer that isn't a domain controller or CA server to a SCOM management server or gateway (one finding per domain lists those computers); SCVMM/ belongs to Virtual Machine Manager.
- The Hyper-V live migration and console service principal names (Microsoft Virtual System Migration Service/, `Microsoft Virtual Console Service/`) mark Hyper-V hosts. One finding per domain lists them, and notes the failover cluster nodes.
- A computer that can read the password of the Entra Connect sync service account (ADSyncMSA...), or a group named ADSyncAdmins, when no sync account in the domain can DCSync.
Inferred, Tier Zero computers (high):
- A domain controller or CA server is an SCCM client (it has the CmRcService/ service principal name of SCCM Remote Control, or a GPO that applies to it pushes the SCCM client), and its forest has several site servers, or none in the collection. With the built-in collector, SCCM's site objects narrow several site servers to the one of the client's site first; the finding says whether they were read.
- A GPO that applies to a domain controller or CA server points it at a WSUS server that isn't a computer in the collection (an IP address, a DNS alias, or a server in another forest). Built-in collector only.
- A domain controller or CA server is a SCOM agent (it has the MSOMHSvc/ service principal name) and no AD integration group names its management server.
- From its Tier Zero settings file (the management agents the script reads on the computer): an SCCM client whose site code is ambiguous (two site objects publish it), a SCOM agent or a Hyper-V virtual machine whose server or host the registry names but which doesn't match a single computer in the collection (Pathwarden never guesses from a short name in another domain), and a backup agent (Veeam, Commvault, NetBackup, DPM), whose backup server the computer doesn't name. A later run without a current, trusted file from the computer holds these as can't tell.
- A SCOM AD integration group lists domain controllers or CA servers as agents, but its management server isn't in the collection.
Heuristic (low): names only (SVC_VEEAM, WSUS01, ESX01, an MSOL_ account without replication rights). One finding per product and domain lists them all. The ESX Admins group is PW-029.

With a single site server in its forest (or of its site), an SCCM client domain controller makes that server Tier Zero instead (PW-025), and so does a WSUS server that is a computer in the collection.

How attackers use it

Whoever controls a management system controls what it manages:

an SCCM site server or Full Administrator can deploy code as SYSTEM to every client;
a SCOM management server or administrator can run tasks on every agent;
a WSUS server (or anyone on the path to an HTTP one) can push updates;
a backup server holds copies of the domain controllers, and with them every password hash;
a hypervisor administrator controls every virtual domain controller's disk and console. ESXi hosts joined to AD grant administrator rights to any group named "ESX Admins" by default.

When domain controllers or CA servers are among the managed computers, the management system is part of Tier Zero whether or not anyone decided so.

Find it with Pathwarden

Data needed: Directory data from any collection: structures the products create, service principal names, and (with the lowest confidence) object names.

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

Shell

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

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

Before you change anything

Check what the system manages. Directory data can't show it; the computers can:

Product	On a domain controller, look for
SCCM client	`HKLM\SOFTWARE\Microsoft\CCM`; `HKLM\SOFTWARE\Microsoft\SMS\Mobile Client` value `AssignedSiteCode`
SCOM agent	`HKLM\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Agent Management Groups`
WSUS	`HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate` value `WUServer`
Hyper-V guest	`HKLM\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters` value `HostName`
VMware guest	`HKLM\SOFTWARE\VMware, Inc.\VMware Tools`
Backup agents	services from Veeam, Commvault, NetBackup, Rubrik, Cohesity, ...

Also check who administers the system (local Administrators, the product's own roles): those accounts become Tier Zero if the system does.

How to fix it

Option A: It manages Tier Zero: make it Tier Zero, or separate it

Either take the Tier Zero computers out of its management (uninstall the agent, point them at a Tier Zero instance), or add the system (for example CM01.SCALE.LOCAL) under Additional Tier Zero in Settings.
If it becomes Tier Zero, Pathwarden reports who controls it (PW-003). Fix those, and restrict the product's own administrators to Tier Zero admins.

Option B: It doesn't manage Tier Zero

Accept the finding as a risk in Settings, with the reason, so the review is recorded (for example "CM01 manages workstations only; DCs are not SCCM clients, checked 2026-10-10"). Set a review date: what a system manages changes.

PowerShell

# On each domain controller: management agents (read-only)
$keys = 'HKLM:\SOFTWARE\Microsoft\CCM',
        'HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client',
        'HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Agent Management Groups',
        'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate',
        'HKLM:\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters',
        'HKLM:\SOFTWARE\VMware, Inc.\VMware Tools'
foreach ($dc in (Get-ADDomainController -Filter *).HostName) {
    Invoke-Command -ComputerName $dc -ScriptBlock {
        param($keys) foreach ($k in $keys) { if (Test-Path $k) { [pscustomobject]@{ Key = $k; Values = (Get-ItemProperty $k | Out-String).Trim() } } }
    } -ArgumentList (,$keys)
}

# SCCM site servers: who has Full Control of System Management
$sm = "AD:\CN=System Management,CN=System," + (Get-ADDomain).DistinguishedName
(Get-Acl $sm).Access | Where-Object ActiveDirectoryRights -eq 'GenericAll' |
    Select-Object IdentityReference, IsInherited

Verify the fix

Collect again. With Option A the system is listed as "Configured as Tier Zero" and the finding is gone; with Option B the finding shows as an accepted risk.

Roll back

Remove the object from Additional Tier Zero in Settings, or remove the accepted risk.

References

Misconfiguration Manager: SCCM attack and defense techniquesgithub.com
Microsoft: SCOM Active Directory integration for agent assignmentlearn.microsoft.com
Microsoft: Enterprise access modellearn.microsoft.com
Broadcom VMSA-2024-0013: VMware ESXi updates, including CVE-2024-37085 (ESX Admins)support.broadcom.com
MITRE ATT&CK T1072: Software Deployment Toolsattack.mitre.org

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