diff --git a/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md b/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md index 4b9c9e64bd..8a74cb79d7 100644 --- a/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md +++ b/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md @@ -8,7 +8,7 @@ author: jsuther1974 ms.reviewer: jogeurte ms.author: vinpa manager: aaroncz -ms.date: 06/27/2022 +ms.date: 03/24/2023 ms.topic: reference --- @@ -20,43 +20,77 @@ ms.topic: reference - Windows 11 - Windows Server 2016 and later (limited events) -A Windows Defender Application Control policy logs events locally in Windows Event Viewer in either enforced or audit mode. These events are generated under two locations: +## WDAC Events Overview -- Events about Application Control policy activation and the control of executables, dlls, and drivers appear in **Applications and Services logs** > **Microsoft** > **Windows** > **CodeIntegrity** > **Operational** +WDAC logs events when a policy is loaded as well as when a binary attempts to run and is blocked, or would be blocked if the policy is in audit mode. These block events include information that identifies the policy and gives more details about the block. Generally, WDAC doesn't generate events when a binary is allowed; however, you can turn on allow audit events for files that were authorized by Managed Installer or the Intelligent Security Graph (ISG) as described later in this article. -- Events about the control of MSI installers, scripts, and COM objects appear in **Applications and Services logs** > **Microsoft** > **Windows** > **AppLocker** > **MSI and Script** +### 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] > These event IDs are not included on Windows Server Core edition. -## Windows CodeIntegrity Operational log +## 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. | -| 3033 | This event isn't common. It often means the file's signature is revoked or expired. Try using option `20 Enabled:Revoked Expired As Unsigned` in your policy along with a non-signature rule (for example, hash) to address issues with revoked or expired certs. | +| 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.

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 is not 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 an expired signature will be blocked by WDAC. Try using option `20 Enabled:Revoked Expired As Unsigned` in your policy along with a non-signature rule (for example, hash) to address issues with revoked or expired certs.

