mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 19:03:46 +00:00
Justin Hall
GitHub
@ -13,10 +13,13 @@
|
||||
### [Types of devices](types-of-devices.md)
|
||||
###Use WDAC with custom policies
|
||||
#### [Create an initial default policy](create-initial-default-policy.md)
|
||||
#### [Create path-based rules](create-path-based-rules.md)
|
||||
#### [Microsoft recommended block rules](microsoft-recommended-block-rules.md)
|
||||
### [Audit WDAC policies](audit-windows-defender-application-control-policies.md)
|
||||
### [Merge WDAC policies](merge-windows-defender-application-control-policies.md)
|
||||
### [Deploy multiple WDAC policies](deploy-multiple-windows-defender-application-control-policies.md)
|
||||
### [Enforce WDAC policies](enforce-windows-defender-application-control-policies.md)
|
||||
### [Allow COM object registration](allow-com-object-registration-in-windows-defender-application-control-policy.md)
|
||||
### [Deploy WDAC with a managed installer](use-windows-defender-application-control-with-managed-installer.md)
|
||||
### [Deploy WDAC with Intelligent Security Graph (ISG)](use-windows-defender-application-control-with-intelligent-security-graph.md)
|
||||
### [Deploy WDAC policies using Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md)
|
||||
|
||||
@ -0,0 +1,77 @@
|
||||
---
|
||||
title: Allow COM object registration in a Windows Defender Application Control policy (Windows 10)
|
||||
description: You can allow COM object registration in a Windows Defender Application Control policy.
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
ms.localizationpriority: medium
|
||||
author: mdsakibMSFT
|
||||
ms.date: 05/17/2019
|
||||
---
|
||||
|
||||
# Allow COM object registration in a Windows Defender Application Control policy
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10
|
||||
- Windows Server 2016
|
||||
|
||||
>[!IMPORTANT]
|
||||
>Some information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
|
||||
|
||||
The [Microsoft Component Object Model (COM)](https://docs.microsoft.com/windows/desktop/com/the-component-object-model) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM specifies an object model and programming requirements that enable COM objects to interact with other objects.
|
||||
|
||||
### COM object configurability in WDAC policy
|
||||
|
||||
Prior to the Windows 10 1903 update, Windows Defender Application Control (WDAC) enforced a built-in allow list for COM object registration. While this mechanism works for most common application usage scenarios, customers have provided feedback that there are cases where additional COM objects need to be allowed. The 1903 update to Windows 10 introduces the ability to specify allowed COM objects via their GUID in the WDAC policy.
|
||||
|
||||
### Get COM object GUID
|
||||
|
||||
Get GUID of application to allow in one of the following ways:
|
||||
- Finding block event in Event Viewer (Application and Service Logs > Microsoft > Windows > AppLocker > MSI and Script) and extracting GUID
|
||||
- Creating audit policy (using New-CIPolicy –Audit), potentially with specific provider, and use info from block events to get GUID
|
||||
|
||||
### Author policy setting to allow or deny COM object GUID
|
||||
|
||||
Three elements:
|
||||
- Provider: platform on which code is running (values are Powershell, WSH, IE, VBA, MSI, or a wildcard “AllHostIds”)
|
||||
- Key: GUID for the program you with to run, in the format Key="{33333333-4444-4444-1616-161616161616}"
|
||||
- ValueName: needs to be set to "EnterpriseDefinedClsId"
|
||||
|
||||
One attribute:
|
||||
- Value: needs to be “true” for allow and “false” for deny
|
||||
- Note that deny only works in base policies, not supplemental
|
||||
- The setting needs to be placed in the order of ASCII values (first by Provider, then Key, then ValueName)
|
||||
|
||||
### Examples
|
||||
|
||||
Example 1: Allows registration of all COM object GUIDs in any provider
|
||||
|
||||
```xml
|
||||
<Setting Provider="AllHostIds" Key="AllKeys" ValueName="EnterpriseDefinedClsId">
|
||||
<Value>
|
||||
<Boolean>true</Boolean>
|
||||
</Value>
|
||||
</Setting>
|
||||
```
|
||||
|
||||
Example 2: Blocks a specific COM object from being registered via Internet Explorer (IE)
|
||||
|
||||
```xml
|
||||
<Setting Provider="IE" Key="{00000000-4444-4444-1616-161616161616}" ValueName="EnterpriseDefinedClsId">
|
||||
<Value>
|
||||
<Boolean>false</Boolean>
|
||||
</Value>
|
||||
</Setting>
|
||||
|
||||
Example 3: Allows a specific COM object to register in PowerShell
|
||||
|
||||
```xml
|
||||
<Setting Provider="PowerShell" Key="{33333333-4444-4444-1616-161616161616}" ValueName="EnterpriseDefinedClsId">
|
||||
<Value>
|
||||
<Boolean>true</Boolean>
|
||||
</Value>
|
||||
</Setting>
|
||||
```
|
||||
|
||||
@ -0,0 +1,65 @@
|
||||
---
|
||||
title: Windows Defender Application Control path-based rules (Windows 10)
|
||||
description: Beginning with Windows 10 version 1903, Windows Defender Application Control (WDAC) policies can contain path-based rules.
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
ms.localizationpriority: medium
|
||||
author: mdsakibMSFT
|
||||
ms.date: 05/17/2019
|
||||
---
|
||||
|
||||
# Create Windows Defender Application Control path-based rules
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10
|
||||
- Windows Server 2016
|
||||
|
||||
>[!IMPORTANT]
|
||||
>Some information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
|
||||
|
||||
Beginning with Windows 10 version 1903, Windows Defender Application Control (WDAC) policies can contain path-based rules.
|
||||
|
||||
- New-CIPolicy parameters
|
||||
- FilePath: create path rules under path \<path to scan> for anything not user-writeable (at the individual file level)
|
||||
|
||||
```powershell
|
||||
New-CIPolicy -f .\mypolicy.xml -l FilePath -s <path to scan> -u
|
||||
```
|
||||
|
||||
Optionally, add -UserWriteablePaths to ignore user writeability
|
||||
|
||||
- FilePathRule: create a rule where filepath string is directly set to value of \<any path string>
|
||||
|
||||
```powershell
|
||||
New-CIPolicyRule -FilePathRule <any path string>
|
||||
```
|
||||
|
||||
Useful for wildcards like C:\foo\\*
|
||||
|
||||
- Usage follows the same flow as per-app rules:
|
||||
|
||||
```powershell
|
||||
$rules = New-CIPolicyRule …
|
||||
$rules += New-CIPolicyRule …
|
||||
…
|
||||
New-CIPolicyRule -f .\mypolicy.xml -u
|
||||
```
|
||||
|
||||
- Wildcards supported
|
||||
- Suffix (ex. C:\foo\\*) OR Prefix (ex. *\foo\bar.exe)
|
||||
- One or the other, not both at the same time
|
||||
- Does not support wildcard in the middle (ex. C:\\*\foo.exe)
|
||||
- Examples:
|
||||
- %WINDIR%\\...
|
||||
- %SYSTEM32%\\...
|
||||
- %OSDRIVE%\\...
|
||||
|
||||
- Disable default FilePath rule protection of enforcing user-writeability. For example, to add “Disabled:Runtime FilePath Rule Protection” to the policy:
|
||||
|
||||
```powershell
|
||||
Set-RuleOption -o 18 .\policy.xml
|
||||
```
|
||||
|
||||
@ -0,0 +1,79 @@
|
||||
---
|
||||
title: Deploy multiple Windows Defender Application Control Policies (Windows 10)
|
||||
description: Windows Defender Application Control supports multiple code integrity policies for one device.
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
ms.localizationpriority: medium
|
||||
author: mdsakibMSFT
|
||||
ms.date: 05/17/2019
|
||||
---
|
||||
|
||||
# Deploy multiple Windows Defender Application Control Policies
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10
|
||||
- Windows Server 2016
|
||||
|
||||
>[!IMPORTANT]
|
||||
>Some information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
|
||||
|
||||
The restriction of only having a single code integrity policy active on a system at any given time has felt limiting for customers in situations where multiple policies with different intents would be useful. Beginning with Windows 10 version 1903, WDAC supports multiple simultaneous code integrity policies for one device in order to enable the following scenarios:
|
||||
|
||||
1. Enforce and Audit Side-by-Side
|
||||
- To validate policy changes before deploying in enforcement mode, users can now deploy an audit-mode base policy side-by-side with an existing enforcement-mode base policy
|
||||
2. Multiple Base Policies
|
||||
- Users can enforce two or more base policies simultaneously in order to allow simpler policy targeting for policies with different scope/intent
|
||||
- If two base policies exist on a device, an application has to be allowed by both to run
|
||||
3. Supplemental Policies
|
||||
- Users can deploy one or more supplemental policies to expand a base policy
|
||||
- A supplemental policy expands a single base policy, and multiple supplemental policies can expand the same base policy
|
||||
- For supplemental policies, applications that are allowed by either the base policy or its supplemental policy/policies are allowed to run
|
||||
|
||||
## How do Base and Supplemental Policies Interact?
|
||||
|
||||
- Multiple base policies: intersection
|
||||
- Only applications allowed by both policies run without generating block events
|
||||
- Base + supplemental policy: union
|
||||
- Files that are allowed by the base policy or the supplemental policy are not blocked
|
||||
|
||||
Note that multiple policies will not work on pre-1903 systems.
|
||||
|
||||
### Allow Multiple Policies
|
||||
|
||||
In order to allow multiple policies to exist and take effect on a single system, policies must be created using the new Multiple Policy Format. The "MultiplePolicyFormat" switch in New-CIPolicy results in 1) random GUIDs being generated for the policy ID and 2) the policy type being specified as base.
|
||||
|
||||
```powershell
|
||||
New-CIPolicy -MultiplePolicyFormat -foo –bar
|
||||
```
|
||||
|
||||
Optionally, you can choose to make the new base policy supplementable (allow supplemental policies).
|
||||
|
||||
```powershell
|
||||
Set-RuleOption -FilePath <string> Enabled:Allow Supplemental Policies
|
||||
```
|
||||
|
||||
For signed base policies that are being made supplementable, you need to ensure that supplemental signers are defined. Use the "Supplemental" switch in Add-SignerRule to provide supplemental signers.
|
||||
|
||||
```powershell
|
||||
Add-SignerRule -FilePath <string> -CertificatePath <string> [-Kernel] [-User] [-Update] [-Supplemental] [-Deny] [<CommonParameters>]
|
||||
```
|
||||
|
||||
### Supplemental Policy Creation
|
||||
|
||||
In order to create a supplemental policy, begin by creating a new policy in the Multiple Policy Format. From there, use Set-CIPolicyIdInfo to convert it to a supplemental policy and specify which base policy it expands.
|
||||
- "SupplementsBasePolicyID": guid of new supplemental policy
|
||||
- "BasePolicyToSupplementPath": base policy that the supplemental policy applies to
|
||||
|
||||
```powershell
|
||||
Set-CIPolicyIdInfo [-FilePath] <string> [-PolicyName <string>] [-SupplementsBasePolicyID <guid>] [-BasePolicyToSupplementPath <string>] [-ResetPolicyID] [-PolicyId <string>] [<CommonParameters>]
|
||||
```
|
||||
|
||||
Note that "ResetPolicyId" reverts a supplemental policy to a base policy, and resets the policy guids back to a random guid.
|
||||
|
||||
### Merging policies
|
||||
|
||||
When merging, the policy type and ID of the leftmost/first policy specified is used. If the leftmost is a base policy with ID <ID>, then regardless of what the GUIDS and types are for any subsequent policies, the merged policy will be a base policy with ID <ID>.
|
||||
|
||||
@ -8,26 +8,26 @@ ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
ms.localizationpriority: medium
|
||||
author: jsuther1974
|
||||
ms.date: 05/03/2018
|
||||
ms.date: 05/14/2019
|
||||
---
|
||||
|
||||
# Manage packaged apps with Windows Defender Application Control
|
||||
# Manage Packaged Apps with Windows Defender Application Control
|
||||
|
||||
**Applies to:**
|
||||
|
||||
- Windows 10
|
||||
- Windows Server 2016
|
||||
|
||||
This topic for IT professionals describes concepts and lists procedures to help you manage Packaged apps with Windows Defender Application Control (WDAC) as part of your overall application control strategy.
|
||||
This topic for IT professionals describes concepts and lists procedures to help you manage packaged apps with Windows Defender Application Control (WDAC) as part of your overall application control strategy.
|
||||
|
||||
## Understanding Packaged apps and Packaged app installers
|
||||
## Understanding Packaged Apps and Packaged App Installers
|
||||
|
||||
Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity. With classic Windows apps, each file within the app could have a unique identity.
|
||||
With packaged apps, it is possible to control the entire app by using a single WDAC rule.
|
||||
|
||||
Typically, an app consists of multiple components: the installer that is used to install the app, and one or more exes, dlls, or scripts. With classic Windows apps, these components don't always share common attributes such as the software’s publisher name, product name, and product version. Therefore, WDAC controls each of these components separately through different rule collections, such as exe, dll, script, and Windows Installer rules. In contrast, all the components of a packaged app share the same publisher name, package name, and package version attributes. Therefore, you can control an entire app with a single rule.
|
||||
|
||||
### <a href="" id="bkmk-compareclassicmetro"></a>Comparing classic Windows apps and packaged apps
|
||||
### <a href="" id="bkmk-compareclassicmetro"></a>Comparing classic Windows Apps and Packaged Apps
|
||||
|
||||
WDAC policies for packaged apps can only be applied to apps installed on computers running at least Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least Windows Server
|
||||
2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced in tandem. The differences between packaged apps and classic Windows apps that you should consider include:
|
||||
@ -38,13 +38,101 @@ WDAC policies for packaged apps can only be applied to apps installed on compute
|
||||
|
||||
WDAC uses different rule collections to control packaged apps and classic Windows apps. You have the choice to control one type, the other type, or both.
|
||||
|
||||
## Using WDAC to manage packaged apps
|
||||
## Using WDAC to Manage Packaged Apps
|
||||
|
||||
Just as there are differences in managing each rule collection, you need to manage the packaged apps with the following strategy:
|
||||
|
||||
1. Gather information about which Packaged apps are running in your environment.
|
||||
1. Gather information about which packaged apps are running in your environment.
|
||||
|
||||
2. Create WDAC rules for specific packaged apps based on your policy strategies. For more information, see [Deploy WDAC policy rules and file rules](select-types-of-rules-to-create.md).
|
||||
|
||||
3. Continue to update the WDAC policies as new package apps are introduced into your environment. To do this, see [Merge WDAC policies](merge-windows-defender-application-control-policies.md).
|
||||
|
||||
## Blocking Packaged Apps
|
||||
|
||||
You can now use `New-CIPolicyRule -Package $Package -Deny` to block packaged apps.
|
||||
|
||||
### Blocking Packaged Apps Which Are Installed on the System
|
||||
|
||||
Below are the list of steps you can follow to block one or more packaged apps in the case that the apps are on the system you are using the WDAC PowerShell cmdlets on:
|
||||
|
||||
1. Get the app identifier for an installed package
|
||||
|
||||
```powershell
|
||||
$package = Get-AppxPackage -name <example_app>
|
||||
```
|
||||
2. Make a rule by using the New-CIPolicyRule cmdlet
|
||||
|
||||
```powershell
|
||||
$Rule = New-CIPolicyRule -Package $package -deny
|
||||
```
|
||||
3. Repeat for other packages you want to block using $rule +=…
|
||||
|
||||
4. Make a policy for just the blocks you created for packages
|
||||
|
||||
```powershell
|
||||
New-CIpolicy -rules $rule -f .\policy.xml -u
|
||||
```
|
||||
|
||||
5. Merge with an existing policy that authorizes the other applications and system components required for your scenario. Here we use the sample Allow Windows policy
|
||||
|
||||
```powershell
|
||||
Merge-CIPolicy -PolicyPaths .\policy.xml,C:\windows\Schemas\codeintegrity\examplepolicies\DefaultWindows_Audit.xml -o allowWindowsDenyPackages.xml
|
||||
```
|
||||
|
||||
6. Disable audit mode if needed
|
||||
|
||||
```powershell
|
||||
Set-RuleOption -o 3 -Delete .\allowWindowsDenyPackages.xml
|
||||
```
|
||||
|
||||
7. Enable invalidate EAs on reboot
|
||||
|
||||
```powershell
|
||||
Set-RuleOption -o 15 .\allowWindowsDenyPackages.xml
|
||||
```
|
||||
|
||||
8. Compile the policy
|
||||
|
||||
```powershell
|
||||
ConvertFrom-CIPolicy .\AllowWindowsDenyPackages.xml C:\compiledpolicy.bin
|
||||
```
|
||||
|
||||
9. Install the policy without restarting
|
||||
|
||||
```powershell
|
||||
Invoke-CimMethod -Namespace root\Microsoft\Windows\CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{FilePath = "C:\compiledpolicy.bin"}
|
||||
```
|
||||
### Blocking Packaged Apps Which Are Not Installed on the System
|
||||
|
||||
If the app you intend to block is not installed on the system you are using the WDAC PowerShell cmdlets on, then follow the steps below:
|
||||
|
||||
1. Create a dummy rule using Steps 1-5 in the Blocking Packaged Apps Which Are Installed on the System section above
|
||||
|
||||
2. Navigate to the app you want to block on the Store website
|
||||
|
||||
3. Copy the GUID in the URL for the app
|
||||
- Example: the GUID for the Microsoft To-Do app is 9nblggh5r558
|
||||
- https://www.microsoft.com/en-us/p/microsoft-to-do-list-task-reminder/9nblggh5r558?activetab=pivot:overviewtab
|
||||
4. Use the GUID in the following REST query URL to retrieve the identifiers for the app
|
||||
- Example: for the Microsoft To-Do app, the URL would be https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9nblggh5r558/applockerdata
|
||||
- The URL will return:
|
||||
|
||||
```
|
||||
{ "packageFamilyName": "Microsoft.Todos_8wekyb3d8bbwe",
|
||||
"packageIdentityName": "Microsoft.Todos",
|
||||
"windowsPhoneLegacyId": "6088f001-776c-462e-984d-25b6399c6607",
|
||||
"publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
|
||||
}
|
||||
```
|
||||
|
||||
5. Use the value returned by the query URL for the packageFamilyName to replace the package name generated earlier in the dummy rule from Step 1.
|
||||
|
||||
## Allowing Packaged Apps
|
||||
The method for allowing specific packaged apps is similar to the method outlined above for blocking packaged apps, with the only difference being the parameter to the New-CIPolicyRule cmdlet.
|
||||
|
||||
```powershell
|
||||
$Rule = New-CIPolicyRule -Package $package -allow
|
||||
```
|
||||
|
||||
Since a lot of system apps are packaged apps, it is generally advised that customers rely on the sample policies in C:\Windows\schemas\CodeIntegrity\ExamplePolicies to help allow all inbox apps by the Store signature already included in the policies and control apps with deny rules.
|
||||
|
||||
@ -23,8 +23,6 @@ Windows Defender Application Control (WDAC) provides control over a computer run
|
||||
|
||||
A common system imaging practice in today’s IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone additional company assets. WDAC policies follow a similar methodology, that begins with the establishment of a golden computer. As with imaging, you can have multiple golden computers based on model, department, application set, and so on. Although the thought process around the creation of WDAC policies is similar to imaging, these policies should be maintained independently. Assess the necessity of additional WDAC policies based on what should be allowed to be installed and run and for whom. For more details on doing this assessment, see the [WDAC Design Guide](windows-defender-application-control-design-guide.md).
|
||||
|
||||
> **Note** Each computer can have only **one** WDAC policy at a time. Whichever way you deploy this policy, it is renamed to SIPolicy.p7b and copied to **C:\\Windows\\System32\\CodeIntegrity** and, for UEFI computers, **<EFI System Partition>\\Microsoft\\Boot**. Keep this in mind when you create your WDAC policies.
|
||||
|
||||
Optionally, WDAC can align with your software catalog as well as any IT department–approved applications. One straightforward method to implement WDAC is to use existing images to create one master WDAC policy. You do so by creating a WDAC policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, if the applications are installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computer’s role or department. Organizations have a choice of how their policies are created, merged or serviced, and managed.
|
||||
|
||||
If you plan to use an internal CA to sign catalog files or WDAC policies, see the steps in [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md).
|
||||
@ -103,4 +101,50 @@ To create the WDAC policy, they build a reference server on their standard hardw
|
||||
|
||||
As part of normal operations, they will eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they will not need to update their WDAC policy. If they come to a time when the internally-written, unsigned application must be updated, they must also update the WDAC policy so that the hash in the policy matches the hash of the updated internal application.
|
||||
|
||||
They could also choose to create a catalog that captures information about the unsigned internal application, then sign and distribute the catalog. Then the internal application could be handled by WDAC policies in the same way as any other signed application. An update to the internal application would only require that the catalog be regenerated, signed, and distributed (no restarts would be required).
|
||||
They could also choose to create a catalog that captures information about the unsigned internal application, then sign and distribute the catalog. Then the internal application could be handled by WDAC policies in the same way as any other signed application. An update to the internal application would only require that the catalog be regenerated, signed, and distributed (no restarts would be required).
|
||||
|
||||
## Create path-based rules
|
||||
|
||||
Beginning with Windows 10 version 1903, Windows Defender Application Control (WDAC) policies can contain path-based rules.
|
||||
|
||||
- New-CIPolicy parameters
|
||||
- FilePath: create path rules under path \<path to scan> for anything not user-writeable (at the individual file level)
|
||||
|
||||
```powershell
|
||||
New-CIPolicy -f .\mypolicy.xml -l FilePath -s <path to scan> -u
|
||||
```
|
||||
|
||||
Optionally, add -UserWriteablePaths to ignore user writeability
|
||||
|
||||
- FilePathRule: create a rule where filepath string is directly set to value of \<any path string>
|
||||
|
||||
```powershell
|
||||
New-CIPolicyRule -FilePathRule <any path string>
|
||||
```
|
||||
|
||||
Useful for wildcards like C:\foo\\*
|
||||
|
||||
- Usage follows the same flow as per-app rules:
|
||||
|
||||
```powershell
|
||||
$rules = New-CIPolicyRule …
|
||||
$rules += New-CIPolicyRule …
|
||||
…
|
||||
New-CIPolicyRule -f .\mypolicy.xml -u
|
||||
```
|
||||
|
||||
- Wildcards supported
|
||||
- Suffix (ex. C:\foo\\*) OR Prefix (ex. *\foo\bar.exe)
|
||||
- One or the other, not both at the same time
|
||||
- Does not support wildcard in the middle (ex. C:\\*\foo.exe)
|
||||
- Examples:
|
||||
- %WINDIR%\\...
|
||||
- %SYSTEM32%\\...
|
||||
- %OSDRIVE%\\...
|
||||
|
||||
- Disable default FilePath rule protection of enforcing user-writeability. For example, to add “Disabled:Runtime FilePath Rule Protection” to the policy:
|
||||
|
||||
```powershell
|
||||
Set-RuleOption -o 18 .\policy.xml
|
||||
```
|
||||
|
||||
|
||||
Reference in New Issue
Block a user