Skip to content

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.

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.

With admin rights on ws-017, dana's workstation and now a foothold, the hives that hold its secrets are copied and decoded elsewhere.Step through it

ws-017 Foothold

srv-fin-01 File server

Offline

  1. Step 1 of 4, Hives Saved, on ws-017
  2. Step 2 of 4, Copies Taken Away, ws-017 to Offline
  3. Step 3 of 4, Secrets Decoded, on Offline
  4. Step 4 of 4, Local Admin Hash Reused, ws-017 to srv-fin-01
  1. 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.

  2. 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.

  3. 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.

  4. Step 4 of 4: Local Admin Hash Reused

    ws-017 Foothold to srv-fin-01 File server

    Answer made from the local hash AUTHENTICATE_MESSAGE SMB, port 445

    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.

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.

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 LogWritten OnLook ForSwitch It On
4688 A new process has been created (opens in a new tab) Security logEvery Windows computer, domain controllers includedreg.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 logThe computer that was logged on toLogon 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 logThe computer that holds the account, a domain controller for a domain account or the computer itself for a local oneCredential 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 Type 3

  • The built-in local Administrator. Without LAPS it often has the same password on many machines.

    As Windows writes it: Account Name Administrator

  • A 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 Domain SRV-FIN-01

  • The machine the hash was used from.

    As Windows writes it: Workstation Name WS-017

  • ws-017's address, matching the workstation name.

    As Windows writes it: Source Network Address 192.0.2.17

  • A local account has no KDC to get tickets from, so a stolen local hash arrives over NTLM.

    As Windows writes it: Authentication Package NTLM

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.

KQLDefender XDR, Advanced hunting
// 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 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.

Sources