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.

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