deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-16 19:03:46 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

WDAC --> App Control for Business

Browse Source
This commit is contained in:
Vinay Pamnani (from Dev Box)
2024-09-10 15:51:10 -06:00
parent c0d05ec056
commit b3aebafb79
215 changed files with 2855 additions and 2171 deletions
Download Patch File Download Diff File Expand all files Collapse all files

258
windows/security/application-security/application-control/app-control-for-business/operations/appcontrol-debugging-and-troubleshooting.md Normal file
View File

@ -0,0 +1,258 @@
---
title: WDAC debugging and troubleshooting guide
description: Learn how to debug and troubleshoot app and script failures when using WDAC
ms.topic: how-to
ms.date: 04/06/2023
---
# WDAC debugging and troubleshooting
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This article describes how to debug and troubleshoot app and script failures when using Windows Defender Application Control (WDAC).
## 1 - Gather WDAC diagnostic data
Before debugging and troubleshooting WDAC issues, you must collect information from a device exhibiting the problem behavior.
Run the following commands from an elevated PowerShell window to collect the diagnostic information you may need:
1. Gather general WDAC diagnostic data and copy it to %userprofile%\AppData\Local\Temp\DiagOutputDir\CiDiag:
```powershell
cidiag.exe /stop
```
If CiDiag.exe isn't present in your version of Windows, gather this information manually:
- WDAC policy binaries from the [Windows and EFI system partitions](known-issues.md#wdac-policy-file-locations)
- [WDAC event logs](#core-wdac-event-logs)
- [AppLocker event logs](#core-wdac-event-logs)
- [Other event logs that may contain useful information](#other-windows-event-logs-that-may-be-useful) from other Windows apps and services
2. Save the device's System Information to the CiDiag folder:
```powershell
msinfo32.exe /report $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\SystemInformation.txt
```
3. Use [CiTool.exe](citool-commands.md) to inventory the list of WDAC policies on the device. Skip this step if CiTool.exe isn't present in your version of Windows.
```powershell
citool.exe -lp -json > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\CiToolOutput.json
````
4. Export AppLocker registry key data to the CiDiag folder:
```powershell
reg.exe query HKLM\Software\Policies\Microsoft\Windows\SrpV2 /s > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerRegistry.txt; reg.exe query HKLM\Software\Policies\Microsoft\Windows\AppidPlugins /s >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerRegistry.txt; reg.exe query HKLM\System\CurrentControlSet\Control\Srp\ /s >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerRegistry.txt
```
> [!NOTE]
> You may see an error that the system was unable to find the specified registry key or value. This error doesn't indicate a problem and can be ignored.
5. Copy any AppLocker policy files from %windir%System32\AppLocker to the CiDiag folder:
```powershell
Copy-Item -Path $env:windir\System32\AppLocker -Destination $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\ -Recurse -Force -ErrorAction Ignore
```
6. Collect file information for the AppLocker policy files collected in the previous step:
```powershell
Get-ChildItem -Path $env:windir\System32\AppLocker\ -Recurse | select Mode,LastWriteTime,CreationTime,Length,Name >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerPolicyFiles.txt
```
7. Export the effective AppLocker policy:
```powershell
Get-AppLockerPolicy -xml -Effective > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xml
```
8. Collect AppLocker services configuration and state information:
```powershell
sc.exe query appid > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt; sc.exe query appidsvc >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt; sc.exe query applockerfltr >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt
```
### Core WDAC event logs
WDAC events are generated under two locations:
- Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational
- Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script
Within the CiDiag output directory, these event logs are called CIOperational.evtx and ALMsiAndScript.evtx, respectively.
### Other Windows event logs that may be useful
Sometimes, you may be able to supplement the information contained in the core WDAC event logs with information found in these other event logs. CIDiag.exe doesn't collect the ones shown in *italics*.
- Applications and Services logs - Microsoft - Windows - CodeIntegrity - Verbose
- Applications and Services logs - Microsoft - Windows - AppLocker - EXE and DLL
- Applications and Services logs - Microsoft - Windows - AppLocker - Packaged app-Deployment
- Applications and Services logs - Microsoft - Windows - AppLocker - Packaged app-Execution
- Applications and Services logs - Microsoft - Windows - AppID - Operational
- Applications and Services logs - Microsoft - Windows - CAPI2 - Operational
- Applications and Services logs - Microsoft - Windows - DeviceGuard - Operational
- *Applications and Services logs - Microsoft - Windows - PowerShell - \**
- *Windows - Application*
- *Windows - System*
## 2 - Use the diagnostic and log data to identify problems
Having gathered the necessary diagnostic information from a device, you're ready to begin your analysis of the diagnostic data collected in the previous section.
1. Verify the set of WDAC policies that are active and enforced. Confirm that only those policies you expect to be active are currently active. Be aware of the [Windows inbox policies](inbox-appcontrol-policies.md) that may also be active. You can use either of these methods:
- Review the output from *CiTool.exe -lp*, if applicable, which was saved to the CIDiag output directory as CiToolOutput.json. See [use Microsoft Edge to view the formatted json file](/microsoft-edge/devtools-guide-chromium/json-viewer/json-viewer).
- Review all [policy activation events](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations#wdac-policy-activation-events) from the core WDAC event log found at **Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational**. Within the CIDiag output directory, this event log is called CIOperational.evtx.
2. Review any [block events for executables, dlls, and drivers](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations#wdac-block-events-for-executables-dlls-and-drivers) from the core WDAC event log found at **Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational**. Within the CIDiag output directory, this event log is called CIOperational.evtx. Use information from the block events and their correlated 3089 signature details event(s) to investigate any blocks that are unexplained or unexpected. See the blocked executable example described later in this article for reference.
3. Review any [block events for packaged apps, MSI installers, scripts, and COM objects](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations#wdac-block-events-for-packaged-apps-msi-installers-scripts-and-com-objects) from the core script enforcement event log found at **Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script**. Within the CIDiag output directory, this event log is called ALMsiAndScript.evtx. Use information from the block events and their correlated 8038 signature details event(s) to investigate any blocks that are unexplained or unexpected.
Most WDAC-related issues, including app and script failures, can be diagnosed using the preceding steps.
### Event analysis for an example blocked executable
Here's an example of detailed EventData from a typical WDAC enforcement mode block event 3077, and one of its correlated 3089 signature information events. The tables that follow each event screenshot describe some of the elements contained in the events. Following the event descriptions is a step-by-step walkthrough explaining how to use the events to understand why the block occurred.
#### Event 3077 - WDAC enforcement block event
![Example 3077 block event for PowerShell.exe.](../images/event-3077.png)
| Element name | Description |
| ----- | ----- |
| System - Correlation - \[ActivityID\] | **Not shown in screenshot** <br> Use the correlation ActivityID to match a WDAC block event with one or more 3089 signature events. |
| File Name | The file's path and name on disk that was blocked from running. Since the name on disk is mutable, this value **isn't** the one used when creating WDAC file rules with `-Level FileName`. Instead, see the OriginalFileName element later in this table. |
| Process Name | The path and name of the file that attempted to run the blocked file. Also called the parent process. |
| Requested Signing Level | The Windows signing authorization level the code needed to pass in order to run. See [Requested and validated signing level](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#requested-and-validated-signing-level). |
| Validated Signing Level | The Windows signing authorization level the code was given. See [Requested and validated signing level](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#requested-and-validated-signing-level). |
| Status | Windows NT status code. You can use `certutil.exe -error <status>` to look up the meaning of the status code. |
| SHA1 Hash | The SHA1 Authenticode hash for the blocked file. |
| SHA256 Hash | The SHA256 Authenticode hash for the blocked file. |
| SHA1 Flat Hash | The SHA1 flat file hash for the blocked file. |
| SHA256 Flat Hash | The SHA256 flat file hash for the blocked file. |
| PolicyName | The friendly name of the WDAC policy that caused the block event. A separate 3077 block event (or 3076 audit block event) is shown for each policy that blocks the file from running. |
| PolicyId | The friendly ID value of the WDAC policy that caused the block event. |
| PolicyHash | The SHA256 Authenticode hash of the WDAC policy binary that caused the block event. |
| OriginalFileName | The immutable file name set by the developer in the blocked file's resource header. This value is the one used when creating WDAC file rules with `-Level FileName`. |
| InternalName | Another immutable value set by the developer in the blocked file's resource header. You can substitute this value for the OriginalFileName in file rules with `-Level FileName -SpecificFileNameLevel InternalName`. |
| FileDescription | Another immutable value set by the developer in the blocked file's resource header. You can substitute this value for the OriginalFileName in file rules with `-Level FileName -SpecificFileNameLevel FileDescription`. |
| ProductName | Another immutable value set by the developer in the blocked file's resource header. You can substitute this value for the OriginalFileName in file rules with `-Level FileName -SpecificFileNameLevel ProductName`. |
| FileVersion | The policy's VersionEx value used to enforce version control over signed policies. |
| PolicyGUID | The PolicyId of the WDAC policy that caused the block event. |
| UserWriteable | A boolean value indicating if the file was in a user-writeable location. This information is useful for diagnosing issues when allowing by FilePath rules. |
| PackageFamilyName | The Package Family Name for the packaged app (MSIX) that includes the blocked file. |
#### Event 3089 - WDAC signature information event
![Example 3089 signature information event for PowerShell.exe.](../images/event-3089.png)
| Element name | Description |
| ----- | ----- |
| System - Correlation - \[ActivityID\] | Use the correlation ActivityID to match a WDAC signature event with its block event. |
| TotalSignatureCount | The total number of signatures detected for the blocked file. |
| Signature | The index count, starting at 0, of the current signature shown in this 3089 event. If the file had multiple signatures, you'll find other 3089 events for the other signatures. |
| Hash | The hash value that WDAC used to match the file. This value should match one of the four hashes shown on the 3077 or 3076 block event. If no signatures were found for the file (TotalSignatureCount = 0), then only the hash value is shown. |
| SignatureType | The [type of signature](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#signaturetype). |
| ValidatedSigningLevel | The Windows signing authorization level the signature met. See [Requested and validated signing level](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#requested-and-validated-signing-level). |
| VerificationError | The reason this particular signature failed to pass the WDAC policy. See [VerificationError](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations#verificationerror). |
| PublisherName | The common name (CN) value from the leaf certificate. |
| IssuerName | The CN value from the highest available certificate in the certificate chain. This level is typically one certificate below the root. |
| PublisherTBSHash | The TBS hash of the leaf certificate. |
| IssuerTBSHash | The TBS hash of the highest available certificate in the certificate chain. This level is typically one certificate below the root. |
#### Step-by-step walkthrough of the example 3077 and 3089 events
Now let's walk through how to use the event data in the example 3077 and 3089 events to understand why the WDAC policy blocked this file.
##### Understand what file is being blocked and the block context
Referring to the 3077 event, locate the information that identifies the policy, the file being blocked, and the parent process that tried to run it. Consider this context information to determine whether the block is expected and wanted.
In the example, the file being blocked is PowerShell.exe, which is part of Windows and would normally be expected to run. However, in this case, the policy was based off of the Windows in S mode policy template, which doesn't allow script hosts to run as a way to limit the attack surface. For S mode, this block event is a success. But let's assume the policy author was unaware of that constraint when they chose the template, and treat this block as unexpected.
##### Determine why WDAC rejected the file
Again referring to the 3077 event, we see the Requested Signing Level of 2 means the code must pass the WDAC policy. But the Validated Signing Level of 1 means the code was treated as though unsigned. "Unsigned" could mean the file was truly unsigned, signed but with an invalid certificate, or signed but without any certificates allowed by the WDAC policy.
Now, let's inspect the correlated 3089 event(s) for the blocked file. In the example, we're looking at only the first signature (Signature index 0) found on a file that had multiple signatures. For this signature, the ValidatedSigningLevel is 12, meaning it has a Microsoft Windows product signature. The VerificationError of 21 means that the signature didn't pass the WDAC policy.
It's important to review the information for each correlated 3089 event as each signature may have a different ValidatedSigningLevel and VerificationError.
> [!IMPORTANT]
> Notice how the Validated Signing Level on the 3077 event is interpreted very differently from the ValidatedSigningLevel on the 3089 event.
>
> In the case of the 3077 event, Validated Signing Level tells us how the binary was actually treated by Windows.
>
> In the case of the 3089 event, on the other hand, ValidatedSigningLevel tells us the potential **maximum** level the signature could receive. We must use the VerificationError to understand why the signature was rejected.
## 3 - Resolve common problems
Having analyzed the WDAC diagnostic data, you can take steps to resolve the issue or do more debugging steps. Following are some common problems and steps you can try to resolve or further isolate the root issue:
### Issue: A file was blocked that you want to allow
- Use data from the core WDAC event logs to add rules to allow the blocked file.
- Redeploy the file or app using a managed installer if your policy trusts managed installers.
### Issue: A policy is active that is unexpected
This condition may exist if:
- A policy was removed but the system hasn't been rebooted.
- A policy was partially removed, but a copy of the policy still exists in either the System or EFI partition.
- A policy with PolicyId {A244370E-44C9-4C06-B551-F6016E563076} (single-policy format) was copied to the multiple-policy format policy location before activation, resulting in a duplicate policy binary on disk. Check for both SiPolicy.p7b and \{A244370E-44C9-4C06-B551-F6016E563076\}.cip files in the System and EFI partitions.
- A policy was incorrectly deployed to the device.
- An attacker with administrator access has applied a policy to cause denial of service for some critical processes.
To resolve such an issue, follow the instructions to [Remove WDAC policies](/windows/security/threat-protection/windows-defender-application-control/disable-windows-defender-application-control-policies) for the identified policy.
### Issue: An unhandled app failure is occurring and no WDAC events are observed
Some apps alter their behavior when a user mode WDAC policy is active, which can result in unexpected failures. It can also be a side-effect of script enforcement for apps that don't properly handle the enforcement behaviors implemented by the script hosts.
Try to isolate the root cause by doing the following actions:
- Check the other event logs listed in section 1 of this article for events corresponding with the unexpected app failures.
- Temporarily replace the WDAC policy with another policy that [disables script enforcement](/windows/security/threat-protection/windows-defender-application-control/design/script-enforcement) and retest.
- Temporarily replace the WDAC policy with another policy that [allows all COM objects](/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy) and retest.
- Temporarily replace the WDAC policy with another policy that relaxes other [policy rules](/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create#windows-defender-application-control-policy-rules) and retest.
### Issue: An app deployed by a managed installer isn't working
To debug issues using managed installer, try these steps:
- Check that the WDAC policy that is blocking the app includes the option to enable managed installer.
- Check that the effective AppLocker policy $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xml is correct as described in [Automatically allow apps deployed by a managed installer](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer#create-and-deploy-an-applocker-policy-that-defines-your-managed-installer-rules-and-enables-services-enforcement-for-executables-and-dlls).
- Check that the AppLocker services are running. This information is found in $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt created in section 1 of this article.
- Check that an AppLocker file exists called MANAGEDINSTALLER.APPLOCKER exists in the CiDiag folder created earlier. If not, repeat the steps to deploy and enable the managed installer AppLocker configuration.
- Restart the managed installer process and check that an 8002 event is observed in the **AppLocker - EXE and DLL** event log for the managed installer process with PolicyName = MANAGEDINSTALLER. If instead you see an event with 8003 or 8004 with PolicyName = MANAGEDINSTALLER, then check the ManagedInstaller rules in the AppLocker policy XML and ensure a rule matches the managed installer process.
- [Use fsutil.exe](/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer#using-fsutil-to-query-extended-attributes-for-managed-installer-mi) to verify files written by the managed installer process have the managed installer origin extended attribute. If not, redeploy the files with the managed installer and check again.
- Test installation of a different app using the managed installer.
- Add another managed installer to your AppLocker policy and test installation using the other managed installer.
- Check if the app is encountering a [known limitation with managed installer](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer#known-limitations-with-managed-installer). If so, you must authorize the app using other means.
### Issue: An app you expected the Intelligent Security Graph (ISG) to allow isn't working
To debug issues using ISG, try these steps:
- Check that the WDAC policy that is blocking the app includes the option to enable the intelligent security graph.
- Check that the AppLocker services are running. This information is found in $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt created in section 1 of this article.
- [Use fsutil.exe](/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer#using-fsutil-to-query-extended-attributes-for-intelligent-security-graph-isg) to verify files have the ISG origin extended attribute. If not, redeploy the files with the managed installer and check again.
- Check if the app is encountering a [known limitation with ISG](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph#known-limitations-with-using-the-isg).
## 4 - Report issues to Microsoft, if appropriate
If after following the guidance covered by this article you believe you've identified a product issue, report the issue to Microsoft.
- Customers with Microsoft Premier Support should log a service request through normal channels.
- All other customers can report issues directly to the WDAC product team via the Windows [Feedback Hub](feedback-hub:?contextid=790&tabid=2&newFeedback=true). Select the category **Security & Privacy - Application Control** to ensure the issue is properly routed to the WDAC product team.
When reporting issues, be sure to provide the following information:
- All [WDAC diagnostic data](#1---gather-wdac-diagnostic-data) described earlier.
- If possible, the blocked file(s).
- Clear instructions to reproduce the problem.

27
windows/security/application-security/application-control/app-control-for-business/operations/appcontrol-operational-guide.md Normal file
View File

@ -0,0 +1,27 @@
---
title: Managing and troubleshooting Windows Defender Application Control policies
description: Gather information about how your deployed Windows Defender Application Control policies are behaving.
ms.localizationpriority: medium
ms.date: 03/30/2023
ms.topic: how-to
---
# Windows Defender Application Control operational guide
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
You now understand how to design and deploy your Windows Defender Application Control (WDAC) policies. This guide explains how to understand the effects your policies have and how to troubleshoot when they aren't behaving as expected. It contains information on where to find events and what they mean, and also querying these events with Microsoft Defender for Endpoint Advanced Hunting feature.
## In this section
| Article | Description |
| - | - |
| [Debugging and troubleshooting](/windows/security/threat-protection/windows-defender-application-control/operations/wdac-debugging-and-troubleshooting) | This article explains how to debug app and script failures with WDAC. |
| [Understanding Application Control event IDs](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations) | This article explains the meaning of different WDAC event IDs. |
| [Understanding Application Control event tags](/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations) | This article explains the meaning of different WDAC event tags. |
| [Query WDAC events with Advanced hunting](/windows/security/threat-protection/windows-defender-application-control/querying-application-control-events-centrally-using-advanced-hunting) | This article covers how to view WDAC events centrally from all systems that are connected to Microsoft Defender for Endpoint. |
| [Admin Tips & Known Issues](/windows/security/threat-protection/windows-defender-application-control/operations/known-issues) | This article describes some WDAC Admin Tips & Known Issues. |
| [Managed installer and ISG technical reference and troubleshooting guide](/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer) | This article provides technical details and debugging steps for managed installer and ISG. |
| [CITool.exe technical reference](/windows/security/threat-protection/windows-defender-application-control/operations/citool-commands) | This article explains how to use CITool.exe. |
| [Inbox WDAC policies](/windows/security/threat-protection/windows-defender-application-control/operations/inbox-wdac-policies) | This article describes the WDAC policies that ship with Windows and when they're active. |

134
windows/security/application-security/application-control/app-control-for-business/operations/citool-commands.md Normal file
View File

@ -0,0 +1,134 @@
---
title: Managing CI policies and tokens with CiTool
description: Learn how to use policy commands, token commands, and miscellaneous commands in CiTool
ms.topic: reference
ms.date: 10/02/2023
appliesto:
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 11</a>
---
# CiTool technical reference
CiTool makes Windows Defender Application Control (WDAC) policy management easier for IT admins. You can use this tool to manage Windows Defender Application Control policies and CI tokens. This article describes how to use CiTool to update and manage policies. It's currently included as part of the Windows image in Windows 11, version 22H2.
## Policy commands
| Command | Description | Alias |
|--------|---------|---------|
| `--update-policy </Path/To/Policy/File>` | Add or update a policy on the current system. | `-up` |
| `--remove-policy <PolicyGUID>` | Remove a policy indicated by PolicyGUID from the system. | `-rp` |
| `--list-policies` | Dump information about all policies on the system, whether they're active or not. | `-lp` |
## Token commands
| Command | Description | Alias |
|--------|---------|---------|
| `--add-token <Path/To/Token/File> <--token-id ID>` | Deploy a token onto the current system, with an optional specific ID. | `-at` |
| `--remove-token <ID>` | Remove a token indicated by ID from the system. | `-rt` |
| `--list-tokens` | Dump information about all tokens on the system. | `-lt` |
> [!NOTE]
> Regarding `--add-token`, if `<ID>` is specified, a pre-existing token with `<ID>` shouldn't exist.
## Miscellaneous commands
| Command | Description | Alias |
|--------|---------|---------|
| `--device-id` | Dump the code integrity device ID. | `-id` |
| `--refresh` | Attempt to refresh WDAC policies. | `-r` |
| `--help` | Display the tool's help menu. | `-h` |
## Output attributes and descriptions
### List policies (`--list-policies`)
```output
Policy ID: d2bda982-ccf6-4344-ac5b-0b44427b6816
Base Policy ID: d2bda982-ccf6-4344-ac5b-0b44427b6816
Friendly Name: Microsoft Windows Driver Policy
Version: 2814751463178240
Platform Policy: true
Policy is Signed: true
Has File on Disk: false
Is Currently Enforced: true
Is Authorized: true
Status: 0
```
| Attribute | Description | Example value |
|--------|---------|---------|
| Policy ID | Lists the ID of the policy. | `d2bda982-ccf6-4344-ac5b-0b44427b6816` |
| Base Policy ID | Lists the ID of the base policy. | `d2bda982-ccf6-4344-ac5b-0b44427b6816` |
| Friendly Name | Value listed in `<Setting Provider="PolicyInfo" Key="Information" ValueName="Name">` | `Microsoft Windows Driver Policy` |
| Version | Version of the policy listed in `<VersionEx>` | `2814751463178240` |
| Platform Policy | Indicates whether the policy is provided by Microsoft, for example in the vulnerable driver blocklist policy. | `true` |
| Policy is Signed | Indicates whether the policy has a valid signature. | `true` |
| Has File on Disk | Indicates whether the policy file is currently on the disk. | `false` |
| Is Currently Enforced | Indicates whether the policy file is active. | `true` |
| Is Authorized | If the policy requires a token to be activated, this value is the state of authorization for the token. If the policy doesn't require a token, this value matches the value for the **Is Currently Enforced** property. | `true` |
## Examples
### Deploy a WDAC policy
```powershell
CiTool --update-policy "\Windows\Temp\{BF61FE40-8929-4FDF-9EC2-F7A767717F0B}.cip"
```
### Refresh the WDAC policies on the system
```powershell
CiTool --refresh
```
### Remove a specific WDAC policy by its policy ID
```powershell
CiTool --remove-policy "{BF61FE40-8929-4FDF-9EC2-F7A767717F0B}"
```
### List the actively enforced WDAC policies on the system
```powershell
# Check each policy's IsEnforced state and return only the enforced policies
(CiTool -lp -json | ConvertFrom-Json).Policies | Where-Object {$_.IsEnforced -eq "True"} |
Select-Object -Property PolicyID,FriendlyName | Format-List
```
### Display the help menu
```powershell
CiTool -h
----------------------------- Policy Commands ---------------------------------
--update-policy /Path/To/Policy/File
Add or update a policy on the current system
aliases: -up
--remove-policy PolicyGUID
Remove a policy indicated by PolicyGUID from the system
aliases: -rp
--list-policies
Dump information about all policies on the system, whether they be active or not
aliases: -lp
----------------------------- Token Commands ---------------------------------
--add-token Path/To/Token/File <--token-id ID>
Deploy a token onto the current system, with an optional specific ID
If <ID> is specified, a pre-existing token with <ID> should not exist.
aliases:-at
--remove-token ID
Remove a Token indicated by ID from the system.
aliases: -rt
--list-tokens
Dump information about all tokens on the system
aliases: -lt
----------------------------- Misc Commands ---------------------------------
--device-id
Dump the Code Integrity Device Id
aliases: -id
--refresh
Attempt to Refresh CI Policies
aliases: -r
--help
Display this message
aliases: -h
```

101
windows/security/application-security/application-control/app-control-for-business/operations/configure-appcontrol-managed-installer.md Normal file
View File

@ -0,0 +1,101 @@
---
title: Managed installer and ISG technical reference and troubleshooting guide
description: A technical reference and troubleshooting guide for managed installer and Intelligent Security Graph (ISG).
ms.localizationpriority: medium
ms.date: 11/11/2022
ms.topic: troubleshooting
---
# Managed installer and ISG technical reference and troubleshooting guide
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](../feature-availability.md).
## Enabling managed installer and Intelligent Security Graph (ISG) logging events
Refer to [Understanding Application Control Events](event-id-explanations.md#diagnostic-events-for-intelligent-security-graph-isg-and-managed-installer-mi) for information on enabling optional managed installer diagnostic events.
## Using fsutil to query extended attributes for Managed Installer (MI)
Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) enabled can use fsutil.exe to determine whether a file was created by a managed installer process. This verification is done by querying the Extended Attributes (EAs) on a file using fsutil.exe and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. Then, you can use the data from the first row of output to identify if the file was created by a managed installer. For example, let's look at the fsutil.exe output for a file called application.exe:
**Example:**
```powershell
fsutil.exe file queryEA C:\Users\Temp\Downloads\application.exe
Extended Attributes (EA) information for file C:\Users\Temp\Downloads\application.exe:
Ea Buffer Offset: 410
Ea Name: $KERNEL.SMARTLOCKER.ORIGINCLAIM
Ea Value Length: 7e
0000: 01 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 ................
0010: b2 ff 10 66 bc a8 47 c7 00 d9 56 9d 3d d4 20 2a ...f..G...V.=. *
0020: 63 a3 80 e2 d8 33 8e 77 e9 5c 8d b0 d5 a7 a3 11 c....3.w.\......
0030: 83 00 00 00 00 00 00 00 5c 00 00 00 43 00 3a 00 ........\...C.:.
0040: 5c 00 55 00 73 00 65 00 72 00 73 00 5c 00 6a 00 \.U.s.e.r.s.\.T.
0050: 6f 00 67 00 65 00 75 00 72 00 74 00 65 00 2e 00 e.m.p..\D.o.w.n...
0060: 52 00 45 00 44 00 4d 00 4f 00 4e 00 44 00 5c 00 l.o.a.d.\a.p.p.l.
0070: 44 00 6f 00 77 00 6e 00 6c 00 6f 00 61 00 64 i.c.a.t.i.o.n..e.x.e
```
From the output shown above, find the first row of data labeled "0000:", which is then followed by 16 two-character sets. Every four sets form a group known as a ULONG. The two-character set at the front of the first ULONG will always be "01" as shown here:
0000: **`01` 00 00 00** 00 00 00 00 00 00 00 00 01 00 00 00
If there is "00" in the fifth position of the output (the start of the second ULONG), that indicates the EA is related to managed installer:
0000: 01 00 00 00 **`00` 00 00 00** 00 00 00 00 01 00 00 00
Finally, the two-character set in the ninth position of the output (the start of the third ULONG) indicates whether the file was created by a process running as managed installer. A value of "00" means the file was directly written by a managed installer process and will run if your WDAC policy trusts managed installers.
0000: 01 00 00 00 00 00 00 00 **`00` 00 00 00** 01 00 00 00
If instead the starting value for the third ULONG is "02", then that indicates a "child of child". "Child of child" is set on any files created by something that was installed by a managed installer. But, the file was created **after** the managed installer completed its work. So this file **wouldn't** be allowed to run unless there's some other rule in your policy to allow it.
In rarer cases, you may see other values in this position, but that will also run if your policy trusts managed installer.
## Using fsutil to query extended attributes for Intelligent Security Graph (ISG)
When an installer runs that has good reputation according to the ISG, the files that the installer writes to disk will inherit the reputation from the installer. These files with ISG inherited trust will also have the KERNEL.SMARTLOCKER.ORIGINCLAIM EA set as described above for managed installers. You can identify that the EA was created by the ISG by looking for the value "01" in the fifth position of the output (the start of the second ULONG) from fsutil:
0000: 01 00 00 00 **`01` 00 00 00** 00 00 00 00 01 00 00 00
## More troubleshooting steps for Managed Installer and ISG
Both managed installer and the ISG depend on AppLocker to provide some functionality. Use the following steps to confirm that AppLocker is configured and running correctly.
1. Check that AppLocker services are running. From an elevated PowerShell window, run the following and confirm the STATE shows as RUNNING for both appidsvc and AppLockerFltr:
```powershell
sc.exe query appidsvc
SERVICE_NAME: appidsvc
TYPE : 30 WIN32
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
sc.exe query AppLockerFltr
SERVICE_NAME: applockerfltr
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
```
If not, run *appidtel start* from the elevated PowerShell window and check again.
2. For managed installer, check for AppCache.dat and other *.AppLocker files created under %windir%\System32\AppLocker. There should minimally be a ".AppLocker" file created for each of EXE, DLL, and MANAGEDINSTALLER rule collections. If you don't see these files created, proceed to the next step to confirm the AppLocker policy has been correctly applied.
3. For managed installer troubleshooting, check that the AppLocker effective policy is correct. From an elevated PowerShell window:
```powershell
Get-AppLockerPolicy -Effective -XML > $env:USERPROFILE\Desktop\AppLocker.xml
```
Then open the XML file created and confirm it contains the rules you expect. In particular, the policy should include at least one rule for each of the EXE, DLL, and MANAGEDINSTALLER RuleCollections. The RuleCollections can either be set to AuditOnly or Enabled. Additionally, the EXE and DLL RuleCollections must include the RuleCollectionExtensions configuration as shown in [Automatically allow apps deployed by a managed installer with Windows Defender Application Control](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer#create-and-deploy-an-applocker-policy-that-defines-your-managed-installer-rules-and-enables-services-enforcement-for-executables-and-dlls).

161
windows/security/application-security/application-control/app-control-for-business/operations/event-id-explanations.md Normal file
View File

@ -0,0 +1,161 @@
---
title: Understanding Application Control event IDs
description: Learn what different Windows Defender Application Control event IDs signify.
ms.localizationpriority: medium
ms.date: 03/24/2023
ms.topic: reference
---
# Understanding Application Control events
## WDAC Events Overview
WDAC logs events when a policy is loaded, when a file is blocked, or when a file would be blocked if in audit mode. These block events include information that identifies the policy and gives more details about the block. WDAC doesn't generate events when a binary is allowed. However, you can turn on allow audit events for files authorized by a managed installer or the Intelligent Security Graph (ISG) as described later in this article.
### Core WDAC event logs
WDAC events are generated under two locations in the Windows Event Viewer:
- **Applications and Services logs - Microsoft - Windows - CodeIntegrity - Operational** includes events about Application Control policy activation and the control of executables, dlls, and drivers.
- **Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script** includes events about the control of MSI installers, scripts, and COM objects.
Most app and script failures that occur when WDAC is active can be diagnosed using these two event logs. This article describes in greater detail the events that exist in these logs. To understand the meaning of different data elements, or tags, found in the details of these events, see [Understanding Application Control event tags](event-tag-explanations.md).
> [!NOTE]
> **Applications and Services logs - Microsoft - Windows - AppLocker - MSI and Script** events are not included on Windows Server Core edition.
## WDAC block events for executables, dlls, and drivers
These events are found in the **CodeIntegrity - Operational** event log.
| Event ID | Explanation |
|--------|-----------|
| 3004 | This event isn't common and may occur with or without an Application Control policy present. It typically indicates a kernel driver tried to load with an invalid signature. For example, the file may not be WHQL-signed on a system where WHQL is required. <br><br> This event is also seen for kernel- or user-mode code that the developer opted-in to [/INTEGRITYCHECK](/cpp/build/reference/integritycheck-require-signature-check) but isn't signed correctly. |
| 3033 | This event may occur with or without an Application Control policy present and should occur alongside a 3077 event if caused by WDAC policy. It often means the file's signature is revoked or a signature with the Lifetime Signing EKU has expired. Presence of the Lifetime Signing EKU is the only case where WDAC blocks files due to an expired signature. Try using option `20 Enabled:Revoked Expired As Unsigned` in your policy along with a rule (for example, hash) that doesn't rely on the revoked or expired cert. <br><br> This event also occurs if code compiled with [Code Integrity Guard (CIG)](/microsoft-365/security/defender-endpoint/exploit-protection-reference#code-integrity-guard) tries to load other code that doesn't meet the CIG requirements. |
| 3034 | This event isn't common. It's the audit mode equivalent of event 3033. |
| 3076 | This event is the main Application 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 Application Control block event for enforced policies. It indicates that the file didn't pass your policy and was blocked. |
| 3089 | This event contains signature information for files that were blocked or audit blocked by Application Control. One of these events is created for each signature of a file. Each event shows the total number of signatures found and an index value to identify the current signature. Unsigned files generate a single one of these events with TotalSignatureCount of 0. These events are correlated with 3004, 3033, 3034, 3076 and 3077 events. You can match the events using the `Correlation ActivityID` found in the **System** portion of the event. |
## WDAC block events for packaged apps, MSI installers, scripts, and COM objects
These events are found in the **AppLocker - MSI and Script** event log.
| Event ID | Explanation |
|--------|-----------|
| 8028 | This event indicates that a script host, such as PowerShell, queried Application Control about a file the script host was about to run. Since the policy was in audit mode, the script or MSI file should have run, but wouldn't have passed the WDAC policy if it was enforced. Some script hosts may have additional information in their logs. Note: Most third-party script hosts don't integrate with Application Control. Consider the risks from unverified scripts when choosing which script hosts you allow to run. |
| 8029 | This event is the enforcement mode equivalent of event 8028. Note: While this event says that a script was blocked, the script hosts control the actual script enforcement behavior. The script host may allow the file to run with restrictions and not block the file outright. For example, PowerShell runs script not allowed by your WDAC policy in [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). |
| 8036| COM object was blocked. To learn more about COM object authorization, see [Allow COM object registration in a Windows Defender Application Control policy](../design/allow-com-object-registration-in-appcontrol-policy.md). |
| 8037 | This event indicates that a script host checked whether to allow a script to run, and the file passed the WDAC policy. |
| 8038 | Signing information event correlated with either an 8028 or 8029 event. One 8038 event is generated for each signature of a script file. Contains the total number of signatures on a script file and an index as to which signature it is. Unsigned script files generate a single 8038 event with TotalSignatureCount 0. These events are correlated with 8028 and 8029 events and can be matched using the `Correlation ActivityID` found in the **System** portion of the event. |
| 8039 | This event indicates that a packaged app (MSIX/AppX) was allowed to install or run because the WDAC policy is in audit mode. But, it would have been blocked if the policy was enforced. |
| 8040 | This event indicates that a packaged app was prevented from installing or running due to the WDAC policy. |
## WDAC policy activation events
These events are found in the **CodeIntegrity - Operational** event log.
| Event ID | Explanation |
|--------|-----------|
| 3095 | The Application Control policy can't be refreshed and must be rebooted instead. |
| 3096 | The Application Control policy wasn't refreshed since it's already up-to-date. This event's Details includes useful information about the policy, such as its policy options. |
| 3097 | The Application Control policy can't be refreshed. |
| 3099 | Indicates that a policy has been loaded. This event's Details includes useful information about the Application Control policy, such as its policy options. |
| 3100 | The application control policy was refreshed but was unsuccessfully activated. Retry. |
| 3101 | Application Control policy refresh started for *N* policies. |
| 3102 | Application Control policy refresh finished for *N* policies. |
| 3103 | The system is ignoring the Application Control policy refresh. For example, an inbox Windows policy that doesn't meet the conditions for activation. |
| 3105 | The system is attempting to refresh the Application Control policy with the specified ID. |
## Diagnostic events for Intelligent Security Graph (ISG) and Managed Installer (MI)
> [!NOTE]
> When Managed Installer is enabled, customers using LogAnalytics should be aware that Managed Installer may fire many 3091 events. Customers may need to filter out these events to avoid high LogAnalytics costs.
The following events provide helpful diagnostic information when a WDAC policy includes the ISG or MI option. These events can help you debug why something was allowed/denied based on managed installer or ISG. Events 3090, 3091, and 3092 don't necessarily indicate a problem but should be reviewed in context with other events like 3076 or 3077.
Unless otherwise noted, these events are found in either the **CodeIntegrity - Operational** event log or the **CodeIntegrity - Verbose** event log depending on your version of Windows.
| 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 Application 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 WDAC. |
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 Application Control policy is in audit mode, otherwise it is in enforce mode |
| PolicyName | The name of the Application Control policy to which the event applies |
### Enabling ISG and MI diagnostic events
To enable 3090 allow events, create a TestFlags regkey with a value of 0x300 as shown in the following PowerShell command. Then restart your computer.
```powershell
reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x300
```
Events 3091 and 3092 are inactive on some versions of Windows and are turned on by the preceding command.
## Appendix
A list of other relevant event IDs and their corresponding description.
| 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 application control policy. |
| 3024 | Windows application 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 application control policy. |
| 3034 | The file under validation wouldn't meet the requirements to pass the Application Control policy if it was enforced. The file was allowed since the policy is in audit mode. |
| 3036 | Microsoft or the certificate issuing authority revoked the certificate that signed the file being validated. |
| 3064 | If the Application Control policy was enforced, a user mode DLL under validation wouldn't meet the requirements to pass the application control policy. The DLL was allowed since the policy is in audit mode. |
| 3065 | If the Application Control policy was enforced, a user mode DLL under validation wouldn't meet the requirements to pass the application control policy. |
| 3074 | Page hash failure while hypervisor-protected code integrity was enabled. |
| 3075 | This event measures the performance of the Application Control policy check during file validation. |
| 3076 | This event is the main Application 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 Application 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 application control policy. |
| 3080 | If the Application Control policy was in enforced mode, the file under validation wouldn't have met the requirements to pass the application control policy. |
| 3081 | The file under validation didn't meet the requirements to pass the application control policy. |
| 3082 | If the Application 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 Application 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 Application Control policy is in audit mode. |
| 3092 | This event is the enforcement mode equivalent of 3091. |
| 3095 | The Application Control policy can't be refreshed and must be rebooted instead. |
| 3096 | The Application Control policy wasn't refreshed since it's already up-to-date. |
| 3097 | The Application 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 Application Control policy. |
| 3100 | The application control policy was refreshed but was unsuccessfully activated. Retry. |
| 3101 | The system started refreshing the Application Control policy. |
| 3102 | The system finished refreshing the Application Control policy. |
| 3103 | The system is ignoring the Application 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 Application 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 Application Control policy validation. The file under validation didn't pass your policy and was blocked. |

164
windows/security/application-security/application-control/app-control-for-business/operations/event-tag-explanations.md Normal file
View File

@ -0,0 +1,164 @@
---
title: Understanding Application Control event tags
description: Learn what different Windows Defender Application Control event tags signify.
ms.localizationpriority: medium
ms.date: 05/09/2023
ms.topic: conceptual
---
# Understanding Application Control event tags
Windows Defender Application Control (WDAC) events include many fields, which provide helpful troubleshooting information to figure out exactly what an event means. This article describes the values and meanings for a few useful event tags.
## SignatureType
Represents the type of signature which verified the image.
| SignatureType Value | Explanation |
|---|----------|
| 0 | Unsigned or verification hasn't been attempted |
| 1 | Embedded signature |
| 2 | Cached signature; presence of a CI EA means the file was previously verified |
| 3 | Cached catalog verified via Catalog Database or searching catalog directly |
| 4 | Uncached catalog verified via Catalog Database or searching catalog directly |
| 5 | Successfully verified using an EA that informs CI that catalog to try first |
| 6 | AppX / MSIX package catalog verified |
| 7 | File was verified |
## Requested and Validated Signing Level
Represents the signature level at which the code was verified.
| SigningLevel Value | Explanation |
|---|----------|
| 0 | Signing level hasn't yet been checked |
| 1 | File is unsigned or has no signature that passes the active policies |
| 2 | Trusted by Windows Defender Application Control policy |
| 3 | Developer signed code |
| 4 | Authenticode signed |
| 5 | Microsoft Store signed app PPL (Protected Process Light) |
| 6 | Microsoft Store-signed |
| 7 | Signed by an Antimalware vendor whose product is using AMPPL |
| 8 | Microsoft signed |
| 11 | Only used for signing of the .NET NGEN compiler |
| 12 | Windows signed |
| 14 | Windows Trusted Computing Base signed |
## VerificationError
Represents why verification failed, or if it succeeded.
| VerificationError Value | Explanation |
|---|----------|
| 0 | Successfully verified signature. |
| 1 | File has an invalid hash. |
| 2 | File contains shared writable sections. |
| 3 | File isn't signed. |
| 4 | Revoked signature. |
| 5 | Expired signature. |
| 6 | File is signed using a weak hashing algorithm, which doesn't meet the minimum policy. |
| 7 | Invalid root certificate. |
| 8 | Signature was unable to be validated; generic error. |
| 9 | Signing time not trusted. |
| 10 | The file must be signed using page hashes for this scenario. |
| 11 | Page hash mismatch. |
| 12 | Not valid for a PPL (Protected Process Light). |
| 13 | Not valid for a PP (Protected Process). |
| 14 | The signature is missing the required ARM processor EKU. |
| 15 | Failed WHQL check. |
| 16 | Default policy signing level not met. |
| 17 | Custom policy signing level not met; returned when signature doesn't validate against an SBCP-defined set of certs. |
| 18 | Custom signing level not met; returned if signature fails to match `CISigners` in UMCI. |
| 19 | Binary is revoked based on its file hash. |
| 20 | SHA1 cert hash's timestamp is missing or after valid cutoff as defined by Weak Crypto Policy. |
| 21 | Failed to pass Windows Defender Application Control policy. |
| 22 | Not Isolated User Mode (IUM)) signed; indicates an attempt to load a standard Windows binary into a virtualization-based security (VBS) trustlet. |
| 23 | Invalid image hash. This error can indicate file corruption or a problem with the file's signature. Signatures using elliptic curve cryptography (ECC), such as ECDSA, return this VerificationError. |
| 24 | Flight root not allowed; indicates trying to run flight-signed code on production OS. |
| 25 | Anti-cheat policy violation. |
| 26 | Explicitly denied by WADC policy. |
| 27 | The signing chain appears to be tampered/invalid. |
| 28 | Resource page hash mismatch. |
## Policy activation event Options
The Application Control policy rule option values can be derived from the "Options" field in the Details section for successful [policy activation events](event-id-explanations.md#wdac-policy-activation-events). To parse the values, first convert the hex value to binary. To derive and parse these values, follow the below workflow.
- Access Event Viewer.
- Access the Code integrity 3099 event.
- Access the details pane.
- Identify the hex code listed in the "Options" field.
- Convert the hex code to binary.
:::image type="content" source="../images/event-3099-options.png" alt-text="Event 3099 policy rule options.":::
For a simple solution for converting hex to binary, follow these steps:
1. Open the Calculator app.
1. Select the menu icon. :::image type="icon" source="../images/calculator-menu-icon.png" border="false":::
1. Select **Programmer** mode.
1. Select **HEX**. :::image type="icon" source="../images/hex-icon.png" border="false":::
1. Enter your hex code. For example, `80881000`.
1. Switch to the **Bit Toggling Keyboard**. :::image type="icon" source="../images/bit-toggling-keyboard-icon.png" border="false":::
:::image type="content" source="../images/calculator-with-hex-in-binary.png" alt-text="An example of the calculator app in programmer mode, with a hex code converted into binary.":::
This view provides the hex code in binary form, with each bit address shown separately. The bit addresses start at 0 in the bottom right. Each bit address correlates to a specific event policy-rule option. If the bit address holds a value of 1, the setting is in the policy.
Next, use the bit addresses and their values from the following table to determine the state of each [policy rule-option](../design/select-types-of-rules-to-create.md#table-1-windows-defender-application-control-policy---policy-rule-options). For example, if the bit address of 16 holds a value of 1, then the **Enabled: Audit Mode (Default)** option is in the policy. This setting means that the policy is in audit mode.
| Bit Address | Policy Rule Option |
|-------|------|
| 2 | `Enabled:UMCI` |
| 3 | `Enabled:Boot Menu Protection` |
| 4 | `Enabled:Intelligent Security Graph Authorization` |
| 5 | `Enabled:Invalidate EAs on Reboot` |
| 7 | `Required:WHQL` |
| 10 | `Enabled:Allow Supplemental Policies` |
| 11 | `Disabled:Runtime FilePath Rule Protection` |
| 13 | `Enabled:Revoked Expired As Unsigned` |
| 16 | `Enabled:Audit Mode (Default)` |
| 17 | `Disabled:Flight Signing` |
| 18 | `Enabled:Inherit Default Policy` |
| 19 | `Enabled:Unsigned System Integrity Policy (Default)` |
| 20 | `Enabled:Dynamic Code Security` |
| 21 | `Required:EV Signers` |
| 22 | `Enabled:Boot Audit on Failure` |
| 23 | `Enabled:Advanced Boot Options Menu` |
| 24 | `Disabled:Script Enforcement` |
| 25 | `Required:Enforce Store Applications` |
| 27 | `Enabled:Managed Installer` |
| 28 | `Enabled:Update Policy No Reboot` |
## Microsoft Root CAs trusted by Windows
The rule means trust anything signed by a certificate that chains to this root CA.
| Root ID | Root Name |
|---|----------|
| 0| None |
| 1| Unknown |
| 2 | Self-Signed |
| 3 | Microsoft Authenticode(tm) Root Authority |
| 4 | Microsoft Product Root 1997 |
| 5 | Microsoft Product Root 2001 |
| 6 | Microsoft Product Root 2010 |
| 7 | Microsoft Standard Root 2011 |
| 8 | Microsoft Code Verification Root 2006 |
| 9 | Microsoft Test Root 1999 |
| 10 | Microsoft Test Root 2010 |
| 11 | Microsoft DMD Test Root 2005 |
| 12 | Microsoft DMDRoot 2005 |
| 13 | Microsoft DMD Preview Root 2005 |
| 14 | Microsoft Flight Root 2014 |
| 15 | Microsoft Third Party Marketplace Root |
| 16 | Microsoft ECC Testing Root CA 2017 |
| 17 | Microsoft ECC Development Root CA 2018 |
| 18 | Microsoft ECC Product Root CA 2018 |
| 19 | Microsoft ECC Devices Root CA 2017 |
For well-known roots, the TBS hashes for the certificates are baked into the code for Windows Defender Application Control. For example, they don't need to be listed as TBS hashes in the policy file.
## Status values
Represents values that are used to communicate system information. They are of four types: success values, information values, warning values, and error values. See [NTSATUS](/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55) for information about common usage details.

31
windows/security/application-security/application-control/app-control-for-business/operations/inbox-appcontrol-policies.md Normal file
View File

@ -0,0 +1,31 @@
---
title: Inbox WDAC policies
description: This article describes the inbox WDAC policies that may be active on a device.
ms.manager: jsuther
ms.date: 03/10/2023
ms.topic: conceptual
ms.localizationpriority: medium
---
# Inbox WDAC policies
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This article describes the Windows Defender Application Control (WDAC) policies that ship inbox with Windows and may be active on your devices. To see which policies are active on your device, use [citool.exe](/windows/security/threat-protection/windows-defender-application-control/operations/citool-commands) or check the *CodeIntegrity - Operational* event log for 3099 policy activation events.
## Inbox WDAC Policies
| **Policy Name** | **Policy ID** | **Policy Type** | **Description** |
|-----------|-----------|-----------|-----------|
| **Microsoft Windows Driver Policy** | {d2bda982-ccf6-4344-ac5b-0b44427b6816} | Kernel-only Base policy | This policy blocks known [vulnerable or malicious kernel drivers](/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules). It's active by default on Windows 11 22H2, [Windows in S mode](https://support.microsoft.com/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85), [Windows 11 SE](/education/windows/windows-11-se-overview), and anywhere [memory integrity](https://support.microsoft.com/windows/core-isolation-e30ed737-17d8-42f3-a2a9-87521df09b78) (also known as hypervisor-protected code integrity (HVCI)) is on. Its policy binary file is found at `%windir%\System32\CodeIntegrity\driversipolicy.p7b` and in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\driversipolicy.p7b`. |
| **Windows10S_Lockdown_Policy_Supplementable** | {5951a96a-e0b5-4d3d-8fb8-3e5b61030784} | Base policy | This policy is active on devices running [Windows in S mode](https://support.microsoft.com/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85). Its policy binary file is found in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\winsipolicy.p7b`. |
| **WindowsE_Lockdown_Policy** | {82443e1e-8a39-4b4a-96a8-f40ddc00b9f3} | Base policy | This policy is active on devices running [Windows 11 SE](/education/windows/windows-11-se-overview). Its policy binary file is found in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\CIPolicies\Active\{82443e1e-8a39-4b4a-96a8-f40ddc00b9f3}.cip`. |
| **WindowsE_Lockdown_Flight_Policy_Supplemental** | {5dac656c-21ad-4a02-ab49-649917162e70} | Supplemental policy | This policy is active on devices running [Windows 11 SE](/education/windows/windows-11-se-overview) that are enrolled in the [Windows Insider](https://insider.windows.com) program. Its policy binary file is found in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\CIPolicies\Active\{5dac656c-21ad-4a02-ab49-649917162e70}.cip`. |
| **WindowsE_Lockdown_Test_Policy_Supplemental** | {CDD5CB55-DB68-4D71-AA38-3DF2B6473A52} | Supplemental policy | This policy is active on devices running [Windows 11 SE](/education/windows/windows-11-se-overview) with Secure Boot disabled and TESTSIGNING on. Its policy binary file is found in the EFI system partition at `<EFI System Partition>\Microsoft\Boot\CIPolicies\Active\{CDD5CB55-DB68-4D71-AA38-3DF2B6473A52}.cip`. |
| **VerifiedAndReputableDesktop** | {0283ac0f-fff1-49ae-ada1-8a933130cad6} | Base policy | This policy is active on devices running Windows 11 with [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) turned on. Its policy binary file is found at `%windir%\System32\CodeIntegrity\CIPolicies\Active\{0283ac0f-fff1-49ae-ada1-8a933130cad6}.cip`. |
| **VerifiedAndReputableDesktopFlightSupplemental** | {1678656c-05ef-481f-bc5b-ebd8c991502d} | Supplemental policy | This policy is active on devices running Windows 11 with [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) turned on and enrolled in the [Windows Insider](https://insider.windows.com) program. Its policy binary file is found at `%windir%\System32\CodeIntegrity\CIPolicies\Active\{1678656c-05ef-481f-bc5b-ebd8c991502d}.cip`. |
| **VerifiedAndReputableDesktopTestSupplemental** | {0939ED82-BFD5-4D32-B58E-D31D3C49715A} | Supplemental policy | This policy is active on devices running Windows 11 with [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) turned on and with Secure Boot disabled and TESTSIGNING on. Its policy binary file is found at `%windir%\System32\CodeIntegrity\CIPolicies\Active\{0939ED82-BFD5-4D32-B58E-D31D3C49715A}.cip`. |
| **VerifiedAndReputableDesktopEvaluation** | {1283ac0f-fff1-49ae-ada1-8a933130cad6} | Base policy | This policy is active on devices running Windows 11 with [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) in *evaluation mode*. Its policy binary file is found at `%windir%\System32\CodeIntegrity\CIPolicies\Active\{1283ac0f-fff1-49ae-ada1-8a933130cad6}.cip`. |
| **VerifiedAndReputableDesktopEvaluationFlightSupplemental** | {2678656c-05ef-481f-bc5b-ebd8c991502d} | Supplemental policy | This policy is active on devices running Windows 11 with [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) in *evaluation mode* and enrolled in the [Windows Insider](https://insider.windows.com) program. Its policy binary file is found at `%windir%\System32\CodeIntegrity\CIPolicies\Active\{2678656c-05ef-481f-bc5b-ebd8c991502d}.cip`. |
| **VerifiedAndReputableDesktopEvaluationTestSupplemental** | {1939ED82-BFD5-4D32-B58E-D31D3C49715A} | Supplemental policy | This policy is active on devices running Windows 11 with [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) in *evaluation mode* and with Secure Boot disabled and TESTSIGNING on. Its policy binary file is found at `%windir%\System32\CodeIntegrity\CIPolicies\Active\{1939ED82-BFD5-4D32-B58E-D31D3C49715A}.cip`. |

104
windows/security/application-security/application-control/app-control-for-business/operations/known-issues.md Normal file
View File

@ -0,0 +1,104 @@
---
title: WDAC Admin Tips & Known Issues
description: WDAC Known Issues
ms.manager: jsuther
ms.date: 04/15/2024
ms.topic: troubleshooting
ms.localizationpriority: medium
---
# WDAC Admin Tips & Known Issues
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This article covers tips and tricks for admins and known issues with Windows Defender Application Control (WDAC). Test this configuration in your lab before enabling it in production.
## WDAC policy file locations
**Multiple policy format WDAC policies** are found in the following locations depending on whether the policy is signed or not, and the method of policy deployment that was used.
- &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\CiPolicies\Active\\*\{PolicyId GUID\}*.cip
- &lt;EFI System Partition&gt;\\Microsoft\\Boot\\CiPolicies\Active\\*\{PolicyId GUID\}*.cip
The *\{PolicyId GUID\}* value is unique by policy and defined in the policy XML with the &lt;PolicyId&gt; element.
For **single policy format WDAC policies**, in addition to the two preceding locations, also look for a file called SiPolicy.p7b in the following locations:
- &lt;EFI System Partition&gt;\\Microsoft\\Boot\\SiPolicy.p7b
- &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\SiPolicy.p7b
> [!NOTE]
> A multiple policy format WDAC policy using the single policy format GUID `{A244370E-44C9-4C06-B551-F6016E563076}` may exist under any of the policy file locations.
## File Rule Precedence Order
When the WDAC engine evaluates files against the active set of policies on the device, rules are applied in the following order. Once a file encounters a match, WDAC stops further processing.
1. Explicit deny rules - a file is blocked if any explicit deny rule exists for it, even if other rules are created to try to allow it. Deny rules can use any [rule level](/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create#windows-defender-application-control-file-rule-levels). Use the most specific rule level practical when creating deny rules to avoid blocking more than you intend.
2. Explicit allow rules - if any explicit allow rule exists for the file, the file runs.
3. WDAC then checks for the [Managed Installer extended attribute (EA)](/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer) or the [Intelligent Security Graph (ISG) EA](/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph) on the file. If either EA exists and the policy enables the corresponding option, then the file is allowed.
4. Lastly, WDAC makes a cloud call to the ISG to get reputation about the file, if the policy enables the ISG option.
5. Any file not allowed by an explicit rule or based on ISG or MI is blocked implicitly.
## Known issues
### Boot stop failure (blue screen) occurs if more than 32 policies are active
Until you apply the Windows security update released on or after April 9, 2024, your device is limited to 32 active policies. If the maximum number of policies is exceeded, the device bluescreens referencing ci.dll with a bug check value of 0x0000003b. Consider this maximum policy count limit when planning your WDAC policies. Any [Windows inbox policies](/windows/security/threat-protection/windows-defender-application-control/operations/inbox-wdac-policies) that are active on the device also count towards this limit. To remove the maximum policy limit, install the Windows security update released on, or after, April 9, 2024 and then restart the device. Otherwise, reduce the number of policies on the device to remain below 32 policies.
**Note:** The policy limit was not removed on Windows 11 21H2, and will remain limited to 32 policies.
### Audit mode policies can change the behavior for some apps or cause app crashes
Although WDAC audit mode is designed to avoid impact to apps, some features are always on/always enforced with any WDAC policy that turns on user mode code integrity (UMCI) with the option **0 Enabled:UMCI**. Here's a list of known system changes in audit mode:
- Some script hosts might block code or run code with fewer privileges even in audit mode. See [Script enforcement with WDAC](/windows/security/application-security/application-control/windows-defender-application-control/design/script-enforcement) for information about individual script host behaviors.
- Option **19 Enabled:Dynamic Code Security** is always enforced if any UMCI policy includes that option. See [WDAC and .NET](/windows/security/application-security/application-control/windows-defender-application-control/design/wdac-and-dotnet#wdac-and-net-hardening).
### .NET native images may generate false positive block events
In some cases, the code integrity logs where Windows Defender Application Control errors and warnings are written include error events for native images generated for .NET assemblies. Typically, native image blocks are functionally benign as a blocked native image falls back to its corresponding assembly and .NET regenerates the native image at its next scheduled maintenance window.
### Signatures using elliptical curve cryptography (ECC) aren't supported
WDAC signer-based rules only work with RSA cryptography. ECC algorithms, such as ECDSA, aren't supported. If WDAC blocks a file based on ECC signatures, the corresponding 3089 signature information events show VerificationError = 23. You can authorize the files instead by hash or file attribute rules, or using other signer rules if the file is also signed with signatures using RSA.
### MSI installers are treated as user writeable on Windows 10 when allowed by FilePath rule
MSI installer files are always detected as user writeable on Windows 10, and on Windows Server 2022 and earlier. If you need to allow MSI files using FilePath rules, you must set option **18 Disabled:Runtime FilePath Rule Protection** in your WDAC policy.
### MSI Installations launched directly from the internet are blocked by WDAC
Installing .msi files directly from the internet to a computer protected by WDAC fails.
For example, this command fails:
```console
msiexec -i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-76209EA4F429/Windows10_Version_1511_ADMX.msi
```
As a workaround, download the MSI file and run it locally:
```console
msiexec -i c:\temp\Windows10_Version_1511_ADMX.msi
```
### Slow boot and performance with custom policies
WDAC evaluates all processes that run, including inbox Windows processes. You can cause slower boot times, degraded performance, and possibly boot issues if your policies don't build upon the WDAC templates or don't trust the Windows signers. For these reasons, you should use the [WDAC base templates](../design/example-appcontrol-base-policies.md) whenever possible to create your policies.
#### AppId Tagging policy considerations
AppId Tagging policies that aren't built upon the WDAC base templates or don't allow the Windows in-box signers might cause a significant increase in boot times (~2 minutes).
If you can't allowlist the Windows signers or build off the WDAC base templates, add the following rule to your policies to improve the performance:
:::image type="content" source="../images/known-issue-appid-dll-rule.png" alt-text="Allow all dlls in the policy.":::
:::image type="content" source="../images/known-issue-appid-dll-rule-xml.png" alt-text="Allow all dll files in the xml policy.":::
Since AppId Tagging policies evaluate but can't tag dll files, this rule short circuits dll evaluation and improve evaluation performance.

84
windows/security/application-security/application-control/app-control-for-business/operations/querying-application-control-events-centrally-using-advanced-hunting.md Normal file
View File

@ -0,0 +1,84 @@
---
title: Query Application Control events with Advanced Hunting
description: Learn how to query Windows Defender Application Control events across your entire organization by using Advanced Hunting.
ms.localizationpriority: medium
ms.date: 03/01/2022
ms.topic: troubleshooting
---
# Querying Application Control events centrally using Advanced hunting
A Windows Defender Application Control (WDAC) policy logs events locally in Windows Event Viewer in either enforced or audit mode.
While Event Viewer helps to see the impact on a single system, IT Pros want to gauge it across many systems.
In November 2018, we added functionality in Microsoft Defender for Endpoint that makes it easy to view WDAC events centrally from all connected systems.
Advanced hunting in Microsoft Defender for Endpoint allows customers to query data using a rich set of capabilities. WDAC events can be queried with using an ActionType that starts with "AppControl".
This capability is supported beginning with Windows version 1607.
## Action Types
| ActionType Name | ETW Source Event ID | Description |
| - | - | - |
| AppControlCodeIntegrityDriverRevoked | 3023 | The driver file under validation didn't meet the requirements to pass the application control policy. |
| AppControlCodeIntegrityImageRevoked | 3036 | The signed file under validation is signed by a code signing certificate that has been revoked by Microsoft or the certificate issuing authority. |
| AppControlCodeIntegrityPolicyAudited | 3076 | This event is the main Windows Defender Application Control block event for audit mode policies. It indicates the file would have been blocked if the WDAC policy was enforced. |
| AppControlCodeIntegrityPolicyBlocked | 3077 | This event is the main Windows Defender Application Control block event for enforced policies. It indicates the file didn't pass your WDAC policy and was blocked. |
| AppControlExecutableAudited | 8003 | Applied only when the Audit only enforcement mode is enabled. Specifies the .exe or .dll file would be blocked if the Enforce rules enforcement mode were enabled. |
| AppControlExecutableBlocked | 8004 | The .exe or .dll file can't run. |
| AppControlPackagedAppAudited | 8021 | Applied only when the Audit only enforcement mode is enabled. Specifies the packaged app would be blocked if the Enforce rules enforcement mode were enabled. |
| AppControlPackagedAppBlocked | 8022 | The packaged app was blocked by the policy. |
| AppControlScriptAudited | 8006 | Applied only when the Audit only enforcement mode is enabled. Specifies the script or .msi file would be blocked if the Enforce rules enforcement mode were enabled. |
| AppControlScriptBlocked | 8007 | Access to file name is restricted by the administrator. Applied only when the Enforce rules enforcement mode is set either directly or indirectly through Group Policy inheritance. The script or .msi file can't run. |
| AppControlCIScriptAudited | 8028 | Audit script/MSI file generated by Windows LockDown Policy (WLDP) being called by the script hosts themselves. |
| AppControlCIScriptBlocked | 8029 | Block script/MSI file generated by Windows LockDown Policy (WLDP) being called by the script hosts themselves. |
| AppControlCodeIntegrityOriginAllowed | 3090 | File was allowed due to good reputation (ISG) or installation source (managed installer). |
| AppControlCodeIntegrityOriginAudited | 3091 | Reputation (ISG) and installation source (managed installer) information for an audited file. |
| AppControlCodeIntegrityOriginBlocked | 3092 | Reputation (ISG) and installation source (managed installer) information for a blocked file. |
| AppControlCodeIntegrityPolicyLoaded | 3099 | Indicates a policy has been successfully loaded. |
| AppControlCodeIntegritySigningInformation | 3089 | Signing information event correlated with either a 3076 or 3077 event. One 3089 event is generated for each signature of a file. |
| AppControlPolicyApplied | 8001 | Indicates the AppLocker policy was successfully applied to the computer. |
Learn more about the [Understanding Application Control event IDs (Windows)](event-id-explanations.md)
## Example Advanced Hunting Application Control Queries
Query Example 1: Query the application control action types summarized by type for past seven days
Here's a simple example query that shows all the Windows Defender Application Control events generated in the last seven days from machines being monitored by Microsoft Defender for Endpoint:
```
DeviceEvents
| where Timestamp > ago(7d) and
ActionType startswith "AppControl"
| summarize Machines=dcount(DeviceName) by ActionType
| order by Machines desc
```
The query results can be used for several important functions related to managing Windows Defender Application Control including:
- Assessing the impact of deploying policies in audit mode
Since applications still run in audit mode, it's an ideal way to see the impact and correctness of the rules included in the policy. Integrating the generated events with Advanced Hunting makes it much easier to have broad deployments of audit mode policies and see how the included rules would influence those systems in real world usage. This audit mode data will help streamline the transition to using policies in enforced mode.
- Monitoring blocks from policies in enforced mode
Policies deployed in enforced mode may block executables or scripts that fail to meet any of the included allow rules. Legitimate new applications and updates or potentially unwanted or malicious software could be blocked. In either case, the Advanced hunting queries report the blocks for further investigation.
Query Example #2: Query to determine audit blocks in the past seven days
```
DeviceEvents
| where ActionType startswith "AppControlExecutableAudited"
| where Timestamp > ago(7d)
|project DeviceId, // the device ID where the audit block happened
FileName, // The audit blocked app's filename
FolderPath, // The audit blocked app's system path without the FileName
InitiatingProcessFileName, // The file name of the parent process loading the executable
InitiatingProcessVersionInfoCompanyName, // The company name of the parent process loading the executable
InitiatingProcessVersionInfoOriginalFileName, // The original file name of the parent process loading the executable
InitiatingProcessVersionInfoProductName, // The product name of the parent process loading the executable
InitiatingProcessSHA256, // The SHA256 flat hash of the parent process loading the executable
Timestamp, // The event creation timestamp
ReportId, // The report ID - randomly generated by MDE AH
InitiatingProcessVersionInfoProductVersion, // The product version of the parent process loading the executable
InitiatingProcessVersionInfoFileDescription, // The file description of the parent process loading the executable
AdditionalFields // Additional fields contains FQBN for signed binaries. These contain the CN of the leaf certificate, product name, original filename and version of the audited binary
```