This is Part 3 in a look at Event Log Tampering. Check out Part 1 and 2 before reading this one!
Part 1: Disrupting the EventLog Service
Part 2: Manipulating Individual Event Logs
Part 3: Combining Techniques
Combining these Techniques
So what do we know so far?
- We can Disrupt the EventLog Service to incapacitate the log service without having to suspend the process or service.
- We know how to Manipulate Individual Event Logs using a couple of methods.
This now means we can successfully suspend or kill the threads of the event service, to edit or delete an event record (or clear but that’s boring 😜), and resume the service. Depending on the operation you do, this can be quick enough to not create a big gap in logs.
These two repo’s use the techniques we’ve learnt about to create a fairly effective way of tampering with logs.
EventCleaner combines the method of Service Host Thread Tampering, Duplicating Handles and Event Record Manipulation to create a powerful result.
As an example, I ran an executable, bad.exe, which has the EventRecordID 1026 in security.evtx.
First, we suspend the event log service threads.
Duplicate the handle on the security.evtx file and close the current handle.
We can now see the instance of svchost.exe with the EventLog service no longer has a file handle for security.evtx.
Delete the EventRecordID 1026, fix the checksums, and restore the file handle.
Resume the threads of the service.
When inspecting security.evtx, it was observed that the EventRecordID skips from 1025 to 1027.
Detection:
We can’t rely on detecting the service going down because we used the thread suspend technique and because this method actually deletes the record rather than hiding it (as seen in Danderspritz in Part 2), that detection method no longer works.
However, as already mentioned, there is now a hole in the EventRecordIDs. It is enough to just look for non-sequential EventRecordIDs.
Doing one better!
Using 3gstudent’s method we learnt in Part 2, can recreate the log with sequential Record Ids.
3gstudent also detailed 2 ways of getting the handle to the log in their blog:
- Obtaining operation authority of the handle through DLL injection
- Using NtDuplicateObject to copy the handle and obtain permission to modify the file
I used the tools from their repo here:
As with the previous attempt, our first step is to suspend the threads of the EventLog service using SuspendorResumeTid.exe suspend.
The next step is to use the EvtExportLog WinAPI to copy the current Security.evtx, excluding a specific EventRecordID using DeleteRecord-EvtExportLog.exe security.evtx <EventRecordID>.
Use DeleteRecordbyGetHandleEx.exe security.evtx 1 temp.evtx, to move temp.evtxto replace Security.evtx by duplicating the file handle on the file.
And finally, restarting the threads with SuspendorResumeTid.exe resume.
We’ve now successfully replaced the log without evidence of EventRecordID inconsistencies.
Conclusion
From a DFIR perspective, it was good to go through each method practically myself to quickly understand some concepts I was lacking. I was definitely surprised with the effectiveness of the last methods which was a good reminder to not always trust the sources you rely on.
As a Detection engineer, the retroactive modification of logs isn’t something to be too concerned about if you are collecting logs centrally real-time, but disrupting the EventLog service is. Log gap analysis could be the best method of detecting these anti-forensics techniques.
Thanks for reading, Zach.
