Registry Parser
← All articles

Detecting T1003.002: SAM credential-dumping activity

9 min read

MITRE ATT&CK T1003.002 — OS Credential Dumping: Security Account Manager — is one of the most reliably abused techniques in the credential-access tactic, and it is one of the few that leaves clean, registry-resident evidence behind. This post is for the blue team: it is about detecting and investigating SAM credential-dumping activity, not performing it. There are no extraction commands, no dumping recipes, and no cracking steps here. The goal is to understand why the SAM hive is a target, why an attacker needs more than the SAM hive to get anything out of it, and what you — the investigator — actually see when this technique runs against a host. If you want the broader map of how techniques land in the registry, start with MITRE ATT&CK and the registry; this is the T1003.002-specific companion.

What's in the SAM and why it's targeted

The SAM (Security Account Manager) hive is the local account database. Every local user defined on the machine lives as a subkey under SAM\Domains\Account\Users\<RID>, and each one carries two binary values — F and V — that hold the account metadata and, crucially, the password material. The V structure stores the NT hash (and, on older or misconfigured systems, the LM hash) alongside the username, full name, and comment. That is what makes the SAM a credential-access target: it is a per-host vault of local credential hashes, sitting on disk, in a file format that has been documented for two decades.

The attacker's interest is concrete. The local Administrator account (RID 500) is present on every Windows install, even when renamed, and its hash is frequently reused across a fleet that was imaged from a common golden build. Recover one local-admin hash and, where pass-the-hash is viable, you may have just acquired lateral movement to every machine that shares it. That is the prize. The SAM is local — it knows nothing about domain accounts, which live in NTDS.dit on a domain controller — so a SAM dump buys local and lateral credential access, not domain-wide compromise on its own. For the full breakdown of what the SAM's structures contain and how they decode, see the samparse deep-dive.

Why SAM alone isn't enough (the SYSTEM bootkey)

Here is the structural fact that shapes both the attack and your detection of it: the hashes inside the SAM are encrypted, and the SAM hive does not contain the key to decrypt them. The hashes are protected by the syskey — the bootkey — and the bootkey is not stored in the SAM at all. It is assembled from four obfuscated Class attributes scattered across SYSTEM\CurrentControlSet\Control\Lsa: the JD, Skew1, GBG, and Data subkeys. The bootkey derived from those values unlocks the SAM's encryption, and only then does the credential material become recoverable offline.

This is why credential dumping at T1003.002 always involves both the SAM and the SYSTEM hive. SAM holds the ciphertext; SYSTEM holds the material to derive the key. A SAM hive collected on its own is a vault whose contents cannot be read. The same dependency that frustrates an attacker working with a partial collection is a gift to the defender: the technique has a two-hive signature. Wherever you see SAM being accessed, copied, or exported for credential purposes, you should expect SYSTEM to be touched right alongside it, and the appearance of the two together is a far stronger signal than either alone. (I am deliberately not walking through the derivation — you do not need it to investigate, and it is not the point of this post.)

Acquiring those hives also requires SYSTEM-level access. The live SAM and SYSTEM files are locked by the kernel while Windows runs, and reading the raw hive — or reaching the syskey Class attributes, which are hidden from ordinary registry queries — is a privileged operation. So T1003.002 is, by construction, a post-exploitation, already-elevated activity. If you see its artifacts, an adversary already had administrative or SYSTEM rights on the host. Treat the dump as a marker of a compromise that has already escalated, not the first foothold.

Detecting and investigating SAM access

Because the live hives are locked, an attacker cannot simply copy C:\Windows\System32\config\SAM with a file copy. They have to go around the lock, and every route around it leaves a detectable trace. These are the signals to hunt for.

  • Registry hive export. The built-in reg save (and its reg export / RegSaveKey API equivalents) can write a copy of HKLM\SAM and HKLM\SYSTEM to a file from an elevated context. The tell is the command line: an invocation referencing hklm\sam, hklm\system, or hklm\security writing to a path. Command-line and process-creation logging (Sysmon Event ID 1, Security 4688 with command-line auditing enabled) is your primary detection. A reg save of SAM and SYSTEM in close succession — the two-hive signature — is high-fidelity. Legitimate reg save of SAM is rare; backup software has its own paths.

  • Volume Shadow Copy abuse. The classic way around the file lock is to read the hive from a VSS snapshot, where the SAM and SYSTEM files are accessible as ordinary files. Watch for unexpected shadow-copy creation (vssadmin create shadow, WMI Win32_ShadowCopy creation, or esentutl reads against shadow paths) on workstations and servers that have no business making them. Snapshot creation outside a backup window, followed by file reads under a \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy...\Windows\System32\config\ path, is the pattern.

  • Raw volume / device reads. More sophisticated tooling reads the NTFS volume at the device level (\\.\C:) to pull the hive bytes without ever opening the locked file. This is harder to catch with file-system auditing but shows up as a process opening a raw \Device\HarddiskVolume handle — Sysmon Event ID 1 plus driver/handle telemetry, and EDR raw-disk-access detections, are where this surfaces.

  • The remote-registry and live-LSASS adjacencies. SAM material can also be pulled over the wire via the Remote Registry service against HKLM\SAM, and credential access frequently pairs with the related sub-techniques (see below). Monitor remote-registry activity to SAM/SECURITY and treat it as credential-access-adjacent.

