LSA Secrets (T1003.004) is a credential access sub-technique for Windows. Adversaries with SYSTEM access to a host may try to read Local Security Authority secrets, which can hold credential material such as credentials for service accounts.
How attackers use it
MITRE describes where the secrets live: in the registry at HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets. They can also be dumped from memory. The built-in Reg utility can extract them from the registry, and Mimikatz can pull them from memory.
The risk is highest for service accounts. A service that runs under a domain account often needs its password stored locally, and that password sits among the LSA secrets. One compromised server can leak an account that has reach elsewhere.
How to detect it
MITRE's analytic watches for two behaviors: exporting the Secrets registry key, and memory scraping with tools such as Mimikatz or PowerSploit's Invoke-Mimikatz.
Where to look:
- Process creation events with command lines for reg.exe touching the SECURITY hive.
- Registry auditing on the Secrets key, which few legitimate processes read.
- Process access events targeting LSASS, which accompany the in-memory route.
- PowerShell script block logging, which can expose known tool names inside scripts.
Because only SYSTEM can read these, any alert here usually means the attacker already holds high privileges on the host. Treat it as a sign of deeper compromise.
How to reduce the risk
MITRE lists:
- Password Policies: complex, unique local administrator passwords across systems.
- Privileged Account Management: follow best practices for design and administration of an enterprise network to limit privileged account use across administrative tiers.
- User Training: do not reuse passwords across accounts.
For service accounts, apply the same logic. Give each service its own account with the least privilege it needs, so that a leaked secret opens one door.
Why service accounts are the real prize
LSA secrets are where Windows keeps the passwords that services need to start under a domain account. Anyone who reads them gets that account, not just a local foothold. A service account that is also a member of a powerful group turns one server compromise into a domain problem.
That makes the cleanup work concrete. Make a list of every account that runs a service, scheduled task or application pool. Next to each, write down where it is used and what groups it belongs to. Remove membership you cannot justify, and prefer managed service accounts where your applications support them, because the system rotates those passwords for you.
Tuning the detection
Reads of the Secrets key are rare outside the operating system itself. Start with registry auditing on that key, exclude the system processes you can name, and send what is left to an analyst. Combine it with the process access signals for LSASS, since the memory route leaves those traces.
After a detection
Treat every service account configured on that host as exposed. Reset their passwords, starting with the most privileged, and check where each one has logged on since the event.
Check your own environment
- List service accounts that run on more than one server, and note which ones are domain administrators. The second list should be empty.
- Confirm that registry auditing covers the SECURITY hive on servers.
- Make sure PowerShell script block logging is enabled.
Quick check
What access does an adversary need to read LSA secrets?
MITRE says SYSTEM access to the host. That makes any detection here a sign that the attacker already holds high privileges.
