25.12.2014 Views

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

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!