For the artifacts left behind, look at: the registry hive LastWrite and the on-disk MFT timestamps for stray SAM/SYSTEM copies in temp, staging, or archive directories; shadow-copy creation events in the System and Microsoft-Windows-VolumeSnapshot logs; process-creation records for the reg/vssadmin/esentutl/wmic invocations above; and archive creation (a .zip/.7z/.cab bundling the hive files) immediately before exfiltration. The dump itself touches the registry lightly, but the mechanism of getting at the locked hive is loud if you are logging the right things.

What the SAM tells an investigator

When you are the one parsing the SAM — during triage of a host you suspect was hit, or analysing a hive someone else dumped — the same structures the attacker wanted reveal the state of the local accounts to you. You read the SAM not for the hashes but for the account story:

  • The account inventory and RIDs. Enumerate SAM\Domains\Account\Users and map every RID against the well-known set: 500 (Administrator, always, even renamed), 501 (Guest, normally disabled), the system-managed accounts in the 500s, and human/service accounts from 1000 up. An enabled Guest, a renamed 500, or an unexpected account in the 1000s is where you look first.
  • Login counts and timestamps. The F structure carries the login count, the failed-login count, last-login and password-last-set FILETIMEs. A privileged account with a zero login count is exactly what a staged backdoor looks like before activation; a password-last-set landing inside your incident window says the credential was provisioned or reset during the event.
  • Account-control flags. The ACB bitfield exposes Account disabled, Account auto-locked, Password not required, and Password does not expire. A Password not required bit on a human account is dangerous on its own. Cross-reference the flagged accounts against local Administrators group membership (the Builtin Aliases branch) and the accounts in both lists are your shortlist.

None of that requires decrypting anything. The SAM's account metadata is a forensic narrative of who could log in, when they did, and which accounts were created or weakened — and it reads the same whether you are doing live triage or examining a recovered hive. For the per-field decoding, the samparse deep-dive is the reference.

Investigate it in your browser

You can analyze a SAM hive in your browser with no upload and no local toolchain — the parser decodes the F and V structures, the ACB flags, the RIDs, and the timestamps client-side, so a hive recovered from a triage image or a VSS copy never leaves your machine. That matters for credential-bearing artifacts: a SAM hive is sensitive evidence, and a browser-only parser keeps your chain of custody and your data-handling clean. Load the SAM for the account inventory, then pull the SYSTEM and SECURITY hives alongside it for the surrounding context — the same two-hive (plus SECURITY) collection logic that the technique itself depends on.

Related techniques

T1003.002 rarely travels alone. The sibling sub-techniques under T1003 OS Credential Dumping are where the same actor usually goes next, and the registry holds evidence for several of them:

  • T1003.004 — LSA Secrets. The SECURITY hive's Policy\Secrets holds service-account passwords, autologon credentials, and the machine-account password — and it is unlocked by the same SYSTEM bootkey. Detecting SECURITY-hive access goes hand-in-hand with SAM access; see the lsasecrets deep-dive.
  • T1003.005 — Cached Domain Credentials. The MSCACHEv2 verifiers under SECURITY\Cache reveal which domain accounts logged on interactively to the host — a lateral-movement signal that a SAM-only dump never shows.
  • Profile and logon corroboration. When you need to tie account activity to actual sessions, the ProfileList deep-dive covers the SID-to-profile mapping that complements the SAM's local-account view.

The defensible report from a T1003.002 investigation is: the mechanism of access (hive export, shadow copy, or raw read), the timeline from process-creation and snapshot events, the two-hive signature confirming credential intent, and the account inventory the SAM exposes about the host's local-identity state. The hashes are the part everyone fixates on; the access trail and the account story are the parts that actually move the investigation.