Script control Skip Navigation

Script control

Script control protects devices by blocking malicious scripts from running.
Script control monitors and protects against scripts running in your environment. The agent is able to detect the script and script path before the script is executed. Depending on the policy set for script control (alert or block), the agent will allow or block the execution of the script.
Script control is for Windows agents only.
For agent 1370 and earlier, setting the action affects active script and PowerShell.
For agent 1380 and later, the action can be set separately for active script, PowerShell, and macros.
For agent 1580 and later, actions can be set for .NET Dynamic Language Runtime (DLR) and Python.
  • Alert:
    This action monitors scripts running in your environment. Recommended for initial deployment.
  • Block:
    This action allows scripts to run only from specific folders. Use after testing in Alert mode
This control allows all scripts to run and alerts you when scripts are run. It is recommended that you initially enable Script Control in Alert mode to monitor and observe all scripts running in their environment.
Enabling Alert mode for Script Control does not send alerts about PowerShell console usage. The ability to block PowerShell console usage requires that PowerShell be set to
, and
Block PowerShell console usage
must also be enabled.
This control blocks all scripts from running. You can allow scripts to run using the
Approve scripts in these folders (and subfolders)
When you have a good understanding of all scripts running in your environment, you can change their settings to Block mode and only allow scripts to run out of specified folders.
Active Script
This controls alerts or blocks Active Scripts from running.
This control alerts or blocks PowerShell scripts.
Block PowerShell console usage
For agent version 1380 or later, prevents the PowerShell console from launching. Blocking the PowerShell console provides additional security by protecting against the use of PowerShell one-liners. You can disable this feature and allow the PowerShell console to run, at the policy level.
If you use a script that launches the PowerShell console, and Block PowerShell console usage is enabled, the script fails. If possible, it is recommended that users change their scripts to invoke the PowerShell scripts, not the PowerShell console. You can do this using the
switch. A basic command to run a PowerShell script without invoking the console would be:
Powershell.exe -file [script name]
This control alerts or blocks
Microsoft Office
macros. Macros use Visual Basic for Applications (VBA) that allows embedding code inside a Microsoft Office document (typically Word,
, and
). The main purpose for macros is to simplify routine actions, like manipulating data in a spreadsheet or formatting text in a document. However, malware creators can use macros to run commands and attack the system. It is assumed that a
Microsoft Office
macro trying to manipulate the system is a malicious action. The agent looks for malicious actions originating from a macro that affects things outside the
Microsoft Office
  • The script control macros feature work with agent version 1578 and earlier. For newer agents, use the
    Dangerous VBA Macros
    violation type with memory protection.
  • Any macro exclusions created for script control must be added to the memory protection exclusions for the
    Dangerous VBA Macros
    violation type.
  • Starting with
    Microsoft Office
    2013, macros are disabled by default. Most of the time, you do not need to enable macros to view the content of an
    Microsoft Office
    document. You should only enable macros for documents you receive from users you trust, and you have a good reason to enable it. Otherwise, macros should always be disabled.
This control alerts or blocks Python version 2.7 and 3.0 - 3.8 scripts.
This control alerts or blocks .NET DLR scripts.
Disable Script Control
For agents 1430 and later, clicking
Disable Script Control
means the script type will not be blocked or alerted on. For agents 1420 and lower, the only settings are alert or block, meaning some action is always taken on the script type.
Add Exclusion
You can specify folders to allow any script in that folder (and sub-folders) to execute without generating an alert or being blocked with Script Control enabled. You can also add a process exclusion to allow scripts to run if the process is excluded.
Script exclusion
When you approve scripts in a folder:
  • Folder paths can be to a local drive, a mapped network drive, or a universal naming convention (UNC) path.
  • Script folder exclusions must specify the relative path of the folder or sub-folder.
  • Folder exclusions cannot contain the script or macro file name, these entries are ignored by the agent.
  • If you want to exclude a specific script, you must use a wildcard. See Use wildcards in script control exclusions for more information.
  • If the “everyone” group has write permissions (share or file) this makes the folder “world-writable” and
    CylancePROTECT Desktop
    will continue to alert/block on scripts. This is because if the everyone group has write permissions, anyone inside or outside of the organization can drop a script in a folder or subfolder and write to it. The world-writable restrictions applies not only to the direct parent folder, but all parent folders, all the way to the root.
Process exclusion
Use a process exclusion when you want to block scripts from executing except ones being run by a specific application. For example, you don't want end-users running scripts, but you want to allow your IT department to run scripts as part of their work. If the IT department uses the same tools all the time, you can add the process as an exclusion. This would identify the process running the interpreter, and if the process is excluded, it will be allowed to run.
  • Requires agent version 1580 or higher.
  • If the executable in the process exclusion is blocked by Execution Control (Policy > File Actions), the scripts will not run. In this case, add the executable to the Safelist.
  • This does not restrict running scripts from a designated folder. This allows all scripts to run that use a policy with the process excluded.