PW-010HygieneKerberos, passwords and credentials

Old Tier Zero passwords

Tier Zero accounts with passwords older than a year have had more time to leak, and stolen hashes of them still work.

Category: Hygiene
Severity: Medium.
Typical owner: AD / identity team (service account owners for service accounts)
Data needed: Any collection: password ages are directory data, measured from the collection's time. Change the threshold with password_age_days (365 by default).

Most useful toDefensive engineers Identity and access engineers Auditors

On this page

In plain language

A password that hasn't changed in years may sit in old backups, scripts, memory dumps or an earlier breach's loot. If an attacker ever captured its hash, they can still use it, because Windows accepts the hash itself in place of the password (pass-the-hash) until the password changes.

Rotating privileged passwords limits how long stolen material stays useful. For service accounts, gMSAs make rotation automatic.

What Pathwarden flags

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.

How attackers use it

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

Find it with Pathwarden

Data needed: Any collection: password ages are directory data, measured from the collection's time. Change the threshold with password_age_days (365 by default).

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

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

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.

How to fix it

Option A: Rotate the password now (recommended)

Open Active Directory Users and Computers (dsa.msc).
Right-click the account > Reset Password.
Set a long random password (25+ characters for service accounts) and store it in your privileged access vault.
For service accounts, update every place that uses the password, then restart the dependent services.

Option B: Move service accounts to a gMSA

Create a gMSA (New-ADServiceAccount) that the computers running the service are allowed to use.
Install it on those computers (Install-ADServiceAccount) and reconfigure the service to run as <Domain>\<gMSA>$ with an empty password.
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 the fix

PowerShell

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

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

Roll back

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

References

Microsoft: Group Managed Service Accounts overviewlearn.microsoft.com
MITRE ATT&CK T1078.002: Valid Accounts: Domain Accountsattack.mitre.org
MITRE ATT&CK T1550.002: Use Alternate Authentication Material: Pass the Hashattack.mitre.org