In this section
Windows Account Forensics: SAM Hive, Account Creation, Group Membership, RegRipper
Every user account on a Windows system is recorded in the SAM registry hive. The SAM tells you which accounts exist, when they were created, what groups they belong to, and when they last logged in. This is the starting point for answering "who was on this system?"
Scenario
The compromised workstation has six local user accounts. Five match known employees. The sixth, svc_backup, was created three days before the EDR alert and is a member of the local Administrators group. No IT ticket authorized this account. You need to determine when it was created, by whom, and whether it was used during the attack.
The SAM hive is the first place to look when answering "who was on this system?" It gives you the complete account inventory. Event logs (Section 3.2) tell you what those accounts did. This section covers extracting and interpreting SAM data with RegRipper, correlating with account lifecycle events in the Security log, and identifying attacker-created accounts.
Estimated time: 35 minutes.
Evidence location and availability
The SAM hive is locked while Windows is running. KAPE uses raw disk access to collect it. On a powered-off system, extract it from the disk image or mount the image with Arsenal Image Mounter (Section 1.5) and copy it directly. The SAM records only local accounts. Domain accounts are in Active Directory. For domain-joined systems, the SAM still contains local accounts including the built-in Administrator, Guest, DefaultAccount, WDAGUtilityAccount, and any locally created accounts the attacker may have added.
Extracting accounts with RegRipper
RegRipper's samparse plugin is the standard tool for SAM extraction. It reads the binary hive and produces human-readable output with every forensically relevant field.
# Extract all account information from SAM
cd C:\Forensics\Tools\RegRipper
perl rip.pl -r "E:\Collection\C\Windows\System32\config\SAM" -p samparseThe samparse output lists every account in the SAM hive with its properties. Here is the output for the six accounts on the compromised workstation:
Reading the SAM output
Each field tells you something specific about the account. Reading them together reveals whether the account is legitimate or suspicious.
RID (Relative Identifier). The number in brackets after the username. RID 500 is always the built-in Administrator. RID 501 is always Guest. RIDs 1000 and above are user-created accounts. A gap in RIDs (e.g., 1003 then 1005 with no 1004) may indicate a deleted account. Check the MFT for deleted user profile directories under C:\Users\ to investigate gaps.
Account Created. The timestamp when the account was created. For RID 500 and 501, this is the Windows installation date. For user accounts, this is when IT (or the attacker) created the account. Compare the creation timestamp with the attack timeline from Module 2. An account created at 02:33 UTC in the middle of an intrusion is almost certainly attacker-created.
Last Login. The last time the account successfully authenticated to the system. This is updated on local console logons and some remote logons. Be aware that the SAM Last Login timestamp is not always updated for network (Type 3) logons depending on the system configuration. Cross-reference with Event 4624 (Section 3.2) for the complete authentication history.
Login Count. The total number of successful logons. A low login count on a recently created account is consistent with an attacker-created persistence account used only a few times. A high login count on a service account that should run unattended may indicate interactive misuse.
Flags. Account configuration flags. The most forensically relevant:
FLAG MEANING INVESTIGATION RELEVANCE
Password does not expire Password never requires reset Persistence indicator
Account Disabled Cannot authenticate Expected for Guest, suspicious if recent
Password not required Empty password allowed Security misconfiguration
Account locked out Too many failed attempts May indicate brute-force target
Normal user account Standard user privileges Expected for user accountsGroups. Local group membership. Administrators group means full system access. An account in the Administrators group that does not belong there is a critical finding.
Identifying attacker-created accounts
Three indicators flag svc_backup as attacker-created:
Creation timestamp within the attack window. The account was created on March 12 at 02:33 UTC, three days before the EDR alert. The creation time (02:33 UTC) is outside normal business hours. Legitimate service accounts are created during planned IT operations with change management approval, not at 2 AM.
Immediate Administrator group membership. The attacker created the account and added it to the local Administrators group within the same second (confirmed by the Event 4732 timestamp in the next section). Legitimate service accounts are typically created with limited permissions and elevated only after review and documentation.
"Password does not expire" flag. The attacker configured the account to never require a password change. Combined with the admin group membership and the overnight creation time, this is a persistence mechanism. The attacker wants this account to remain usable indefinitely without triggering a password expiry lockout.
Empty Full Name field. The five legitimate accounts all have Full Name populated (or are built-in accounts where an empty name is expected). The attacker did not bother setting a display name. This is a minor indicator but contributes to the pattern.
RID gap. RID 1004 is missing. There are RIDs 1001, 1002, 1003, then 1005. If the attacker created and then deleted a test account (RID 1004) before creating svc_backup, the gap may indicate a trial-and-error approach. Check the MFT for a deleted user profile at C:\Users\ that does not correspond to any current SAM account.
Correlating with event log account lifecycle events
The SAM tells you the account exists and its properties. Event logs tell you the full lifecycle: who created it, when it was enabled, when it was added to groups, and every logon and logoff.
# Search for account lifecycle events
Import-Csv "C:\Forensics\Processed\case-001\security.csv" |
Where-Object { $_.EventId -in @(4720, 4722, 4724, 4725, 4726, 4732, 4733) } |
Select-Object TimeCreated, EventId, PayloadData1, PayloadData2, PayloadData3 |
Sort-Object TimeCreatedEVENT ID WHAT IT RECORDS
4720 Account created (includes who created it)
4722 Account enabled
4724 Password reset attempted
4725 Account disabled
4726 Account deleted
4732 Member added to security-enabled local group
4733 Member removed from security-enabled local groupThe three events occurred within one second. This sequence (create, enable, add to Administrators) is consistent with a scripted command:
# This is what the attacker likely ran (reconstruction, not from evidence)
net user svc_backup P@ssw0rd123 /add
net localgroup Administrators svc_backup /addThe net user command creates the account and enables it (generating Events 4720 and 4722). The net localgroup command adds it to Administrators (generating Event 4732). The one-second gap between 4720 and 4732 is consistent with two sequential commands rather than manual GUI account creation, which typically takes 10 to 30 seconds.
Who created the account. Event 4720 records the SubjectUserName field, which identifies the account that performed the creation. In this case, the built-in Administrator account (RID 500) created svc_backup. This means the attacker already had Administrator-level access before creating the persistence account. The credential theft that obtained Administrator access (Module 2 execution analysis) preceded the account creation.
When the event log has rolled
If the Security log has rolled past the account creation date, there is no Event 4720 for the account. You have an account in the SAM with no documented origin in the event logs. This is common when collection happens days or weeks after the initial compromise.
In this situation:
The SAM creation timestamp is your only record of when the account appeared. Document it as such: "The svc_backup account was created on 2026-03-12 at 02:33 UTC according to the SAM hive. The corresponding Event 4720 is not present in the Security event log, which begins at 2026-03-14 08:00 UTC."
Check Volume Shadow Copies. If VSS snapshots exist from before the log rolled, the snapshot may contain a copy of the Security event log that still includes the 4720 event. Mount the VSS snapshot (Module 8) and parse the older event log.
Check the SAM for clues about the creator. The SAM hive does not record who created the account (that information is only in Event 4720). However, if the account's Pwd Reset timestamp matches the creation timestamp exactly, the password was set at account creation time. If Pwd Reset is later than the creation timestamp, someone changed the password after creation.
Built-in accounts and their expected state
Not every account in the SAM is suspicious. Knowing the expected state of built-in accounts prevents false positives.
ACCOUNT RID EXPECTED STATE
Administrator 500 Exists on all systems. May be renamed. Check if it was
active during the attack window (Last Login timestamp).
Guest 501 Should be disabled. If enabled, investigate why.
DefaultAccount 503 Service account for SYSTEM. Disabled. Normal.
WDAGUtilityAccount 504 Windows Defender Application Guard. Disabled. Normal.The built-in Administrator account (RID 500) deserves special attention. Many organizations rename it (e.g., admin_local, corp_admin) but it remains RID 500. If the attacker compromised this account, the RID confirms it is the built-in Administrator regardless of what it has been renamed to. Check the Last Login timestamp: if it was active during the attack window, the attacker had full system access through the highest-privilege local account.
Anti-Pattern
Focusing only on user-created accounts and ignoring the built-in Administrator. The built-in Administrator (RID 500) is the most common target for credential attacks. If its Last Login timestamp falls within the attack window, the attacker used it. Many investigations miss this because the account was renamed and analysts did not check the RID.
Before moving on, verify your understanding: extract the SAM hive from your KAPE collection with RegRipper. List all accounts with their RIDs, creation timestamps, last login times, and group memberships. Identify the built-in Administrator by RID 500 regardless of its current name. Search event logs for account creation events (4720) and group modification events (4732) for each non-built-in account. Note any accounts where the creation event is missing from the logs and document the SAM-only evidence.
Next: Section 3.2 covers authentication and session analysis. You will use event log logon events to trace what each account did after logging in, and LogonId to correlate every action within a session.