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

Merge branch 'main' into v-jmathew-6020449

Browse Source
This commit is contained in:
Jeff Borsecnik
2022-06-02 08:27:48 -07:00
committed by GitHub
parent 91750419b7 e3a151055e
commit aa1967a9e2
413 changed files with 8600 additions and 3936 deletions
Download Patch File Download Diff File Expand all files Collapse all files

100
windows/security/threat-protection/auditing/advanced-security-auditing-faq.yml
View File

@ -1,22 +1,17 @@
### YamlMime:FAQ
metadata:
title: Advanced security auditing FAQ (Windows 10)
description: This topic for the IT professional lists questions and answers about understanding, deploying, and managing security audit policies.
ms.assetid: 80f8f187-0916-43c2-a7e8-ea712b115a06
ms.reviewer:
ms.author: dansimp
description: This article lists common questions and answers about understanding, deploying, and managing security audit policies.
ms.prod: m365-security
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.technology: mde
ms.localizationpriority: none
author: dansimp
ms.author: dansimp
manager: dansimp
audience: ITPro
ms.reviewer:
ms.collection: M365-security-compliance
ms.topic: faq
ms.date: 11/10/2021
ms.technology: mde
ms.date: 05/24/2022
title: Advanced security auditing FAQ
@ -35,36 +30,37 @@ sections:
- question: |
What is the difference between audit policies located in Local Policies\\Audit Policy and audit policies located in Advanced Audit Policy Configuration?
answer: |
The basic security audit policy settings in **Security Settings\\Local Policies\\Audit Policy** and the advanced security audit policy settings in **Security Settings\\Advanced Audit Policy Configuration\\System Audit Policies** appear to overlap, but they are recorded and applied differently. When you apply basic audit policy settings to the local computer by using the Local Security Policy snap-in (secpol.msc), you are editing the effective audit policy, so changes made to basic audit policy settings will appear exactly as configured in Auditpol.exe.
The basic security audit policy settings in **Security Settings\\Local Policies\\Audit Policy** and the advanced security audit policy settings in **Security Settings\\Advanced Audit Policy Configuration\\System Audit Policies** appear to overlap, but they're recorded and applied differently. When you apply basic audit policy settings to the local computer by using the Local Security Policy snap-in (secpol.msc), you're editing the effective audit policy. Changes made to basic audit policy settings will appear exactly as configured in Auditpol.exe.
There are a number of additional differences between the security audit policy settings in these two locations.
There are several other differences between the security audit policy settings in these two locations.
There are nine basic audit policy settings under **Security Settings\\Local Policies\\Audit Policy** and settings under **Advanced Audit Policy Configuration**. The settings available in **Security Settings\\Advanced Audit Policy
Configuration** address similar issues as the nine basic settings in **Local Policies\\Audit Policy**, but they allow administrators to be more selective in the number and types of events to audit. For example, the basic audit policy provides a single setting for account logon, and the advanced audit policy provides four. Enabling the single basic account logon setting would be the equivalent of setting all four advanced account logon settings. In comparison, setting a single advanced audit policy setting does not generate audit events for activities that you are not interested in tracking.
Configuration** address similar issues as the nine basic settings in **Local Policies\\Audit Policy**, but they allow administrators to be more selective in the number and types of events to audit. For example, the basic audit policy provides a single setting for account sign-in, and the advanced audit policy provides four. Enabling the single basic setting would be the equivalent of setting all four advanced settings. In comparison, setting a single advanced audit policy setting doesn't generate audit events for activities that you aren't interested in tracking.
In addition, if you enable success auditing for the basic **Audit account logon events** setting, only success events will be logged for all account logon–related behaviors. In comparison, depending on the needs of your organization, you can configure success auditing for one advanced account logon setting, failure auditing for a second advanced account logon setting, success and failure auditing for a third advanced account logon setting, or no auditing.
In addition, if you enable success auditing for the basic **Audit account logon events** setting, only success events will be logged for all account sign-in activities. In comparison, depending on the needs of your organization, you can configure success auditing for one advanced account logon setting, failure auditing for a second advanced account logon setting, success and failure auditing for a third advanced account logon setting, or no auditing.
The nine basic settings under **Security Settings\\Local Policies\\Audit Policy** were introduced in Windows 2000. Therefore, they are available in all versions of Windows released since then. The advanced audit policy settings were introduced in Windows Vista and Windows Server 2008. The advanced settings can only be used on computers running Windows 7, Windows Server 2008, and later.
The nine basic settings under **Security Settings\\Local Policies\\Audit Policy** and the advanced audit policy settings are available in all supported versions of Windows.
- question: |
What is the interaction between basic audit policy settings and advanced audit policy settings?
answer: |
Basic audit policy settings are not compatible with advanced audit policy settings that are applied by using Group Policy. When advanced audit policy settings are applied by using Group Policy, the current computer's audit policy settings are cleared before the resulting advanced audit policy settings are applied. After you apply advanced audit policy settings by using Group Policy, you can only reliably set system audit policy for the computer by using the advanced audit policy settings.
Basic audit policy settings aren't compatible with advanced audit policy settings that are applied by using group policy. When advanced audit policy settings are applied by using group policy, the current computer's audit policy settings are cleared before the resulting advanced audit policy settings are applied. After you apply advanced audit policy settings by using group policy, you can only reliably set system audit policy for the computer by using the advanced audit policy settings.
Editing and applying the advanced audit policy settings in Local Security Policy modifies the local Group Policy Object (GPO), so changes made here may not be exactly reflected in Auditpol.exe if there are policies from other domain GPOs or logon scripts. Both types of policies can be edited and applied by using domain GPOs, and these settings will override any conflicting local audit policy settings. However, because the basic audit policy is recorded in the effective audit policy, that audit policy must be explicitly removed when a change is desired, or it will remain in the effective audit policy. Policy changes that are applied by using local or domain Group Policy settings are reflected as soon as the new policy is applied.
Editing and applying the advanced audit policy settings in Local Security Policy modifies the local group policy object (GPO). If there are policies from other domain GPOs or logon scripts, changes made here may not be exactly reflected in Auditpol.exe. Both types of policies can be edited and applied by using domain GPOs, and these settings will override any conflicting local audit policy settings. Because the basic audit policy is recorded in the effective audit policy, that audit policy must be explicitly removed when a change is desired, or it will remain in the effective audit policy. Policy changes that are applied by using local or domain group policy settings are reflected as soon as the new policy is applied.
> **Important**  Whether you apply advanced audit policies by using Group Policy or by using logon scripts, do not use both the basic audit policy settings under **Local Policies\\Audit Policy** and the advanced settings under **Security Settings\\Advanced Audit Policy Configuration**. Using both advanced and basic audit policy settings can cause unexpected results in audit reporting.
> [!Important]
> Whether you apply advanced audit policies by using group policy or by using logon scripts, don't use both the basic audit policy settings under **Local Policies\\Audit Policy** and the advanced settings under **Security Settings\\Advanced Audit Policy Configuration**. Using both advanced and basic audit policy settings can cause unexpected results in audit reporting.
If you use Advanced Audit Policy Configuration settings or use logon scripts to apply advanced audit policies, be sure to enable the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This setting prevents conflicts between similar settings by forcing basic security auditing to be ignored.
 
