LAPS and gMSA Password Reads

Also calledLAPS password read, Golden gMSA

Reads a managed local-admin or service-account password straight from the directory.

Technique: MITRE ATT&CK T1555: Credentials from Password Stores (opens in a new tab)
Needs: Domain Admin
Gives: Local AdminandService Key

How the Attack Works

Windows LAPS stores each machine's managed local-administrator password in the directory, and a group managed service account's password lives there too. Both are meant to be read only by a few accounts, so a read of the password attribute by anyone else is the signal, whether it is the local-admin secret or the service-account key. The read is an ordinary directory lookup, so it leaves nothing on the domain controller unless the directory is set to audit it.

Read first Password Hashes and Kerberos Keys, Credentials on a Running Machine

How It Plays Out

The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.

From ws-042, srv-fin-01's LAPS password attribute and a gMSA's managed password are read from the directory, and each read lands in the Security log on dc-01.Step through it

ws-042 Foothold

dc-01 Domain controller

srv-fin-01 File server

Step 1 of 3, Password Read, ws-042 to dc-01
Step 2 of 3, gMSA Read, ws-042 to dc-01
Step 3 of 3, On the Managed Host, on srv-fin-01

Step 1 of 3: Password Read
ws-042 Foothold to dc-01 Domain controller
ws-042 reads srv-fin-01's LAPS password attribute from the directory, a value only a few accounts should ever read.
Logged
- 4662 An operation was performed on an object
  On dc-01, in the Security log When enabled
  A read of the LAPS password attribute, with the account that read it.
What Defenders See
The Security log on dc-01 shows event 4662 with Control Access on the computer object and the LAPS password attribute in Properties, naming the account that read it.
Step 2 of 3: gMSA Read
ws-042 Foothold to dc-01 Domain controller
The managed password of a group managed service account is read the same way, which hands over its key.
Logged
- 4662 An operation was performed on an object
  On dc-01, in the Security log When enabled
  A read of msDS-ManagedPassword on a gMSA, with the account that read it.
What Defenders See
The Security log on dc-01 shows event 4662 on the service account object for msDS-ManagedPassword, and Defender for Identity may raise its Golden gMSA alert.
Step 3 of 3: On the Managed Host
On srv-fin-01 File server
On srv-fin-01 itself, Windows LAPS writes its own operational events when the managed account is used, on the client and not the DC.
Logged
- 10018 and 10041 LAPS successfully updated Active Directory with the new password, LAPS detected a successful authentication for the currently managed account
  On srv-fin-01, in the Microsoft-Windows-LAPS/Operational log When enabled
  A LAPS operational event on the managed machine, where the account was used.
What Defenders See
The Microsoft-Windows-LAPS/Operational log on srv-fin-01 shows a LAPS event where the managed account authenticated, which the DC never sees.

Needs First

What the attacker must already hold for this attack to be possible.

Domain Admin RightsThe right to read the managed password, which by default only Domain Admins and a few chosen readers hold.

Comes From

Domain Admin: Golden Ticket, Diamond and Sapphire Tickets, Certificate Services Abuse, noPac (sAMAccountName Spoofing) every attack that gives it: Domain Admin Rights

Gives the Attacker

What running it hands the attacker to use next.

Local Admin RightsThe local administrator password of the machine whose LAPS secret was read, and so admin on it.
A Service's KeyA gMSA's key, where its managed password was read, which seals every ticket to it.

Leads To

Local Admin: LSASS Memory Theft, SAM, LSA Secrets and Cached Logons, Clearing and Silencing Logs
Service Key: Silver Ticket

What Defenders See

What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.

Event and Log	Written On	Look For	Switch It On
4662 `An operation was performed on an object` (opens in a new tab) Security log	Domain controllers, for objects with a matching audit entry	Control Access on a computer or service account object for the LAPS or msDS-ManagedPassword attribute, by an account outside the few allowed to read it.	Audit Directory Service Access, and an audit entry (SACL) on the object
10018 and 10041 `LAPS successfully updated Active Directory with the new password, LAPS detected a successful authentication for the currently managed account` (opens in a new tab) Microsoft-Windows-LAPS/Operational log	The machine whose local administrator account Windows LAPS manages, not the DC	A Windows LAPS operational event on the managed machine, read alongside the DC's 4662 to tie the read to a use of the account.	Windows LAPS on the machine, with post-authentication actions in its policy for 10041

What It Looks Like

One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.

4662 An operation was performed on an object

In the Security log on dc-01, 15 Oct 2026, 16:55:11 UTC

A read of a LAPS password attribute on dc-01, from the foothold on ws-042.

The computer object read, srv-fin-01. A read of its password attribute by anyone but the few allowed accounts is the signal to follow.
As Windows writes it: Object Name CN=SRV-FIN-01,OU=Servers,DC=corp,DC=example
The read used the Control Access right, how a confidential attribute such as the LAPS password is read. Read it with Properties to see which attribute.
As Windows writes it: Accesses Control Access
The ms-LAPS-Encrypted-Password-Attributes right, so this read touched the LAPS password. Check whether the account that read it should have.
As Windows writes it: Properties {f3531ec6-6330-4f8e-8d39-7a671fbac605}
The account that read it, the ws-042 computer account acting as SYSTEM. A workstation reading a server's LAPS password is not normal.
As Windows writes it: Subject Account Name WS-042$

Defender for Identity Alerts

Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.

Suspicious Golden gMSA related activity (opens in a new tab)Raised where a sensitive gMSA's managed password objects are read in a way that fits a Golden gMSA attempt. It covers the gMSA case, not every LAPS read, so pair it with event 4662 in the Security log, scoped to the password attributes.

Blind Spots

Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.

Event 4662 appears only where Audit Directory Service Access is on and an audit entry (SACL) is set on the objects, so without that the read leaves nothing on the DC.
The event names the attribute read, not the password value, and a legitimate administrator read looks the same, so judge it by who read it and whether they should.

Hunt It

The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.

Needs Defender for Identity sensors on every DC. The raw directory read is not in the device tables, so this leans on the sensor's alerts. Confirm against event 4662 scoped to the password attributes.

KQLDefender XDR, Advanced hunting

// Defender for Identity alerts for sensitive-attribute reads and gMSA password readsAlertInfo| where Timestamp > ago(30d)| where Title in ("Suspicious Golden gMSA related activity", "Suspicious LDAP query targeting sensitive attributes")| join kind=inner AlertEvidence on AlertId| summarize FirstSeen = min(Timestamp), Accounts = make_set(AccountName), Devices = make_set(DeviceName) by AlertId, Title| order by FirstSeen desc

How to Prevent It

The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.

Windows LAPS (opens in a new tab)
Use Windows LAPS so each machine's local admin password is unique and managed, and keep its read permission to the few who need it.
Group managed service accounts (opens in a new tab)
Run services as group managed service accounts, and grant retrieval of each managed password only to the hosts that run the service.
Delegated managed service accounts (opens in a new tab)
Move service accounts to delegated managed service accounts, whose keys are managed and usable only from the machines named for them.
Replication rights reviewed (opens in a new tab)
Review who can read the LAPS and managed-password attributes, and treat a read by anyone else as an incident to explain.

How the Attack Works

How It Plays Out

Step 1 of 3: Password Read

Step 2 of 3: gMSA Read

Step 3 of 3: On the Managed Host