Welcome back two Windows Registry forensics course four the SAM hive file. Before we get started on the SAM file, let's take a quick review of what we've covered so far in this path. In course one, we described what the Windows Registry was. We talked about why the registry was important and we talked about the structure of the Windows Registry. Next slide, in course two we took a look at the live registry. We used reg edit and looked at those H key, those Hive keys and looked at the hierarchical file system and how it works. We prepared our environment for examination. We downloaded some specialist tools to examine the registry files. We also learned where the registry files were located within the file system and we exported those files. Once we did that we talked about interpreting the registry values, whether there are binary value, a dword value etcetera. In course three, we covered the NT user dot dot hive and we looked at a lot of things in course three. We looked at our recent docs recently accessed documents. We looked at our type URLs those were URLs typed into the Windows Explorer address bar. We took a look at UserAssist recent and often we use programs, we looked at recent app which were recently used applications. We looked at the run and the run once key. Those are programs that are set by that particular user to run at startup. We also talked about how malware could be there. We looked at the ComDialogue 32, we looked at the RunMRU, we looked at typed paths. Those are paths typed into our Explorer address bar. Not the Internet, but the Windows Explorer. We looked at the most recently used documents in Microsoft Office. We also looked at Word wheel query, which talks about search terms the user may have looked for through the Windows Explorer box. In this course, the SAM hive file and SAM stands for Security Account Manager. We're going to take a look at identifying each individual users account and we're going to use something called a relative identifier or you'll hear rid for short. And we're going to be able to identify each user on that particular system. We're going to talk about how we interpret the user name information, how we resolve those user names back to those rids. We're going to look at the log in dates and times. We're going to take a look at how many times the user logged on the log in count. We're going to learn how to interpret the machine identifier, the SIDS, the security identifiers, the machine or domain, they can be either or. And we're going to take a look at user login password hashes and we're going to talk a little bit about how we would work through that to decode or decrypt the log on password. Let's have a quick overview of the SAM file. The SAM file, like I said, stands for Security Account Manager. SAM is a root key of H key local machine going back to when we looked at RegEdit and we saw the H key local machine hive, SAM is one of the root keys there. The path, the file path from within the system. We would go to C Windows System 32 highlight can fig and would be able to see the SAM file. And we saw that when we exported the files from within the file system. Now users generally get put on a machine by the administrator of that particular system and it's done through the control panel more often. But we can also use the manage utility. If we right click, then go to My Computer and manage we can also add a remove users from there. The SAM file, like when we looked at RegEdit, we couldn't see inside the sam file, we could see the SAM file was there in the live machine when we looked at RegEdit, but we couldn't see inside it. And that is because it is a protected file and a lot of that has to do with the fact that it does contain those password hashes or at least part of what we need to decode the password. When a users added to the machine, their user information, now we're talking about the local machine, we're not talking about domain accounts or Microsoft accounts. But when a user is added to the local machine itself, the information will be stored and the SAM file under the user's sub key. And we're going to take a look at that as we go through. When a user logs into a machine, they either need to have, well, first of all, they need to have a user account created on that machine or they're going to be logging in through a domain or a Microsoft account if we're talking about a Windows machine. But there's going to be some type of authentication involved in that either a password with Windows 10, we see pin numbers and we also have the ability to use biometrics to authenticate a user to the system. The SAM file is what stores this information and it's in order to provide security to the system throughout the login process. The hash is in the SAM files are stored in an MD four format and we're going to talk about all that later on in the code. What the SAM file does is it stores are information and it organizes the information about each user on the system and like we talked about it has log in password hashes. It will also have group information. There's default groups on the machine that are built in accounts and we can also create our own specialized user groups. The SAM file, much like the other files that we've looked at the anti user does have that hierarchical database structure. When we get a chance and look at it, we're going to see that it has folders and sub folders. And as we expand the tree, you can see the information that's under there. We see that we have the account sub key. And we're going to take a look at that in section two. We see we have the user sub key and we see some hexi decimal representation of each individual users identify where and then we also have the name sub key. And we're going to use the name sub key to resolve back to the user sub key so we can identify a name with an individual user. In the next section of this course, section two, we are going to discuss the SIDS, the security identifiers, which identify the machine or
