This is an old article, but Wikipedia still has a link to it. Sorry about the lack of graphics, I failed the backup test.  It also contains absolutely no analysis of the structure of the EVT file and focuses only on file system analysis. 

BACKGROUND:
When confronted with analyzing a windows host that mysteriously has had some entries in its Event Logs disappear, we turn to forensically analyzing the disk to explain the "what happened" question. Here we are going to examine what evidence is left on the disk after the use of one of the public tools to do exactly this. WinZapper (http://ntsecurity.nu/toolbox/winzapper/) is a program that allows one to remove entries from the Windows Event Logs.

More exact, we will answer: What happens to SecEvent.evt at a file system level when one uses WinZapper against your host?

Our analysis will focus on the disk blocks that contain the current, older versions, or records inside the log. It is our hope that if we can successfully delete records from the current Event Log, we will see remnants of the deleted entries in unallocated space on the drive thus providing the evidence that the entries once existed.

Yeah WinZapper is old, but still relevant.

EQUIPMENT/SOFTWARE USED:

• dcfldd from http://dcfldd.sourceforge.net/
  
• grep, hexdump, sdiff
  
• The Sleuth Kit from http://www.sleuthkit.org/sleuthkit/ We use v2.07 here.
  
• WinZapper from http://ntsecurity.nu/toolbox/winzapper/
  
• One USB Thumb drive
  
• Our victim host is Win2k Professional, SP4, NTFS

ANALYSIS
Our Win2k Pro host is configured with every option enabled for Security logging. This is done both for content to delete, and in hopes that the activity will be caught and later found in the look we have at the HDD.

First off, for comparison purposes we must get a clean image of the victim host. This means imaging the partition the OS sits on prior to using WinZapper. Our setup has Win2k on a large disk but only using a 4G partition. The remainder of the diskspace is an ext3 partition. Booting with a live linux distro in console mode allows us to dd the win partition to a file on the ext3 partition. Good for several uses; restoring the pristine partition after a test gets out of control or completed, examining the partition, comparing it to other images or snapshots in time. We shall refer to this image as clean.dd.

Next, we download WinZapper and copy the contents of the .zip file to our thumb drive. The host you are testing this on does have a USB port, right? We are not concentrating on locating the binary and accompanying .dll on the disk, rather we want to know its effects on the various .evt files and further identify some solid characteristics caused by the program's use.

Log in to the target with an account that has Administrator privileges, or use your own favorite technique to gain admin or better execution context. Plug in the thumb drive, and execute winzapper.exe.

The next task is to select the entries to delete. Here, we will pick all of a certain date. Feb 16, 2007 to be specific. Clicking on "Delete events and Exit" gets us the exit warning:

So we comply as asked. Completely shutdown, and log in again. We check the Event Logs. Well, we are met with a the warning below.

After we click OK, we are told by Event Viewer that it is unable to read the contents of the System Log. Hmmm.. Checking the Security log shows that we have successfully cleared all events from our specified day. The Application Log is intact and shows events including events from the 16th.

Now, we will shut down the machine and take our second image. Imaging can be done with any bootable disk that contains dd or dcfldd, or other utility that lets you make a block-level copy of the target partition.

Using fls on both images to get the complete file listing and redirecting the output to a text file makes comparison a bit easier. We then grep through the output for case insensitive search of \.evt because we know that this is the extension of the in-tact files. Two clear things are noticable when comparing the results from each fls output. One, we now see an all lowercase secevent.evt log that does not match the case of the others (AppEvent.Evt and SysEvent.Evt) and inode numbering is a bit off. We can assume that all three event log files were created around the same time, so their inode numbers should probably be close. This is seen in the clean fls output, not the post-winzapper output. Checking the inode number that is used for SecEvent.Evt in the clean image on the post-zapped image, we now see a file called dummy.dat residing there. Recovering this file with icat shows that it is an event log and does contain the contents of the Security Event log prior to winzapper usage.

Looking at our images with:

Since we did not use the -p switch to fls to show us the full path, we see + characters to symbolize the depth in the directory tree the files sit. Of interest above is the difference in inode numbers for SecEvent.Evt (2724) and secevent.evt (6514). We can search through the win2k_1.fls_all file for 6514 and see that it did not exist in the first image. We also search through win2k_2.fls_all for 2724 and find the following:

Further, we can compare outputs of istat for more information and pull the contents of the data blocks that the inodes point to:

For readability, we convert the .raw results to hex like so:

Some systems may have hd available which is really 'hexdump -C' in shorthand. We can then use something like sdiff to see the file differences side by side.