This is Part 2 in a look at Event Log Tampering. Check out Part 1 before reading this one!
Part 1: Disrupting the EventLog Service
Part 2: Manipulating individual event logs
- Evtx Structure & Manual Event Editing (A must-read to understand the following sections)
- Event Record Unreferencing (Shadow Brokers leak of NSA’s DanderSpritz/eventlogedit)
- Rewriting Logs with WinAPI EvtExportLog (3gstudent’s evolutions of eventlogedit)
Manipulating Individual Event Logs
This is where it gets interesting… The techniques we covered in Part 1 generally leave a timespan where there are no events, but the 3 methods we will cover now are about changing or deleting individual event records. This could lead to event logs that have disinformation or completing remove the malicious activity from the log.
Manual Event Editing
Here we are going to manually edit the account name of an event log. Below you can see the before and after tampering of the same log entry!
To edit the event log, we first need to understand the structure of a .evtx file.
On a very high level, the .evtx file is made up of the file header, several chunks and then records that contain our event data.
These records contain binary XML data which is what we would commonly recognise as the events themselves.
It is still important to understand the rest of the structure when we are looking to manipulate the logs due to several checksum fields.
Here are some quick diagrams to highlight the important parts of each file. Take note of the 2 checksum fields in the Chunk Header.
File Header
Chunk Header
Event Record
Below is a much more detailed list of the structure and file offsets for the .evtx file if you are interested.
Time to Tamper
Now knowing the file structure comes in handy. 3 main checksums will cause the event log to become corrupt if not updated correctly, the File Header Checksum, Chunk Header Checksum and the Event Record Checksum. Depending on the modifications you do, you may have to recalculate all 3 checksums to ensure the event log is valid.
- Stop the Event log service and copy the .evtx
- Modify your events
For this example, I’ve changed the name of the user responsible for an event from Administrator, to “Not_a_hacker.”.
3. Recalculate the Event Record Checksum and update the Chunk Header
As we have edited an event record, we have invalidated the Event Record checksum.
Event Record Checksum = CRC32 of first event record to the last event record for that chunk.
You can use the fields in the headers to locate the last event offset for the given chunk you are editing.
For my example the CRC32 output for all event records in the chunk I was editing was 0x5d312313. Below is the Chunk Header after updating the value (and make sure to swap the order of the value due to little-endian format).
4. Recalculate the Chunk Header Checksum and update the Chunk Header
After you’ve completed step 3, you should have updated the Chunk Header with the new Event Record checksum. This now means the current Chunk Header Checksum is no longer valid.
Chunk Header Checksum = CRC32 of first 120 bytes of the header + the bytes between 128–512.
Put simply, the checksum is basically the whole Chunk header except the 8 bytes near where the checksum sits. I’ve highlighted the selection below because I think its easier to understand visually.
5. (If needed) Recalculate the File Header Checksum and update the File Header
For the example above, I didn’t alter the number of chunks or change the latest event so I did not have to recalculate the File Header Checksum.
Results
Opening up the .evtx, we can see the Account Name field has been changed.
If you’ve not calculated the checksums right, you will get this error when opening the file.
Detection
The good thing about this manual method for investigators is that there will be certain evidence left behind:
- Service Control Manager Event ID 7035
- Command-line usage of Service manipulation (sc.exe)
- File access to the .evtx itself (moving, copying or accessing)
Event Record Unreferencing
Building on what we’ve just learnt about the structure of the event log file, instead of editing the log itself, we can manipulate the headers to hide certain logs seen in Danderspritz, part of the NSA leak.
By manipulating certain size fields in the record headers, we can effectively unreference an event log without changing or deleting the record itself.
The goal of this method is to modify the size in the record headers of the preceding log to be “deleted”. By increasing the size of the previous log with the size of the target log, we have successfully unreferenced the record by joining the two records.
Initially, I thought that it would still show the two records in one when opened in event viewer, but it must be seen as excess data and is not shown because it detected a new record file signature.
Just like we learnt in the last method, the Record and Chunk Header checksums will still need to be recalculated.
The full process would be:
- Edit the size of the previous Event Record to hide the target record
- (Can be skipped technically, but will leave a trace of EventRecordIds not in sequence) Update all subsequent Event Record IDs (this means all subsequent chunks now need their checksums recalculated)
- Update and recalculate the following in the Chunk Header
- Last event record number
- Last event record identifier
- Last event record data offset
- Event Record checksum
- Chunk Header Checksum - Update and recalculate the following in the File Header
- Next Record Identifier (eg -1 if deleted one event)
- File Header Checksum
As part of the NSA shadow-brokers leak, one of the tools included was Danderspritz. Danderspritz has a module called eventlogedit which uses this method.
The blog by Fox-IT describes the method of the module eventlogedit in more detail, and they have also released a tool to detect the use.
Detection
The logs are never deleted! Due to the nature of this method, it is possible to undo these changes to recover the hidden logs by looking for the record signature (0x2a2a) and looking for EventRecordId inconsistencies. Fox-IT also posted a script that can do this for you - https://github.com/fox-it/danderspritz-evtx.
As of today Eric Zimmerman also updated his tool, EvtxECmd, to detect this method.
Rewriting Logs with WinAPI EvtExportLog
3gstudent released several blogs on event logs and they developed a method using the built WinAPI.
As seen in the Microsoft doc, the function supports a Query which can be an XPath XML query. Below is the source code for a tool by 3gstudent, which we can see simply creates a query to exclude any log that has the EventRecordID supplied to it.
After running the tool, it creates a temp.evtx excluding the EventRecordID I supplied.
There is now a gap in the logs, but the log is completely deleted and not recoverable.
We now we have an ability to quickly create a new log excluding certain events.
Detection:
We will look at this again in the next part, but now a hole in the EventRecordIDs, this method can be detected looking for non-sequential EventRecordIDs.
Covering All Bases
DeleteRecordofFile doesn’t use the WinAPI, but the file structure we learnt about at the start of this part. Using this method, by 3gstudent, we can delete an event and fix the EventRecordIds in front of it so we no longer have a detectable hole.
Here we have a log with 10148 events.
We edit the source code so we are deleting the record 3547.
After running the program, we can not only see that there is one less event, but there is no gap in Event Record IDs.
In the next part, we will combine what we’ve learnt by replacing the log while the EventLog service is running.
Thanks for reading, Zach.
