Device policy: Script Control settings
Script control settings specify how the
CylancePROTECT Desktop
agent handles the execution of scripts on Windows
devices.Setting | Description |
---|---|
Script control | You must enable this option to configure any script control settings. You can select one of the following control mode actions for each type of script:
Active script and PowerShell include additional enhanced script control options, see the appropriate rows below for more information. You can find script control alert and block events in Protection > Script Control. |
Active script | Controls how the agent will handle active scripts, including VBScript and JScript. The following control modes are available for active scripts in addition to Disabled, Alert, and Block. These settings require agent version 3.2 or later (if the device is running an earlier agent, the script will be blocked by default):
|
PowerShell | Controls how the agent will handle PowerShell scripts. The following control modes are available for PowerShell scripts in addition to Disabled, Alert, and Block. These settings require agent version 3.2 or later (if the device is running an earlier agent, the script will be blocked by default):
|
PowerShell Console | Controls how the agent will handle the PowerShell console. Blocking the PowerShell console provides additional security by protecting against the use of PowerShell console in interactive mode. The Alert control mode requires CylancePROTECT Desktop agent version 3.2 or later. For agents that don't support Alert mode, the use of PowerShell console will be allowed by default and an alert won't be generated.If the control mode is set to Block and a script launches the PowerShell console, the script fails. It is a best practice for scripts to invoke the PowerShell scripts instead of the PowerShell console (a basic command to run a PowerShell script without invoking the console is Powershell.exe -file [script name]). |
Macros | Controls how the agent will handle Microsoft
Office macros. Macros use Visual Basic for Applications (VBA) which allows embedding code inside a Microsoft
Office document. Malware creators can use macros to run commands and attack the system.This setting applies only to agent version 2.1.1578 and earlier. For newer agents, use the Dangerous VBA macro violation type on the Memory Protection tab. Any macro exclusions that you created previously for script control must be added to the memory protection exclusions for the Dangerous VBA macro violation type. Starting with Microsoft
Office 2013, macros are disabled by default. Typically you do not need to enable macros for users to view the content of a Microsoft
Office document. Enable macros only for documents from trusted users. It is a best practice to disable macros. |
Python | Controls how the agent will handle Python scripts version 2.7 and 3.0 to 3.8. |
.NET DLR | Controls how the agent will handle .NET DLR scripts. |
XLM macros (Preview) | The XLM macros feature is currently available in Preview mode where it might behave unexpectedly. Controls how the agent will handle Excel 4.0 (XLM) macros.This feature requires:
|
Score all scripts | When enabled, all active script and PowerShell scripts are scored, even if the control mode is set to Alert or Block. If not enabled, Active script and PowerShell scripts are scored only if the control mode is set to “Block unsafe scripts” or “Block abnormal and unsafe scripts”. |
Upload script to cloud | When enabled, a copy of active script and PowerShell scripts are uploaded to the CylancePROTECT cloud services for threat analysis and scoring. If not enabled, CylancePROTECT attempts to obtain a score for active script and PowerShell scripts using the hash details. |
Alert on suspicious scripts execution only | When enabled, only active script or PowerShell script executions that are determined to be unsafe or abnormal are reported to the management console. If not enabled, the execution of any active script or PowerShell script is reported to the console, regardless of whether a threat is detected. |
Actions for Large Scripts | When enabled, the agent takes the specified action when a threat is detected from a larger script (for example, PowerShell scripts larger than 5 MB):
|
Exclude files, scripts, or processes: Add Exclusion | You can specify folders that are excluded from script control. Any script that is executed from within a specified folder (or sub-folder) are not subject to the control mode that you configured, and will not generate an alert. You can add exclusions for processes to allow scripts from certain applications that would otherwise be blocked. For example, if your IT department uses specific tools to run scripts, you can add the process for that tool as an exclusion so that scripts are allowed to run. You specify the relative path of the folder or sub-folder. The path can be to a local drive, a mapped network drive, or to a universal naming convention (UNC) path. Excluding folders and scripts:
Excluding processes:
See the details below for using wildcards for file, script, or process exclusions. |
Using wildcards for file, script, or process exclusions
Note the following considerations for using wildcards (*) in script control exclusions:
- Only the asterisk (*) is supported as a wildcard for script control exclusions. The wildcard represents one or more characters.
- Exclusions must use Unix-style slashes (even forWindowssystems), for example, /windows/system*/*.
- To exclude a folder, the exclusion must have a wildcard at the end of the path to distinguish the exclusion as a folder and not a file. For example: /windows/system32/test*/*.
- When you want to exclude a file, the exclusion must end with a file extension to distinguish the exclusion as a file and not a folder. For example: /windows/system32/script*.vbs.
- Each wildcard represents one folder level only. The number of folder levels represented in the exclusion must match the level of the file that you are trying to exclude. For example, /folder/*/script.vbs matches \folder\test\script.vbs, but does not match \folder\test\001\script.vbs. This would require either /folder/*/001/script.vbs or /folder/*/*/script.vbs.
- The wildcard would need to persist down per level to where the script resides.
- Two or more wildcards per level are not allowed. For example, /folder/*file*.ext is not allowed.
- Process exclusions with a wildcard must have a file extension to distinguish it as a process exclusion and not a folder. For example, /my*.exe (local drive),/directory/child/my*.exe (local drive), //my*.exe (network drive),//directory/child/my*.exe (network drive)
- Wildcards can lower your security stance if your exclusions are too broad. For example, avoid excluding entire folders such as /windows/temp. Instead, use a wildcard while specifying the full or partial filename of the script that you want to exclude (for example,/windows/temp/myscript*.vbs).
- Absolute paths are not supported in script control exclusions.
- If you can identify a common relative path, you can exclude Universal Naming Convention (UNC) paths with a wildcard. For example, if you use device names in a path such as "DC01" to "DC24":/dc*/path/to/script/*
- Network paths can be excluded. For example,//host*/application/*.
- For detailed examples, see Examples of script control exclusions.