Windows 10 OS - Ear...
 
Notifications
Clear all

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

9 Posts
6 Users
0 Reactions
2,366 Views
(@siris)
Active Member
Joined: 9 years ago
Posts: 5
Topic starter  

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
keydet89
(@keydet89)
Famed Member
Joined: 21 years ago
Posts: 3568
 

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
(@siris)
Active Member
Joined: 9 years ago
Posts: 5
Topic starter  

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


   
ReplyQuote
keydet89
(@keydet89)
Famed Member
Joined: 21 years ago
Posts: 3568
 

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
(@siris)
Active Member
Joined: 9 years ago
Posts: 5
Topic starter  

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
mjpetersen
(@mjpetersen)
Active Member
Joined: 7 years ago
Posts: 12
 

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
BReninger
(@breninger)
New Member
Joined: 15 years ago
Posts: 1
 

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
pr3cur50r
(@pr3cur50r)
Eminent Member
Joined: 15 years ago
Posts: 28
 

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
jaclaz
(@jaclaz)
Illustrious Member
Joined: 18 years ago
Posts: 5133
 

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
Share: