Planting evidence

The other day, Dimitris left a comment asking about how to determine if someone has altered the BIOS clock and placed a new file on the file system. In essence, this is “planting evidence”.

So, what might the side effects of this type of activity be? It’s difficult (if not impossible) to give an exact answer that will fit every time. Especially since there are different ways of planting evidence in this scenario. For example, the suspect could:

  1. Power down the system
  2. Change the BIOS clock
  3. Power the system back up
  4. Place the file on the system
  5. Power the system back down
  6. Fix the BIOS clock

Alternatively, the suspect could also:

  1. Yank the power cord
  2. Update the BIOS clock
  3. Boot up with a bootable CD
  4. Place the file on the system
  5. Yank the power cord (again)
  6. Fix the BIOS clock

It’s also possible to change the clock while the power is running. Again, it’s a different scenario with different possible side effects. Really, this needs to be evaluated on a case-by-case basis. However, the fundamental idea is to look for evidence of events that are somehow (directly or indirectly) tied to time, and see if you can find inconsistencies (a “glitch in the matrix” if you will.) The evidence can be both physical as well as digital. For example, if the “victim” were having lunch with the CEO and CIO during the time which the document was supposedly placed on the system, then the “victim” likely has a good alibi.

For digital evidence, there are 3 basic aspects of computing devices:

  • the code they run (e.g. programs such as anti viruses)
  • the management code (e.g. operating system related aspects), and the
  • communication between computing devices (e.g. the network).

Dimitris mentioned the event log, so we’ll start with operating system related aspects (which falls under the category of host-based forensics). There are a number of operating-system specific events that are tied to time. I suspect that the reason the event log is often referred to, is that it is difficult to modify the event log. Each time the event log service is started and stopped (when a Windows machine is booted up and shutdown) an entry is made in the event log. Another time related event on a Windows system could be the System Restore functionality. If a restore point had been created during the time a suspect was planting evidence, you may find an additional restore point with time related events from the future.

Another aspect to examine would be the programs that are run on the system. This falls under the category of code forensics. For instance, if an anti-virus software were configured to run at boot up, examining the anti-virus log might show time related anomalies. Under the category of code forensics, you might also want to examine the file that has been purported to be “planted”. For example, Microsoft Word documents typically contain metadata such as the last time the file was opened, by whom, where the file has been, etc. If the suspect were to boot up the system with a bootable CD and place a document that way, examining the suspect file(s) may be one of the more fruitful options.

Don’t forget about the communication between computing devices, which would be the category of network-forensics. For example, if the system was booted up, did it grab an IP address via DHCP? If so, the DHCP server may have logs of this activity. Other common footprints of a system on a network include checking for system updates (e.g. updates server), Netbios announcements, synchronizing time with a time server, etc. This alone could be a good reason to pull logs from network devices during an incident, even if you are sure they network devices weren’t directly involved with the incident, since the log files could still contain useful information.

Now, I’m sure there are some folks who say that “well this can all be faked or modified”. Yes, that’s true, if it’s digital, at some point it can be overwritten. First, realize that I didn’t intend for this to be an all-inclusive checklist of things to look for. Second, especially if the system was booted using the host operating system, there are a myriad of actions that take place, and accounting for every single one of them can be a daunting task. I’m not saying that it’s impossible, just that it is likely to be very difficult to do so. In essence, it would come down to how well the suspect covered their tracks, and how thoroughly you would be able to examine the system.

At this point, I am interested in hearing from others, where might they look? For instance, the registry could hold useful information. Thoughts?


  1. Dimitris says:

    Very nice article Mike.

    The first two “planting” scenarios are the most commonly used if someone wants to plant a document and i agree with the procedure as described.

    I agree with the restore point, anti-virus logs is also a hint but Event Viewer can be tricky.It is possible to stop Event Viewer from logging, change the time not even shutdown the machine, plant the doc with a past date, enable logging and go. Examining analytically the timestamps of the suspicious documents in combination with event viewer logs will not show this, try it yourself.

    The best practice to audits time events is to enable Privilege Use logging(off by default). Every time the system time changes u will get two codes 577 and 520, that will do the job.

    Concerning restore points, fifo.log keeps track the restore point deletion process but how you can use this to claim that system time hasn’t change ?

    Dhcp logs is also a very good idea, but pulling the cable out or the use of static ip is overcome the whole claim.

    I would like to hear form others too 🙂

  2. Thanks for the support…

    I didn’t intend for the start/stop of the Event logs to be the only indicator to look for. The scenario you described is definitely a possibility. Instead I was suggesting the Event logs as a source of time-related events. Although, the starting and stopping of the event logs (even with time altered) should still generate logging started and stopped events. The times for the start/stop events might not be backdated, although you should still see the logging service start and stop events. Good note about the privilege use logging.

    With the restore points, I was thinking more of a possible scenario such that if a system restore point was created during the time the document was planted, files in that specific system restore directory might show timestamps from the future (since the clock was turned back). I haven’t verified this, again I was using the system restore directories as a possible source of time-related events.

    With regards to DHCP logs, yes there are scenarios where they may not be useful. As mentioned, this wasn’t meant to be an all-inclusive list (which would be highly case-specific), instead a starting point of what types of things to look for. The general idea (mentioned at the end of the post) was that the more data you have to analyze, the more likely your conclusion (about the document being planted) would be correct. It’s an example of inductive reasoning. 🙂

  3. I came across this now. Very interesting concepts. You’ll find something similar in my PhD thesis available at Kind of a generalization of the ideas presented here.

Leave a Comment