Wednesday, July 03, 2013

HowTo: Determine Users on the System

Now and again, I see questions in various forums that are related to (or flat out asking) about how to go about determining users on a Windows system.  In several instances, I've seen the question posted to the EnCase User Forum, asking why the results of the "Initialize Case" EnScript are different from what is retrieved by other tools.  There are several locations within the Windows system that can contain information about accounts on the system.

SAM hive - The SAM hive maintains information about user accounts local to that system.  In a corporate environment, many times you won't find the user account for the active user listed in the SAM hive, as the user account was set up in Active Directory and managed from a domain controller.  In home environments, you're likely to see multiple user accounts listed in the SAM hive.

Tool: RegRipper samparse.pl plugin; the samparse_tln.pl plugin will parse the SAM hive and output various items (account creation date, last login date, etc.) in TLN format for inclusion in a timeline.

Software hive - Within the Software hive is a key named "ProfileList" that maintains a list of...you guessed it...user profiles on the system.  This information can then be correlated against what you find within the file system (see below).

Tool: RegRipper profilelist.pl and winlogon.pl plugins.  The winlogon.pl plugin checks for "Special Accounts", which are accounts that do not appear on the Welcome screen.  This technique used by intruders in order to "hide" accounts from administrators.

File system - User information is maintained and "recorded" in the user's profile within the file system...on Vista+ systems, in the C:\Users folder.  There should be a correlation between what's in the ProfileList key, and what can be observed within the file system.

Tool: Any file viewer, or mount the image as a volume and use the dir command

Note
The LocalService or NetworkService accounts having a populated IE index.dat (web history) may be an indication of a malware infection.  I've examined systems infected with malware that is used for click-fraud and found an enormous index.dat file for one of these accounts.

Now, most analysts are aware that you can have an account listed in the SAM hive, but not have a user profile folder within the file system.  What this can indicate is that the user account was set up, but has not been used to access the system yet.  User profiles are not created until the user logs into the system using the account credentials.

Changing Settings
In order to determine if someone was accessing user settings (changing user account information, or modifying account information), there are two places you can look.  First, examine the Windows Security Event Log for indications of events that pertain to user account management (see MS KB 977519 for a list of pertinent event IDs).

Tools: LogParser, evtxparse.pl

Second, look to the shellbags.  What?  That's right...look to the shellbag artifacts.  Event Logs can roll over, and sometimes quickly, depending upon activity and Event Log settings (events being audited, Event Log size, etc.).  If you suspect that a user has been creating user accounts, or if you just want to determine if that has been the case, check the shellbags artifacts, and you might see something similar to the following in the artifact listing:

Desktop\Control Panel\User Accounts
Desktop\Control Panel\User Accounts\Create Your Password
Desktop\Control Panel\User Accounts\Change Your Picture

The above listing is an extract that was pulled out of the shellbags artifacts from my own system, but I should note that while investigating a system that had been compromised via Terminal Services, I parsed the shellbags artifacts for the compromised user account, and found similar entries related to those above, with the exception that they indicated that a user account had been created.   The intruder had then attempted to "hide" the account from the Welcome screen by making the new account a "Special Account", but they had misspelled one of the keys in the path, so the functionality was not enabled for the account.

Tool: RegRipper shellbags.pl plugin

Note
If you have thoughts as to how to expand these "HowTo" posts, or questions regarding how to take the analysis further, please let me know. Also, if there's anything specific that you'd like to see addressed, please comment here or contact me at keydet89 at yahoo dot com.

4 comments:

Jimmy_Weg said...

Although it's not directly on point, MSIE index records identify logged on users. This can be handy to identify former users on the system. Of course, so can recovered registry hives or keys in registry free space.

Keydet89 said...

Jimmy,

That's an interesting point...can you expand on it a bit, for the benefit of the readers?

For example, how would you use MSIE index records to identify logged on users?

Thanks!

Jimmy_Weg said...

The info is in the URL record for almost every cache and history type. The offsets may vary based upon record type (I'd upload a screenshot if I could, as much of an URL record is binary). However, in some records it follows U: and in others Visited:. What adds to its value is that the records will provide a historical time frame of a user's machine use that is unavialble from more often-thought-of sources.

Keydet89 said...

Jimmy,

Excellent point. I have some code for parsing MSIE index.dat files, so I'll see if I can't post an example.

Again, thanks.