PW-009HygieneKerberos, passwords and credentials

Stale Tier Zero accounts

Enabled Tier Zero accounts that haven't signed in for months, or ever, are privileged access nobody is watching.

Category: Hygiene
Severity: Medium.
Typical owner: AD / identity team
Data needed: Any collection: last logon times are directory data. Ages are measured from the collection's time. Change the threshold with stale_days in pathwarden.toml.

Most useful toDefensive engineers Identity and access engineers Auditors

On this page

In plain language

Every enabled privileged account is a key to the domain. When nobody has used one for 90 days (the default threshold), it usually belongs to someone who left or a project that ended. Its password is probably old, it is often outside MFA and monitoring, and nobody would notice if it signed in tonight.

Disabling unused admin accounts is one of the cheapest risk reductions there is.

What Pathwarden flags

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.

How attackers use it

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.

Find it with Pathwarden

Data needed: Any collection: last logon times are directory data. Ages are measured from the collection's time. Change the threshold with stale_days in pathwarden.toml.

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

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

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 accept the finding as a risk in Settings, with a review date, instead of disabling them.

How to fix it

Option A: Disable the account (recommended)

Open Active Directory Users and Computers (dsa.msc).
Find the account, right-click > Disable Account.
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:

Open the account > Member Of tab.
Remove Domain Admins, Enterprise Admins, Administrators and any other Tier Zero group.
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 the fix

PowerShell

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

Collect again (or use Retest on the finding) and confirm the finding ID is gone (or lists fewer accounts).

Roll back

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

Microsoft: Implementing least-privilege administrative modelslearn.microsoft.com
MITRE ATT&CK T1078.002: Valid Accounts: Domain Accountsattack.mitre.org