Deploy, Test, Monitor: Mastering Microsoft AppLocker, Part 2

Welcome back to our deep dive into Microsoft's AppLocker. In the first part of this series, we provided a comprehensive overview of AppLocker and guided you through the process of activating and configuring AppLocker policies. Now in part two, we'll shift our focus to leveraging the power of Splunk to ingest, visualize, and analyze AppLocker events, enabling you to gain valuable insights and strengthen your organization's security posture.

Effective monitoring and analysis of AppLocker events are essential for maintaining a robust application control strategy. By centralizing AppLocker logs in Splunk, you can unlock the full potential of this security feature, allowing you to identify potential threats, detect policy violations, and make data-driven decisions to refine your AppLocker policies.

In this blog, the Splunk Threat Research Team will walk you through the process of setting up AppLocker data logging in Splunk, creating informative visualizations, and utilizing advanced analytics to detect anomalies and potential security incidents. We'll provide you with practical examples and pre-built dashboards that you can easily implement in your own environment. 

By the end of this blog, you'll have a clear understanding of how to use Splunk to maximize the effectiveness of your AppLocker implementation. So, let's dive in and explore AppLocker!

Prefer a video overview? Jump to the end of this post for a walkthrough of the topics covered in parts 1 and 2.

Logging AppLocker Data in Splunk

Using the Splunk Universal Forwarder and inputs.conf, we can easily add the four log sources and begin logging them right away. 

