Welcome back to Windows registry forensics course 4. The SAM hive file, Section 3. We're going to talk about user accounts, and RIDs. We're going to talk about the user accounts and the values within the user accounts, and we're going to talk about the relative identifiers and what they mean to us. As we looked at before, the RID is the last portion of our total security identifier, and the RID identifies each individual user on the system. If you're looking at a vista or seven machine, the RIDs are going to start at 1000, the user created accounts are going to begin with 1000. If you're looking at Windows 8 and 10, or you can say Windows 8 and up, the user-created accounts are going to start with a RID of 1001. Now, each time a new user is added, these numbers are incremented by one. It's very important to remember these numbers are never reused. If you come across a computer that has 1001, 1002, and then skips to 1004, you can be pretty sure that at some point in time an account was deleted on that local machine. The way we resolve these grids, those hexidecimal representations under the user Sub key to a particular user name, is through the names key. When we look at the names Key below, we can see a list of users. If we look at a specific user, we can see that they have a specific relative identifier. In this case we're looking at the Sub key of names, and we're looking at the Ivan user, and we can see that the Ivan user RID in this particular account is 1001 in decimal. In hex, we see that 3E9. If we look above, we can see the 3E9 under the users Sub key, and that would be Ivan's user account information contained within that sub key. Now when we look at that sub key, we can see that there are two values in that sub key. We have a V value and an F value. We also have a last write time to that sub key, and with that last write time, we know that something was changed, but we don't know which value within that sub key was changed. As we can see, we have also a number 4 there, which that is the number of values in the sub key. One of those four values was changed at that last write time, but which one we won't be able to tell from within the registry. When we're taking a look, the first value we're going to look at is going to be the F value, and what's important to remember here is whichever value when you're using the tool that you are clicked on are highlighted on is going to determine the hex that you see below for the value. If you're looking at the F value, you want to make sure you are clicked on the F value, or you'll be seeing the wrong hex and it won't make a lot of sense. One of the things contained within the F value, is going to be the last login time. That is going to be seen at hex offset 08 for a length of eight bytes to hex offset 0F, and that would be decimal 8 to 15. The last login time is eight bytes long. It's RID little-endian, and it is a 64 bit Windows File time. We can see it converted there. You see the bites highlighted. We see the Windows File time in our decoder off to the right-hand side, and we can also see a little bigger representation of that there too. When you translate those bytes, little-endian, you're going to get a date of January 27th, 2020 at 040826. That would be the last login time for this user account, and we are looking at the Ivan account. Also contained within the F value, is going to be our last password change time. This is going to be located at hex offsets 1821F, which is decimal 21 to 31. Again, it's eight bytes long, 64-bit Windows File time, and it is RID little-endian. Our last failed login time, which is the last time a user either entered a wrong password or didn't enter a password, just click the head, but it's our last failed login time. Again it is eight bytes long, it starts at hexadecimal offset to 2F decimal 4047. It gives us the last failed login time. Those bytes, again, are RID little endian, and it is a Windows 64-bit File time format. The location of the RID. Where do we find the RID? It's also contained within the F value, and it's contained at offset 30 to 33. It is also RID little endian, and we can see that if we look at that and we reverse the byte order, we can see 00, 00, 03, E9 and 3E9 or 03E9 would be Ivan's RID in hex. We can see on the right-hand side, it's 32 bits. It translates to 1,001 in decimal. If we were to convert that hexadecimal, we would get 1,001, and we know that the user with the RID 1,001 is Ivan in our specific case. Password required. This is something that over the years has been misinterpreted. It does not mean that a password is or is not set for that particular user account. What this means is that it means that any password policies, like you have to have a characters. You have to have upper and lowercase. You have to cap a character. You have to have numbers. Any of these particular password policies that are set do not apply to this specific user account. If you see a 0, it would be the account is active and a password is required. If you see a 1, that would mean that the account is not active, and if we see a 4, and again, we're looking at the right nibble of hex offset 38, DECIMAL 56. Just the nibble. Just that little highlighted 4 there, on the right-hand side, the right nibble of that hex offset is what we're interpreting. If we see a 4, that means that any password policies do not apply to this account. It does not mean that there's no password set for this account. Even if that was a 0, that doesn't necessarily mean that a password is set for the account. That would mean that any policies would apply to that account. But it does not mean specifically that a password is required. You cannot rely just on that right nibble. But that 4, and I just want to make this very clear, because I know you're going to see other stuff out there, because I've seen it that says that that 4 means that there's no password on the account. That is not what it means. Now, the login count, how many times has the user logged into the account? We're going to be able to see that again, we're staying in the F value. That is going to be at hexadecimal offset, 42 and 43 decimal 66 and 67. This is how many times the specific user has logged into the account. In this case we see a hexadecimal number of its read Little Endian. Again, it would be 00, 35, and if we translated that from hex to decimal. We would get a login count of 53. In this particular case, Ivan has logged onto his account 53 times. Now let's talk about the V value. Within the V value, you're going to see the account username and the hash for the password, the NTLM hash values. There used to be LAN Man hash values, LM hash values. You're not going to see that on anything Vista or above, you have to go back to XP to see these. They're not going to be on newer computers. Pretty much we're not seeing those anymore. Although those were great because they were really easy to code. But unfortunately for us, it gets a little harder, but we can still do it and we're going to talk about that more in the next section. User account-name. Now because the user account-name can be variable in length. I can name my user account anything I want basically. It does not have a location set like we looked at in the f value, we could say, I know if I look at offset x, offset y, I'm going to be able to see the login count, the failed login count, the last time the password was set. When we're talking about the user account-name. There are pointers to it within the V-value, but I'm not going to drag you through that calculation, because it's very easy if you look at the ASCII on the right-hand side of the pane. Again, I'm just using Registry Explorer with this particular photo. You could use Registry Browser. You could use AccessData Registry Viewer, or you could even use Registry Ripper and it will give you the user account name. Since it is very easy to see in the ASCII on the right-hand side of the pane, we can see the username of Ivan. One thing you do want to remember is you're looking at Unicode, and I think I briefly mentioned Unicode is going to be padded. You're going to see those 0's in between the letters and they're represented in ASCII as the dots. If you look at the right-hand side, you can see it's dot i, dot v, dot a, dot n, that's Unicode. The username will be in Unicode and it'll be easily visible on the right-hand side of your pane looking at your ASCII column. Here we can see I have highlighted the bytes and the username. We're going to talk about the NTLM hashes and decrypting these hashes to obtain the account password in the next section.
