What does ReadLAPSPassword look like in a real intrusion?

How ReadLAPSPassword Shows Up During an Intrusion

In practice, ReadLAPSPassword is not a malware signature or a noisy exploit chain. It is an access pattern: someone with delegated directory permissions queries the LAPS attribute and receives the local administrator password in cleartext or retrievable form. If that read is legitimate for the account used, the event can look normal unless you correlate it with unusual host targeting, time of access, or follow-on use.

The important detail is that the read itself is often the pivot point, not the end state. Once an attacker has the password, the next move is usually to authenticate to the target system, test whether the same local admin credential works elsewhere, and then expand from one host to a wider lateral-movement path. That makes directory-read activity worth treating as a privileged action, not just a directory lookup.

For defenders, the first question is whether the account that performed the read should ever have had that permission in the first place. If the answer is no, the incident is already an access-control failure. If the answer is yes, the next question is whether the read volume, target set, and timing fit normal admin workflow or instead resemble reconnaissance before lateral movement.

What the Attacker Does After Getting the Password

Once the password is obtained, the intrusion usually shifts from directory access to endpoint access. The attacker may use it to remote into the specific machine, harvest additional local context, or repeat the process on other machines where the same local admin pattern creates a reusable path. MITRE ATT&CK Enterprise Matrix is useful here because the relevant behaviors map cleanly to credential access, privilege escalation, and lateral movement.

That is why a ReadLAPSPassword event should be evaluated alongside signs of post-authentication activity on the endpoint. A single password read can be the beginning of a chain that includes remote logon, remote management use, service discovery, and eventual takeover of other systems. If the same local administrator secret is shared or reused across systems, the blast radius grows quickly.

In a real intrusion, the attacker’s advantage is not just the password value itself but the trust relationship behind it. Directory permissions that were designed for recovery, support, or administration become a covert path to privileged access when misused. FIRST EPSS is not a direct LAPS reference, but it is a practical reminder that prioritization should follow likelihood of exploitation and likely follow-on impact, not just the existence of a readable attribute.

How to Tell Legitimate Administration from Abuse

Distinguishing normal LAPS use from malicious read activity is mostly a question of context. A legitimate admin usually reads passwords for a bounded set of assets, during an expected change or recovery window, from a known management path. An intruder tends to probe more broadly, touch assets that do not fit a service desk or operations pattern, and quickly convert the read into remote access.

Read permissions should therefore be narrow, explicit, and reviewable. The role that can read the password should be limited to the smallest set of people or systems that truly need it, and the read path should be logged in a way that makes it possible to answer who queried what, when, and from where. NIST Cybersecurity Framework 2.0 supports that approach because the governance, protect, detect, and respond functions all apply to privileged directory access.

It also helps to distinguish the attribute read from downstream endpoint use. If a password read is followed by a successful login on an unusual host, or if multiple systems are accessed in quick succession, the read was likely not routine administration. That sequence is what turns a directory permission issue into an active intrusion indicator.

Risk and Threat Considerations

ReadLAPSPassword is risky because it turns directory read access into a reusable privileged credential. If that permission is too broad, an attacker who compromises a single account can retrieve local admin passwords, authenticate directly to endpoints, and expand laterally without needing to crack anything.

Failure mechanism: Excessive directory-read rights, weak delegation boundaries, or password reuse across hosts let a single query become an endpoint compromise path.

Impact: The attacker can move from directory access to local administrator control, which raises the chance of rapid lateral movement, host takeover, and wider domain compromise.

Practitioner Guidance

What to verify: Confirm which principals can read the LAPS attribute, whether those principals are still required, and whether the read scope matches actual operational need. If a help desk, admin group, or automation account can read far more systems than it should, treat that as a privilege review finding, not a cosmetic policy issue.

What good looks like: Reads are rare, attributable, and tied to expected support activity; endpoint use follows a documented recovery pattern; and there is enough logging to reconstruct the sequence from directory read to host access. If you cannot connect those steps, your visibility is too weak to tell routine administration from abuse.

Practitioner takeaway: The read permission is the control boundary. If an attacker can obtain the password, the real question becomes how quickly you can detect the read, contain the account, and determine whether that credential has already been used to pivot.

Related resources from NHI Mgmt Group

• Guide: Local Administrator Password Solution (LAPS) Guide
• What does Fast-Flux DNS look like in a real intrusion?
• What does HTTP Desync Attack look like in a real intrusion?
• What does timeroasting look like in a real intrusion?
• How should security teams handle credential abuse when breaches look like system intrusion?