Detecting SAM Database Credential Dumping (T1003.002)

Security Account Manager (T1003.002) is a credential access sub-technique for Windows. The SAM is a database that holds the local accounts of a host, typically those you see with the net user command. Adversaries try to extract credential material from it, either through in-memory techniques or through the registry where SAM is stored. MITRE notes that enumerating the SAM requires SYSTEM level access.

How attackers use it

MITRE describes two broad approaches. In-memory tools can retrieve the SAM, and MITRE names several, including pwdumpx, gsecdump, Mimikatz and secretsdump.py. The alternative is to save the SAM and SYSTEM registry hives to files with the built-in reg utility and process them offline with a separate tool.

MITRE adds a note on account numbering. RID 500 is the built-in local administrator, RID 501 is the guest account, and user accounts start at 1,000 and up. That matters to defenders because the built-in administrator is the usual prize, and its hash is only useful elsewhere if the password is shared.

The offline route is the one worth watching for. The hashes leave the machine as ordinary files.

How to detect it

MITRE's analytic describes SYSTEM-level activity that touches HKLM\SAM and HKLM\SYSTEM in sequence, or direct reads of files in the config directory, followed by creation of files with names ending in .save or .dmp. Those files make offline hash extraction possible.

Sources to wire up:

• Process creation events with command lines, looking for reg.exe saving the SAM or SYSTEM hives.
• Registry access auditing on the SAM hive.
• File creation events for new .save or .dmp files, especially in temp or user folders.
• Reads of the config directory by anything other than expected system components and backup software.

A user-level admin running reg save against the SAM is rare in healthy environments. Start with an alert that fires on that exact command line and add other signals later.

How to reduce the risk

MITRE lists these mitigations:

• Password Policies: complex, unique local administrator passwords on every system, so a stolen hash from one machine opens nothing else.
• Privileged Account Management: do not place domain user or admin accounts in local administrator groups across systems unless tightly controlled, and limit privileged account use across administrative tiers.
• Operating System Configuration: consider disabling or restricting NTLM.
• User Training: do not reuse passwords across accounts.

The first item deserves the most attention. Shared local administrator passwords turn one dumped hash into a whole-network problem.

Why local accounts still matter

Teams often focus on domain credentials and forget that every Windows host has local accounts. They matter because they tend to be the same on many machines. If imaging or deployment tools set one local administrator password across the fleet, a hash from the SAM of a single laptop is a key to all of them.

The fix is old and effective: make each machine's local administrator password different, random and rotated. Microsoft ships a feature for that, called Local Administrator Password Solution, which stores each password in the directory with controlled access. It matches what MITRE says about unique passwords across systems.

Tuning the detection

Registry hive saves are rare in normal operations. Backup tools and some forensic utilities do them, so build a short list of the processes that are allowed and alert on the rest. Command line logging is the key, because it turns "reg.exe ran" into "reg.exe saved the SAM to a user folder", which is a very different statement.

Pay attention to where the output lands. Files written to temp folders, user profile folders or network shares, with names that echo the hive names, are the ones to chase.

After a detection

Treat every local account hash on that host as exposed. Rotate the local administrator password, check whether any other machine shared it, and review where the account logged on. Then look for the next step, which is usually authentication to other hosts using the stolen material.

Check your own environment

• Count how many machines share the same local administrator password. The answer should be zero.
• List the members of local Administrators groups on a sample of workstations and look for domain accounts.
• Confirm that command line logging is on, so process creation events show arguments.
• Check that NTLM use is measured, since you cannot restrict what you have not measured.

To confirm command line logging is enabled on a Windows host (reg.exe, read-only):

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit /v ProcessCreationIncludeCmdLine_Enabled

A value of 1 means the arguments are being recorded.

Quick check

Sources

• MITRE ATT&CK T1003.002: Security Account Manager