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