SAM Hive: The Registry Knows Who You Are

Every investigation eventually comes back to the same question:

who was actually sitting at that keyboard?

You can find the most damning files, the most suspicious network connections, the most carefully hidden evidence — but none of it means much until you can tie it to a specific person.

That's where the SAM hive comes in. It's Windows' own internal roster of every local account on the machine, and it's usually one of the first stops in any serious forensic examination.

Think of it as the HR department of your operating system.

It knows who works there, when they showed up last, how many times they've tried and failed to badge in, and exactly what level of access they have.

----------------------------------------------------------------------------------------------------------

Why User Profiling Comes First

Before you chase artifacts, before you dig into execution history or browser forensics, you need to know who you're looking for.

This sounds obvious, but it has a very practical implication that trips up newer analysts: many Windows artifacts don't use usernames. They use RIDs.

• The Recycle Bin folder structure? RID.

• Certain Event Log entries? RID.

• The BAM registry key? RID.

If you haven't mapped usernames to their corresponding Relative Identifiers early in the investigation, you'll find yourself staring at numbers that point to a person you haven't identified yet.

The SAM hive solves this problem completely — and gives you a lot more besides.

----------------------------------------------------------------------------------------------------------

What the SAM Actually Stores

----------------------------------------------------------------------------------------------------------

Three Reasons the SAM Hive Is Always Worth Checking

First — RID mapping. 

Say you're looking at a Recycle Bin folder named $RECYCLE.BIN\S-1-5-21-XXXXXXXX-1001. That 1001 at the end is a RID.

Without the SAM telling you that RID 1001 belongs to akash, that folder is just a number. With it, you have a name.

Second — account profiling. 

The login statistics alone can tell a story.

• An account that's only logged in twice ever could be a ghost account created for a specific purpose.

• An account showing hundreds of failed login attempts screams brute force.

• An admin account with a last login from two years ago — probably irrelevant.

• An admin account with a login from last Tuesday that nobody mentioned? Very relevant. The SAM gives you the context to ask the right questions.

Third — the built-in Administrator account. 

Every Windows machine has one. Most organizations disable it. If the SAM shows it has an active login count and a recent last login, that's a flag worth pulling on — especially in intrusion cases where attackers love to abuse built-in accounts that sometimes get overlooked by monitoring tools.

----------------------------------------------------------------------------------------------------------

The Cloud Account Wrinkle

Here's something that trips up analysts who haven't encountered it before:

Microsoft cloud accounts behave differently in the SAM, and the differences matter.

When a user logs in with a Microsoft account (their Outlook or Hotmail email address) instead of a traditional local account, Windows still creates a SAM entry — but it doesn't populate it the same way.

Example:

The InternetUserName value is the smoking gun here. If it's present, the account is cloud-linked — and that has downstream implications for the entire investigation.

Cloud accounts are tied to OneDrive, SharePoint, browser sync, cross-device history.

A cloud account isn't just a login on this one machine. It's a thread that potentially connects to an entire ecosystem of synced data elsewhere.

----------------------------------------------------------------------------------------------------------

Beyond Local Accounts: The ProfileList

The SAM is excellent — but it only covers local accounts. In any enterprise environment, you'll also be dealing with domain accounts, and those don't live in the SAM. They live on the domain controller.

What does live on the endpoint, however, is a key called ProfileList — and it's the bridge between local and domain account identification.

I do not have real example to show :(

----------------------------------------------------------------------------------------------------------

ProfileList vs SAM: Know the Difference

The SAM and ProfileList solve related but different problems. Here's how to think about each one:

SAM 

gives you depth on local accounts — rich login statistics, group membership, cloud linkage. If you want to know everything about a local user's habits on this specific machine, go there first.

ProfileList

 gives you breadth — it casts a wider net and catches both local and domain accounts that have ever sat down at this machine. No deep statistics, but an invaluable roster of everyone who's had a genuine interactive session.

Use them together.

Map out the full account landscape with ProfileList first, then go deep on relevant local accounts with the SAM. For domain accounts, ProfileList is just your starting point — the real detail lives on the domain controller, which is a separate investigation entirely.

One important caveat:

ProfileList's Last Write timestamp is notoriously unreliable. Operating system updates have a tendency to touch these keys, resetting the timestamp to something meaningless. Don't build a timeline argument around it.

----------------------------------------------------------------------------------------------------------

The Analyst Mindset

What makes SAM-based account profiling powerful isn't any single data point — it's the combination of them. A last login time by itself is a fact. A last login time on an account that theoretically hasn't been used in three years, with a logon count of two, at 3am, from an admin account nobody mentioned? That's a story.

Let the data ask the questions. The SAM will give you plenty of material to work with.

------------------------------------------Dean----------------------------------------------------------

Full Series:

https://www.cyberengage.org/courses-1/mastering-windows-registry-forensics%3A