Up to this point, we’ve touched on using Active Directory and the Registry to store code for later use. To add on to the topic, we can also use Event Logs. The effectiveness of this technique is based on the environment in which one looks to use it. I say this because if an organization is shipping logs to another server, it probably wouldn’t make sense for the Event Logs to be used. If that isn’t the case though, this may be a great place for a stager. Let’s explore this option a little more.

Depending on the environment, Event Logs could rollover pretty quickly. In order to combat this, we will look at making our own Event Log. While we are creating another artifact, the fact of the matter is that most administrators don’t have an understanding of the Event Logs that are already there, so one more won’t hurt.

First, we need to define our stager as well as base64 it for good measures.

Next, we will create a source for our log followed by creating an Event Log. In this example, we named our Event Log “Microsoft Office Diagnostics” with an event ID of 7832. We choose both of these settings in order to blend in to the standard Microsoft load yet not affect anything else.

We can then verify that our event actually wrote by getting a listing of the logs and the record counts of them.

We can also view the contents of the log as well.

When it is time to execute our stager, we can retrieve the data from the Event Log and execute it.