Script Control

CylancePROTECT Script Control protects users from malicious scripts running on their devices. Script Control injects into a script interpreter (responsible for the execution of scripts) to monitor and protect against scripts running in your environment. By injecting into the interpreter, 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. See FAQ - What is Script Control? for frequently asked questions about Script Control.

Script Control supports PowerShell and Active Scripts.

  • PowerShell requires Agent version 1310 or higher
  • Active Script requires Agent version 1340 or higher
  • Microsoft Office Macros requires Agent version 1380 or higher

Note: When Script Control is enabled on some systems, it can sometimes cause a conflict with other applications running on the device(s). See Known Memory Protection and Script Control Incompatibilities for more information. 

To enable Script Control from the Cylance Console, go to Settings -> Device Policy -> Script Control and turn on Script Control. Script Control can either be utilized in Alert mode or Block Mode.

 

Note: For Agent versions 1370 and lower, you can only Alert or Block on both Active Scripts and PowerShell Scripts. Macros is not included with 1370 and lower.

Alert Mode

Allows all scripts to run and alerts you when scripts are run.

It is recommended that administrators initially enable Script Control in Alert mode to monitor and observe all scripts running in their environment.

Note: 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 Block, and Block PowerShell console usage must also be enabled.

Block Mode

Blocks all scripts. Scripts can be allowed to run using the Approve scripts in these folders (and subfolders) option (see information below).

Once administrators have a good understanding of all scripts running in their environment, they can change their settings to Block mode and only allow scripts to run out of specified folders.

PowerShell Console: For Agents version 1380 and higher, setting PowerShell to Block also enables Block PowerShell console usage, which prevents launching the PowerShell console. Blocking the PowerShell console provides additional security by protecting against the use of PowerShell one-liners. Administrators can disable this feature and allow the PowerShell console to run, at the policy level.

Note: If you uses a script that launches the PowerShell console, and Block PowerShell console usage is enabled, the script will fail. If possible, it is recommended that users change their scripts to invoke the PowerShell scripts, not the PowerShell console. This is done through the use of the -file switch. A basic command to run a powershell script without invoking the console would be: Powershell.exe -file [script name]



Note: Reports from the field indicate Block PowerShell console usage prevents Microsoft System Center Configuration Manager (SCCM) from performing needed functions (deploying patches, inventory tasks, etc). Unchecking "Block Powershell console usage" may be required for customers utilizing SCCM. We recommend creating a "Change Control" device policy, unchecking "Block Powershell console usage" and only applying this device policy to devices when you are deploying changes using SCCM.

Note:¬†Windows 8 handles the "Run with PowerShell" right click option differently than Windows 7. Using "Run with PowerShell" on Windows 8 will cause PowerShell scripts to be run as a one-liner. Please read¬†Why does the Agent handle PowerShell scripts differently from Windows 7 to Windows 8 and above‚Äč.

Approve Scripts in these folders

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.

When approving 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.
  • CORRECT:¬†Windows:¬†\Cases\ScriptsAllowed
  • CORRECT:¬†Web Based Documents (ex: SharePoint):¬†\shared documents\ScriptsAllowed\¬†or¬†/shared documents/ScriptsAllowed
  • INCORRECT:¬†\Cases\ScriptsAllowed\Allowedscript.vbs
    • The exclusions listed above will work for documents from the following URL:¬†https://company.sharepoint.com/sites/SiteName/Shared Documents/ScriptsAllowed/macro-document.xlsm
      • Any part of the relative folder path¬†after the domain name (Ex: company.sharepoint.com)¬†can be excluded.
      • Exclusions for web based documents requires¬†Agent 1410¬†or higher.
  • Any specified folder path also includes any sub-folders.
  • The relative path has a 255 character limit and does not provide an error message if the path is over 255 characters.
  • Wildcards are not allowed in Agent 1480 and lower.¬†With Agent 1490 or higher, a wildcard can be used in the Script Control exclusion. See the¬†Script Control Exclusions - Wildcard Support¬†article.
  • What is causing a script to run?
    • The script being triggered is not caused by the CylancePROTECT Agent.¬†Script Control's reaction to detecting a script is dependent on device policy setting.
    • Script Control does not provide further contextual information about the offending script. It's possible that the detected script maybe triggering due to a 3rd party application, an add-on, or simply triggering by design.
    • Because of this, Cylance Support cannot troubleshoot or ascertain why a particular script is being detected.
  • What is this file path: 'C:_unknown_document_path_\unknown_document'?
    • The file path 'C:_unknown_document_path_\unknown_document, is reported by the PROTECT Agent when a macro script is detected by the PROTECT Agent, but the PROTECT Agent is unable to ascertain the path that the macro script originated from. If this occurs, the PROTECT Agent will generate 'C:_unknown_document_path_\unknown_document'.
    • Potential scenarios where this could occur:
      • 3rd party add-ons execute a script prior to the office document opening
      • Script is ran outside the confines of a document
      • Script runs faster than the document can open¬†
    • The above scenarios are not caused by the CylancePROTECT Agent, as the script or add-on would be from a 3rd party and potentially designed to function in that manner. Because of this, Cylance Support cannot troubleshoot or ascertain the location of these scripts.¬†
  • How do I exclude a macro script when Script Control reports 'C:_unknown_document_path_\unknown_document' as the File Path?
    • Exclusion: \__unknown_document_path__\
    • Note:¬†Requires¬†Agent 1470¬†or higher to utilize. Please see our release note¬†here.
  • If you utilize Windows Junction Points, that Junction Point can serve as a valid folder exclusion¬†as long as the script is invoked from the Junction's¬†path.
  • When authorizing a folder, make sure the folder is not world-writable.
    • The world-writable restrictions applies not only to the direct parent folder, but all parent folders, all the way to the root.
      • In Windows, world-writable means the Everyone / World SID (S-1-1-0) is present on the access control list (ACL) of the folder.
  • In block mode, Script Control will block all scripts in world-writable folders and write an error in the Windows Event Log.
  • Approve Scripts does work on network folders with any ACL that is less than world-writable.
  • Note:¬†When safelisting a script by Hash, the agent will disregard if the script is in a world-writeable folder - i.e. the safelisted hash will take precedence over the folder permissions.

Note: By default, Windows prevents PowerShell scripts from executing from remote paths. To allow the scripts to run, you must set Set-ExecutionPolicy Bypass on the local system. See this article for other authorization options: http://setspn.blogspot.com/2011/05/running-powershell-scripts-from-unc.html.

When a script is executed, the action will be reported by the Agent UI (under the Scripts tab) as well as the Cylance Console (on the Protection page and on the Device Details page, under the Script Control tab).

Script Control Safelist by Hash

Please see our knowledge base article here to learn more about script control safe-listing by hash. 
 

Best Practices for Script Control

  • Test Script Control in Alert mode¬†- This allows you to review all findings by Script Control and add-in the appropriate folder exclusions. Once this is done, set Script Control to¬†Block¬†mode.
  • Add folder exclusions for approved scripts to run from¬†- This includes automated scripts and scripts regularly used by your IT staff. This will help filter out detections for approved scripts running in your environment. Specified folders cannot be world-writable. For such folders, with automated scripts regularly used by your IT staff, it is recommended that you restrict access (example - using ACL's) to prevent unauthorized access.
  • Script Control for PowerShell: If you set PowerShell to block, it is recommended that you also check¬†Block PowerShell console usage¬†(this is enabled by default when PowerShell is set to block). By enabling this, PowerShell console usage is blocked, which helps protect against PowerShell one-liner usage. Approved scripts can still be invoked by using the¬†-F¬†parameter in the¬†cmd.exe¬†console. Example:¬†"Powershell -F c:\temp\approved\sample.ps1", assuming the approved scripts have been added to the exclusion list.

Note: You should exclude common folders that you run automated scripts from.

Once Script Control is enabled in a policy, you can review any results on the Protection page, under the Script Control tab. For more information, see Script Control on the Protection Tab.