Object outside Tier Zero controls a Tier Zero object through another system
Another collector reports a way into Tier Zero outside AD permissions, such as a scheduled task that stores a Domain Admin's password.
- Category
- Attack Path
- Severity
- At least High.
- Typical owner
- the team that runs the system the collector describes (server team for scheduled tasks and services, database team for SQL Server)
- Data needed
- An OpenGraph collector's output (TaskHound, MSSQLHound and others) together with a trusted mapping pack. See the OpenGraph guide.
On this page
In plain language
Some of the most dangerous routes into Tier Zero aren't AD permissions at all: a scheduled task on a member server that stores a Domain Admin's password, or a database login that runs code as a privileged service account. Directory-only tools never see them.
Specialist collectors such as TaskHound and MSSQLHound find them and write BloodHound OpenGraph data. Pathwarden reads that data and follows a relationship only when a reviewed mapping pack says it grants control. The finding names its source, so you can confirm it on the system it describes. The best-known routes have rules of their own and are reported there instead: a stored Tier Zero password (PW-033), SQL Server running as Tier Zero (PW-034) and SCCM managing a Tier Zero host (PW-035).
What Pathwarden flags
A specialist collector (TaskHound, MSSQLHound, ...) reported a relationship outside Active Directory that gives an object outside Tier Zero control of a Tier Zero object. For example: a scheduled task on a member server stores the password of a Domain Admin, so every administrator of that server can recover the password and act as the Domain Admin.
The finding names the source in its title. Pathwarden only follows such a relationship when a reviewed mapping pack says it gives control; the file itself can't. The evidence rests on the collector's data, not on the directory, so confirm it on the system it describes.
How attackers use it
Tier Zero is only as safe as everything that holds a way into it. Stored credentials (T1555, Credentials from Password Stores; T1003.004, LSA Secrets), database logins that run code as a service account, and management systems that push code to domain controllers are all ways around AD permissions that directory-only tools never see. Attackers look for them precisely because they are rarely reviewed.
Find it with Pathwarden
Data needed: An OpenGraph collector's output (TaskHound, MSSQLHound and others) together with a trusted mapping pack. See the OpenGraph guide.
In the web UI or the HTML report, open the Findings tab and expand PW-030: 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:
# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-030
# the step-by-step guide on this page, offline
pathwarden guide PW-030
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-030Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.
Before you change anything
- Read the step in the finding's path that comes from the source, and confirm it on the system: open the scheduled task or service, the SQL Server login, or whatever the source describes.
- Find out who depends on it. A scheduled task that runs as a Domain Admin usually does something that needs far less: find what, and with which account it could run instead.
- Note the current configuration (export the task, script the login) so you can roll back.
How to fix it
Option A: Remove the relationship at its source (recommended)
Follow the fix text in the finding: it comes from the source's mapping pack. Typical fixes:
| Source | Relationship | Fix |
|---|---|---|
| TaskHound | Scheduled task stores a password | Run the task as a gMSA, or as SYSTEM if it needs no network identity; then rotate the account's password |
| TaskHound | Service runs as a domain account | Run it as a gMSA or a virtual account; then rotate the account's password |
When a credential was stored on a computer outside Tier Zero, rotate the account's password after the fix: any administrator of that computer could already have read it.
Option B: Bring the system into Tier Zero
If the system really administers Tier Zero (a backup server, a management server), add it under Additional Tier Zero in Settings and manage it like Tier Zero: dedicated admins, Tier Zero logon restrictions, and the hardening of a domain controller. External objects can be named there by their ID.
PowerShell
# Scheduled tasks that store a password, on one computer
Get-ScheduledTask -CimSession "<Computer>" |
Where-Object { $_.Principal.LogonType -eq 'Password' } |
Select-Object TaskPath, TaskName, @{n='RunAs';e={$_.Principal.UserId}}
# Run a task as a gMSA instead (the gMSA must be allowed on the computer)
$p = New-ScheduledTaskPrincipal -UserId "<Domain>\<gMSA>$" -LogonType Password
Set-ScheduledTask -CimSession "<Computer>" -TaskPath "<TaskPath>" -TaskName "<TaskName>" -Principal $p
# Services that run as a domain account
Get-CimInstance Win32_Service -ComputerName "<Computer>" |
Where-Object { $_.StartName -like '<Domain>\*' } | Select-Object Name, StartName
# Rotate the exposed account's password
Set-ADAccountPassword -Identity "<Account>" -Reset -NewPassword (Read-Host -AsSecureString "New password")Verify the fix
Collect again with the same source and its coverage file
(see docs/opengraph.md) that lists the computer or instance you changed,
and analyze the new collection. The finding is marked fixed only when the source covered that computer this run;
without a coverage file it stays open as "can't tell".
Roll back
Re-import the exported task (Register-ScheduledTask -Xml (Get-Content task.xml -Raw)),
or restore the service account with sc.exe config <Service> obj= <Account>.
Do not restore a password that was exposed: set a new one.
References
- Microsoft: Group Managed Service Accounts overviewlearn.microsoft.com
- TaskHoundgithub.com
- SpecterOps: BloodHound OpenGraph schemabloodhound.specterops.io
- MITRE ATT&CK T1555: Credentials from Password Storesattack.mitre.org
- MITRE ATT&CK T1003.004: OS Credential Dumping: LSA Secretsattack.mitre.org