I was recently reviewing some event logs on a Windows server and noticed a few items that I hadn’t seen before. These events related to Applocker, which was released a long time ago, but I hadn’t really seen much in the forensic analysis space. This post will cover a brief intro to setting up Applocker, some resources for configuration, and some event logs that you should probably keep an eye out for.

TLDR: Turn on applocker on servers you own (workstations too if your users wont kill you). Also look out for applocker events during your event log analysis!

Special thanks to Troy Larson for helping me out with this research

Applocker

Microsoft introduced applocker as a method of white listing executables way back in Windows 7/Server 2008 R2. I’d heard of it before (thanks to a webcast by Blackhills Infosec) but hadn’t seen it in the wild. Thankfully a system I was examining had it enabled, which was good 🙂 But also set to allow everything, which was bad 😦

Some useful reading material on applocker has been put together by Microsoft here. To enable it, open the Local Security Policy console and navigate to Security Settings > Application Control Policies > AppLocker.

You may need to turn on the AppIDSvc service

Expand AppLocker, right-click on Executable Rules, and select Create Default Rules. This is to ensure that rules that you create do not interfere with execution of critical operating system files. You can be fancy and create your own rules, and tweak it as necessary. There’s also the option of setting it to work in Audit mode, which means that it’ll record everything as it goes without preventing any executions. As a result, you can baseline your standard activity and then implement rules as necessary.

The standard rules allow everyone to run scripts and executables from “Program Files” and “Windows”, and to allow Administrators to do whatever they want. Now of course, we don’t let our standard users run as Administrators so thats all good right? Right!?

Troy Larson also sent through this, which looks like it is super useful at assisting in your configuration. It’s also something I haven’t explored yet, so YMMV.

Configuration Settings

Ok, so I had a couple of questions that I wanted to answer. Firstly, where are these rules stored. The Registry of course 🙂

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SrpV2\

A quick check of this location should tell us what rules were enabled. I didn’t look too much into what would happen if an attacker was able to reconfigure applocker, but then if they could change the settings they would already be an Administrator. Question for another time I suppose. I also didn’t look to deep into the rules and whether this is where Windows stores whether applocker is enabled or just set to Audit only.

We can easily pull this info out with our Recmd/RegistryExplorer/Regripper registry tool of choice.

But then, the next question is, what do the event logs show!?

Event Logs

There are 2 major event logs that we’re going to look at.

Big bold caveat up front. Wait, let’s make it red for emphasis.

Test this on the version of Windows you’re examining before you make definitive statements about execution timestamps. Different versions will act differently. Also let me know what testing you’ve done if you can and I can try and keep track of it.

AppID

This is what kicked this whole thing off. This event log seems to relate to signed code verification, although tests have shown that this may track unsigned code as well. From the looks of things it’s also likely that this event is recorded on the initial execution of a program. Initial suspicions were that it could be logged similar to appcompat but this doesn’t seem to be the case.

Troy suggested that when the verification occurs, Windows will add an extended attribute and therefore the changed time of the executable should reflect this as well. How to examine the EA is another question. Apparently the data held within here is at the developer of the times discretion so treat with care.

It appears that this event log entry can be used as a record of the first time a program was run. The caveat here is that there are lots of executables being run all the time and the log doesn’t appear to record all of the background executables being run, which is not a bad thing for tools being dropped, but may not show LOLBins as well.

I’m not sure how it distinguishes between executables either. It could be hashes, timestamps, or even whether there’s an EA. Further testing is required.

From an examiner/defender perspective, if you build up a whitelist of developer names you would be able to filter them all out reasonably quickly (assuming an attacker isn’t using a signed MS executable for badness).

For my task I only had a few to look through, and quickly identified that Mimikatz is signed by “Open source developer”. Which is also shown in this tweet.

The event data may also contain a success code. If the code is 0 then code verification succeeded. Any other number is that verification failed or the executable was unsigned. Further testing on this is required. 

The main takeaway is that if applocker is enabled this is a good event to look for at least to highlight any signed programs that look suspicious. With a good whitelist it’ll be a good quick win.

Applocker

There are actually four specific event logs relating to applocker, depending on how you’ve got it configured. Microsoft has put together a great article here.

Security considerations: “AppLocker can only control VBScript, JScript, .bat files, .cmd files, and Windows PowerShell scripts. It does not control all interpreted code that runs within a host process, for example, Perl scripts and macros”. But then, no one system is perfect and this will still protect your users/servers from a lot of badness.

As a result, I built a few maps for Evtxecmd, and sent them over to Troy, who tidied them up and added a few more. He has since pushed them to the repository, so sync if you haven’t!

These are really useful events to review for program or script execution because we get great information including the execution time, path of the file, and the hash as well. You may need to review the payload data as we may not have pulled out all of the fields that are important to your case. 

The caveat here is that it didn’t identify all executions that I knew existed, but it’s a good place to look. Especially considering there are limited artefacts available for command line executions on servers as it is. I hope to see applocker be enabled by default, which will mean that there will be difficult conversations with sysadmins that choose to remove the rules rather than adjust them where necessary.

---

Overall, download the latest maps for Evtxecmd and have a play. It’s a good idea to enable applocker where you can, or , even if you’re just going to put it in Audit mode, that might be helpful.