Examples of script control exclusions
Adding exclusions for dynamic scripts that are run from a specific directory location or for a script that is run from multiple different user folders is possible by using wildcards in script control exclusions. As an example, you can use the token “*” in the exception path to ensure it covers your variants.
The following table includes some example exclusions with matches that would be successfully excluded, and non-matches that won't be excluded.
These folders won't be excluded because the number of folder levels don't match.
These folders won't be excluded because wildcards represent one or more characters.
This script won't be excluded because wildcards represent one or more characters.
This script won't be excluded because the number of folder levels don't match.
You can add processes to the list of script control exclusions. This feature can be useful if you want to exclude specific processes that may be calling scripts. For example, you can exclude SCCM to allow it to launch PowerShell scripts in a temporary directory. A process is any process that calls a script interpreter to run a script.
- The following example allows the myfile.exe process to call an interpreter (such as PowerShell.exe) to run a script.
- The following examples add myprocess.exe to the exclusion list so that it is allowed to run regardless of its folder path:
- \myprocess.exe(on a local Windows drive)
- \\myprocess.exe(on a network Windows drive)
- The following example adds myprocess.exe to the exclusion list so that it is only allowed to run from a specific folder path:
- \directory\child\myprocess.exe(on a local Windows drive)
- \\directory\child\myprocess.exe(on a network Windows drive)
- Absolute paths are not supported for exclusions.
- Ancestors are not supported.
- When an executable file (exe) is added to an exclusion, /[CySc_process]/ is automatically added to the exclusion. If you added the above example exclusion, the result would be: /[CySc_process]/ /windows/*/myfile.exe.
Alternative options for exclusions for script control
You can use the global safelist or add a certificate as an alternative method to excluding scripts.
- This method requires a SHA256 hash value and assumes that this value won't change. Updates to the script or changes made by the script by design causes the hash value to change. Therefore, this method requires more administrative work to maintain if the script or macro is frequently updated or changes programmatically (for example, appends a new date or time, or makes system requests, pulls data). Each time theCylancePROTECT Desktopagent reports a script to the management console, it must report a SHA256 hash value. Each time the hash value changes, the agent reports the new value and you need to add the new value to the global safe list. If a hash value cannot be generated (for example, if the script doesn't execute properly, the file doesn't exist, or there are permission issues), then a generic hash is used when the script is reported to the console.
- The following SHA256 hash value is a generic hash that theCylancePROTECT Desktopagent uses when a hash cannot be generated for a script. If you try to add this value to the global safe list, an error message displays due to the agent functionality.
- The following SHA256 hash value is a generic hash that theCylancePROTECT Desktopagent uses when a PowerShell one-liner is used and a hash cannot be generated for a script. If you try to add this value to the global safe list, an error message displays due to the agent functionality.
- This method requires you to submit a valid code signing certificate to the console and is only available for PowerShell and Active scripts (not macros).