BAM SID to Username: Attributing Execution to a User

TL;DR. BAM's key names are the attribution: one subkey per SID under UserSettings. Resolve SIDs with the SOFTWARE hive's ProfileList (folder name), the SAM hive (local account names) or the domain (domain accounts). Recognise well-known SIDs — S-1-5-18 is LocalSystem, S-1-5-90-0-N are DWM accounts, S-1-5-96-0-N font-driver accounts. And word it carefully: BAM attributes execution to an account, not to a person at a keyboard.

User attribution is BAM's main advantage over Prefetch, ShimCache and Amcache, which are system-wide. This article shows how to get from a SID to a name you can put in a report, and how far that name can be trusted. Basics are in the BAM/DAM forensics guide.

Reading a SID

A security identifier such as S-1-5-21-3623811015-3361044348-30300820-1119 breaks down as (Microsoft Learn):

Two rules of thumb from the same documentation: RID 500 is the built-in Administrator, and SIDs are never reused within their scope. Two BAM keys that share the domain part belong to the same machine or domain; compare that prefix with the machine SID to tell local from domain accounts.

Resolving names

ProfileList (SOFTWARE hive)

SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID> has a ProfileImagePath value such as C:\Users\svc_backup. The last folder is usually the account name, and that's what our BAM/DAM Parser shows once you add the SOFTWARE hive: each row gets an Account next to its SID (the User column in exports), and the account filter lists "name (SID)".

The catch: Microsoft documents that renaming a user account doesn't change the profile path (Microsoft Learn). So "profile folder name" is a strong hint, not the authoritative account name. We label it as such in reports.

SAM hive (local accounts)

For local accounts, the SAM hive's SAM\Domains\Account\Users holds each RID with its current user name. If the domain part of the BAM SID matches the machine SID, the RID resolves there. Our tool doesn't parse SAM; Registry Parser or RegRipper's SAM plugins do.

The domain

For domain accounts, ask the domain controller (Get-ADUser -Identity <SID>), or use logon events on the host that carry both SID and account name (EVTX Parser for 4624/4648 logons).

Well-known SIDs you'll meet

The first three are listed in Microsoft's well-known SIDs; the DWM and font-driver formats are documented in the Security Identifier reference and in Boutnaru's dwm.exe notes.

A SYSTEM key with entries outside System32 deserves attention. In the fictional sample on this site, S-1-5-18 shows \Windows\Temp\svchost.exe next to the real \Windows\System32\svchost.exe — the kind of row the "system binary out of place" flag exists for. Something ran as LocalSystem from a temp folder, and on a real case you'd look for the service or scheduled task that launched it (7045 service installs, Services key, task XML).

Account, not person

A BAM entry under SID X means the process was attributed to account X. It does not tell you who was at the keyboard. Nothing in the record distinguishes between these situations, which all run code under the same account:

• the user ran the program themselves,
• someone else used their password, token or session (RDP, runas, stolen credentials),
• a scheduled task or service configured to run as that account started it,
• remote execution tools created a process under those credentials.

That's why the phrase in reports should be "executed under the account…", with the logon context (interactive, RDP, network, service) taken from event logs. For remote logons, SRUM and RDP artifacts help place the session.

Service accounts and shared accounts

Service accounts are where BAM attribution shines. A backup account that normally runs one agent binary and suddenly shows cmd.exe, mstsc.exe and a scanner in its BAM key is a clear sign of interactive misuse. The lateral-movement walkthrough follows exactly that pattern with the fictional svc_backup account.

Shared accounts (kiosk, lab, generic admin) are the opposite: BAM will attribute everything to one SID. Pair it with logon events and source IPs to split sessions.

Worked example with the sample data

The fictional sample hives behind the tool's Try a sample button contain three BAM keys:

Both S-1-5-21 SIDs share the domain part 3623811015-3361044348-30300820, so they belong to the same machine or domain; their RIDs, 1104 and 1119, distinguish the accounts. Without the SOFTWARE hive the tool would show only the SIDs; with it, the account filter reads alice (S-1-5-21-…-1104) and svc_backup (S-1-5-21-…-1119). Whether those are local or domain accounts can't be decided from these two hives alone: compare the domain part with the machine SID from the SAM hive, or ask the domain. The investigation walkthrough uses exactly this attribution to show that the service account, not the user, ran the attack tools.

Checklist

1. Load SYSTEM and SOFTWARE so names appear next to SIDs.
2. Compare each SID's domain part with the machine SID: local or domain?
3. Resolve authoritative names from SAM (local) or the domain.
4. Treat well-known SIDs as their own category; look hard at unusual paths under SYSTEM.
5. Report "under the account", and bring logon type and source from event logs.

Everything above except SAM and domain lookups happens directly in the BAM/DAM Parser; see the step-by-step how-to for the full workflow.

Frequently asked questions

How do I turn a BAM SID into a username?

Load the SOFTWARE hive and read ProfileList\<SID>\ProfileImagePath: the last folder of that path is usually the account name. For local accounts, the SAM hive gives the current name by RID; for domain accounts, query the domain or look at logon events.

Does a BAM entry prove that a person ran the program?

It proves the process was attributed to that account's SID. The record cannot tell apart the user, an attacker using the password, or a task or service configured to run as that account; bring logon context from event logs.