A Common Misconception

An article in a German computer magazine recently remined me of a common misconception in event log parsers. Most parsers treat Windows event log files as sequential files - and read them from top to bottom. While this usually works, it might mangle or suppress a single log entry under special circumstances.

The event log found among the family of Windows operating systems which are based on the NT kernel can be configured to overwrite the oldest entry if the log file has reached maximum size allowed. From that point on the log no longer is a sequential file, but a ring buffer.

Now it can happen that an event record starts near the end of the (physical) file and continues near its top, right behind the file header. A log parser expecting to find sequential file will skip over the 2nd half of the split record, because it can't find the magic string which indicates a new event record. Sure it'll find the 1st part of the record at the bottom. But it might fail to parse the seemingly incomplete record. The image below shows the output generated by EnCase 5. Please keep in mind that EnCase just stands as an example here; several other parsers suffer from the same problem.

Several parsers fail to interpret  a split event record.

I provide a test file containing such a split record so you can check your favorite log parser on your own.

Archives

Imprint

This blog is a project of:
Andreas Schuster
Im Äuelchen 45
D-53177 Bonn
impressum@forensikblog.de

Copyright © 2005-2012 by
Andreas Schuster
All rights reserved.