What’s in a name? That which we call a profile
By any other name would still let us log in.
I recently ran across a case where I needed to prove which user was using which profile folder. Every once in a while, the profile folder name won’t actually be the same as the account’s username. It’s pretty easy to assume that the folder is the username, since it that is the case better than 90% of the time. But, as Admiral Akbar says, “It’s a trap!”
There are two scenarios that I’ve witnessed where this isn’t the case. If there is already a profile folder with the same username, such as if a local account was created for the user prior to them logging in with their domain credentials and both these usernames are the same, then a second profile folder will be created. Profile folders are unique by SID and even if local account and domain account are same name they will be different SIDs and thus will get their own folders. To overcome the name conflict, the system will append the domain to the username when creating the profile folder name. This is exactly what you see in the screenshot below – the \Users\benjamin.russell folder is a local account and then when Ben logged in with this domain account for the first time the system created the \Users\benjamin.russell.hitek folder. The login that associated with the former folder is benjamin.russell and the login associated with the latter is hitek\benjamin.russell. Had it happened in the opposite order, so domain credentials logged in first and then a local account was created and used, the new profile folder’s name would have hostname appended to it instead of the domain name as that is the domain context for local accounts.
Another scenario is when the user changes their name. If there is an existing profile from the user having already logged in and the user’s username changes, the system will continue to use the existing profile folder even though the name no longer matches. Changing the username doesn’t change the SID, so in the system’s mind this is not a new profile and thus it should continue with what it has. This can happen post marriage when a last name changes or can happen when a user requests their name changed for other reasons, such as in our example below where Mr. Russell said he really prefers to go by Ben. When he requested they change his login from benjamin.russell to ben.russell, the SID never changed and thus his profile is still stored in the \Users\benjamin.russell.hitek folder, as you can see in the command prompt in the screenshot below. This can very easily cause a forensic examiner to associate data from NTUSER.DAT with a non-existent username if care is not taken.
Humans are amazing, we can intuitively tell that Ben and Benjamin are the same person and that Hitek is the domain thus benjamin.russell.hitek is the profile folder of his domain account, but computers aren’t so quick. So, how do we positively tell which folder belongs to which user?
I was really hoping the NTUSER.DAT held that answer, but it doesn’t. There is no pointed reference to the username or SID anywhere in that hive. There are some consequential references, such as some MS Office, ActiveInstaller, and Media Player related keys that list usernames, but they aren’t concrete and aren’t guaranteed to be there on every system. There is a solid clue in this article. The answer is in the SYSTEM hive in the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ key. Within that key is a series of keys named after the SID of each user profile on the system. This includes the various system profiles and omits the \Users\Default folder that trips up a lot of automated user data processing scripts I’ve seen. If you want a script to touch every profile that actually is a profile, this is where it should go to start its search.
Inside each SID named key you will find a value named ProfileImagePath that contains the location on disk of the profile for the user that has this SID. This allows you to definitively tie this folder to this SID, but you will have to look elsewhere to tie the SID to the username (hint: PsGetSid from Sysinternals). The other values in there, according to this, are as follows, just in case you find them forensically interesting depending on your specific case needs.
Default: It’s the value whose name is null.
Flags: Enables you to control the installation and uninstallation of your registry entries. No further information available.
GUID: This is a unique ID for this user account. It is only present on domain accounts; local accounts are absent this value. Locally, it corresponds to keys in the PoliciesGUID and ProfilesGUID keys just above the ProfileList key. Inside each of those keys is a key for each GUID with a value that tells me which SID this GUID maps to. Kinda circular and not very helpful.
ProfileImagePath: The User’s profile path. This is the important one.
ProfileLoadTimeHigh:
ProfileLoadTimeLow: These two DWORDs make up the high-order bits and low-order bits, respectively, of a double dword that is a timestamp. Combine the 4 bytes you get from each in the right order and you should get 8 bytes that become the date and time when the user logged in. I frequently find these values as zeros, though, so I’m not sure when this gets populated vs when it gets ignored.
RefCount: value of 0 means the account has no active session, anything higher means the account has an active session. The implication is that this number indicates the number of concurrent logins by that user, but I’ve seen this number be higher than current session count so I think it counts logins but doesn’t decrement when the session ends.
RunLogonScriptSync: Determines whether the system waits for the logon script to finish running before it starts Windows Explorer and creates the desktop.
0 The logon script and Windows Explorer can run simultaneously.
1 Windows Explorer does not start until the logon script has finished running.
Sid: The Security Identifier in binary
State: Indicates the state of the local profile cache. For example, a state of 256 = x100 = Admin account, and 772 = x304 = x200 + x100 + x004 = a bunch of stuff.
x0001 Profile is mandatory.
x0002 Update the locally cached profile.
x0004 New local profile.
x0008 New central profile.
x0010 Update the central profile.
x0020 Delete the cached profile.
x0040 Upgrade the profile.
x0080 Using Guest user profile.
x0100 Using Administrator profile.
x0200 Default net profile is available and ready.
x0400 Slow network link identified.
x0800 Temporary profile loaded.