Checking Bios time ...
 
Notifications
Clear all

Checking Bios time yes or no

24 Posts
8 Users
0 Likes
4,149 Views
(@fissa)
Posts: 27
Eminent Member
Topic starter
 

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.

 
Posted : 09/05/2019 12:28 pm
(@fissa)
Posts: 27
Eminent Member
Topic starter
 

nobody?

 
Posted : 14/05/2019 1:31 pm
(@www0ut)
Posts: 6
Active 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!

 
Posted : 15/05/2019 2:50 pm
(@athulin)
Posts: 1156
Noble Member
 

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.

 
Posted : 15/05/2019 3:35 pm
(@rich2005)
Posts: 535
Honorable 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.

 
Posted : 16/05/2019 5:00 pm
kastajamah
(@kastajamah)
Posts: 109
Estimable 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.

 
Posted : 16/05/2019 6:45 pm
(@pbeardmore)
Posts: 289
Reputable 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.

 
Posted : 17/05/2019 10:40 am
(@athulin)
Posts: 1156
Noble 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.

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.)

 
Posted : 17/05/2019 6:02 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

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

 
Posted : 18/05/2019 10:09 am
passcodeunlock
(@passcodeunlock)
Posts: 792
Prominent 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.

 
Posted : 19/05/2019 6:58 pm
Page 1 / 3
Share: