SAM, LSA Secrets and Cached Logons
Also calledSAM dump, LSA secrets, Cached credentials, DCC2
Takes local hashes, stored passwords and cached domain logons from a machine's hives.
- Technique
- MITRE ATT&CK T1003.002: OS Credential Dumping: Security Account Manager (opens in a new tab)MITRE ATT&CK T1003.004: OS Credential Dumping: LSA Secrets (opens in a new tab)MITRE ATT&CK T1003.005: OS Credential Dumping: Cached Domain Credentials (opens in a new tab)
- Needs
- Local Admin
- Gives
- NT HashandPasswordandService Key
How the Attack Works
Each machine keeps its local accounts' NT hashes in the SAM hive, and its SECURITY hive holds its LSA secrets (the passwords of services that run as an account, and its own computer account password) and verifiers for recent domain sign-ins. Both are encrypted with a key kept in the SYSTEM hive, so admin rights are enough to copy all three and decode them elsewhere. A local hash can be passed as it is, but a cached verifier cannot be passed, only guessed against offline.
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.
ws-017 Foothold
srv-fin-01 File server
Offline
Step 1 of 4: Hives Saved
On ws-017 Foothold
With admin rights, copies of the SAM, SECURITY and SYSTEM hives are saved to files on ws-017.
Logged
4688 A new process has been created
On ws-017, in the Security log When enabled
reg.exe started with the SAM, SECURITY or SYSTEM hive on its command line
What Defenders See
On ws-017, event 4688 in the Security log, or Sysmon event 1 in the Microsoft-Windows-Sysmon/Operational log, shows reg.exe saving those hives. New files named like them also appear in temporary folders.
Step 2 of 4: Copies Taken Away
ws-017 Foothold to Offline
The three files leave ws-017. The SYSTEM hive holds the startup key that unlocks the secrets in the other two.
What Defenders See
Endpoint file and network events from ws-017 show the copies leaving the machine.
Step 3 of 4: Secrets Decoded
Offline, away from the network
Local NT hashes, LSA secrets and cached domain verifiers come out, with ws-017's own computer account password.
What Defenders See
No log on any machine in the domain records this step, because it happens offline.
Step 4 of 4: Local Admin Hash Reused
ws-017 Foothold to srv-fin-01 File server
The local Administrator's NT hash answers NTLM on srv-fin-01, which accepts it where the two share that password.
Logged
4624 An account was successfully logged on
On srv-fin-01, in the Security log
Logon Type 3 over NTLM, Account Domain SRV-FIN-01, a local account signing in from another machine
Reading Logon Events explains how to read it.4776 The computer attempted to validate the credentials for an account
On srv-fin-01, in the Security log
The local account checked against srv-fin-01's own SAM
NTLM Authenticate and Validation explains how to read it.
What Defenders See
The Security log on srv-fin-01 shows event 4624 with Logon Type 3 and NTLM for Administrator of SRV-FIN-01, from WS-017. Its event 4776 lands in the Security log on srv-fin-01, not on a DC.
Needs First
What the attacker must already hold for this attack to be possible.
- Local Admin RightsAdmin rights on the machine, enough to save or copy its SAM, SECURITY and SYSTEM hives.
Comes From
Gives the Attacker
What running it hands the attacker to use next.
- An NT HashLocal accounts' NT hashes, so one shared local admin password opens every machine that has it.
- A PasswordPasswords kept as LSA secrets, such as those of services that run as domain accounts.
- A Service's KeyThe machine's own computer account password, whose key forges service tickets to it.
Leads To
- NT Hash: Pass-the-Hash, Overpass-the-Hash
- Password: Pass-the-Hash, Overpass-the-Hash
- 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 |
|---|---|---|---|
| 4688 A new process has been created (opens in a new tab) Security log | Every Windows computer, domain controllers included | reg.exe, or another process, saving the SAM, SECURITY or SYSTEM hive. The command line needs its own policy setting. | Audit Process Creation, with Include command line in process creation events also on to record the command line |
| 4624 An account was successfully logged on (opens in a new tab) Security log | The computer that was logged on to | Logon Type 3 over NTLM by a local account, its Account Domain the target itself, from another machine.Reading Logon Events explains how to read it. | Audit Logon |
| 4776 The computer attempted to validate the credentials for an account (opens in a new tab) Security log | The computer that holds the account, a domain controller for a domain account or the computer itself for a local one | Credential validation logged on a member server or workstation, which means a local account was used there.NTLM Authenticate and Validation explains how to read it. | Audit Credential Validation |
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.
4624 An account was successfully logged on
In the Security log on srv-fin-01,
ws-017's local Administrator hash opening srv-fin-01, where the two machines share one password.
A network sign-in, such as a share or a remote service, not a desktop.
As Windows writes it:
Logon Type3The built-in local Administrator. Without LAPS it often has the same password on many machines.
As Windows writes it:
Account NameAdministratorA local account of srv-fin-01 itself. A local account signing in from another machine is rare in a domain.
As Windows writes it:
Account DomainSRV-FIN-01The machine the hash was used from.
As Windows writes it:
Workstation NameWS-017ws-017's address, matching the workstation name.
As Windows writes it:
Source Network Address192.0.2.17A local account has no KDC to get tickets from, so a stolen local hash arrives over NTLM.
As Windows writes it:
Authentication PackageNTLM
Blind Spots
Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.
- A missing hive-saving event proves little, because anyone who can read the disk, a backup or a shadow copy of it can read the hives too.
- Nothing in the reuse marks the hash as stolen. What stands out is a local account signing in from another machine at all.
Look for It on a Machine
The Registry keys on an endpoint that hold a trace of this, each opening its own page.
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 Endpoint on the machine. Backup tools save hives too, so a save from a user session or into a temporary folder deserves a look.
// reg.exe saving the SAM, SECURITY or SYSTEM hive to a fileDeviceProcessEvents| where Timestamp > ago( 30d)| where FileName =~ "reg.exe"| where ProcessCommandLine has_any ( "save", "export")| where ProcessCommandLine has_any ( "sam", "security", "system")| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine| order by Timestamp descHow 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)
Give every machine its own local administrator password, so a hash from one opens no other.
Local admins kept off the network (opens in a new tab)
Deny local accounts network and Remote Desktop sign-ins, so a stolen local hash does not travel.
Check it on a machine: User Account Control SettingsGroup managed service accounts (opens in a new tab)
Run services as group managed service accounts, whose passwords Windows sets and changes, not people.
No automatic logon (opens in a new tab)
Store no password for automatic logon on the machine.
Check it on a machine: Automatic LogonFewer cached logons (opens in a new tab)
Cache fewer domain logons, or none on machines that always reach a DC, so fewer verifiers sit on disk.
Check it on a machine: Cached Domain LogonsTiered administration (opens in a new tab)
Keep privileged accounts off ordinary machines, so none of their verifiers or secrets are stored there.
Sources
- MITRE ATT&CK T1003.002: OS Credential Dumping: Security Account Manager (opens in a new tab)
- MITRE ATT&CK T1003.004: OS Credential Dumping: LSA Secrets (opens in a new tab)
- MITRE ATT&CK T1003.005: OS Credential Dumping: Cached Domain Credentials (opens in a new tab)
- Microsoft Learn: Credentials processes in Windows authentication (LSA secrets) (opens in a new tab)
- Microsoft Learn: System key utility technical overview (the startup key) (opens in a new tab)
- Microsoft Learn: Local accounts (opens in a new tab)
- Microsoft Learn: Windows LAPS overview (opens in a new tab)
- Microsoft Learn: Interactive logon, number of previous logons to cache (opens in a new tab)