Finding user accounts on a computer running the Windows Operating System (OS) is a standard part of a forensic examination. Local user accounts are found within the SAM Registry Hive, but what about computers connected to a domain?
During an examination, you may see a mismatch between accounts stored in the SAM Registry Hive and accounts found on the system itself, such as within the C:\Documents and Settings\%User% or C:\Users\%User% file paths. In most enterprise environments using a domain, IT staff will try to limit the number of local accounts on systems to manage accounts via the Active Directory (AD) domain. In investigations involving domain accounts, there will not be entries in the SAM hive for domain users, only local users.
You may find activity on a host or in network logs that identify the security identifier (SID) and a relative identifier (RID) of a user. For example, the target of your investigation may have a RID of 1209 but when you look at the subject’s workstation, there are only a few local accounts in the SAM hive and none of them with the RID of 1209. You know from event logs and other network activity that your subject uses the workstation you have forensically imaged. How do you correlate the SIDs and RIDs from a local computer back to a domain?
The SAM registry hive of a local host computer will only store the credential information for local user accounts. However, that doesn’t mean that the registry of the computer doesn’t have information about domain users. Depending on Group Policy Objects (GPOs) set by their AD, they may set how many cached domain credentials can exist on a local machine. This is why if you logon to a host that isn’t connected to the domain, but you are using your domain credentials and have been on that machine before, you can still logon. The default is 10 cached credentials can be stored on the machine.
If you’re not seeing your subject’s information in the SAM hive with the same SID as confirmed local users, and you can correlate the SID back to domain controller running AD, then you’re correct, your target did not logon to that computer with a local user account. You can see the number of cached credentials stored by looking at the HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon key. You can also see in the registry the domain information for connections here: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\.
Cached domain credentials are stored in the SECURITY registry hive and can be found in HKLM\Security\Cache. Just remember though that some of the information is encrypted. There is a tool called creddump (https://github.com/moyix/creddump) that may help you if you’re trying to get the cached domain password.
Also look at the relative identifier as another indicator. A local account with a RID of 1003 for example, would be normal for a local account (any user created account will have a RID of 1000 or above). If your subject’s account has a different SID (that of the domain) and a RID that is much higher (1209) this is an indicator you are dealing with a domain account. While domain controllers can assign RID’s differently based upon the needs of the organization, the default is sequential assignment so it ensures the RID’s are unique.
Here is a link to a MSDN article about SIDs/RIDs: https://msdn.microsoft.com/en-us/library/cc246018.aspx.
