Monitoring App Control for Business Audit Logs
👋 Introduction
In this article, we’ll dive into how to monitor and manage audit logs for App Control for Business policies in Microsoft Intune. App Control for Business is a handy tool that helps you lock down application security by deciding which apps can run on your managed Windows devices. By checking out audit logs, you can see how apps behave, spot any issues, and tweak your policies to fit your organization’s needs.
This guide walks you through everything—from finding and exporting logs to creating and automating App Control policies using audit data. Whether you’re just getting started with App Control or looking to fine-tune your setup, this article has you covered with practical tips and resources.
❓ What is App Control for Business?
To help prevent undesired apps from running on your managed Windows devices, you can use Microsoft Intune App Control for Business policies. Intune's App Control for Business policies are part of endpoint security and use the Windows ApplicationControl CSP to manage allowed apps on Windows devices.
TIP
You can find a Step-by-Step guide on how to implement App Control for Business in my article here.
🔍 How to Montior the Logs?
You can find the App Control Events for binary logs in the Event Viewer under:
Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational
and you can find the App Control Events for Script and MSI logs in the Event Viewer under:
Applications and Services Logs\Microsoft\Windows\AppLocker\MSI and Script
You can find a list of the relevant event IDs below.
Export with PowerShell
If you want to export the events using PowerShell, you can use a command like this:
# This command filters the event logs for specific criteria.
Get-WinEvent -FilterHashtable @{ LogName='*'; Id='3076'; ProviderName='Microsoft-Windows-CodeIntegrity' }Export with Intune
If you want to collect the events from your end users' computers, I have created a script that simplifies the process. This script can be deployed via Intune and automatically gathers all relevant events from the past 30 days. The collected logs are saved in the Intune Management Extensions log folder as XML.
You can run the script on your clients' computers by deploying it through Intune or executing it manually in an elevated PowerShell session.
For Intune deployment, follow these steps:
- Navigate to the Microsoft Intune admin center -> Devices -> Scripts and remediations -> Platform scripts.
- Click Add and select Windows 10 and later.
- Provide a Name and Description for the script.
- Upload the script file and configure the required settings.
- Assign the script to the desired groups and click Add to complete the deployment.
For manual execution, download the script from the GitHub repository and run it in an elevated PowerShell session on the target computer.
📝 Create an App Control for Business policy from these logs
IMPORTANT
It is recommended to use a standard base policy, such as the default Microsoft policy, to block most scenarios.
Then, create a supplemental policy to define specific exclusions or blocks tailored to your requirements.
- Files allowed by either the base policy or the supplemental policy will run.
If you plan to use two base policies, keep in mind that only applications allowed by both policies run without generating block events.
- Use the
New-CIPolicycmdlet to create a new App Control policy from your audit logs. In this example, we’re using the FilePublisher rule level with fallback options like SignedVersion, FilePublisher and Hash.
New-CIPolicy -FilePath "C:\temp\Policy.xml" -Audit -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormatNOTE
When creating policies from audit events, think carefully about the file rule level you choose to trust.
For more information about App Control rule levels, see Understand App Control policy rules and file rules | Microsoft Learn.
Automating creating App Control policies from logs
First, set up an audit App Control policy to start collecting events in your clients' event viewer.
Need help? Check out this guide: App Control for Business | michaelsendpoint.com.
Next, set up a KeyUser group in your environment. This group should include users who use all the apps, scripts, and resources your organization needs.
By focusing on this group, you can keep things simple and avoid creating too many unnecessary exclusions across all managed devices, which could happen if you included everyone.
Finally, use Intune to push out a script that runs for your key user group.
- You can use the following script or download it directly from my GitHub repository to push to your key users.
Be aware that the script needs an elevated powershell session.
IMPORTANT
Make sure to give the audit policy enough time to gather events before running this script.
If an app, script, or resource hasn’t been used, it won’t show up in the event logs, and no exclusion will be added to the policy.
Waiting around 30 to 60 days usually works well.
# Creating the audit policy in the Microsoft Intune Management Extension log folder.
# When running this command manually, it will print warnings for event logs that describe files that are no longer present on the system.
# There will be no exceptions added for files that are no longer on the system.
New-CIPolicy -FilePath "$($env:ProgramData)\Microsoft\IntuneManagementExtension\Logs\$($env:computername)_policy.xml" -Audit -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat
# Convert the newly created base policy into a supplemental policy to use it alongside the default Microsoft base policy.
Set-CIPolicyIdInfo -FilePath "$($env:ProgramData)\Microsoft\IntuneManagementExtension\Logs\$($env:computername)_policy.xml" -SupplementsBasePolicyID "{2DA0F72D-1688-4097-847D-C42C39E631BC}"INFO
Here are the IDs for the default Microsoft base policies.
You can activate these using Intune or group policy.
| Base policy ID | Explanation |
|---|---|
| {A8012CFC-D8AE-493C-B2EA-510F035F1250} | Enable app control policy to trust Windows components and Store apps. |
| {D6D6C2D6-E8B6-4D8F-8223-14BE1DE562FF} | Enable app control policy to trust Windows components and Store apps and Trust apps with good reputation. |
| {63D1178A-816A-4AB6-8ECD-127F2DF0CE47} | Enable app control policy to trust Windows components and Store apps and Trust apps from managed installers. |
| {2DA0F72D-1688-4097-847D-C42C39E631BC} | Enable app control policy to trust Windows components and Store apps and Trust apps with good reputation and Trust apps from managed installers. |
- Go to your key users' devices in Intune and click Collect diagnostics.
This will let you download a zip file from Intune containing the Intune Management Extension log folder ((67) FoldersFiles ProgramData_Microsoft_IntuneManagementExtension_Logs) along with the created policies.
If you're interested in learning more on how to manage multiple App Control policies, check out the following resources:
- Use multiple App Control for Business Policies | Microsoft Learn
- Merge App Control for Business policies | Microsoft Learn
🔢 App Control for Business Event IDs
AppLocker - MSI and Script Event IDs
App Control block events for packaged apps, MSI installers, scripts, and COM objects
| Event ID | Explanation |
|---|---|
| 8028 | Script host queried App Control about a file. The file ran in audit mode but would fail in enforced mode. |
| 8029 | Enforcement mode equivalent of 8028. Script may run with restrictions instead of being blocked. |
| 8036 | COM object was blocked. See Allow COM object registration. |
| 8037 | Script host allowed a script to run as it passed the App Control policy. |
| 8038 | Signing info for scripts, correlated with 8028/8029. Unsigned scripts generate TotalSignatureCount 0. |
| 8039 | Packaged app allowed to run in audit mode but would be blocked in enforced mode. |
| 8040 | Packaged app was blocked due to App Control policy. |
CodeIntegrity - Operational Event IDs
App Control block events for executables, dlls, and drivers
| Event ID | Explanation |
|---|---|
| 3004 | Kernel driver with invalid signature tried to load. |
| 3033 | File's signature is revoked or expired. Occurs with 3077. |
| 3034 | Audit mode equivalent of 3033. |
| 3076 | File would have been blocked in enforced mode. |
| 3077 | File was blocked as it didn't pass the policy. |
| 3089 | Signature info for files that were audit blocked. |
App Control policy activation events
| Event ID | Explanation |
|---|---|
| 3095 | Policy can't refresh; reboot required. |
| 3096 | Policy is up-to-date; no refresh needed. |
| 3097 | Policy refresh failed. |
| 3099 | Policy loaded successfully. |
| 3100 | Policy refresh failed; retry required. |
| 3101 | Policy refresh started. |
| 3102 | Policy refresh completed. |
| 3103 | Policy refresh ignored. |
| 3105 | System attempting to refresh the policy. |
Diagnostic events for Intelligent Security Graph (ISG) and Managed Installer (MI)
NOTE
When Managed Installer is enabled, customers using Log Analytics should note that it may generate a significant number of 3091 events. To manage Log Analytics costs effectively, consider filtering out these events.
The following events are super helpful for troubleshooting when your App Control policy uses Intelligent Security Graph (ISG) or Managed Installer (MI). They give you insights into why a file was allowed or blocked based on ISG or MI. Events 3090, 3091, and 3092 aren’t necessarily red flags but should be looked at alongside other events like 3076 or 3077 to get the full picture.
Depending on your Windows version, you’ll find these events in the CodeIntegrity - Operational or CodeIntegrity - Verbose event logs.
| Event ID | Explanation |
|---|---|
| 3090 | Optional This event indicates that a file was allowed to run based purely on ISG or managed installer |
| 3091 | This event indicates that a file didn't have ISG or managed installer authorization and the App Control policy is in audit mode |
| 3092 | This event is the enforcement mode equivalent of 3091 |
| 8002 | This event is found in the AppLocker - EXE and DLL event log. When a process launches that matches a managed installer rule, this event is raised with PolicyName = MANAGEDINSTALLER found in the event Details. Events with PolicyName = EXE or DLL aren't related to App Control |
Events 3090, 3091, and 3092 are reported per active policy on the system, so you may see multiple events for the same file.
ISG and MI diagnostic event details
The following information is found in the details for 3090, 3091, and 3092 events.
| Name | Explanation |
|---|---|
| ManagedInstallerEnabled | Indicates whether the specified policy enables managed installer trust |
| PassesManagedInstaller | Indicates whether the file originated from a MI |
| SmartlockerEnabled | Indicates whether the specified policy enables ISG trust |
| PassesSmartlocker | Indicates whether the file had positive reputation according to the ISG |
| AuditEnabled | True if the App Control policy is in audit mode, otherwise it is in enforce mode |
| PolicyName | The name of the App Control policy to which the event applies |
Enabling ISG and MI diagnostic events
To turn on 3090 allow events, just create a TestFlags registry key with a value of 0x300 using the PowerShell command below. After that, restart your computer to apply the changes.
reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x300Events 3091 and 3092 are inactive on some versions of Windows and are turned on by the preceding command.
Other Event IDs
| Event ID | Description |
|---|---|
| 3001 | An unsigned driver was attempted to load on the system |
| 3002 | Code Integrity couldn't verify the boot image as the page hash couldn't be found |
| 3004 | Code Integrity couldn't verify the file as the page hash couldn't be found |
| 3010 | The catalog containing the signature for the file under validation is invalid |
| 3011 | Code Integrity finished loading the signature catalog |
| 3012 | Code Integrity started loading the signature catalog |
| 3023 | The driver file under validation didn't meet the requirements to pass the App Control policy |
| 3024 | Windows App Control was unable to refresh the boot catalog file |
| 3026 | Microsoft or the certificate issuing authority revoked the certificate that signed the catalog |
| 3032 | The file under validation is revoked or the file has a signature that is revoked |
| 3033 | The file under validation didn't meet the requirements to pass the App Control policy |
| 3034 | The file under validation wouldn't meet the requirements to pass the App Control policy if it was enforced |
| 3036 | Microsoft or the certificate issuing authority revoked the certificate that signed the file being validated |
| 3064 | If the App Control policy was enforced, a user mode DLL under validation wouldn't meet the requirements to pass the App Control policy. The DLL was allowed since the policy is in audit mode |
| 3065 | If the App Control policy was enforced, a user mode DLL under validation wouldn't meet the requirements to pass the App Control policy |
| 3074 | Page hash failure while hypervisor-protected code integrity was enabled |
| 3075 | This event measures the performance of the App Control policy check during file validation |
| 3076 | This event is the main App Control block event for audit mode policies. It indicates that the file would have been blocked if the policy was enforced |
| 3077 | This event is the main App Control block event for enforced policies. It indicates that the file didn't pass your policy and was blocked |
| 3079 | The file under validation didn't meet the requirements to pass the App Control policy |
| 3080 | If the App Control policy was enforced, the file under validation wouldn't have met the requirements to pass the App Control policy |
| 3081 | The file under validation didn't meet the requirements to pass the App Control policy |
| 3082 | If the App Control policy was enforced, the policy would have blocked this non-WHQL driver |
| 3084 | Code Integrity is enforcing WHQL driver signing requirements on this boot session |
| 3085 | Code Integrity isn't enforcing WHQL driver signing requirements on this boot session |
| 3086 | The file under validation doesn't meet the signing requirements for an isolated user mode (IUM) process |
| 3089 | This event contains signature information for files that were blocked or audit blocked by App Control. One 3089 event is created for each signature of a file |
| 3090 | Optional This event indicates that a file was allowed to run based purely on ISG or managed installer |
| 3091 | This event indicates that a file didn't have ISG or managed installer authorization and the App Control policy is in audit mode |
| 3092 | This event is the enforcement mode equivalent of 3091 |
| 3095 | The App Control policy can't be refreshed and must be rebooted instead |
| 3096 | The App Control policy wasn't refreshed since it's already up-to-date |
| 3097 | The App Control policy can't be refreshed |
| 3099 | Indicates that a policy has been loaded. This event also includes information about the options set by the App Control policy |
| 3100 | The App Control policy was refreshed but was unsuccessfully activated. Retry |
| 3101 | The system started refreshing the App Control policy |
| 3102 | The system finished refreshing the App Control policy |
| 3103 | The system is ignoring the App Control policy refresh |
| 3104 | The file under validation doesn't meet the signing requirements for a PPL (protected process light) process |
| 3105 | The system is attempting to refresh the App Control policy |
| 3108 | Windows mode change event was successful |
| 3110 | Windows mode change event was unsuccessful |
| 3111 | The file under validation didn't meet the hypervisor-protected code integrity (HVCI) policy |
| 3112 | Windows has revoked the certificate that signed the file being validated |
| 3114 | Dynamic Code Security opted the .NET app or DLL into App Control policy validation. The file under validation didn't pass your policy and was blocked |