LSA secrets access
A value under HKLM\SECURITY\Policy\Secrets was read or written.
What it detects
A value under HKLM\SECURITY\Policy\Secrets was read or written. This is the LSA secrets store, and it is not ordinary configuration — it holds the plaintext- recoverable secrets Windows needs to operate:
* $MACHINE.ACC — the computer account password. With it an attacker can authenticate AS the machine, request Kerberos tickets in its name, and on a domain controller reach material that leads to a full domain compromise. * service-account passwords for services configured to run as a named user, recoverable in cleartext. * cached domain credentials, DPAPI keys, and auto-logon passwords.
HKLM\SECURITY is not readable even by administrators without deliberately taking ownership or running as SYSTEM, so access to it is never incidental — reaching it is a step someone took on purpose. Mimikatz lsadump::secrets, reg save HKLM\SECURITY and secretsdump all pass through here.
MITRE ATT&CK mapping
False positives and triage
Effectively none. Backup software that images the registry may touch these hives, and domain-join or password-rotation operations write $MACHINE.ACC legitimately — both from SYSTEM-level service processes, on a schedule you can recognise.
To confirm: the accessing process is the question. lsass.exe or a backup agent is routine; reg.exe, powershell.exe, or anything in a user directory is credential theft. Treat the machine account as disclosed and force a password change, and treat every service account on the host as disclosed too. On a domain controller, assume domain compromise and escalate accordingly — the machine account there is not just one more credential.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 90%. Source: rules/windows/lsa_secrets_access.yaml, licensed under the Apache License 2.0.
id: windows.credential.lsa_secrets_access
version: 1.0.0
status: stable
severity: critical
confidence: 0.9
platforms: [windows]
mitre_techniques: [T1003.004, T1003.002]
description: |
A value under `HKLM\SECURITY\Policy\Secrets` was read or written. This is the LSA
secrets store, and it is not ordinary configuration — it holds the plaintext-
recoverable secrets Windows needs to operate:
* `$MACHINE.ACC` — the computer account password. With it an attacker can
authenticate AS the machine, request Kerberos tickets in its name, and on a
domain controller reach material that leads to a full domain compromise.
* service-account passwords for services configured to run as a named user,
recoverable in cleartext.
* cached domain credentials, DPAPI keys, and auto-logon passwords.
`HKLM\SECURITY` is not readable even by administrators without deliberately taking
ownership or running as SYSTEM, so access to it is never incidental — reaching it is
a step someone took on purpose. Mimikatz `lsadump::secrets`, `reg save HKLM\SECURITY`
and secretsdump all pass through here.
match:
registry_path_contains_any:
- '\SECURITY\Policy\Secrets'
- '\SECURITY\Cache\NL$'
correlation_keys: [hostname, user_name]
false_positive_guidance: |
Effectively none. Backup software that images the registry may touch these hives,
and domain-join or password-rotation operations write `$MACHINE.ACC` legitimately —
both from SYSTEM-level service processes, on a schedule you can recognise.
To confirm: the accessing process is the question. `lsass.exe` or a backup agent is
routine; `reg.exe`, `powershell.exe`, or anything in a user directory is credential
theft. Treat the machine account as disclosed and force a password change, and treat
every service account on the host as disclosed too. On a domain controller, assume
domain compromise and escalate accordingly — the machine account there is not just
one more credential.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.