Computer Forensics - sometimes it’s all about timing

A good reminder by Ms. Raincock.

I just went through a message thread where some of the messages were time stamped out of sequence. That is, the response had prior time stamp than the original question. One of the mail servers' clocks were off several minutes.

So what is the best practice? To synchronize date/time stamps? What do you synchronize the time to? Would a radio synchronized clock be sufficient? Or, what can be considered sufficiently authoritative time source and methodology?

Here is a link to the various pool of Time Servers.
http//www.pool.ntp.org/en/

With respect to analyzing acquired images, the issue of relative time is one of the reasons why we need to include multiple data sources in a timeline.

A system's time should be fairly consistent, particularly over short periods, relative to itself. By being able to show multiple related events within relatively close proximity to each other, our relative confidence in the more mutable times ($STANDARD_INFORMATION attr time stamps from the NTFS MFT, etc.) will increase.

Jhup

Thank you for your questions and comments.

In terms of the time accuracy of the events in a past crime, it is more about establishing the accuracy when it is unknown what procedures were in place. The investigation may assist in determining through examination the accuracy or via an analysis of procedures. Hence, it is not so much about the best practice of keeping accurate time, it is more about if it can be established if it was accurate for past events. The article focuses on how this accuracy assessment step is sometimes not considered in cases (or even occurs to the legal team) resulting in a time sequence of events where the accuracy and ordering is unknown.

Regarding keeping accurate computer system time, synchronising with a time server is a good way of assisting in this. However, synchronisations alone are not always enough evidence, since in essence, it only states that at the point of the synchronisation the time was (assumed) accurate. It doesn’t alone state anything about the times in between. The easiest way to look for time drifts between synchronisations is to examine the ordering of the event log (including where required fragments found in unallocated). If you analyse the events in order and discover an entry at 28th June 2010 2000, then the synchronisation occurs and entries appear at 1755 on the same date then you are alerted that further in-depth investigation would be required.

Kind regards

Sam Raincock

Ms. Raincock's article is a good read, overall.

I was struck by her section on telephone time, particularly her statement

Mobile telephones also potentially suffer from time accuracy problems since the handset date and time is set and can be altered by a user.

Is this a UK-specific issue? It's been my experience that mobile handsets in the US get their time from the carrier, whose time is very accurate due to interstate tariffs and the "need" for precise billing.

keydet89

Absolutely. As well as being able to show there is consistently little drifting and no evidence of a user changing their time in between events.

The issues I frequently see are when full consideration is not given to a particular digital device and the accuracy of time is assumed to be accurate using minimal information or no checking at all. I have seen this result in cases being taken forward through the legal process where the evidence just isn't as assumed.

One very basic case for me was a male being charged with death by dangerous driving (carrying up to 14 years imprisonment in the UK) based on the assumption he was using his telephone at the time of the accident. The approximate accident time was established by a person on the scene dialling the emergency services (which will have occurred an unknown time after the impact occur). The telephone usage was established only by the call information stored on the telephone and compared with the emergency call time. I reviewed the case and the charge was dropped to death by careless driving (likely no custodian sentence).

Kind regards

Sam Raincock

A system's time should be fairly consistent, particularly over short periods, relative to itself.

I'm sorry – I don't understand that. Relative itself? What criteria are you thinking of for consistency here?

My first thought is that as long as the system clock keeps ticking, no matter how much real time there is between each tick, system time will be self consistent. It's when the clock stops ticking or starts ticking backwards that there will be lack of internal consistency visible in, say, log time stamps..

Or do I over-interpret 'relative itself' – to me that suggests no reference to any other source of time?

Is this a UK-specific issue? It's been my experience that mobile handsets in the US get their time from the carrier, whose time is very accurate due to interstate tariffs and the "need" for precise billing.

In my experience, it varies from carrier to carrier. For example, my Sprint phone did not record the change in Daylight Savings Time until after 10AM EST whereas my ATT phone was updated almost immediately.

Another area where I have seen a problem is with certain hardware imaging devices. For example, I noticed the other day that my ImageMASSter Solo III unit had a date in the year 2019. While that would not be expected to change the date of the actual evidence, it certainly complicates things if the Solo III log were to be used as part of the chain of custody documentation. At least it would call into question the fastidiousness of the examiner.

AWTLPI

In the UK some handsets do allow syncronisations to occur, for example the iPhones. However, a lot of phones certainly do not have this as a default option or do not offer it.

Of course, if a user connects their telephone to their PC you may get a time syncs occurring. In such a case the PC accuracy may then need investigating…..

Kind regards

Sam Raincock

A system's time should be fairly consistent, particularly over short periods, relative to itself.

I'm sorry – I don't understand that. Relative itself? What criteria are you thinking of for consistency here?

My first thought is that as long as the system clock keeps ticking, no matter how much real time there is between each tick, system time will be self consistent. It's when the clock stops ticking or starts ticking backwards that there will be lack of internal consistency visible in, say, log time stamps..

Or do I over-interpret 'relative itself' – to me that suggests no reference to any other source of time?

In a recent case, I received two images, without having access to the systems, or documentation regarding how the images were acquired. In and of itself, this is not unusual…sadly.

The assumption I have to make when examining each system individually is that the system clock is relatively consistent, and all times recorded for events on the system (ie, Event Log record generated times, Registry key LastWrite times, MFT attribute times, etc.) are all consistent relative to the system clock. Is there an issue of drift? Perhaps…but with nothing more than an image, how does one measure that? How *would* one measure that, and remain within the scope of the contracted task? Is it possible that a user changed the system time? Of course, but there are no indications of that. The issue is one of identifying when (and possibly, how) specific malware was installed, and if sensitive data was taken.

Now, the malware in question is known to (and this was verified) copy the timestamps from a system file when installed. So the creation date within the $STANDARD_INFORMATION attribute was modified, but the last accessed date within the same attribute was consistent with other events on the system; the $FILE_NAME attribute time stamps were used to identify when the malware was originally created on the system.

As the system is being analyzed as a standalone system, and not relative to any other systems, we have to and can assume that the system times are relatively consistent within the context of that system.