This event is also seen for code that the developer opted-in to [Code Integrity Guard (CIG)](/microsoft-365/security/defender-endpoint/exploit-protection-reference?view=o365-worldwide#code-integrity-guard) but then attempts to load code that doesn't meet the requirements of CIG. | | 3034 | This event isn't common. It's the audit mode equivalent of event 3033 described above. | | 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 would have been blocked by Application Control. One 3089 event is created for each signature of a file. The event shows the total number of signatures found and an index value to identify the current signature. Unsigned files produce a single 3089 event with TotalSignatureCount 0. 3089 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. | -| 3099 | Indicates that a policy has been loaded. This event also includes information about the Application Control policy options that were specified by the policy. | -## Windows AppLocker MSI and Script log +## 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. 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. | +| 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 would not 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 described above. Note: While this event says that a script was blocked, the actual script enforcement behavior is implemented by the script host. The script host may allow the file to run with restrictions and not block the file outright. For example, PowerShell will allow a script to run but only 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](allow-com-object-registration-in-windows-defender-application-control-policy.md). | +| 8037 | This event indicates that a script host queried Application Control about a file the script host was about to run, the file passed the WDAC policy and was allowed to run. | | 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 will generate a single 8038 event with TotalSignatureCount 0. 8038 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 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, unless otherwise noted. + +| 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 Application Control policy, such as the policy options that were specified by the policy. | +| 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 the policy options that were specified by the policy. | +| 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 does not meet the conditions for activation. | +| 3105 | The system is attempting to refresh the Application Control policy with the specified Id. | +| 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 are not related to WDAC. | ## 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. +### WDAC diagnostic events 3090, 3091, and 3092 + Events 3090, 3091 and 3092 prove helpful diagnostic information when the ISG or MI option is enabled by any Application Control policy. These events can help you debug why something was allowed/denied based on managed installer or ISG. These events don't necessarily indicate a problem but should be reviewed in context with other events like 3076 or 3077 described above. +These events are found in the **CodeIntegrity - Operational** event log. + | Event ID | Explanation | |--------|---------| | 3090 | *Optional* This event indicates that a file was allowed to run based purely on ISG or managed installer. | @@ -65,10 +99,12 @@ Events 3090, 3091 and 3092 prove helpful diagnostic information when the ISG or The above events are reported per active policy on the system, so you may see multiple events for the same file. -### ISG and MI diagnostic event details +#### ISG and MI diagnostic event details The following information is found in the details for 3090, 3091, and 3092 events. +These events are found in either the **CodeIntegrity - Operational** event log or the **CodeIntegrity - Verbose** event log, depending on your version of Windows. + | Name | Explanation | |------|------| | ManagedInstallerEnabled | Indicates whether the specified policy enables managed installer trust | @@ -78,7 +114,7 @@ The following information is found in the details for 3090, 3091, and 3092 event | 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 +#### 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. @@ -88,56 +124,6 @@ reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x 3091 and 3092 events are inactive on some versions of Windows. The above steps will also turn on those events. -## Event ID 3099 Options - -The Application Control policy rule option values can be derived from the "Options" field in the Details section of the Code integrity 3099 event. 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 will provide 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 table below to determine the state of each [policy rule-option](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` | - ## Appendix A list of other relevant event IDs and their corresponding description. diff --git a/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations.md b/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations.md index f358465735..31cf192cbc 100644 --- a/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations.md +++ b/windows/security/threat-protection/windows-defender-application-control/event-tag-explanations.md @@ -10,10 +10,10 @@ ms.pagetype: security ms.localizationpriority: medium audience: ITPro author: jsuther1974 -ms.reviewer: isbrahm +ms.reviewer: jogeurte ms.author: vinpa manager: aaroncz -ms.date: 07/13/2021 +ms.date: 03/24/2023 ms.technology: itpro-security ms.topic: article --- @@ -37,14 +37,14 @@ Represents the type of signature which verified the image. | 6 | AppX / MSIX package catalog verified | | 7 | File was verified | -## ValidatedSigningLevel +## Requested and ValidatedSigningLevel Represents the signature level at which the code was verified. | ValidatedSigningLevel Value | Explanation | |---|----------| | 0 | Signing level hasn't yet been checked | -| 1 | File is unsigned | +| 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 | @@ -92,6 +92,56 @@ Represents why verification failed, or if it succeeded. | 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 will provide 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 table below to determine the state of each [policy rule-option](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. diff --git a/windows/security/threat-protection/windows-defender-application-control/operations/known-issues.md b/windows/security/threat-protection/windows-defender-application-control/operations/known-issues.md index a5642a032c..f2125eb6c8 100644 --- a/windows/security/threat-protection/windows-defender-application-control/operations/known-issues.md +++ b/windows/security/threat-protection/windows-defender-application-control/operations/known-issues.md @@ -28,15 +28,34 @@ ms.localizationpriority: medium 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. -## Managed Installer and ISG will cause garrulous events +## 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. + +- <OS Volume>\\Windows\\System32\\CodeIntegrity\\CiPolicies\Active\\*\{PolicyId GUID\}*.cip +- <EFI System Partition>\\Microsoft\\Boot\\CiPolicies\Active\\*\{PolicyId GUID\}*.cip + +The *\{PolicyId GUID\}* value is unique by policy and defined in the policy XML with the <PolicyId> element. + +For **single policy format WDAC policies**, in addition to the two locations above, also look for a file called SiPolicy.p7b that may be found in the following locations: + +- <EFI System Partition>\\Microsoft\\Boot\\SiPolicy.p7b +- <OS Volume>\\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. + +## Known issues + +### Managed Installer and ISG will cause garrulous events When Managed Installer and ISG are enabled, 3091 and 3092 events will be logged when a file didn't have Managed Installer or ISG authorization, regardless of whether the file was allowed. These events have been moved to the verbose channel beginning with the September 2022 Update Preview since the events don't indicate an issue with the policy. -## .NET native images may generate false positive block events +### .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 will contain error events for native images generated for .NET assemblies. Typically, native image blocks are functionally benign as a blocked native image will fall back to its corresponding assembly and .NET will regenerate the native image at its next scheduled maintenance window. -## MSI Installations launched directly from the internet are blocked by WDAC +### MSI Installations launched directly from the internet are blocked by WDAC Installing .msi files directly from the internet to a computer protected by WDAC will fail. For example, this command won't work: diff --git a/windows/security/threat-protection/windows-defender-application-control/operations/wdac-debugging-and-troubleshooting.md b/windows/security/threat-protection/windows-defender-application-control/operations/wdac-debugging-and-troubleshooting.md new file mode 100644 index 0000000000..91970316c1 --- /dev/null +++ b/windows/security/threat-protection/windows-defender-application-control/operations/wdac-debugging-and-troubleshooting.md @@ -0,0 +1,143 @@ +--- +title: WDAC debugging and troubleshooting guide +description: Learn how to debug and troubleshoot app and script failures when using WDAC +author: valemieux +ms.author: jogeurte +ms.reviewer: jsuther1974 +ms.topic: how-to +ms.date: 03/23/2023 +ms.custom: template-how-to +ms.prod: windows-client +ms.technology: itpro-security +--- + +# WDAC debugging and troubleshooting + +**Applies to** + +- Windows 10 +- Windows 11 +- Windows Server 2016 and above + +> [!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). + +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 by running: + + ```powershell + cidiag.exe /stop + ``` + + If CiDiag.exe is not 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 + - AppLocker event logs + - Other event logs that may contain useful information from other Windows apps and services + - A text file containing only critical error events found in the WDAC event logs + - A text file containing full event details for critical error events found in the WDAC event logs + +2. Save the device's System Information to the CiDiag folder by running `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 by running `citool.exe -lp -json > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\CiToolOutput.json`. Skip this step if CiTool.exe is not present in your version of Windows. +4. Export AppLocker registry key data to the CiDiag folder by running the following commands: + + `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` + +5. Copy any AppLocker policy files from %windir%System32\AppLocker to the CiDiag folder by running `Copy-Item -Path $env:windir\System32\AppLocker -Destination $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\ -Recurse -Force` +6. Collect file information for the AppLocker policy files collected in the previous step by running `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 by running `Get-AppLockerPolicy -xml -Effective > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xml` +8. Collect AppLocker services configuration and state information by running the following commands: + + `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. The ones shown in *italics* are not collected by cidiag.exe. + +- 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 step. + +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 that [Windows includes inbox policies](inbox-wdac-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](../event-id-explanations.md#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](../event-id-explanations.md#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](../event-id-explanations.md#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 + + + +## 3 - Resolve common problems + +### 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. +- Re-deploy the file or app using a managed installer if your policy trusts managed installers. + +### 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](../disable-windows-defender-application-control-policies.md) for the identified policy. + +### 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. This can also be seen as a side-effect of script enforcement, since the script enforcement behaviors are implemented by the individual script hosts and may not be handled by apps that interact with those script hosts. + +Try to isolate the root cause by doing the following: + +- Check for events in [other event logs](#other-windows-event-logs-that-may-be-useful) corresponding with the app failures. +- Temporarily replace the WDAC policy with another policy that [disables script enforcement](../design/script-enforcement.md) and re-test. +- Temporarily replace the WDAC policy with another policy that [allows all COM objects](../allow-com-object-registration-in-windows-defender-application-control-policy.md) and re-test. +- Temporarily replace the WDAC policy with another policy that relaxes other [policy rules](../select-types-of-rules-to-create.md#windows-defender-application-control-policy-rules) and re-test. + +### An app deployed by a managed installer is not working + +To debug issues using managed installer, try the following: + +- Check that the effective AppLocker policy $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xml is correct as described in +- Check that the AppLocker services are running. These should be found in $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt created earlier. +- Check that an AppLocker file exists called MANAGEDINSTALLER.APPLOCKER +- Check if the app is encountering a [known limitation with managed installer](../configure-authorized-apps-deployed-with-a-managed-installer.md#known-limitations-with-managed-installer). If so, you must authorize the app using other means. +- diff --git a/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-operational-guide.md b/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-operational-guide.md index 4a03e5ee20..ffa96146c9 100644 --- a/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-operational-guide.md +++ b/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-operational-guide.md @@ -31,16 +31,6 @@ ms.topic: article After enabling you understand how to design and deploy your Windows Defender Application Control (WDAC) policies, this guide covers understanding the effects your policies are having and troubleshooting 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. -## WDAC Events Overview - -Windows Defender Application Control generates and logs events when a policy is loaded as well as when a binary attempts to execute and is blocked. These events include information that identifies the policy and gives more details about the block. Generally, WDAC doesn't generate events when a binary is allowed; however, there's the option to enable events when Managed Installer and/or the Intelligent Security Graph (ISG) is configured. - -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 - ## In this section | Topic | Description |