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