Join Us!

Windows 10 OS - Ear...
 
Notifications
Clear all

Windows 10 OS - Earlier Times than Windows Install Date/Time  

  RSS
Siris
(@siris)
New Member

Hello,

Can anybody help with the following?

Background Info I am analysing a Windows 10 OS. The Install Date/Time for this OS according to SOFTWARE Reg is 02/02/17.

I was analysing a user account and noticed that some files / directory timestamps were 'off'.

Directories such as the 'Desktop', 'Downloads', etc, all show a far earlier 'Last Written' timestamp than in comparison to the 'File Created', 'Entry Modified' and 'Last Accessed' timestamps available. To give you an idea of how large of a time difference I am talking about, its a two year time difference shown in 'Last Modified' vs 'File Created' 'Entry Modified' and 'Last Accessed'.

To give you a figure, the Last Written Timestamp is dated 14/05/16.

Not all directories are like this. The 'Documents' directory has, what I would consider, consistent timestamp metadata. The same generally applies for the AppData directory as well, however, there is a noticeable lack of directories residing in 'Local' and 'Roaming'. (Perhaps a separate discussion in itself.)

I have noticed that the Last Written Timestamp of 14/05/16 is also seen for other Windows accounts such as 'Default'. I should also add that Reg Hives such as SYSTEM, SOFTWARE, SAM, SECURITY, etc are all dated 14/05/16.

I have ruled out any potential file copy due to the mass presence of 14/05/16 inherited across the filesystem.

At this point in my analysis I am little bit confused as to how files can be dated earlier than the OS installation date/time? I am considering that this machine was upgraded from Windows 7/8, however, there is no presence of a Windows.old directory. I am of course aware that this can be deleted, but without it I cannot prove otherwise.

Does this ring bells with anybody out there? Any help and proving / disproving my thoughts would be greatly appreciated.

Thank you.

Quote
Posted : 25/03/2019 5:35 pm
keydet89
(@keydet89)
Community Legend

Rather than looking at individual artifacts in isolation, have you tried creating a timeline? You might find an answer there.

Also consider things like VSCs.

There are a number of possible answers. However, the key to questions such as this is to not consider artifacts in isolation, but to instead look at the system as a whole, ordered by time stamp.

ReplyQuote
Posted : 25/03/2019 5:39 pm
Siris
(@siris)
New Member

Thank you, I haven't done a timeline. But if I did, what would I be looking for to prove / disprove what exactly?

ReplyQuote
Posted : 25/03/2019 5:40 pm
keydet89
(@keydet89)
Community Legend

The purpose of a timeline is to order events from the systems based on their time stamp. As such, you would include metadata from the file system, Registry, Windows Event Logs, and possibly other sources on the system, as well. Once you have created your timeline, the goal would be to then determine what may have occurred "near" the suspicious time stamps in question.

Also keep in mind that you may want to check fro time stomping, as well as modifications to the system time, as well.

ReplyQuote
Posted : 25/03/2019 5:43 pm
Siris
(@siris)
New Member

Yes, you raise a good point. I think in this instance it'll be worth timelining and I will do so.

However, other than your recommendation of timelining and in playing devil's advocate, do you know of any host based artefacts that could assist in isolation to prove / disprove that this system was upgraded from a previous Windows OS version and upgraded to Windows 10?

If so, in this instance it could also speed up the process of deducing what may have happened and why the presence of 2016 timestamps appear on this system despite an indicative 2017 installation date. Nothing better than quick easy wins (where possible) 8)

ReplyQuote
Posted : 25/03/2019 5:48 pm
mjpetersen
(@mjpetersen)
New Member

Could the date you see be the OS date of the last large update (creators update, etc) and not the installation date? By doing a timeline analysis you should be able to tell.

ReplyQuote
Posted : 25/03/2019 6:20 pm
BReninger
(@breninger)
New Member

Verify the creation date of the $MFT/$Boot/$Volume etc to determine install date of OS . The Software Registry key Install date is updated with a Windows major update.

ReplyQuote
Posted : 25/03/2019 7:55 pm
pr3cur50r
(@pr3cur50r)
Junior Member

Yes, you raise a good point. I think in this instance it'll be worth timelining and I will do so.

However, other than your recommendation of timelining and in playing devil's advocate, do you know of any host based artefacts that could assist in isolation to prove / disprove that this system was upgraded from a previous Windows OS version and upgraded to Windows 10?

If so, in this instance it could also speed up the process of deducing what may have happened and why the presence of 2016 timestamps appear on this system despite an indicative 2017 installation date. Nothing better than quick easy wins (where possible) 8)

Some registry keys may be able to answer your question

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate
HKEY_LOCAL_MACHINE\SYSTEM\SetupSource OS (Updated on dd/mm/yyyy 000000\InstallDate

ReplyQuote
Posted : 25/03/2019 10:26 pm
jaclaz
(@jaclaz)
Community Legend

Any chance that it was a Windows 7/8/8.1 later updated to 10?

The NTFS data will tell you when the volume was created (formatted) unless it was deployed as an image (dd-like).

It is not probable that the latter method was used unless the PC is either of
1) a "large" OEM brand
2) belonging to an enterprise with an IT department
both the above cases may use a "master" image, later customized and deployed.

jaclaz

ReplyQuote
Posted : 26/03/2019 9:58 am
Share: