The Men who stare at the AppLocker event log

In this blog, we’ll delve into the curious interplay between AppLocker, MSI installers, Intune, and event logs. We’ll explore how to configure and monitor AppLocker policies, the limitations imposed by Intune, and what to expect from your event logs when blocking applications. Let’s get started!

1. Introduction to AppLocker

AppLocker is a powerful tool for administrators to control what applications users can run on their devices. By creating rules that govern executable files, scripts, MSI installers, and packaged apps, AppLocker allows you to enforce security policies and mitigate the risks of unapproved software running in your environment.

You might already know that deploying AppLocker policies manually can be done fairly quickly using PowerShell. It takes just a few minutes to roll out an AppLocker baseline across multiple devices. If you’re unfamiliar with this process, I recommend checking out this guide for a quick overview of deploying AppLocker via PowerShell.

Before diving deeper, let’s take a moment to understand where AppLocker stores its configurations when not using Intune.

• File System:
  Navigate to C:\Windows\System32\AppLocker to view all your AppLocker policies. If you’re using Intune, these policies will be moved to the MDM folder.

• Registry (without Intune):
  AppLocker stores its settings in the registry under
  HKLM\Software\Policies\Microsoft\Windows\SrpV2.
  Notice “SRPV2”? That stands for Software Restriction Policy V2.

A useful tip here: If you’ve ever accidentally locked yourself out due to an AppLocker misconfiguration, you can remotely adjust the settings by editing(deleting) those registry and file paths.

2. Configuring AppLocker to Block CMD and PowerShell

Now that we’ve touched on how to view your AppLocker settings, it’s time to test its functionality by configuring a few basic rules. For this example, we’ll block command prompt (CMD) and PowerShell.

If you need help setting up these rules, here’s a step-by-step guide to configure AppLocker to block administrative tools like CMD and PowerShell through Intune.

Once you’ve applied the necessary rules, try opening CMD. You should be greeted with an AppLocker notification, warning that the application has been blocked by the administrator.

This is the first sign that your baseline configuration is working as expected.

3. Monitoring AppLocker Events: The Case of the Blocked EXE

After successfully blocking CMD or PowerShell, the next step is to inspect the logs. Open Event Viewer and navigate to the EXE and DLL AppLocker event log. Here, you’ll see an Event ID 8004, confirming that AppLocker blocked the execution attempt.

Event logs are crucial for monitoring AppLocker activity, and integrating this with your monitoring tools, such as SolarWinds, can provide ongoing insight into the behavior of restricted applications.

However, things get more interesting when you attempt to block MSI files or scripts. Unlike executables, the event logging behavior for MSIs under Intune-managed AppLocker is a bit different—and far more perplexing.

4. The Case of the Blocked MSI: Where Did the Logs Go?

AppLocker also includes the ability to block MSI and script files, which you can monitor via the MSI and Script AppLocker event log. At least, that’s how it’s supposed to work. When AppLocker is deployed via Intune, this section of the event log can often seem completely empty.

Here’s the curious part: When I configured AppLocker through Intune to block MSI files, I noticed no AppLocker notification when I tried to run a blocked MSI. Even more strangely, when I checked the AppLocker logs for MSI and scripts, they were completely silent—no log entries, no trace of blocked actions.

But the mystery doesn’t end there. When I looked in the Application log, I found an Event ID 1007, which is typically associated with Software Restriction Policies (SRP).

This led to an interesting discovery: Microsoft appears to be using the legacy SRP to block MSI files rather than relying on AppLocker’s more modern infrastructure.

This mix of old and new technology makes it tricky to fully understand how MSI and script blocking works when using Intune, as the expected AppLocker logs simply don’t exist in these cases. It’s as if the entire MSI and script blocking feature reverts to SRP—an older, more rudimentary method of restriction—when managed through Intune.

5. Conclusion: Understanding the Limitations of AppLocker and Intune

Deploying AppLocker policies to secure your endpoints is a highly effective strategy, but understanding how AppLocker behaves—especially when using Intune—is essential. While blocking EXEs works as expected and generates logs in the proper location, the handling of MSIs and scripts when deployed via Intune can lead to confusion due to the absence of logs in the expected locations.

In short, AppLocker policies behave differently when deployed via Intune compared to traditional methods, especially when it comes to MSI and script restrictions. While AppLocker is a great tool for application control, keep in mind that certain components may fall back on legacy SRP mechanisms, and you may need to look in unexpected places (like the Application event log) to find evidence of blocked actions.

As a final reminder, if you lock yourself out of a device due to a restrictive AppLocker policy, remember that the SRPV2 registry key can be your lifeline for recovery.

In conclusion, while AppLocker remains a vital tool for securing endpoints, understanding the intricacies of how it operates—especially in the context of Intune—can save you from troubleshooting headaches later on.