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

More troubleshooting topic updates

Browse Source
This commit is contained in:
jsuther1974
2023-03-30 12:47:41 -07:00
parent bf3ee53b27
commit 915b9de38f
5 changed files with 175 additions and 79 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
windows/security/threat-protection/windows-defender-application-control/TOC.yml
View File

@ -105,6 +105,8 @@
- name: WDAC operational guide
href: windows-defender-application-control-operational-guide.md
items:
- name: WDAC debugging and troubleshooting
href: operations/wdac-debugging-and-troubleshooting.md
- name: Understanding Application Control event IDs
href: event-id-explanations.md
- name: Understanding Application Control event tags

52
windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md
View File

@ -22,7 +22,7 @@ ms.topic: reference
## WDAC Events Overview
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.
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
@ -42,12 +42,12 @@ 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 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. <br><br> 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. |
| 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?view=o365-worldwide#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 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. |
| 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
@ -55,12 +55,12 @@ 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 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). |
| 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](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. |
| 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
@ -70,15 +70,15 @@ These events are found in the **CodeIntegrity - Operational** event log, unless
| 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. |
| 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 the policy options that were specified by the policy. |
| 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 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. |
| 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. |
| 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. |
## Diagnostic events for Intelligent Security Graph (ISG) and Managed Installer (MI)
@ -87,7 +87,7 @@ These events are found in the **CodeIntegrity - Operational** event log, unless
### 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.
Events 3090, 3091 and 3092 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. These events don't necessarily indicate a problem but should be reviewed in context with other events like 3076 or 3077.
These events are found in the **CodeIntegrity - Operational** event log.
@ -122,7 +122,7 @@ To enable 3090 allow events, create a TestFlags regkey with a value of 0x300 as
reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x300
```
3091 and 3092 events are inactive on some versions of Windows. The above steps will also turn on those events.
Events 3091 and 3092 are inactive on some versions of Windows and are turned on by the preceding command.
## Appendix
@ -138,11 +138,11 @@ A list of other relevant event IDs and their corresponding description.
| 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 | The catalog loaded is signed by a signing certificate that has been revoked by Microsoft and/or the certificate issuing authority. |
| 3032 | The file under validation is revoked by the system or the file has a signature that has been revoked.
| 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 | The signed file under validation is signed by a code signing certificate that has been revoked by Microsoft or the certificate issuing authority. |
| 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. |
@ -152,18 +152,18 @@ A list of other relevant event IDs and their corresponding description.
| 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 in enforced mode, the non-WHQL driver would have been denied by the policy. |
| 3084 | Code Integrity will enforce the WHQL driver signing requirements on this boot session. |
| 3085 | Code Integrity won't enforce the WHQL driver signing requirements on this boot session. |
| 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 would have been blocked by Application Control. One 3089 event is created for each signature of a file. |
| 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 that were specified by the Application Control policy. |
| 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. |
@ -173,5 +173,5 @@ A list of other relevant event IDs and their corresponding description.
| 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 | The file under validation is signed by a certificate that has been explicitly revoked by Windows. |
| 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. |

22
windows/security/threat-protection/windows-defender-application-control/event-tag-explanations.md
View File

@ -20,7 +20,7 @@ ms.topic: article
# 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. Below, we've documented the values and meanings for a few useful 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
@ -30,18 +30,18 @@ Represents the type of signature which verified the image.
|---|----------|
| 0 | Unsigned or verification hasn't been attempted |
| 1 | Embedded signature |
| 2 | Cached signature; presence of CI EA shows that file had been previously verified |
| 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 ValidatedSigningLevel
## Requested and Validated Signing Level
Represents the signature level at which the code was verified.
| ValidatedSigningLevel Value | Explanation |
| SigningLevel Value | Explanation |
|---|----------|
| 0 | Signing level hasn't yet been checked |
| 1 | File is unsigned or has no signature that passes the active policies |
@ -76,15 +76,15 @@ Represents why verification failed, or if it succeeded.
| 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 EKU |
| 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 by file hash |
| 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 IUM (Isolated User Mode) signed; indicates trying to load a non-trustlet binary into a trustlet |
| 22 | Not Isolated User Mode (IUM)) signed; indicates an attempt to load a non-trustlet binary into a trustlet |
| 23 | Invalid image hash |
| 24 | Flight root not allowed; indicates trying to run flight-signed code on production OS |
| 25 | Anti-cheat policy violation |
@ -115,9 +115,9 @@ For a simple solution for converting hex to binary, follow these steps:
:::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.
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 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.
Next, use the bit addresses and their values from the following table 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 |
|-------|------|
@ -173,4 +173,4 @@ For well-known roots, the TBS hashes for the certificates are baked into the cod
## 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. Click on the [NTSATUS](/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55) link for information about common usage details.
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.

159
windows/security/threat-protection/windows-defender-application-control/operations/wdac-debugging-and-troubleshooting.md
View File

@ -26,7 +26,13 @@ This article describes how to debug and troubleshoot app and script failures whe
## 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:
Before debugging and troubleshooting WDAC issues, you must collect information from a device exhibiting the problem behavior.
<br>
<details>
<summary><b>Expand here for instructions on collecting WDAC diagnostic data.</b></summary>
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:
@ -34,7 +40,7 @@ Before debugging and troubleshooting WDAC issues, you must collect information f
cidiag.exe /stop
```
If CiDiag.exe is not present in your version of Windows, gather this information manually:
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
@ -47,7 +53,7 @@ Before debugging and troubleshooting WDAC issues, you must collect information f
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 is not present in your version of Windows.
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
@ -94,7 +100,7 @@ Within the CiDiag output directory, these event logs are called CIOperational.ev
### 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.
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
@ -107,11 +113,17 @@ Sometimes, you may be able to supplement the information contained in the core W
- *Windows - Application*
- *Windows - System*
</details>
## 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.
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 that [Windows includes inbox policies](inbox-wdac-policies.md) that may also be active. You can use either of these methods:
<br>
<details>
<summary><b>Expand here for steps on analyzing WDAC diagnostic data.</b></summary>
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-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.
@ -123,37 +135,47 @@ Most WDAC-related issues, including app and script failures, can be diagnosed us
### Event analysis for an example blocked executable
Here is a screenshot showing the detailed EventData from a typical WDAC enforcement mode block event 3077. The same data is shown for the 3076 audit mode version of the event. The table that follows describes some of the elements contained in the event.
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
#### Event 3077 - WDAC enforcement block event
<br>
<details>
<summary>Expand here to explore an example 3077 WDAC block event.</summary>
![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 is **not** the value used when creating WDAC file rules with `-Level FileName`. See the OriginalFileName element later in this table. |
| 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 | This is the Windows signing authorization level the code needed to pass in order to run. See [Requested and ValidatedSigningLevel](../event-tag-explanations.md#requested-and-validatedsigninglevel). In the example, Requested Signing Level 2 means the code simply must be allowed by the WDAC policy. |
| Validated Signing Level | This is the Windows signing authorization level the code was determined to have met. See [Requested and ValidatedSigningLevel](../event-tag-explanations.md#requested-and-validatedsigninglevel). In the example, Validated Signing Level 1 means the code failed to pass the WDAC policy and was treated as though unsigned. |
| Requested Signing Level | The Windows signing authorization level the code needed to pass in order to run. See [Requested and validated signing level](../event-tag-explanations.md#requested-and-validated-signing-level). |
| Validated Signing Level | The Windows signing authorization level the code was given. See [Requested and validated signing level](../event-tag-explanations.md#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, set by the policy author, 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, set by the policy author, that caused the block event. |
| 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 is the value used when creating WDAC file rules with `-Level FileName`. |
| 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 VersionEx value defined by the WDAC policy XML file. This is the internal version number for the policy and used to enforce version control over signed policies. |
| 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 is useful for diagnosing issues allowing by FilePath rules. |
| PackageFamilyName | For files that are part of a packaged app (MSIX), this is the Package Family Name for the app. |
| 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
</details>
#### Event 3089 - WDAC signature information event
<br>
<details>
<summary>Expand here to explore an example 3089 WDAC signature information event.</summary>
![Example 3089 signature information event for PowerShell.exe.](../images/event-3089.png)
@ -161,16 +183,63 @@ Here is a screenshot showing the detailed EventData from a typical WDAC enforcem
| ----- | ----- |
| 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 of the current signature shown in this 3089 event. If the file had multiple signatures, you will find other 3089 events for the other signatures. |
| Hash | The hash value that WDAC used to match the file. This 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 this is the hash value you want to add to your policy to allow by hash. |
| SignatureType |
| 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](../event-tag-explanations.md#signaturetype). |
| ValidatedSigningLevel | The Windows signing authorization level the signature met. See [Requested and validated signing level](../event-tag-explanations.md#requested-and-validated-signing-level). |
| VerificationError | The reason this particular signature failed to pass the WDAC policy. See [VerificationError](../event-tag-explanations.md#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. |
</details>
#### 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.
</details>
## 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:
<br>
<details>
<summary><b>Issue: A file was blocked that you want to allow.</b></summary>
### 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.
- Re-deploy the file or app using a managed installer if your policy trusts managed installers.
- Redeploy the file or app using a managed installer if your policy trusts managed installers.
</details>
<br>
<details>
<summary><b>Issue: A policy is active that is unexpected.</b></summary>
### Issue: A policy is active that is unexpected
@ -184,36 +253,56 @@ This condition may exist if:
To resolve such an issue, follow the instructions to [Remove WDAC policies](../disable-windows-defender-application-control-policies.md) for the identified policy.
</details>
<br>
<details>
<summary><b>Issue: An unhandled app failure is occurring and no WDAC events are observed.</b></summary>
### 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. 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.
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:
Try to isolate the root cause by doing the following actions:
- 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.
- Temporarily replace the WDAC policy with another policy that [disables script enforcement](../design/script-enforcement.md) and retest.
- 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 retest.
- 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 retest.
### Issue: An app deployed by a managed installer is not working
</details>
To debug issues using managed installer, try the following:
<br>
<details>
<summary><b>Issue: An app deployed by a managed installer is not working.</b></summary>
### 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](../configure-authorized-apps-deployed-with-a-managed-installer.md#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. These should be found in $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt created earlier.
- 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](../configure-wdac-managed-installer.md#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, re-deploy the files with the managed installer and check again.
- [Use fsutil.exe](../configure-wdac-managed-installer.md#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](../configure-authorized-apps-deployed-with-a-managed-installer.md#known-limitations-with-managed-installer). If so, you must authorize the app using other means.
### Issue: An app you expected to be allowed by the Intelligent Security Graph (ISG) is not working
</details>
To debug issues using ISG, try the following:
<br>
<details>
<summary><b>Issue: An app you expected the ISG to allow is not working.</b></summary>
### 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. These should be found in $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt created earlier.
- [Use fsutil.exe](../configure-wdac-managed-installer.md#using-fsutil-to-query-extended-attributes-for-intelligent-security-graph-isg) to verify files have the ISG origin extended attribute. If not, re-deploy the files with the managed installer and check again.
- 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](../configure-wdac-managed-installer.md#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](../use-windows-defender-application-control-with-intelligent-security-graph.md#known-limitations-with-using-the-isg).
</details>

19
windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-operational-guide.md
View File

@ -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: 03/16/2020
ms.date: 03/30/2023
ms.technology: itpro-security
ms.topic: article
---
@ -29,12 +29,17 @@ ms.topic: article
> [!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).
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.
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
| Topic | Description |
| Article | Description |
| - | - |
| [Understanding Application Control event IDs](event-id-explanations.md) | This topic explains the meaning of different WDAC event IDs. |
| [Understanding Application Control event tags](event-tag-explanations.md) | This topic explains the meaning of different WDAC event tags. |
| [Query WDAC events with Advanced hunting](querying-application-control-events-centrally-using-advanced-hunting.md) | This topic covers how to view WDAC events centrally from all systems that are connected to Microsoft Defender for Endpoint. |
| [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. |