Hiding In The Windows Event Log

In May 2022, Kaspersky published a write-up on a newly-discovered campaign where malware authors wrote shellcode to the Windows Event Log. This was pretty interesting, and just about 4 months later, Tim Fowler published this blog post over at BlackHillsInfoSec, digging into this a bit deeper and offering several variations of the technique up to red teamers.

Now, I found this technique interesting, not because it's not really something I'd seen before, but because of how Windows Event Logs, and just "Event Logs" prior to Vista, have been used by DFIR analysts. Back in the days of WinXP and Windows 2000/2003, there were The Big Three...Security, System, and Application Event Logs. With the advent of Vista, and then Windows 7, the numbers of Windows Event Logs available to analysts exploded; on my Windows 10 system, a 'dir' of the winevt\logs folder reveals 400 files with the ".evtx" extension. However, not all logs are populated, or even enabled. 

However, this doesn't mean that these logs are used during analysis; in fact, much like the Registry, the Windows Event Logs are largely misunderstood by a great many analysts, to the point where I've seen log collection processes that are still restricted to just the Security, System, and Application Event Logs. Further, there seems to be a great deal of Windows forensic analysis training that persists in identifying Windows Event Log records solely by their event ID, even when it's been stated and shown that event IDs are not unique. For example, we often refer to "event ID 4624" when identifying successful login events, but when the event source is "EventSystem", that event ID has an entirely different meaning and significance. And there's nothing the prevents someone from creating an application that writes it's logs to a current or it's own Windows Event Log, using the same event ID. In just the past year, I've seen several tools used by threat actors that create Windows Event Log records, two of which use event ID 0 (zero) for everything, literally every record written, regardless of the message, is event ID 0.

In short, using a Windows Event Log file as a persistent repository is a great idea because responders and analysts aren't likely to look there, nor consider it as a source. I found the use of the "Key Management Service" Event Log pretty interesting, because while it's enabled on the systems I have access to, it's not populated on any of them. 

So, I went ahead and tried a variation of one of Tim's commands, as illustrated in figure 1.

Fig. 1 - Powershell command

The resulting WEVT record can be seen in figure 2.

Fig. 2 - Resulting Windows Event Log record

This is the first record written to that WEVT file on this system, and as you'd expect, the file last modification time reflects that. This illustrates why this particular Windows Event Log file serves as a pretty decent persistent repository. You could change the log file used, but you'd have to find one that either is extremely low volume, or enable one that is similarly low volume. A Windows Event Log that regularly has records written to it does not serve as a suitable persistence mechanism, unless you're able to increase the size of the file,

Tim goes on in his article to extend the technique beyond what Kaspersky discovered, and what this really demonstrates is that there's a great deal that can be done with a few simple (native) tools, some knowledge, and some imagination. And, what makes it "interesting" is that it relies on a data source not often leveraged or exploited by analysts.

Tools like Chainsaw and Events Ripper would not be effective for detecting the use of this technique, particularly if the Windows Event Log used for this technique was not included in the collection process. An Events Ripper plugin that listed all source/ID pairs and their frequency might provide a pivot point for the analyst, but a timeline of system activity would certainly show any suspicious records, again, as long as the impacted WEVTX log is included in the collection process.

This StackOverflow question resulted in several ways to create Windows Event Log records using native methods such as eventcreate.exe, Powershell, etc.  Note that using eventcreate.exe is restricted to just the Application Event Log, but the availability of anything written to this (or another) Windows Event Log can be adjusted by the file size and retention settings.