Checking Bios time ...
 
Notifications
Clear all

Checking Bios time yes or no  

Page 1 / 2
  RSS
fissa
(@fissa)
Junior Member

Hi all,

The title says it ; what do you do when seizing an pc/laptop for investigation?
For an unknown reason there is discussing on 'my workfloor'. Some do it but some dont.

These are my throughts (using Encase) to image and investigate the drive in it

When i image or get an image of a harddrive (as an example) for forensic investigation i was learned not to determine the bios time and date.
I was learned checking the currect offset of the timezone. Now, getting more experience i have asked myself ; what does this gain me? Im in Belgium, being in Central European timezone anyway. I do not get pc/laptops out of this timezone, because all cases are locally.

This timezone doesnt tell me something about the actual time and date setting on the pc/laptop does it?
For this ill dive into the registry. To be more specific ; the controlset (currentcontrolset, services, w32time, parameters)
Here i determine if the date and time was in sync with the NTP-server. If so, can i assume the date and time match the real time and date?

If not ; Is there a way determing an offset in time and date? Its quiete an easy anti-forensic action to mess things up for investigators. (Subject X is on an PC at 9-5-2019 at 1400 in a publin library, doing all kinds of evil. The PC's time is changed to 4 hours later. The timezone stamps of 'the evil' will list 4 hours later ; placing an unknow john Do behind the PC 'doing this evil')

Ofcourse, determining the bios time will overcome this 'problem'. But i could change back the normal time and date knowingly after i did my evil.

Any advice will be appreciated.

With kind regards,

Fissa.

Quote
Posted : 09/05/2019 1:28 pm
fissa
(@fissa)
Junior Member

nobody?

ReplyQuote
Posted : 14/05/2019 2:31 pm
www0ut
(@www0ut)
New Member

Hi fissa,

Thank you for your question(s). A few remarks from me

Checking the registry for a configured NTP server doesn't necessarily mean the system was able to sync with that NTP server. You can tell by analysing the Windows Event Logs if it synced successfully yes or no. If it didn't sync, it doesn't necessarily mean the time of the system was out of sync. You should check the BIOS to make sure the time/data of the system were correct at least at that moment of checking and acquiring the system.

So should you check the BIOS time? I think you should.

And regarding your remark of changing the time of the system this will create an entry in the windows event logs as well.

I hope this helps.

Kind regards!

ReplyQuote
Posted : 15/05/2019 3:50 pm
athulin
(@athulin)
Community Legend

When i image or get an image of a harddrive (as an example) for forensic investigation i was learned not to determine the bios time and date.
I was learned checking the currect offset of the timezone.

Different SOPs do different things. In your case, it may be that the probability for a issue requiring the information about system RTC was considered so low that it was considered wasted time. Or … perhaps even an impossibility if all you get your hands on is an image. In that case, you probably were taught to make sure that you didn't say anything specific about the actual hardware of the system in question.

The only situation I can think of when knowledge of the RTC could be important is for a system disconnected from the network, and not able to sync with a NTP server (once a week, default) or with its home AD. However, for that situation, knowledge about typical RTC drift (either in general, or for the one you actually have, in particular) wuld be useful – or not, as RTCs are said to drift more with higher system temperature.

Then again, user systems today tend to go into a kind of sleep state rather than power down entirely. I don't know if system timers (those that keep system time when the system is powered) still keep ticking or not – if they do, collecting RTC would be less interesting, except when full power down has taken place.

This timezone doesnt tell me something about the actual time and date setting on the pc/laptop does it?

It does, sometimes. Most timestamps are in GMT, so for those, registry settings are irrelevant. For any logs kept in local time time, rather than GMT, however, registry settings may give you the means to convert to GMT. Perhaps.

Here i determine if the date and time was in sync with the NTP-server. If so, can i assume the date and time match the real time and date?

Of course not. You apparently have taken some kind of forensic courses – those should have taught you what you can or cannot say. Getting time right is (or should be) basic stuff you should learn that as early as possible (or conversely, you should learn that you will be more or less useless as a forensic analyst until you've learnt it. Yes, I'm exaggerating a bit.). However, it's one of those things most FA don't learn early … so you're probably in good company.

Being in sync with an NTP server cannot be interpreted, unless you know the behaviour of the NTP server. (And no, you don't assume anything about them.) When I do security assessments on corporate networks, I very often find NTP servers all over the place, some seriously out of sync with real time. They're default services, and noone bothers about maintaining them. But if any client computer uses one of those to sync, forensics related to that computer is going to be difficult. (Getting authoritative time is often as important as getting authoritative DNS results.)

Add to that that NTP is a protocol designed for symmetrical bandwidth it assumes that client-to-server traffic is as quick as server-to-client. In many cases, that's not how home computers are connected. So … there's an additional error term to include. But I've never seen that error term discussed. Still, if it cannot be estimated, it should be documented as a disclaimer.

If not ; Is there a way determing an offset in time and date? Its quiete an easy anti-forensic action to mess things up for investigators. (Subject X is on an PC at 9-5-2019 at 1400 in a publin library, doing all kinds of evil. The PC's time is changed to 4 hours later. The timezone stamps of 'the evil' will list 4 hours later ; placing an unknow john Do behind the PC 'doing this evil')

I have heard about a forensic investigation that ended up in that situation DHCP logs were misinterpreted, and identified the connected laptop as belonging to John Innocent instead of, correctly, Richard Evil. It was a corporate investigation, but the mess was big enough to stink.

So … yes, I would collect system RTC, even if I know that it wouldn't necessarily be useful in a well-behaved investigation. It's when the investigation starts to go sideways that it just possibly may come in useful. Besides, if done right, the cost of collecting it is usually minuscule. In some cases it isn't – in those cases, there's good reason for not collecting it.

ReplyQuote
Posted : 15/05/2019 4:35 pm
Rich2005
(@rich2005)
Senior Member

It's one of those things which most places I've worked did as a matter of course…..although I'm largely of the opinion that it's pretty pointless.
If the dates and times on the computer came into question, the fact that the clock was correct (or near correct) when seized would prove of little value, if the other side had any sense (whether counsel or expert).
Just because it's correct at the time of seizure gives no guarantee that it was correct during the period being argued over. There could be multiple scenarios where the clock might have been changed automatically or deliberately (or there might be another issue with the timestamps unrelated to the system-clock) or the timestamps themselves might have been messed with if we're getting into that sort of thing.
Either way, if there was major dispute over time-related data, I don't think anyone would seriously suggest that just because the machine's clock is currently correct, that clears up the issue. You'd then be into the realms of the tricky task of trying to discover evidence that the clock was changed, or perhaps trying to identify items with timestamps within them that naturally derive from somewhere else other than the system-clock, and see if they correlate, and also try to corroborate that were indeed created around the same time as the questionable material from other artefacts. Or checking for evidence of timestamp manipulate. And so on and so forth.

It's not going to hurt to check the current clock setting of a machine, and arguably you should for completeness' sake, but in reality I don't believe it's the end of the world if you/someone didn't, as if a case hangs around timings, especially if disputed, then more work than just looking at the current state of the clock should probably be done.

ReplyQuote
Posted : 16/05/2019 6:00 pm
kastajamah
(@kastajamah)
Member

After reading all of these posts, I agree that you should check it. It goes towards being thorough, and it will be one less thing that the defense/opposing counsel will be able to cross you on why you did not. All of the forensic courses that I have attended, that cover this subject, have told me to do it as a matter of course.

As far as you being in central Europe and all the computers you examine are local so you do not check the time zone, I would disagree with this fully. You never know when a computer will come in that has a different time zone. When I work on the east coast of the US, I would say 97% of computers came in as the Eastern Time Zone. On occasion though, I would get computers from other time zones. If the time is at issue in a case you are working, 500EST is very different than 200PST. If the time frame you are looking into is at 200PST but you are focusing on 500EST, you will miss what your stakeholder wants you to find.

ReplyQuote
Posted : 16/05/2019 7:45 pm
pbeardmore
(@pbeardmore)
Active Member

I think Rich makes a good point re how useful the BIOS date/time is and if one were to introduce it as evidence, the caveats that he points out would have to be stated. The issue is, then, at what point do you get to so many caveats that the original data has little or no use and then, we are back to the question of why collect that info in the first place? The very action of collecting it is an indicator that it will have some evidential use/value which, as pointed out, is questionable. Tricky one.

ReplyQuote
Posted : 17/05/2019 11:40 am
athulin
(@athulin)
Community Legend

I think Rich makes a good point re how useful the BIOS date/time is and if one were to introduce it as evidence, the caveats that he points out would have to be stated. The issue is, then, at what point do you get to so many caveats that the original data has little or no use and then, we are back to the question of why collect that info in the first place? The very action of collecting it is an indicator that it will have some evidential use/value which, as pointed out, is questionable. Tricky one.

Not all information collected has evidential value. Some of it just raise questions, and so have investigative value.

There are also a number of questions that have to be answered for normal timestamps, relating to how long it was since the system synced time with an authoritative time server, and the accuracy that this would be expected to give, as well as how time was kept since that point in time, and what if any deterioration in accuracy this can be expected to have lead to.

Or, if we're lucky enough to get reliable external time logged somewhere on the system, and allow us to match that with internal time, and so get an estimate of how much out of synch system was.

One of the factors in such an analysis there would be if the system been powered down to a point where RTC is where system time is kept, and therefore the additional behaviour of that RTC becomes an issue. (I find a note that typical RTC crystals are temperature limited to less than 60 degrees centigrade – so a system running hotter may have time-keeping issues. I also find a note that +- 1.7 seconds per day is expected at 25 degrees centigrade, and at 'extreme' temperatures (seems to be 'hot' gaming systems), errors of 13 seconds per day have been observed. Some RTCs have built in calibration for these situations … but it's anyones guess if that's enabled in Windows or Linux or … )

If such power down (G4?) has taken place, the RTC date and time may become interesting, as it provides a very rough estimate of drift since last power down or other moment when RTC was updated. As we don't know if this will become relevant, collecting RTC data as early as possible seems like a useful safeguard. (But see below for a reason it might be useless.)

In any case, without such analysis, we cannot say just how far from accurate time that system actually is. Without it, it becomes 'user XYZ downloaded the relevant web page at 1954 ± ??hh??mm??ss. Just guessing that the error is so small that it can be ignored … I'd call bad forensics. Just as bad as guessing that system time hasn't been reset, and not warning about a possible source of error.

Since Microsoft published the warning that prior to Windows 16 Server, Windows did not keep time well on its own (particularly important for traders and banking and payment stuff), forensic analysts really have to be prepared to answer 'well, what is the expected error in times reported'? I have not found any answer to that from Microsoft, except the max 5 minutes error allowed by domain-connected systems. That is, for non-domain client systems, we don't seem to have any idea.

MS published some tests, but as they were made on virtual Windows Server 2016 systems, they're probably 'best case' situations. Does anyone know if those tests have been repeated in client systems, especially for pre-2016/10 releases?

(I also have a big question mark chalked up for Windows 8, which was banned from at least one benchmarking community, because of problems with RTC. It's probably restricted to system running software that adjusts the base clock without reboot … but I have not seen any technical explanation, so … we may have yet another factor to account for. This could easily lead to hands-in-the-air "forget about RTC for anything useful" on systems running Windows, just because accounting for such software seems to be tricky and possibly even imponderable.)

ReplyQuote
Posted : 17/05/2019 7:02 pm
jaclaz
(@jaclaz)
Community Legend

The issue is, then, at what point do you get to so many caveats that the original data has little or no use and then, we are back to the question of why collect that info in the first place? The very action of collecting it is an indicator that it will have some evidential use/value which, as pointed out, is questionable.

Allow me to philosophically disagree.

There are tens of things that are recorded/logged/collected and that give not any real "certainty".

It's not like anyone will ever discuss each of them and the reasons why they were collected, data is simply data, it is not necessarily revealing anything or proving this or that theory.

It's only a matter of pragmatism, most investigators will log BIOS data/time without "attaching" to it any particular meaning.

If you don't, be prepared to be questioned on the matter, losing some time to explain why exactly you omitted taking note of that, since it costs nothing (in money or time) to take note of that, just do it and move on, not entirely unlike the wiping of disks to which images are saved
https://www.forensicfocus.com/Forums/viewtopic/t=13055/

More generally, unlike filesystem timestamps, the BIOS date/time is "volatile", i.e. it is the kind of non-repeatable investigation, if you don't record/log it when you boot the system, it cannot be re-checked later and this alone can be a reason (even if the data do not actually mean *anything*) for the other party to put your report in a "bad light".

The "current" RTC/BIOS clock time will be almost always synchronized with system time, most probably the only "real world" exception being a "dead" CMOS battery (in which case when booting the time will be the BIOS release date/time or a "default", like 1-1-1970 or similar) but I can easily invent 😯 a couple of exceptions
1) the user may have booted the PC with another OS, not connected to the internet, changed the BIOS date/time and then forgot to set it back or reboot the computer
2) the PC might have been kept off (or not connected to the internet) for a relatively long period of time and there could be a significant enough to be noticeable "time drift" between the CMOS and the System (or NTP time)

Besides, depending on the OS, configuration settings may actually prevent the w32time service to sync, example
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc776191(v=ws.10)

jaclaz

ReplyQuote
Posted : 18/05/2019 11:09 am
passcodeunlock
(@passcodeunlock)
Senior Member

It's always a yes. The BIOS/RTC time has nothing to do with the analyzed data, it is part of the documentation for serving authenticity purposes.

ReplyQuote
Posted : 19/05/2019 7:58 pm
Rich2005
(@rich2005)
Senior Member

I won't quote the above posts as it'll make this thread far too long….;)

But whilst saying yes to collection, you do both further describe problems with actually basing any opinion on the reading, and/or why it might not be right.

We could probably all go on and on listing further reasons not to rely on it, or why it shouldn't be taken at face value, or used to assert that an earlier timestamp of some kind is likely to be correct.

As for the merit to counsel knowing it…..that's a double edged sword. You could record/report and it could result in lots of explanation/argument in the box. Equally you could not record it and have the same issue (in both scenarios explaining why you can't rely on it as an indication historic timestamps are correct for all the reasons we've described and no doubt countless more). Either way, I think you should always be prepared to be questioned about timestamps, and whilst it's a horrible subject with endless possibilities, could inevitably crop up at any moment.

Whichever way you cut it, we all know you can't say with any confidence at all, that just because the clock is correct now, that any timestamps in the past are accurate. Equally, just because it's inaccurate at the time of examination, you can't infer that all the previous timestamps were inaccurate.

So, if times are significant, we're back to trying to properly investigate the time issue more thoroughly, and trying to to do the difficult task of trying to give indications of why the time might, or might not be, reliable.

I could argue that the capture, and reporting of the clock alone, is arguably misleading to non-forensics people, by virtue of the fact they might understandably make the logical leap that it's quoted to indicate the other timestamps they're seeing are likely to be reliable, and that, without sufficient explanation / explanatory notes, it potentially does more harm than good.

A better question might be "when WOULD you rely, or give any meaningful weight, to the RTC taken at the time of examination of a seized device"?

ReplyQuote
Posted : 20/05/2019 6:06 pm
passcodeunlock
(@passcodeunlock)
Senior Member


A better question might be "when WOULD you rely, or give any meaningful weight, to the RTC taken at the time of examination of a seized device"?

A good analyst would never rely on the RTC taken at the time of examination of a seized device. As I wrote before, the BIOS time / RTC serves documentation purposes only.

ReplyQuote
Posted : 20/05/2019 8:50 pm
athulin
(@athulin)
Community Legend

I could argue that the capture, and reporting of the clock alone, is arguably misleading to non-forensics people, by virtue of the fact they might understandably make the logical leap that it's quoted to indicate the other timestamps they're seeing are likely to be reliable, and that, without sufficient explanation / explanatory notes, it potentially does more harm than good.

I don't think you raised that question. You asked about collecting the information … not including it in the final report. My answer addresses the collecting part only.

As for making more harm than good … you must be able to say 'this is hard evidence, and there cannot be any technical doubt about it', or 'this evidence may be used only under the assumption that … ' etc. In some cases, you must say 'evidence as to … could not be obtained with any degree of confidence, and so this question has not been answered at all in this report.' Or words to that effect.

As to writing anything without sufficient explanation or without explanatory notes … in my world that's never a option.

A better question might be "when WOULD you rely, or give any meaningful weight, to the RTC taken at the time of examination of a seized device"?

When it is demonstrably false, or turns out to be so out of synch with other evidence that the possibility that it has been used as 'correct' on boot time must be considered. (Basically, when it calls other evidence or the base for other evidence into question.) This should force the analyst to ensure that the base for the time line or important parts of it do not solely rely on the assumption RTC being correct on boot, but on stronger evidence such as logs from NTP synchs, or such.

Actually, such assurance should really be part of standard operating procedure as part of evaluating the evidentiary value of any timestamp in an environment that does not synch timestamps as soon as the system is turned on (or, equivalently, started from a power state that does not maintain internal timers).

And it does not seem impossible that it may be important to verify that the battery driving a battery-powered RTC is indeed within operational limits. If it isn't, … well, that seems to establish doubt that all timestamps are indeed correct … so extra work needs to be spent on limiting such doubts.

ReplyQuote
Posted : 20/05/2019 8:55 pm
jaclaz
(@jaclaz)
Community Legend

When I booted this PC this morning its RTC was showing 21/05/2019 0812.54, roughly at the same time another PC surely connected to an internet time service was showing 21/05/2019 0813.01 UTC.

Now let's see what kind of logical (or illogical 😯 ) leaps can anyone derive from the above statement, intentionally void of any comment, explanation or corollary, only a simple, straightforward statement . roll

jaclaz

ReplyQuote
Posted : 21/05/2019 10:19 am
Rich2005
(@rich2005)
Senior Member

When it is demonstrably false, or turns out to be so out of synch with other evidence that the possibility that it has been used as 'correct' on boot time must be considered. (Basically, when it calls other evidence or the base for other evidence into question.) This should force the analyst to ensure that the base for the time line or important parts of it do not solely rely on the assumption RTC being correct on boot, but on stronger evidence such as logs from NTP synchs, or such.

But surely you should NEVER solely rely on the assumption that the RTC being correct lends weight to the fact that other historic timestamps are correct (and vice versa).

Actually, such assurance should really be part of standard operating procedure as part of evaluating the evidentiary value of any timestamp in an environment that does not synch timestamps as soon as the system is turned on (or, equivalently, started from a power state that does not maintain internal timers).

Even in an environment that doesn't synch timestamps as soon as the system is turned on, with an accurate (or not) RTC, how can you derive credibility from the current RTC. It could have been changed in the bios just prior to seizure. It could have been changed in the bios during a certain point in time and then actions taken. And countless other possibilities.

And it does not seem impossible that it may be important to verify that the battery driving a battery-powered RTC is indeed within operational limits. If it isn't, … well, that seems to establish doubt that all timestamps are indeed correct … so extra work needs to be spent on limiting such doubts.

I would argue that doubt should always exist and an inaccurate RTC doesn't change that.

A good analyst would never rely on the RTC taken at the time of examination of a seized device. As I wrote before, the BIOS time / RTC serves documentation purposes only.

I don't really know what "documentation purposes" means. There's endless things you could document but you select which based on value. Do you fingerprint every component of every machine?

When I booted this PC this morning its RTC was showing 21/05/2019 0812.54, roughly at the same time another PC surely connected to an internet time service was showing 21/05/2019 0813.01 UTC.

Now let's see what kind of logical (or illogical 😯 ) leaps can anyone derive from the above statement, intentionally void of any comment, explanation or corollary, only a simple, straightforward statement . roll

jaclaz

A person not familiar with digital forensics could easily make the leap that because the time on the computer was accurate to within a small number of seconds that the timestamps in the case would be likely to be accurate. We know this is not true.

ReplyQuote
Posted : 21/05/2019 12:21 pm
Page 1 / 2
Share: