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.
- /users/*/temp/* would cover:
/users/*/temp/* would NOT cover:
The above would require - /users/*/*/temp/*.
- /program files*/app/script*.vbs would cover:
/program files*/app/script*.vbs would NOT cover:
- \program files(x86)\app\script1.vbs
- \program files(x64)\app\script2.vbs
- \program files(x64)\app\script3.vbs
The first one would require /program files*/app/script.vbs or /program files*/app/*.vbs. The second would require /program files/app/script*.vbs or /program files/*/script*.vbs.
- \program files(x86)\app\script.vbs
- \program files\app\script1.vbs
- //*example.local/sysvol/script*.vbs would cover:
//*example.local/sysvol/script*.vbs would NOT cover:
- /users/*/*/*.vbs would cover:
You can include processes in the list of script control exclusions. This is useful for example, to exclude specific processes that may be calling scripts like SCCM, which launches PowerShell scripts in a temporary directory.
- The following sample exclusion would allow scripts to run that are launched by any interpreter (such as PowerShell.exe) that is launched by the process myfile.exe. A process is any process calling the script interpreter.
- The following adds the name of the process, regardless of the directory.
- For local Windows drive: \myprocess.exe
- For network Windows drive: \\myprocess.exe
- The following adds a process from a directory.
- For local Windows drive: \directory\child\myprocess.exe
- For network Windows drive: \\directory\child\myprocess.exe
- 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.
- Wildcard exclusions must use Unix-style slashes for Windows systems, such as /directory/child/my*.exe.
Exclusion options for script control
You can use the global safelist or add a certificate as alternative methods to exclude scripts.
- Global safelist a script - allows for script exclusion regardless of location.
- This method is inefficient if the script changes programmatically or is frequently updated (appends a new date/time, system request, etc. that automatically change the script and hash) and for macros (these typically change for each execution because of the way the macro pulls in the data).
- This method may require more administrative work to maintain. As script hashes change, you will need to remove the old hash and add the new one to the safelist.
- When you try to add the the following SHA256 hash to the Global List, an error message displays. This message is due to agent functionality. A SHA256 needs to be reported to the management console.
- FE9B64DEFD8BF214C7490AA7F35B495A79A95E81F8943EE279DC99998D3D3440This is a generic hash theCylancePROTECT Desktopagent uses when a hash cannot be generated for a script. Examples of when a hash might not be generated include: if the script doesn't execute properly, the file doesn't exist, or there are permission issues.
- FE9B64DEFD8BF214C7490BB7F35B495A79A95E81F8943EE279DC99998D3D3440This is a generic hash theCylancePROTECT Desktopagent uses when a Powershell one-liner is used and a hash cannot be generated for a script. Examples of when a hash might not be generated include: if the script doesn't execute properly, the file doesn't exist, or there are permission issues.
- Add a certificate for a script - allows for script exclusion regardless of location.
- Can be used for PowerShell and active scripts only (Does not work for macros)
- Should be a valid code signing certificate
- Must be uploaded to the console