If you use Advanced Audit Policy Configuration settings or use logon scripts to apply advanced audit policies, be sure to enable the **Audit: Force audit policy subcategory settings to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This setting prevents conflicts between similar settings by forcing basic security auditing to be ignored.
- question: |
How are audit settings merged by Group Policy?
How are audit settings merged by group policy?
answer: |
By default, policy options that are set in GPOs and linked to higher levels of Active Directory sites, domains, and OUs are inherited by all OUs at lower levels. However, an inherited policy can be overridden by a GPO that is linked at a lower level.
For example, you might use a domain GPO to assign an organization-wide group of audit settings, but want a certain OU to get a defined group of extra settings. To accomplish this customization, you can link a second GPO to that specific lower-level OU. Therefore, a logon audit setting that is applied at the OU level will override a conflicting logon audit setting that is applied at the domain level (unless you have taken special steps to apply Group Policy loopback processing).
For example, you might use a domain GPO to assign an organization-wide group of audit settings, but want a certain OU to get a defined group of extra settings. To accomplish this customization, you can link a second GPO to that specific lower-level OU. Therefore, a logon audit setting that is applied at the OU level will override a conflicting logon audit setting that is applied at the domain level. The only exception is if you take special steps to apply group policy loopback processing.
The rules that govern how Group Policy settings are applied propagate to the subcategory level of audit policy settings. This coverage means that audit policy settings configured in different GPOs will be merged if no policy settings configured at a lower level exist. The following table illustrates this behavior.
The rules that govern how group policy settings are applied propagate to the subcategory level of audit policy settings. This coverage means that audit policy settings configured in different GPOs will be merged if no policy settings configured at a lower level exist. The following table illustrates this behavior.
| Auditing subcategory | Setting configured in an OU GPO (higher priority) | Setting configured in a domain GPO (lower priority) | Resulting policy for the target computer |
@ -76,74 +72,68 @@ sections:
- question: |
What is the difference between an object DACL and an object SACL?
answer: |
All objects in Active Directory Domain Services (AD DS), and all securable objects on a local computer or on the network, have security descriptors to help control access to the objects. Security descriptors include information about who owns an object, who can access it and in what way, and what types of access are audited. Security descriptors contain the access control list (ACL) of an object, which includes all of the security permissions that apply to that object. An object's security descriptor can contain two types of ACLs:
All objects in Active Directory Domain Services (AD DS), and all securable objects on a local computer or on the network, have security descriptors to help control access to the objects. Security descriptors include information about who owns an object, who can access it and in what way, and what types of access are audited. Security descriptors contain the access control list (ACL) of an object, which includes all of the security permissions that apply to that object. An object's security descriptor can contain two types of ACLs:
- A discretionary access control list (DACL) that identifies the users and groups who are allowed or denied access
- A system access control list (SACL) that controls how access is audited
The access control model that is used in Windows is administered at the object level by setting different levels of access, or permissions, to objects. If permissions are configured for an object, its security descriptor contains a DACL with security identifiers (SIDs) for the users and groups that are allowed or denied access.
If auditing is configured for the object, its security descriptor also contains a SACL that controls how the security subsystem audits attempts to access the object. However, auditing is not configured entirely unless a SACL has been configured for an object and a corresponding **Object Access** audit policy setting has been configured and applied.
If auditing is configured for the object, its security descriptor also contains a SACL that controls how the security subsystem audits attempts to access the object. However, auditing isn't configured entirely unless a SACL has been configured for an object and a corresponding **Object Access** audit policy setting has been configured and applied.
- question: |
Why are audit policies applied on a per-computer basis rather than per user?
answer: |
In security auditing in Windows, the computer, objects on the computer, and related resources are the primary recipients of actions by clients including applications, other computers, and users. In a security breach, malicious users can use alternate credentials to hide their identity, or malicious applications can impersonate legitimate users to perform undesired tasks. Therefore, the most consistent way to apply an audit policy is to focus on the computer and the objects and resources on that computer.
In addition, because audit policy capabilities can vary between computers running different versions of Windows, the best way to ensure that the audit policy is applied correctly is to base these settings on the computer instead of the user.
Audit policy capabilities can vary between computers running different versions of Windows. The best way to make sure that the audit policy is applied correctly is to base these settings on the computer instead of the user.
However, when you want audit settings to apply only to specified groups of users, you can accomplish this customization by configuring SACLs on the relevant objects to enable auditing for a security group that contains only the users you specify. For example, you can configure a SACL for a folder called Payroll Data on Accounting Server 1. This configuration results in an audit of attempts by members of the Payroll Processors OU to delete objects from this folder. The **Object Access\\Audit File System** audit policy setting applies to Accounting Server 1, but because it requires a corresponding resource SACL, only actions by members of the Payroll Processors OU on the Payroll Data folder generates audit events.
However, when you want audit settings to apply only to specified groups of users, you can accomplish this customization by configuring SACLs on the relevant objects to enable auditing for a security group that contains only the users you specify. For example, you can configure a SACL for a folder called Payroll Data on Accounting Server 1. This configuration results in an audit of attempts by members of the Payroll Processors OU to delete objects from this folder. The **Object Access\\Audit File System** audit policy setting applies to Accounting Server 1. Because it requires a corresponding resource SACL, only actions by members of the Payroll Processors OU on the Payroll Data folder generates audit events.
- question: |
What are the differences in auditing functionality between versions of Windows?
Are there any differences in auditing functionality between versions of Windows?
answer: |
Basic audit policy settings are available in all versions of Windows since Windows 2000, and they can be applied locally or by using Group Policy. Advanced audit policy settings were introduced in Windows Vista and Windows Server 2008, but the settings can only be applied by using logon scripts in those versions. Advanced audit policy settings, which were introduced in Windows 7 and Windows Server 2008 R2, can be configured and applied by using local and domain Group Policy settings.
- question: |
Can I use advanced audit policies from a domain controller running Windows Server 2003 or Windows 2000 Server?
answer: |
To use advanced audit policy settings, your domain controller must be installed on a computer running Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003 with Service Pack 2 (SP2). Windows 2000 Server is not supported.
No. Basic and advanced audit policy settings are available in all supported versions of Windows. They can be configured and applied by local or domain group policy settings.
- question: |
What is the difference between success and failure events? Is something wrong if I get a failure audit?
answer: |
A success audit event is triggered when a defined action, such as accessing a file share, is completed successfully.
A failure audit event is triggered when a defined action, such as a user logon, is not completed successfully.
A failure audit event is triggered when a defined action, such as a user sign-in, isn't completed successfully.
The appearance of failure audit events in the event log does not necessarily mean that something is wrong with your system. For example, if you configure Audit Logon events, a failure event may mean that a user mistyped the password.
The appearance of failure audit events in the event log doesn't necessarily mean that something is wrong with your system. For example, if you configure Audit Logon events, a failure event may mean that a user mistyped the password.
- question: |
How can I set an audit policy that affects all objects on a computer?
answer: |
System administrators and auditors increasingly want to verify that an auditing policy is applied to all objects on a system. This requirement has been difficult to accomplish because the system access control lists (SACLs) that govern auditing are applied on a per-object basis. Thus, to verify that an audit policy has been applied to all objects, you would have to check every object to be sure that no changes have been made—even temporarily to a single SACL.
Introduced in Windows Server 2008 R2 and Windows 7, security auditing allows administrators to define global object access auditing policies for the entire file system or for the registry on a computer. The specified SACL is then automatically applied to every object of that type. This application of SACL can be useful for verifying that all critical files, folders, and registry settings on a computer are protected, and for identifying when an issue with a system resource occurs. If a file or folder SACL and a global object access auditing policy (or a single registry setting SACL and a global object access auditing policy) are configured on a computer, the effective SACL is derived from combining the file or folder SACL and the global object access auditing policy. This resultant SACL from the combination means that an audit event is generated if an activity matches either the file or folder SACL or the global object access auditing policy.
Security auditing allows administrators to define global object access auditing policies for the entire file system or for the registry on a computer. The specified SACL is then automatically applied to every object of that type. This application of SACL can be useful for verifying that all critical files, folders, and registry settings on a computer are protected. It's also useful to identify when an issue with a system resource occurs. If a file or folder SACL and a global object access auditing policy are configured on a computer, the effective SACL is derived from combining the file or folder SACL and the global object access auditing policy. This behavior also applies to a single registry setting SACL and a global object access auditing policy. This resultant SACL from the combination means that an audit event is generated if an activity matches either the file or folder SACL or the global object access auditing policy.
- question: |
How do I figure out why someone was able to access a resource?
answer: |
Often it is not enough to know simply that an object such as a file or folder was accessed. You may also want to know why the user was able to access this resource. You can obtain this forensic data by configuring the **Audit Handle Manipulation** setting with the **Audit File System** or with the **Audit Registry** audit setting.
Often it isn't enough to know simply that an object such as a file or folder was accessed. You may also want to know why the user was able to access this resource. You can obtain this forensic data by configuring the **Audit Handle Manipulation** setting with the **Audit File System** or with the **Audit Registry** audit setting.
- question: |
How do I know when changes are made to access control settings, by whom, and what the changes were?
answer: |
To track access control changes on computers running Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 Windows 7, Windows Server 2008 R2, Windows Vista, or Windows Server 2008, you need to enable the following settings, which track changes to DACLs:
To track access control changes, you need to enable the following settings, which track changes to DACLs:
- **Audit File System** subcategory: Enable for success, failure, or success and failure
- **Audit Authorization Policy Change** setting: Enable for success, failure, or success and failure
- A SACL with **Write** and **Take ownership** permissions: Apply to the object that you want to monitor
In Windows XP and Windows Server 2003, you need to use the **Audit policy change** subcategory.
- question: |
How can I roll back security audit policies from the advanced audit policy to the basic audit policy?
answer: |
Applying advanced audit policy settings replaces any comparable basic security audit policy settings. If you later change the advanced audit policy setting to **Not configured**, you need to complete the following steps to restore the original basic security audit policy settings:
1. Set all Advanced Audit Policy subcategories to **Not configured**.
2. Delete all audit.csv files from the %SYSVOL% folder on the domain controller.
2. Delete all audit.csv files from the `%SYSVOL%` folder on the domain controller.
3. Reconfigure and apply the basic audit policy settings.
Unless you complete all of these steps, the basic audit policy settings will not be restored.
Unless you complete all of these steps, the basic audit policy settings won't be restored.
- question: |
How can I monitor if changes are made to audit policy settings?
@ -166,27 +156,25 @@ sections:
- question: |
What are the best tools to model and manage audit policies?
answer: |
The integration of advanced audit policy settings with domain Group Policy, introduced in Windows 7 and Windows Server 2008 R2, is designed to simplify the management and implementation of security audit policies in an organization's network. As such, tools used to plan and deploy Group Policy Objects for a domain can also be used to plan and deploy security audit policies.
On an individual computer, the Auditpol command-line tool can be used to complete many important audit policy–related management tasks.
The integration of advanced audit policy settings with domain is designed to simplify the management and implementation of security audit policies in an organization's network. As such, tools used to plan and deploy group policy objects for a domain can also be used to plan and deploy security audit policies.
On an individual computer, the `Auditpol` command-line tool can be used to complete many important audit policy-related management tasks.
In addition, there are a number of computer management products, such as the Audit Collection Services in the Microsoft System Center Operations Manager products, which can be used to collect and filter event data.
There are also other computer management products, such as the Audit Collection Services in System Center Operations Manager, which can be used to collect and filter event data. For more information, see [How to install an Audit Collection Services (ACS) collector and database](/system-center/scom/deploy-install-acs).
- question: |
Where can I find information about all the possible events that I might receive?
answer: |
Users who examine the security event log for the first time can be a bit overwhelmed by the number of audit events that are stored there (which can quickly number in the thousands) and by the structured information that is included for each audit event. Additional information about these events, and the settings used to generate them, can be obtained from the following resources:
Users who examine the security event log for the first time can be a bit overwhelmed. The number of audit events that are stored there can quickly number in the thousands. The structured information that's included for each audit event can also be confusing. For more information about these events, and the settings used to generate them, see the following resources:
- [Windows 8 and Windows Server 2012 Security Event Details](https://www.microsoft.com/download/details.aspx?id=35753)
- [Security Audit Events for Windows 7 and Windows Server 2008 R2](https://go.microsoft.com/fwlink/p/?linkid=157780)
- [Security Audit Events for Windows Server 2008 and Windows Vista](https://go.microsoft.com/fwlink/p/?linkid=121868)
- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
- [Windows security audit events](https://www.microsoft.com/download/details.aspx?id=50034)
- [Windows 10 and Windows Server 2016 security auditing and monitoring reference](https://www.microsoft.com/download/details.aspx?id=52630)
- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
- question: |
Where can I find more detailed information?
answer: |
To learn more about security audit policies, see the following resources:
- [Planning and deploying advanced security audit policies](planning-and-deploying-advanced-security-audit-policies.md)
- [Security Monitoring and Attack Detection Planning Guide](https://social.technet.microsoft.com/wiki/contents/articles/325.advanced-security-auditing-in-windows-7-and-windows-server-2008-r2.aspx)
- [Security Audit Events for Windows 7 and Windows Server 2008 R2](https://go.microsoft.com/fwlink/p/?linkid=157780)
- [Security Audit Events for Windows Server 2008 and Windows Vista](https://go.microsoft.com/fwlink/p/?LinkId=121868)
- [Planning and deploying advanced security audit policies](planning-and-deploying-advanced-security-audit-policies.md)
- [Windows 8 and Windows Server 2012 security event details](https://www.microsoft.com/download/details.aspx?id=35753)
- [Security audit events for Windows 7 and Windows Server 2008 R2](https://www.microsoft.com/download/details.aspx?id=21561)

1
windows/security/threat-protection/microsoft-defender-smartscreen/microsoft-defender-smartscreen-overview.md
View File

@ -12,6 +12,7 @@ ms.localizationpriority: high
ms.reviewer:
manager: dansimp
ms.technology: windows-sec
adobe-target: true
---
# Microsoft Defender SmartScreen

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

@ -1,21 +1,16 @@
---
title: Understanding Application Control event IDs (Windows)
description: Learn what different Windows Defender Application Control event IDs signify.
keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.technology: windows-sec
ms.localizationpriority: medium
audience: ITPro
ms.collection: M365-security-compliance
author: jsuther1974
ms.reviewer: jogeurte
ms.author: dansimp
manager: dansimp
ms.date: 05/09/2022
ms.technology: windows-sec
ms.topic: reference
---
# Understanding Application Control events
@ -26,44 +21,44 @@ ms.technology: windows-sec
- Windows 11
- Windows Server 2016 and later (limited events)
A Windows Defender Application Control (WDAC) policy logs events locally in Windows Event Viewer in either enforced or audit mode. These events are generated under two locations:
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:
- Events about WDAC policy activation and the control of executables, dlls, and drivers appear in **Applications and Services logs** > **Microsoft** > **Windows** > **CodeIntegrity** > **Operational**
- Events about Application Control policy activation and the control of executables, dlls, and drivers appear in **Applications and Services logs** > **Microsoft** > **Windows** > **CodeIntegrity** > **Operational**
- Events about the control of MSI installers, scripts, and COM objects appear in **Applications and Services logs** > **Microsoft** > **Windows** > **AppLocker** > **MSI and Script**
> [!NOTE]
> These event IDs are not included on Windows Server Core edition.
## WDAC events found in the Microsoft Windows CodeIntegrity Operational log
## Windows CodeIntegrity Operational log
| Event ID | Explanation |
|--------|-----------|
| 3004 | This event isn't common and may occur with or without a WDAC 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. |
| 3034 | This event isn't common. It is the audit mode equivalent of event 3033 described above. |
| 3076 | This event is the main WDAC block event for audit mode policies. It indicates that the file would have been blocked if the WDAC policy was enforced. |
| 3077 | This event is the main WDAC block event for enforced policies. It indicates that the file did not pass your WDAC policy and was blocked. |
| 3089 | This event contains signature information for files that were blocked or would have been blocked by WDAC. 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 WDAC policy options that were specified by the WDAC policy. |
| 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. |
| 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. |
## WDAC events found in the Microsoft Windows AppLocker MSI and Script log
## Windows AppLocker MSI and Script log
| Event ID | Explanation |
|--------|-----------|
| 8028 | This event indicates that a script host, such as PowerShell, queried WDAC about a file the script host was about to run. Since the WDAC 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 do not integrate with WDAC. 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. 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.md). |
| 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). |
| 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. |
| 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. |
## Diagnostic events for Intelligent Security Graph (ISG) and Managed Installer (MI)
Events 3090, 3091 and 3092 prove helpful diagnostic information when the ISG or MI option is enabled by any WDAC policy. These events can help you debug why something was allowed/denied based on managed installer or ISG. These events do not necessarily indicate a problem but should be reviewed in context with other events like 3076 or 3077 described above.
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.
| 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 did not have ISG or managed installer authorization and the WDAC policy is in audit mode. |
| 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. |
The above events are reported per active policy on the system, so you may see multiple events for the same file.
@ -78,8 +73,8 @@ The following information is found in the details for 3090, 3091, and 3092 event
| 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 WDAC policy is in audit mode, otherwise it is in enforce mode |
| PolicyName | The name of the WDAC policy to which the event applies |
| 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
@ -93,29 +88,30 @@ reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x
## Event ID 3099 Options
The WDAC 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.
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
- 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":::
:::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.
- Open the Calculator app
- Click on the menu icon :::image type="content" source="images/calculator-menu-icon.png" alt-text="calculator menu icon example":::
- Click Programmer mode
- Click HEX :::image type="content" source="images/hex-icon.png" alt-text="HEX icon example":::
- Enter your hex code
- Click Bit Toggling Keyboard :::image type="content" source="images/bit-toggling-keyboard-icon.png" alt-text="Bit Toggling Keyboard icon example":::
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":::
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)” is in the policy meaning the policy is in audit mode.
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 |
|-------|------|
@ -147,46 +143,46 @@ 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 could not verify the boot image as the page hash could not be found. |
| 3004 | Code Integrity could not verify the file as the page hash could not be found. |
| 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 did not meet the requirements to pass the application control policy. |
| 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.
| 3033 | The file under validation did not meet the requirements to pass the application control policy. |
| 3034 | The file under validation would not meet the requirements to pass the application control policy if the WDAC policy was enforced. The file was allowed since the WDAC 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. |
| 3064 | If the WDAC policy was enforced, a user mode DLL under validation would not meet the requirements to pass the application control policy. The DLL was allowed since the WDAC policy is in audit mode. |
| 3065 | If the WDAC policy was enforced, a user mode DLL under validation would not meet the requirements to pass the application control policy. |
| 3032 | The file under validation is revoked by the system or the file has a signature that has been 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. |
| 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 WDAC policy check during file validation. |
| 3076 | This event is the main WDAC block event for audit mode policies. It indicates that the file would have been blocked if the WDAC policy was enforced. |
| 3077 | This event is the main WDAC block event for enforced policies. It indicates that the file did not pass your WDAC policy and was blocked. |
| 3079 | The file under validation did not meet the requirements to pass the application control policy. |
| 3080 | If the WDAC policy was in enforced mode, the file under validation would not have met the requirements to pass the application control policy. |
| 3081 | The file under validation did not meet the requirements to pass the application control policy. |
| 3082 | If the WDAC policy was in enforced mode, the non-WHQL driver would have been denied by the WDAC policy. |
| 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 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 will not enforce the WHQL driver signing requirements on this boot session. |
| 3086 | The file under validation does not 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 WDAC. One 3089 event is created for each signature of a file. |
| 3085 | Code Integrity won't enforce the 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. |
| 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 did not have ISG or managed installer authorization and the WDAC policy is in audit mode. |
| 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 WDAC policy cannot be refreshed and must be rebooted instead. |
| 3096 | The WDAC policy was not refreshed since it is already up-to-date. |
| 3097 | The WDAC policy cannot be refreshed. |
| 3099 | Indicates that a policy has been loaded. This event also includes information about the WDAC policy options that were specified by the WDAC policy. |
| 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. |
| 3100 | The application control policy was refreshed but was unsuccessfully activated. Retry. |
| 3101 | The system started refreshing the WDAC policy. |
| 3102 | The system finished refreshing the WDAC policy. |
| 3103 | The system is ignoring the WDAC policy refresh. |
| 3104 | The file under validation does not meet the signing requirements for a PPL (protected process light) process. |
| 3105 | The system is attempting to refresh the WDAC policy. |
| 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 did not meet the hypervisor-protected code integrity (HVCI) policy. |
| 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. |

34
windows/security/threat-protection/windows-defender-application-control/wdac-wizard.md
View File

@ -1,22 +1,16 @@
---
title: Windows Defender Application Control Wizard
description: Microsoft Defender Application Control Wizard (WDAC) Wizard allows users to create, edit, and merge application control policies in a simple to use Windows application.
keywords: allowlisting, blocklisting, security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
description: The Windows Defender Application Control policy wizard tool allows you to create, edit, and merge application control policies in a simple to use Windows application.
ms.prod: m365-security
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.technology: windows-sec
ms.localizationpriority: medium
audience: ITPro
ms.collection: M365-security-compliance
author: jgeurten
ms.reviewer: isbrahm
ms.author: dansimp
manager: dansimp
ms.topic: conceptual
ms.date: 10/14/2020
ms.technology: windows-sec
ms.date: 05/24/2022
---
# Windows Defender Application Control Wizard
@ -30,26 +24,26 @@ ms.technology: windows-sec
> [!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).
The Windows Defender Application Control (WDAC) policy Wizard is an open-source Windows desktop application written in C# and bundled as an MSIX package. The Wizard was built to provide security architects with security, and system administrators with a more user-friendly means to create, edit, and merge WDAC policies. The Wizard desktop application uses the [ConfigCI PowerShell Cmdlets](/powershell/module/configci) in the backend so the output policy of the Wizard and PowerShell cmdlets is identical.
The Windows Defender Application Control policy wizard is an open-source Windows desktop application written in C# and bundled as an MSIX package. It was built to provide security architects with security, and system administrators with a more user-friendly means to create, edit, and merge Application Control policies. This tool uses the [ConfigCI PowerShell cmdlets](/powershell/module/configci) in the backend so the output policy of the tool and PowerShell cmdlets is identical.
## Downloading the application
The WDAC Wizard can be downloaded from the official [Wizard installer website](https://bit.ly/3koHwYs) as an MSIX packaged application. The Wizard's source code is available as part of Microsoft's Open Source Software offerings on GitHub at the [WDAC Wizard Repo](https://github.com/MicrosoftDocs/WDAC-Toolkit).
Download the tool from the official [Windows Defender Application Control Policy Wizard website](https://webapp-wdac-wizard.azurewebsites.net/) as an MSIX packaged application. The tool's source code is available as part of Microsoft's Open Source Software offerings on GitHub at the [WDAC Policy Wizard repository](https://github.com/MicrosoftDocs/WDAC-Toolkit).
**Supported Clients**
### Supported clients
As the WDAC Wizard uses the cmdlets in the background, the Wizard is functional on clients only where the cmdlets are supported as outlined in [WDAC feature availability](feature-availability.md). Specifically, the tool will verify that the client meets one of the following requirements:
As the tool uses the cmdlets in the background, it's functional on clients only where the cmdlets are supported. For more information, see [Application Control feature availability](feature-availability.md). Specifically, the tool verifies that the client meets one of the following requirements:
- Windows builds 1909+
- For pre-1909 builds, the Enterprise SKU of Windows is installed
- Windows 10, version 1909 or later
- For pre-1909 builds, the Enterprise SKU of Windows is installed
If neither requirement is satisfied, the Wizard will throw an error as the cmdlets are not available.
If neither requirement is satisfied, it throws an error as the cmdlets aren't available.
## In this section
## Resources to learn more
| Topic | Description |
| Article | Description |
| - | - |
| [Creating a new base policy](wdac-wizard-create-base-policy.md) | This article describes how to create a new base policy using one of the supplied policy templates. |
| [Creating a new supplemental policy](wdac-wizard-create-supplemental-policy.md) | This article describes the steps necessary to create a supplemental policy, from one of the supplied templates, for an existing base policy. |
| [Editing a base or supplemental policy](wdac-wizard-editing-policy.md) | This article demonstrates how to modify an existing policy and the Wizard's editing capabilities. |
| [Merging policies](wdac-wizard-merging-policies.md) | This article describes how to merge policies into a single application control policy. |
| [Editing a base or supplemental policy](wdac-wizard-editing-policy.md) | This article demonstrates how to modify an existing policy and the tool's editing capabilities. |
| [Merging policies](wdac-wizard-merging-policies.md) | This article describes how to merge policies into a single application control policy. |