Skip Navigation

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:
  • Disabled: Allows all scripts to run and does not report them to the management console. This setting is not recommended.
  • Alert: Allows all scripts to run and reports them to the management console. Use this setting when you want to monitor and observe all scripts that are running in your environment. Recommended for initial deployment while you determine which scripts you want to allow or block.
  • Block: Blocks all scripts from running and reports them to the management console. Only files that are added to the exclusion list are allowed to run. Use this setting after testing and monitoring for threats in alert mode.
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):
  • Block unsafe scripts: If the script is not already in the exclusion list, the agent obtains a threat score from the
    CylancePROTECT
    cloud services. If it receives an unsafe threat score, the script is blocked from executing. Unsafe files greatly resemble malware. Unscored and abnormal scripts are reported to the management console but are not blocked.
  • Block abnormal and unsafe scripts: If the script is not in the exclusion list, the agent obtains a threat score from the
    CylancePROTECT
    cloud services, and if it receives an abnormal or unsafe threat score, the script is blocked from executing. Abnormal files have some malware-like attributes but are less likely to be malware than an unsafe file. Unscored scripts are alerted to the console but are not blocked.
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):
  • Block unsafe scripts: If the script is not already in the exclusion list, the agent obtains a threat score from the
    CylancePROTECT
    cloud services. If it receives an unsafe threat score, the script is blocked from executing. Unsafe files greatly resemble malware. Unscored and abnormal scripts are reported to the management console but are not blocked.
  • Block abnormal and unsafe scripts: If the script is not in the exclusion list, the agent obtains a threat score from the
    CylancePROTECT
    cloud services, and if it receives an abnormal or unsafe threat score, the script is blocked from executing. Abnormal files have some malware-like attributes but are less likely to be malware than an unsafe file. Unscored scripts are alerted to the console but are not blocked.
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:
  • Microsoft Windows
    10 or later
  • CylancePROTECT Desktop
    agent version 3.1 or later
  • VBA macros must be disabled in
    Excel
    .
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):
  • Ignore large scripts: The agent does not report the alert to the management console.
  • Alert only on large scripts: When the agent detects a large script, it will only report the script to the console, and take no other action.
  • Apply language specific policy settings: When the agent detects a large script, it will report the alert to the console and execute the selected action (control mode) that you configured for each type of script.
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:
  • Folder exclusions cannot contain the script or macro file name. These entries are not valid and the agent ignores them.
  • If the “Everyone” group in your organization has write permissions to a folder, anyone inside or outside of the organization can drop a script in the folder and write to it.
    CylancePROTECT Desktop
    will continue to send alerts on scripts and block them. The write permissions apply not only to the direct parent folder, but also to all parent folders, all the way to the root.
  • If you want to exclude a specific script, you must use a wildcard.
Excluding processes:
  • The executable in the process exclusion may be quarantined by execution control and blocked from running. If the executable is quarantined, you need to add it to the policy safe list.
  • Process exclusions allow scripts to run and do not restrict them from running from the specified folder.
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 for
    Windows
    systems), 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.