PW-011HygieneKerberos, passwords and credentials

Computers without LAPS

Computers whose local administrator password isn't managed by LAPS often share one password, so one compromise spreads to many.

Category: Hygiene
Severity: Medium.
Typical owner: Desktop / server team, with the AD team for schema and permissions
Data needed: Any collection: collectors record whether each computer has a LAPS-managed password. Domain controllers are excluded.

MITRE ATT&CKT1550.002 T1021.002

Most useful toDefensive engineers Identity and access engineers Auditors

On this page

In plain language

Every Windows computer has a built-in local Administrator account. If it was set by a disk image or a script, it is often the same password on hundreds of computers. An attacker who takes one computer can sign in to all the others with it.

Windows LAPS gives each computer its own random local admin password, stores it in Active Directory, rotates it, and lets you decide who may read it. It is built into current Windows versions.

What Pathwarden flags

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

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

How attackers use it

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.

Find it with Pathwarden

Data needed: Any collection: collectors record whether each computer has a LAPS-managed password. Domain controllers are excluded.

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

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

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.

How to fix it

Option A: Deploy Windows LAPS by Group Policy (recommended)

Extend the schema once: run Update-LapsADSchema as a Schema Admin.
Let computers write their own password: Set-LapsADComputerSelfPermission -Identity "<OU>".
Grant read access to the support group: Set-LapsADReadPasswordPermission -Identity "<OU>" -AllowedPrincipals "<Domain>\<SupportGroup>".
In Group Policy Management, create a GPO linked to the OU and open Computer Configuration > Policies > Administrative Templates > System > LAPS.
Enable Configure password backup directory = Active Directory, and set Password Settings (complexity, length 15+, age 30 days).
Run gpupdate /force on a test computer and check that a password appears (see Verify).
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 the fix

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 on the finding) and confirm the finding ID is gone (or lists fewer computers).

Roll back

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

Microsoft: Windows LAPS overviewlearn.microsoft.com
Microsoft: Windows LAPS with Windows Server Active Directorylearn.microsoft.com
SpecterOps BloodHound docs: ReadLAPSPasswordbloodhound.specterops.io
MITRE ATT&CK T1550.002: Use Alternate Authentication Material: Pass the Hashattack.mitre.org
MITRE ATT&CK T1021.002: Remote Services: SMB/Windows Admin Sharesattack.mitre.org