OverLAPS: Overriding LAPS Logic

OverLAPS: Overriding LAPS Logic

Speakers: Antoine Goichot

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=stGRkxldg-U

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Antoine%20Goichot%20-%20OverLAPS%20Overriding%20LAPS%20Logic.pdf

Overview

Microsoft's Local Administrator Password Solution (LAPS) is one of the most widely deployed defenses against lateral movement in enterprise Windows environments. By ensuring every managed endpoint has a unique, regularly rotating local administrator password, LAPS eliminates the credential reuse that makes techniques like pass-the-hash devastatingly effective. Yet the security community's attention to LAPS has almost exclusively focused on the server-side attack surface — abusing over-permissioned accounts to read passwords from Active Directory or Entra ID. The client-side implementation has received comparatively little public scrutiny.

Antoine Goichot, a penetration tester at Peder Luxembourg with a decade of experience breaking enterprise systems, changes that. In this DEF CON 33 talk, he presents original research into the internals of Windows LAPS v2 — specifically its DLL-level logic on managed endpoints — and demonstrates three distinct classes of client-side attacks: password interception at rotation time, password desynchronization between the local system and the directory, and on-demand forced password rotation. The research introduces a new tool, OverLAPS, that operationalizes these techniques.

Background

▶ Watch: Introduction: Local Administrator Password Solution (LAPS) overview (0:39)

LAPS Architecture: V1 and V2

LAPS was first introduced by Microsoft as an out-of-band download (dubbed "LAPS V1" by the community) roughly a decade ago. V1 operated as a Group Policy Client Side Extension (CSE) and stored passwords in cleartext within an Active Directory attribute on the computer object. Access control on that attribute provided the only confidentiality guarantee. V1 was Windows domain-joined only.

Windows LAPS (V2), released in 2023 as a built-in Windows component, introduced significant architectural changes:

• Support for both Active Directory and Microsoft Entra ID (Azure AD)
• Password encryption at rest in the directory
• Expanded policy configuration through MDM and Group Policy
• A fixed rotation cycle of once per hour (polling interval hard-coded on managed clients)
• A registry update pathway in addition to directory writes

The core client-side logic in V2 is distributed across three DLLs, but the talk focuses on laps.dll, which contains the central password management logic. Microsoft provides public symbol (PDB) files for this DLL, which significantly accelerates reverse engineering by exposing internal function names.

Prior Work and Research Gaps

Prior published research on LAPS security — including Goichot's own earlier work on V1 with colleague Max Clement — focused almost entirely on abusing directory-side access to read passwords. Tools like LAPSDumper, CrackMapExec, and various BloodHound-aware attack paths all assume the attacker has obtained credentials sufficient to query the directory. The client-side attack surface — the DLL running as SYSTEM on every managed endpoint — had not received equivalent public attention in the V2 era, despite the broader attack surface introduced by Entra ID support and new feature additions.

Goichot's research establishes three goals: (1) Can you intercept the LAPS password during a rotation cycle? (2) Can you desynchronize the password between the local system and the directory? (3) Can you trigger a password rotation on demand?

Key Findings

▶ Watch: LAPS internal logic and password rotation mechanisms (7:30)

All three research goals were achieved:

1. Password interception is possible during rotation. By hooking a specific function inside laps.dll at the point where it calls into the Security Account Manager (SAM) to actually change the local account password, an attacker with local admin privileges can capture the new LAPS password in plaintext before it is set — or immediately after, by inspecting the Unicode string parameters passed to the change function.

1. Password desynchronization is achievable in two directions. An attacker can modify the password that LAPS sends to the directory without changing the real local password, or can change the local password independently of what the directory records. Either approach creates a state where the "official" LAPS password is incorrect, resulting in a denial-of-service condition for any administrator legitimately attempting to use LAPS credentials.

1. Forced password rotation on demand is straightforward. By hooking the function responsible for checking password expiration and forcing it to return true regardless of actual state, an attacker can cause LAPS to initiate a rotation cycle at will — useful for operational timing control or for inducing the interception condition described in finding 1.

Technical Deep Dive

▶ Watch: Live demo: preventing LAPS password rotation on target systems (18:43)

DLL Internals and the Call Tree

The core of the research rests on understanding laps.dll's internal call structure. Using frida — an open-source dynamic instrumentation framework widely used in security research — Goichot mapped the call tree of functions inside the DLL. The simplified call tree breaks into three zones:

• Left zone: Active Directory-specific setup functions
• Right zone: Entra ID (cloud join) setup functions
• Middle zone: Shared logic executed regardless of join type, including all password rotation logic

The critical path for password interception runs through the shared zone. The function ChangePasswordForManagedLocalAccount (name surfaced via PDB symbols) is the point at which LAPS issues the actual local account password change. This function accepts, among its parameters, two pointers to UNICODE_STRING structures. By applying the correct offset from the pointer, you can extract the actual password string in memory at the moment of rotation.

Hooking with Frida

The attack workflow for password interception:

1. Obtain local administrator privileges on the target endpoint (explicitly declared as a precondition for this research).
2. Disable RunAsPPL (Protected Process Light) on lsass.exe if it is enabled, since the attack involves attaching to processes that operate in the LAPS execution context. Goichot notes that bypassing PPL is a separate topic with extensive coverage elsewhere.
3. Attach Frida to the relevant process context.
4. Register a hook on ChangePasswordForManagedLocalAccount (or equivalently on ResetLocalAdminAccountPassword, which is another hookable internal function surfaced by PDB symbols).
5. When LAPS next executes a rotation — triggered by actual expiration or forced via the technique described below — the hook fires, the UNICODE_STRING parameters are read, and the plaintext password is captured.

The demo shows this working against both Active Directory and Entra ID configurations with identical code. The rotation can be forced by separately hooking the password expiration check function and patching its return value to always indicate expiration, then triggering a Group Policy update (gpupdate) to invoke the rotation cycle immediately.

Desynchronization Attack

The desynchronization attack exploits the window between when LAPS generates a new password and when it writes that password to two separate locations: the local SAM (via the account password change API) and the directory (Active Directory or Entra ID). By hooking at different points in the rotation call tree, an attacker can intercept and modify either the value destined for the directory or the value applied locally.

Directory poisoning: The local password remains correct (and unknown to the attacker, since no interception has occurred), but the directory entry is poisoned with an attacker-controlled value. Administrators attempting to retrieve and use the LAPS password through standard tooling will receive an incorrect credential. This is a clean denial-of-service against the LAPS management plane.

Local poisoning: Conversely, the directory entry holds the genuine new password, but the local account is set to a different value. The effect is the same from a usability standpoint — the LAPS-retrieved password will not work — but the direction of the discrepancy differs.

Both desynchronization modes are demonstrated in the talk via screenshots showing the Active Directory domain controller view alongside the local system state, with the values intentionally differing.

Demo / PoC

▶ Watch: Persistence via LAPS manipulation in enterprise environments (32:29)

The talk includes live demos for all three techniques. The interception demo shows two command prompt windows on the managed device: one running with administrator privileges used to attach Frida and configure the hook, and one used to issue a gpupdate /force to trigger the rotation cycle. When the cycle fires, the hooked function outputs the plaintext LAPS password to the console. Goichot then uses the captured password to authenticate to the local system as administrator, confirming it is valid.

The desynchronization demo shows the domain controller's LAPS view alongside the managed client's actual local administrator password state, with the values visibly differing — demonstrating that the control plane and reality have been decoupled.

The tool OverLAPS was released to accompany the research, providing an operationalized implementation of these hooks.

Defensive Implications

▶ Watch: Mitigations and Windows LAPS hardening recommendations (42:29)

Precondition awareness. All three techniques require existing local administrator privileges on the managed endpoint. This does not diminish their significance — lateral movement scenarios routinely deliver local admin access to an initial foothold machine — but it correctly frames the threat. An attacker without local admin on a LAPS-managed endpoint cannot execute these attacks.

PPL as a meaningful barrier. Enabling RunAsPPL for LSASS significantly raises the bar for this class of attack, since DLL injection and hooking require attaching to system processes that operate in a more privileged context. Enforcing PPL should be standard on LAPS-managed endpoints.

Monitor for Frida artifacts. Frida leaves forensic indicators at the process and file level. EDR solutions with behavioral analysis capabilities should be able to detect dynamic instrumentation activity. Hunt for Frida-related artifacts (frida-agent.dll, known pipe names, etc.) in EDR telemetry.

Credential use monitoring. If a LAPS password retrieved from the directory fails to authenticate, treat this as an incident indicator — it suggests either a rotation timing issue or active desynchronization attack. SIEM rules comparing LAPS password read events against subsequent authentication attempts can surface this signal.

Limit local admin exposure. The most robust mitigation remains minimizing the circumstances under which threat actors acquire local admin privileges. Tiered administration models, Privileged Access Workstations (PAWs), and Just-in-Time (JIT) access dramatically narrow the window in which this attack is viable.

Key Takeaways

• LAPS V2's client-side DLL logic is reversible with moderate effort, particularly given Microsoft's public PDB symbol files.
• Three distinct attack classes exist against the LAPS client: password interception at rotation, password desynchronization, and forced rotation triggering.
• All attacks require existing local admin privileges — this is a post-exploitation technique, not an initial access vector.
• Frida is an effective instrumentation framework for this class of DLL-level hooking research.
• Defensive countermeasures (PPL enforcement, EDR behavioral detection, credential use anomaly monitoring) can meaningfully reduce exposure.

About the Speaker

Antoine Goichot is a penetration tester at Peder Luxembourg with a decade of experience in offensive security engagements. He is based in Dijon, France, and specializes in Active Directory and Windows infrastructure attacks. This was his first DEF CON speaking engagement. His earlier LAPS research was conducted in collaboration with colleague Max Clement, focusing on the V1 client-side attack surface; the OverLAPS project represents his extension of that work to the current generation of Windows LAPS.