BLUF
Before I give the BLUF, allow me to address a departure from previous behaviour. I’m not a fan of click-baity stories that make readers read a full post before they get to the point, so in the past I have usually provided a TL;DR at the start of my posts, but I think by convention they are meant to go at the end of an article. For that reason I’m switching up initialisms. The BLUF (Bottom Line Up Front) is my new TL;DR because it’s meant to go at the start, and by goodness, do I believe you should not have to scroll very far to find the point of any particular post!
Obviously I go into more detail as to my journey of finding the knowledge I’m about to reveal, and I would prefer if you took that journey with me, but I get it, you’re busy, so here it is:
In order to get the account creation date for a user account on Windows you need to navigate to the registry key located at:
C:\Windows\system32\config\SAM: [ROOT]\SAM\Domains\Account\Users\NamesOnce there you will see a list of the user name accounts on the system and if you locate the user name you’re interested in, for example “testuser1”, and then check the “Last Written Date” for that folder it will correlate to the user creation date (on that specific computer).
It is an exercise left to the reader as to how to get one’s hands on the SAM file.
Caveats:
- This technique applies to local accounts created on the machine only. It’s a local account creation date.
- The “Last Written Date” may not correlate with the absolute account creation date for internet accounts used on a computer. If you get a new Windows machine and log into it with an old Outlook account, the date you see on the user name key at the above registry location will not correlate with the absolute date of the Outlook account creation, rather it will correlate with the first time that account was used to log on to the computer.
- Domain accounts used to log on to a domain joined machine will not see the same artifacts in the indicated location within the SAM registry file of local machines. The user information will instead be found on the Domain Controller.
The Scenario
First of all I want to let you know the reason for this post. I was working with an image of a computer with a few questions to work through. It was an educational challenge. Among the questions was one asking about user details, looking for details like number of non-system accounts, what are their names and various dates. I knew the answers would be in the SAM registry file, but I didn’t know precisely where.
I will detail two ways to find out the user creation date below, one of them is much easier than the other. However, while I obtained the answer using the easy method I didn’t fully understand where the Creation date was being taken from, and not one source that I found in the world wide web spelled out the exact location for a user’s creation date in Windows. I could have been saved quite an amount of effort if a post such as this existed, and so, now it does.
Softwares Used
In order to process the Windows image I used EnCase. Once I had the image loaded up I exported the SAM file to be used with Eric Zimmerman’s RegistryExplorer.
RegistryExplorer
Once I opened the SAM file with RegistryExplorer it was a simply a matter of navigating to ROOT -> SAM -> Domains -> Account and then clicking on the User folder and all the relevant timestamps are revealed.
As you can see above there are four timestamps surfaced pretty easily by RegistryExplorer, one happens to be the Created On date, the easy method.
But where do you find the creation date when you don’t have such a handy dandy tool at your disposal?
As an aside, check out how easily readable the Reset Data is, these are the questions Microsoft asks when setting up a new local account as part of a knowledge-based password reset process. Granted if somebody has your SAM file you probably have bigger issues, but they could at least have encoded it a little, a bit of base64 perhaps?
Encase (or Your Forensic Software of Choice)
So we have the answer, now we want to satisfy ourselves that we know where it is being taken from by RegistryExplorer, and this is where I went a little bit crazy.
I’m not going to go into the process of how to load the SAM file into EnCase, it’s likely if you have EnCase you already know how, and if you don’t use it, you likely know how to do it in your own favourite software. If you would like such a guide feel free to ask in the comments and I’ll create a post about it.
Bear in mind for this, I used a different computer for EnCase than I did for Registry explorer, so the dates won’t match, but it shouldn’t matter for the general point.
So, when you have the SAM file loaded in your forensic software you navigate down to ROOT -> SAM -> Domains -> Account -> Users -> ????. For the ???? value you need to identify the folder you want, if you go to each folder and check the V key, the user name will show up in plain text. Once you’re in the correct user’s folder you need to start hunting for timestamps.
Time Stamps Everywhere
So what I did next was to have a look at the hex view of the different keys. EnCase has a handy Decode facility that allows you to decode common data types found in computer data. Once you find what looks like a date you can highlight it and using the Windows Date/Time Decoder you’ll know if what you found is a valid date or not.
As you can see from Figure 4 above, the dates are pretty similar. This is common across most accounts used on home user Windows machines. Likely the password was created when the user was and hasn’t changed since. The year and month and day are all the same.
What I did next to find relevant dates was knowing that Windows dates are 8 bytes long and Little Endian, I looked for 8 byte blocks of data that ended with similar values, as the ending of the 8 bytes represents the larger part of the value, which correlates to the year part.
I started with the F Key within the relevant User’s key in the SAM hive. This is what I was faced with.
If you look at it carefully you’ll see two bytes that are repeated several times “D8 01”. These also seem to reliably appear at the end of an 8 byte block of data. Let’s highlight them and see what EnCase can decode.
So there are dates encoded in there. The Invalid parts of the decoding above are the bytes between the valid dates that are not relevant.
Progress, but when I matched these dates up against the dates I had for the user I was looking at during the forensic challenge, none of them were the creation date. These dates represent the last login date, the last password reset date (these are often the same date, who changes a home computer password?) and the last failed login date. As it turns out the block of 8 FF characters also represent a date, this is the account expiration date and 8 FFs mean there is no expiration date set.
While researching these dates in the height of my date mania I came across a very nice article which explained exactly what I had found to be the case and it helped me to restore some of my sanity.
Where’s the Creation Date?
I was still left with the puzzle of where’s the creation date though. To try answer it I approached from a number of different angles. I examined all the keys in the User Key. I even went to the extent of going through the hex output for the raw SAM itself rather than the processed output. And while there, I found the creation dates that I was looking for, but they were not in consistent places that would make them reliably easy to find.
I was missing something. As it turns out it was a part I overlooked while examining the Users Key. As it turns out inside the users Key is a sub Key per user, but also another Key called Names that has another Key per user. These Keys are given the name of the user and there’s no digging around to make sense of them.
When you click on the desired user, in the above case beazzlebub in the Table pain in Encase:
Then have a look in the fields section of the View pane and find the Last Written value, the answer will be revealed.
Conclusion
This post does not do enough justice to how challenging I found this simple question to answer. As I ploughed along trying to find the answer I couldn’t shake the feeling that I had missed something simple. And as you can see from the above, I did. But, boy did it feel good when I finally hit upon the answer. It was like scratching a really unpleasant itch right in my brain!
Resources Found Along the Way
I found four resources of note along the way that I want to link out to from here. The first I already mentioned helped provide me sanity by detailing what the different byte blocks in the F key related to, this article also contains some good general info on Windows User Forensics. The next two contained a mix of generally useful Registry Forensics information that may be useful. The fourth resource is a golden nugget though, it is a very simple blog post by an author who found themself looking for the same data in the registry over and over and rather than keep researching which key to go to each time they created a very simple little index to reference, which I will be keeping close to hand.
https://www.vicarius.io/blog/windows-registry-forensics-pt-2
http://travisaltman.com/location-of-forensic-evidence-in-the-registry/