Join Us!

Thrustworthyness of...
 
Notifications
Clear all

Thrustworthyness of MAC times ...  

  RSS
cosimo
(@cosimo)
New Member

Hello,

I am analyzing the image of a Windows XP disk that was used by a supposedly unfaithful employee, and was given back to the employer on Apr; 6th, 2006. Before Apr. 7th, the disk was in a laptop unaccessible to the employer. Unfortunately, the employer decided to analyze the disk on Apr. 12th, so there have been 6 days in which the data on disk could have been modified by somebody else. On this disk it was found a folder containing unauthorized data whose creation date is Jan. 20th, 2006.
If I was the emplIoyee, I would defend myself saying that the folder has been put there by the employer, that before creating it moved back the system date to Jan. 6th, 2006.
My question is is there a way to determine if (and when) the system date has been changed (either from Windows or from the BIOS) ? For example, is there some registry entry containing this information?

Thanks a lot in advance to anybody answering this question.

– Cosimo

Quote
Posted : 23/04/2006 9:30 pm
gmarshall139
(@gmarshall139)
Active Member

I don't think you'll be able to establish anything definitively either way. My first thought is to look at the restore points. Ideally the computer wouldn't have been booted at all for those six days. No restore points would be created. If however you see a restore point that is in sequence with the others, yet it's created dates within go back to Jan 20th you may be on to something.

If I were working for the employer I would try and show how the files in that folder came to be there. If there are several different sources, and time frames for files in that folder, then it certainly becomes harder to sell the conspiracy.

ReplyQuote
Posted : 23/04/2006 11:08 pm
keydet89
(@keydet89)
Community Legend

I'd have to agree with Greg's response.

I'd also like to add a couple of comments…

First, depending upon the auditing enabled, there may be a System Event Log entry showing that the system time had been altered through Windows. With regards to the Registry entry issue…well, you can certainly test that using tools such as RegMon and InControl5.

Harlan

ReplyQuote
Posted : 24/04/2006 6:14 pm
koko
 koko
(@koko)
New Member

couple of things sort of related if the directory is not at the root of a drive, then you could prove that there was something wrong if the created dates of the parent directories were newer. also, and this may be a bit of a stretch, but apparently the mft contains an entry modified date as well as the mac dates. maybe this extra date, which is updated when the entry is updated, can give you some help. there's good info in brian carrier's book, 'file system forensic analysis'. unfortunately i havent had the time to really go over it. so anything that you find out, please report back to us. thanks.

ReplyQuote
Posted : 25/04/2006 12:44 am
cosimo
(@cosimo)
New Member

Hello guys,

thanks a lot for your valuable info. Actually, thanks to it, I found a way to prove that the files had been put there by the employee, and I'd like to share it with you and to hear your comments.

First, I did an experiment in which I changed the date and time from Windows, and I saw with RegMon that when that happens, the TimeZoneInformation registry entry (located into C\WINDOWS\system32\system) is written, so its last written date reports the last time in which the data has been modified. The same happens if the date is changed via the BIOS.
For the machine I am investigating, the system clock had been modified on Apr. 7th, 2006 at 855 am UTC (probably for the automatic update to the dayligth saving time), and in that day the machine was in the hands of the employer, that in theory could have purposedly put the unauthorized data there.
So, to show that the clock had not been set back to Jan. 20th 2006 and then set again to the correct date by the employer (to fake the unauthorized data creation date), I observed that Windows creates a 6005 event in the System Event Log when the machine is booted, and a 6006 event when the machine is shut down.
The fact that the clock has been changed automatically by Windows is showed by the fact that for Apr. 7th the time stamp of the corresponding 6005 entry is identical to that of the last written time of TimeZoneInformation.
Of course, one might say that Windows changed the date since the BIOS date setting had been changed. However, in this case the time stamps of the 6005-6006 event pairs should be out of sequence data. To see this, I did another experiment in which I rebooted my machine, I set the BIOS date back to Jan 1st 2006, and than I made it complete the boot. After the boot, the System Event Log contained a 6005 event whose time stamp was Jan. 1st, 2006, preceeded by the 6005-6006 pair whose time stamp was May 2nd, 2006. Since the System Event Log of the suspect disk did not contain any out-of-sequence 6005-6006 event pair, the BIOS date settings had not been changed.

