SAM hive direct modification
A value inside the SAM registry hive was written directly.
What it detects
A value inside the SAM registry hive was written directly. HKLM\SAM is the local account database — password verifiers, account flags and group membership — and it is not an ordinary configuration key: it is normally reached only through the account-management APIs, which is what net user, the Users control panel and every legitimate management tool call.
Writing it directly bypasses that layer, and the specific values seen in real intrusions say what was intended: ForcePasswordReset on RID 000001F4 (the built-in Administrator) resets that account's password; entries under Domains\Builtin\Aliases change group membership; entries under Account\Users\Names create accounts.
windows.persistence.hidden_local_account covers the specific $-suffixed hidden-account case at critical severity; this rule is the broader net for the rest of SAM tampering.
MITRE ATT&CK mapping
False positives and triage
LSASS itself writes to SAM whenever an account is genuinely created or changed, so this is not silent on a busy server. Two things separate routine from tampering.
First, the writing process: lsass.exe acting on behalf of a management tool is the normal path; reg.exe, powershell.exe, or a binary in a user directory is not. Second, whether the change has a matching Security-log record — a genuine account creation also produces 4720, and a membership change produces 4732. A SAM write with no corresponding audit event means the API layer was bypassed, which is the whole point of doing it this way, and should be treated as an attempt to create access that ordinary account reviews will not show.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 75%. Source: rules/windows/sam_hive_direct_modification.yaml, licensed under the Apache License 2.0.
id: windows.credential.sam_hive_direct_modification
version: 1.0.0
status: stable
severity: high
confidence: 0.75
platforms: [windows]
mitre_techniques: [T1098, T1003.002]
description: |
A value inside the SAM registry hive was written directly. `HKLM\SAM` is the local
account database — password verifiers, account flags and group membership — and it
is not an ordinary configuration key: it is normally reached only through the
account-management APIs, which is what `net user`, the Users control panel and every
legitimate management tool call.
Writing it directly bypasses that layer, and the specific values seen in real
intrusions say what was intended: `ForcePasswordReset` on RID `000001F4` (the
built-in Administrator) resets that account's password; entries under
`Domains\Builtin\Aliases` change group membership; entries under `Account\Users\Names`
create accounts.
`windows.persistence.hidden_local_account` covers the specific `$`-suffixed
hidden-account case at critical severity; this rule is the broader net for the rest
of SAM tampering.
match:
registry_path_contains_any:
- '\SAM\SAM\Domains\Account\Users\'
- '\SAM\SAM\Domains\Builtin\Aliases\'
correlation_keys: [hostname]
false_positive_guidance: |
LSASS itself writes to SAM whenever an account is genuinely created or changed, so
this is not silent on a busy server. Two things separate routine from tampering.
First, the writing process: `lsass.exe` acting on behalf of a management tool is the
normal path; `reg.exe`, `powershell.exe`, or a binary in a user directory is not.
Second, whether the change has a matching Security-log record — a genuine account
creation also produces 4720, and a membership change produces 4732. A SAM write with
no corresponding audit event means the API layer was bypassed, which is the whole
point of doing it this way, and should be treated as an attempt to create access
that ordinary account reviews will not show.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.