Analysis and Evaluation of the Windows Event Log - Bill Buchanan
Analysis and Evaluation of the Windows Event Log - Bill Buchanan
Analysis and Evaluation of the Windows Event Log - Bill Buchanan
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Barrie Codona, BSc (Hons) Network Computing, 2007<br />
in which case <strong>the</strong> program automatically replaces <strong>the</strong> Security <strong>Event</strong> <strong>Log</strong> with a<br />
predetermined file <strong>and</strong> <strong>the</strong>n restarts <strong>the</strong> service.<br />
Experiment 8 – Master File Table. For this experiment a program called Directory<br />
Snoop was used in conjunction with <strong>the</strong> Hex Editor. Directory Snoop<br />
(http://www.briggs<strong>of</strong>t.com/dsnoop.htm) is an application that allows for <strong>the</strong><br />
inspection <strong>of</strong> <strong>the</strong> NTFS Master File Table. Which, as previously discussed in <strong>the</strong><br />
Literature Review chapter, is a relation database that contains information about every<br />
file on <strong>the</strong> local disk Directory Snoop was used to find <strong>the</strong> actual sectors <strong>of</strong> <strong>the</strong> local<br />
disk that was allocated to <strong>the</strong> Security <strong>Log</strong>. This sector was <strong>the</strong>n opened up with <strong>the</strong><br />
Hex Editor <strong>and</strong> some changes were made to <strong>the</strong> timestamp data. Upon viewing this<br />
information with <strong>the</strong> Directory Snoop it showed that <strong>the</strong> changes had actually been<br />
made, however when <strong>the</strong> <strong>Event</strong> Viewer was opened up it did not show <strong>the</strong>se changes.<br />
This implied that that when <strong>the</strong> <strong>Event</strong> <strong>Log</strong> Service is first started it reads <strong>the</strong> contents<br />
<strong>of</strong> <strong>the</strong> event logs from disk into memory <strong>and</strong> does not read <strong>the</strong>m again until it is<br />
restarted.<br />
The server was <strong>the</strong>n restarted to force <strong>the</strong> event log to reread <strong>the</strong> modified sectors,<br />
once again <strong>the</strong> <strong>Event</strong> Viewer was opened, however <strong>the</strong> changes had not taken effect.<br />
Directory Snoop was again used to check <strong>the</strong> sectors that had been modified <strong>and</strong> it<br />
showed that <strong>the</strong>y had been restored to <strong>the</strong>ir original values. The <strong>Event</strong> <strong>Log</strong>ging<br />
Service must have completely written <strong>the</strong> contents <strong>of</strong> its array in memory back to<br />
disk.<br />
3.5 Conclusions<br />
From <strong>the</strong> above experiments multiple vulnerabilities have been identified, it is<br />
possible to change <strong>the</strong> time that events happened at, usernames can be modified, <strong>the</strong><br />
event log can be copied <strong>and</strong> pasted into ano<strong>the</strong>r machine. The most surprising points<br />
learned was that <strong>the</strong>re is no security in <strong>the</strong> event log at all, no hashing to see if it had<br />
been modified <strong>and</strong> nothing to stop an event log from one machine being used on<br />
ano<strong>the</strong>r.<br />
Being able to modify <strong>the</strong> event log only involved having access to <strong>the</strong> Security <strong>Event</strong><br />
<strong>Log</strong> file <strong>and</strong> <strong>the</strong>n modifying <strong>the</strong> data contained within. Thus, if <strong>the</strong> <strong>Event</strong> <strong>Log</strong> files<br />
28