I'd like to hear from you if you think that my conclusions are definitive.

Thanks a lot,

Cosimo

ReplyQuote
Posted : 04/05/2006 1:28 am
cosimo
(@cosimo)
New Member

… in my previous post I forgot to add that the other option to change the MAC times (using the SetFileTime() API) is not a problem, since the Italian legislation says that is the employee that has to prove that the employer used it, and since using SetFileTime() does not leave any trace, this cannot be shown in any way.

Cosimo

ReplyQuote
Posted : 04/05/2006 1:38 am
koko
 koko
(@koko)
New Member

I'm confused. You don't have to reboot in order to change the date in windows.

ReplyQuote
Posted : 04/05/2006 2:57 am
gmarshall139
(@gmarshall139)
Active Member

By default Windows XP syncs to the windows time server weekly. You would also expect to see these updates, as there will be a time change, if only a second or two. From what I'm reading I think you are on to something.

More testing may be necessary though. What if I changed the time, performed the steps I set out to, then changed it back. All without shutting the computer down.

ReplyQuote
Posted : 04/05/2006 3:04 am
cosimo
(@cosimo)
New Member

Hi Koko and gmarshall,

The last modified time of the TimeZoneInformation key is 4/5/2006 95524,
that is before the system had completed its boot (as can be seen by the fact that the first 6005 eventid entry in the Event Log is timestamped at 95544).
Furthermore, the event log registered the following sequence of events

4/5/2006 100043 AM eventlog None 6006
4/5/2006 95709 AM Service Control Manager None 7036
4/5/2006 95709 AM Service Control Manager None 7036
4/5/2006 95708 AM Service Control Manager None 7036
4/5/2006 95707 AM Service Control Manager None 7035
4/5/2006 95704 AM Service Control Manager None 7035
4/5/2006 95659 AM Service Control Manager None 7036
4/5/2006 95659 AM Service Control Manager None 7035
4/5/2006 95629 AM Service Control Manager None 7036
4/5/2006 95626 AM Service Control Manager None 7035
4/5/2006 95626 AM Service Control Manager None 7036
4/5/2006 95625 AM Service Control Manager None 7036
4/5/2006 95625 AM Service Control Manager None 7035
4/5/2006 95625 AM Service Control Manager None 7036
4/5/2006 95625 AM Service Control Manager None 7035
4/5/2006 95544 AM eventlog None 6005
4/5/2006 95544 AM eventlog None 6009

the bottom two lines register when the machine boots . After that, there is a sequence of messages registered when a service is started (7035) or stopped (7036). This sequence is generated by the services started by the OS, and shows that services were being started after the machine booted. If the clock had been brought back and forth, we would observe some out-of-sequence timestamps, since the time stamp of those generated while the clock was set to Jan 20th would carry that date, and then the other ones generated after the clock had been rested to Apr. 5th would carry the correct date.
As can bee seen by the log, there are no out-of-sequence timestamps, and this should show that the clock has not been brought back and forth. At least, this is the conclusion I would like to draw )
What do you think?

– Cosimo

ReplyQuote
Posted : 05/05/2006 1:57 am
iruiper
(@iruiper)
Active Member

Hi,

I still don't understand all the stuff about the registry and the event log… but I would like to point out something quite simple what if some software has been used to modify files attributes? For example AttributeMagic.

ReplyQuote
Posted : 05/05/2006 2:02 pm
gmarshall139
(@gmarshall139)
Active Member

I think it builds your case in that direction. I don't think it's definitive.

Can I switch the clock, then create/modify a few files without creating a log entry?

If I did create an out of sequence log entry could I delete the entry from the log?

Could I attach the hard drive to another computer and alter/add the files I wanted without booting it's OS?

Can I use something such as Attribute Magic to alter those times?

Could I manually alter the MFT entries for the files in question?

I don't think you'll answer these questions definitively from the computer alone. The people who possessed the computer are part of the chain of custody now. They can testify to what they did with it.

ReplyQuote
Posted : 05/05/2006 6:17 pm
Share: