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
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.
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
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.