Haiyahhh Hack Vault

Active Directory - LAPS Password Retrieval Abuse

4 min read

🧠 Active Directory - LAPS Password Retrieval Abuse

What is it?

  • Concept: LAPS (Local Administrator Password Solution) exists to solve a specific problem: without it, every domain-joined machine tends to share the same local Administrator password, so compromising one host’s local admin often means compromising all of them. LAPS has each machine periodically randomize its own local Administrator password and write the current value straight onto that computer’s own AD object, as a confidential attribute. The catch: “confidential” just means a normal read requires an explicit delegation — any principal placed in a group granted that delegation can read the password over plain LDAP.
  • Impact: Membership in an innocuous-sounding delegated group (e.g. LAPS_Readers, Help Desk) can amount to on-demand read access to the actual local Administrator password of every computer the delegation covers — and when that includes a Domain Controller, the DC’s “local Administrator” account is a full domain-equivalent credential.

How it works

  1. The LAPS client on each managed machine generates a new random local Administrator password on a schedule and writes it, along with an expiration timestamp, to a confidential attribute on that machine’s own computer object — legacy LAPS uses ms-Mcs-AdmPwd (stored in cleartext); the newer, built-in Windows LAPS uses msLAPS-Password (a JSON blob, optionally encrypted).
  2. That attribute isn’t readable by ordinary authenticated users by default — an administrator has to explicitly delegate CONTROL_ACCESS/read-property rights on it to whichever groups are meant to be able to look up local admin passwords (helpdesk staff, deployment tooling, etc.), via the LAPS PowerShell module or the GPO delegation wizard.
  3. Anyone who ends up in one of those delegated groups — whether by design or through a privilege-escalation chain — can query the attribute directly for any computer object the delegation covers, and gets back that machine’s current local Administrator password with no further exploitation needed.
  4. Since the delegation is defined per-OU/per-computer-object rather than domain-wide, the blast radius depends entirely on scope — a delegation covering the Domain Controllers OU is catastrophic in a way that one scoped to a handful of workstations isn’t.

Exploitation

Prerequisites

  • Membership (direct or transitive) in a group with delegated LAPS read rights over a target computer object

Attack Vectors

# Read the LAPS-managed attributes directly over LDAP for every reachable computer
# object at once — no dedicated LAPS module needed, PowerView alone is enough
Get-DomainComputer -Properties "cn","ms-mcs-admpwd","ms-mcs-admpwdexpirationtime"
# Linux-side equivalent, no domain session required — checks whichever LAPS
# attribute (legacy or modern) is actually populated automatically
nxc ldap '<dc_ip>' -u '<user>' -p '<pass>' --laps

Notes

  • PowerView’s Get-DomainComputer -Properties "cn","ms-mcs-admpwd","ms-mcs-admpwdexpirationtime" reads the legacy attribute directly — no dedicated LAPS module needed beyond PowerView itself, and it lists every reachable computer object’s password in one query instead of looking up one machine at a time.
  • The dedicated AdmPwd.PS module (Find-AdmPwdExtendedRights, Get-AdmPwdPassword) reaches the same data through purpose-built cmdlets instead of a raw LDAP property read — useful mainly for Find-AdmPwdExtendedRights, which answers “which computer objects is this delegation actually scoped to” without needing to already know the answer.
  • Either approach only reads the legacy ms-Mcs-AdmPwd attribute — on a host running the newer Windows LAPS client, that attribute may be empty even though a password genuinely is being managed, because it’s stored under msLAPS-Password instead. Confirm which LAPS version is actually deployed before concluding a target isn’t covered.
  • NetExec’s --laps flag checks whichever attribute is populated automatically, from Linux, without needing a domain-joined PowerShell session at all.
  • This is very often the last hop in a chain rather than a starting point — a group like LAPS_Readers is rarely reachable directly, but frequently ends up reachable through an unrelated foothold (a leaked service account credential, a PowerShell history file) that happens to already be a member.

Mitigation

  • Fix: Scope LAPS read-password delegation as narrowly as operationally possible, and treat membership in any group holding that delegation with the same seriousness as Domain Admin membership — especially where the delegation covers Domain Controllers.
FileCreated
HTB - TimelapseFriday, July 24th 2026, 12:47:06 am

References:

Graph View

Backlinks