[WinEventLog://Microsoft-Windows-AppLocker/EXE and DLL]
disabled = 0
renderXml = 1
index = win

[WinEventLog://Microsoft-Windows-AppLocker/MSI and Script]
disabled = 0
renderXml = 1
index = win

[WinEventLog://Microsoft-Windows-AppLocker/Packaged app-Deployment]
disabled = 0
renderXml = 1
index = win

[WinEventLog://Microsoft-Windows-AppLocker/Packaged app-Execution]
disabled = 0
renderXml = 1
index = win

If you are using Microsoft Defender with Advanced Hunting, you can ingest the logs into Splunk or use Advanced Hunting to query for AppLocker logs. To ingest, we recommend using an Azure Event Hub to collect the data and connect to Splunk via the Splunk Add-On for Microsoft Cloud Services. In addition, we can use the Microsoft Defender Advanced Hunting Add-on for Splunk to map the data to the Splunk Common Information Model (CIM), but the data we’re looking for is not specifically needed as it is not mapped to CIM.

Visualizing AppLocker Data in Splunk

Now that we set up log collection, let’s explore how you can visualize AppLocker events using a dashboard the Splunk Threat Research Team created.

As of release 4.30 we’ve added the following dashboard to assist organizations in understanding their AppLocker configuration. Note that the queries are focused on the event logs direct from endpoints and not Windows Defender with Advanced Hunting. 

^{(Windows AppLocker Logs in Splunk, Splunk 2024)}

We organized the dashboard to showcase blocks, audits and allowed events. At the top we can filter by time, event code or policy type (script, exe and so forth). 

The lower half of the dashboard showcases event types and event codes calculated by host. This makes it easier to understand which endpoints are generating the most events and allows you to drill down to explore why.

^{(Windows AppLocker Logs in Splunk, Splunk 2024)}

Our recommendation for using this dashboard would be to drill down by policy type and use this to filter and tune the AppLocker policy. If a script should NOT be blocked, the block will appear here and provide context to go and filter this in the policy. 

AppLocker Event IDs

AppLocker logs various events in the Event Viewer, which can be identified by specific Event IDs:

AppLocker Event GUID

While reviewing AppLocker content, we noticed a GUID that was consistently found - {00000000-0000-0000-0000-000000000000}:
The GUID {00000000-0000-0000-0000-000000000000} in AppLocker events typically indicates that there was no specific rule that was matched for the event, and instead, the action was taken based on the default rule set for that type of file (e.g., executable, script, etc.). In our example case with test.js, the event is showing that a script (test.js) was blocked or audited based on the default rules because there was no explicit rule matching that file.

The and fields in the event data are used to identify which specific rule was triggered.

Analyzing AppLocker Events with Splunk Security Content

For those using the Splunk ES Content Update (ESCU) app, we created analytics using our standard method with macros, and we’ll use a lookup with all the EventCodes and Description of each AppLocker EventCode.

`applocker`
| spath input=UserData_Xml 
| rename RuleAndFileData.* as *
| lookup applockereventcodes EventCode OUTPUT Description
| stats values(host) AS dest by PolicyName, EventCode, Description, RuleId, RuleName, RuleSddl, TargetUser, FullFilePath _time

^{(Windows AppLocker Logs in Splunk, Splunk 2024)}

We removed a few fields to keep the table cleaner; however, feel free to add fields as needed based on your requirements.

Fqbn (Fully Qualified Binary Name)
The Fqbn, or Fully Qualified Binary Name, is crucial for AppLocker's Publisher rules, which allow or block software based on its digital signature. This information is used to uniquely identify the publisher of a piece of software. By specifying the Fqbn, AppLocker can accurately allow or deny the execution of software from a particular publisher, including specific versions. It's a more secure way of specifying rules because it relies on digital signatures rather than just file paths or names.

FilePath
The FilePath is used in Path rules within AppLocker. These rules specify which files or folders are allowed or blocked based on their paths in the file system. The FilePath can be used to control access to scripts, executables, and other potentially harmful files by only allowing them to run from trusted locations. Using variables like %WINDIR% (which refers to the Windows directory) in the paths makes the rules more flexible and adaptable to different system configurations.

TargetProcessId
While the TargetProcessId itself is not directly used in AppLocker rules, understanding the process ID related to a blocked or allowed execution can be vital for auditing and troubleshooting AppLocker policies. It helps identify which processes were involved in policy enforcement decisions, thereby aiding in refining AppLocker rules and understanding the impact of AppLocker policies on system operations.

TargetLogonId
The TargetLogonId represents the security context under which a process or application is running. This is important for understanding and auditing the application of AppLocker rules, as AppLocker can be configured to apply rules differently based on the user or group that initiated the process. By analyzing the TargetLogonId, administrators can troubleshoot why certain applications were allowed or blocked, ensuring that AppLocker rules are applied as intended across different user sessions.

Windows AppLocker Privilege Escalation via Unauthorized Bypass

This analytic uses Windows AppLocker event logs to identify attempts to bypass application restrictions, which could be indicative of an attacker attempting to escalate privileges. The analytic uses EventCodes 8007, 8004, 8022, 8025, 8029, and 8040 to identify these attempts. The analytic will identify the host, full file path, and target user associated with the bypass attempt. These EventCodes are related to block events and focus on five attempts or more.

`applocker` EventCode IN (8007, 8004, 8022, 8025, 8029, 8040)
| spath input=UserData_Xml
| rename RuleAndFileData.* as *
| lookup applockereventcodes EventCode OUTPUT Description
| stats count AS attempt_count by Computer, FullFilePath, TargetUser
| rename Computer as dest, TargetUser AS user
| where attempt_count > 5
| sort - attempt_count

^{(Windows AppLocker Logs in Splunk, Splunk 2024)}

Windows AppLocker Execution from Uncommon Locations

This analytic is designed to identify executions of applications or scripts from uncommon or suspicious file paths, which could be indicative of malware or unauthorized activity. By leveraging a simple statistical model, the query analyzes the frequency of application executions across different file paths. 

It calculates the average (avg) number of executions per file path and uses the standard deviation (stdev) to measure the variation or dispersion of the execution counts from the average. A file path is considered uncommon or suspicious if the number of executions from it is significantly higher than what is expected based on the calculated average and standard deviation. 

Specifically, the analytic flags any file path from which the number of executions exceeds the upper bound, defined as the average plus two times the standard deviation (avg+stdev*2). This approach helps in pinpointing anomalies in application execution patterns, potentially uncovering malicious activities or policy violations.

`applocker`   
| spath input=UserData_Xml
| rename RuleAndFileData.* as *, Computer as dest, TargetUser AS user  
| stats count by FullFilePath dest user  
| eventstats avg(count) as avg, stdev(count) as stdev  
| eval upperBound=(avg+stdev*2), anomaly=if(count > upperBound, "Yes", "No")  
| where anomaly="Yes"

^{(Windows AppLocker Logs in Splunk, Splunk 2024)}

Windows AppLocker Rare Application Launch Detection

This analytic is designed to detect the launch of applications that occur rarely within the environment, which could indicate the use of potentially malicious software or tools by attackers.

`applocker` 
| spath input=UserData_Xml
| rename RuleAndFileData.* as *, Computer as dest, TargetUser AS user 
| stats dc(_time) as days, count by FullFilePath dest user 
| eventstats avg(count) as avg, stdev(count) as stdev 
| eval upperBound=(avg+stdev*3), lowerBound=(avg-stdev*3) 
| where count > upperBound OR count < lowerBound

^{(Windows AppLocker Logs in Splunk, Splunk 2024)}

Windows AppLocker Block Events

This analytic uses Windows AppLocker event logs to generate risk based on blocks related to AppLocker policy violations. The analytic is designed to identify attempts to bypass application restrictions.

`applocker`  EventCode IN (8007, 8004, 8022, 8025, 8029, 8040)  
| spath input=UserData_Xml
| rename RuleAndFileData.* as *, TargetUser as user, Computer as dest  
| lookup applockereventcodes EventCode OUTPUT Description  
| stats count min(_time) as firstTime max(_time) as lastTime by dest, PolicyName, RuleId, user, TargetProcessId, FilePath, FullFilePath  
|`security_content_ctime(firstTime)`   
| `security_content_ctime(lastTime)`

^{(Windows AppLocker Logs in Splunk, Splunk 2024)}

Summary

In the second part of our AppLocker series, the Splunk Threat Research Team guides defenders through the process of using Splunk to collect, visualize, and analyze AppLocker events. By centralizing AppLocker logs in Splunk, organizations can gain valuable insights into their application security posture and make informed decisions to improve their AppLocker policies.

The blog provides step-by-step instructions on setting up AppLocker data logging in Splunk and introduces a comprehensive dashboard to visualize AppLocker events, allowing for easy filtering and granular analysis. It also explores the importance of AppLocker event IDs and provides several analytics to identify potential security issues, such as privilege escalation attempts and policy violations.

By the end of this blog, readers will have a clear understanding of how to effectively use Splunk in conjunction with AppLocker to enhance their organization's security and compliance. The Splunk Threat Research Team's guidance empowers IT and security professionals to take full advantage of AppLocker's capabilities and make data-driven decisions to protect their IT environment.

Learn More

Visit research.splunk.com to view the Splunk Threat Research Team's complete security content repository. You can implement this content using the Splunk ES Content Update app or the Splunk Security Essentials app.