Windows Event Log to the Dark Side — Storing Payloads and Configurations

Mustafa
4 min readMay 2, 2018

--

Event log is a component of Microsoft Windows which provides a central logging service for the operation system, logs helped fixing problems and provided many traces and evidences for forensics.

Event log has been a target for multiple attacks to terminate its Service, clear its entries or terminate its threads(Invoke-Phant0m) to stop it from exposing attackers activities, at the same time other measures where taken to protect it, by forwarding logs to external machines where attackers have no access on, by protecting its service and datasets or keeping log for “clearance” actions done by users.

a log entry stating an RDP session to my desktop

Windows Event Log Structure

Event log consists of one main service called ‘EventLog’ which is ‘wevtsvc.dll’ running under ‘svchost.exe’ as a Local Service, providing logging service through Evt* windows API.

Log files are stored by default on “%SystemRoot%\System32\Winevt\Logs\” specially the legacy ones, and each LogFile has multiple Source as an identification for the application that triggered the source, registering new logfiles or sources requires admin rights on Windows Vista and later versions.

Each Source has different IDs for its different events, predefined IDs usually have predefined text or template that can be filled through string insertions from resources dll identified in EventMessageFile regkey, if you used undefined ID eventlog will display a message stating the “the description for the event is not found“ but it gonna be logged anyways.

EventLog key with Logfiles as sub keys and sources as sub keys

Any application can use any registered source to write logs, some restrictions apply to Security logfile as it’s only accessible to Administrators only, beside that, other logs are easily writable for normal users, guest user will face problems accessing logs even if logfiles lacking “RestrictGuessAccess” key, as he has no permissions to “EventLog” root key.

Reading and Writing to Eventlog

Having proper permissions -not much required- user can write text and binary data to event logs and retrieve them easily with:

  • Evt* EventLog APIs
  • Powershell
  • VBS & WMI
  • eventcreate.exe & wevtutil.exe

methods varies by features, as some allows adding binary data, changing user SID, some can only post text and so.

Write-EventLog -LogName "Application" -Source "Microsoft-Windows-User-Loader" -EventId 916 -EntryType Information -Message "Hello World" -Category 2 -RawData 65,66,67,68

previous powershell command will write to Application logfile, using User-Loader source, with event 916, and will include 4 raw bytes that will be formated as:

event with message formatted as its template

now to retrieve the message we call:

Get-EventLog -Newest 1 -LogName "Application" -Source "Microsoft-Windows-User-Loader" -Message "Provider Hello*"
Last event information

that will get us the latest event having the specified file, source and formatted message, then raw bytes and original replacement strings can be accessed directly.

different IDs can result in different formatted messages to look for, this allows us to hide different parameters inside the message to be extracted later on.

Now we were able to write and read we can use that to store a ‘fileless’ stage2 payload, and as logfiles are managed by system service, nothing suspicious in here, in fact, binary data can hold up to 32kb of data, that means we can even store sophisticated large payloads of empire, Meterpreter or any other payload and combine the chunks to rebuild the emipre.

for the purpose of demonstration, we can try to write some code, and read it back to read, using deflating to compress -despite the ration in here- and store it as raw bytes

Deflate payload and store it as raw data

now we can check and see how it looks in the eventlog viewer:

all we need next is to read and deflate the same way and then call Invoke-Expression to execute the decoded payload.

Payload is decoded and running

What’s Next?

After writing, reading and executing using EventLog, we can work more on:

  • blending the logs with existing logs and make use of parameters and text insertions.
  • multiplexing payloads using Categories, EventID and error Levels.
  • Hiding logs in unexpected logfiles and sources.
  • Increase LogFile size and retention policy, reissue the event to keep it persistent.
  • Reading events from raw log files directly if needed.
  • Sending logs to external computers as an update mechanism, as using remote computer “ doesn’t not rely on Windows PowerShell remoting. You can use the ComputerName parameter of the Get-EventLog cmdlet even if your computer is not configured to run remote commands.”

I hope this finds a good use, and people keep an eye on their logs, for real.

Empire has had this capability for some time. — Casey Smith

--

--

Mustafa
Mustafa

Written by Mustafa

dataisbeautiful, netsec, diy. Security Researcher @techarch.com.sa