Cylance Protect - Script Control

Description

Table of Contents

Overview

BlackBerry Protect Script Control protects users from malicious scripts running on their devices. Script Control is injected 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 allows or blocks the execution of the script. See the FAQ section for frequently asked questions about Script Control.

Script Control supports Active Scripts, Windows PowerShell, and Microsoft Office Macros.

NOTE: Script Control Macro events only alert for devices using agents 2.1.1578 and below. For later agents, macro events are reported as Exploit alerts. Also reference, Cylance: Protect - Exploit Attempt Exclusions (sonicwall.com) 

 

To enable Script Control from the Cylance Console, navigate to Policies > Device Policy. Select the desired policy, and select the Script Control section. Turn on Script Control, Script Control can either be utilized in Alert mode or Block mode.

Script Control Policy Settings

For Agent versions 1370 or earlier, you can only Alert or Block on both Active Scripts and PowerShell Scripts. Macros are not included with 1370 or earlier. 

Best Practices for Script Control

  • Test Script Control in SCA (Script Control Alert) - This allows you to review all findings by Script Control and to add in the appropriate exclusions. Once this is done, set Script Control to Block mode.
  • Add appropriate exclusions for approved scripts to run from - This includes automated scripts and scripts regularly used by your IT staff. This helps 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 (for example, when using ACLs) to prevent unauthorized access.
  • Script Control for PowerShell: If you set PowerShell to block, it is recommended that you also select 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. For example: "Powershell -F c:\temp\approved\sample.ps1" can be invoked, assuming the approved scripts have been added to the exclusion list.
  • See SCB (Script Control Block) > PowerShell console: section for more information

SCA (Script Control Alert)

This mode allows all scripts to run and to alert 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.

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. 

SCB (Script Control Block)

This mode blocks all scripts. Scripts can be allowed to run using the Approve scripts in these folders (and subfolders) option (see Approve Scripts section below).

Once administrators have a good understanding of all the 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 and One-Liner Powershell Commands

For Agents version 1380 and later, 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.

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. 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]

  • If you are not able to change the script to invoke the .ps1 file, then you will need to un-check the Block PowerShell console usage option to allow the [*COMMAND*] to run

 

For devices that use Protect agent 2.1.1578 for Windows OS and older, Powershell Console events will alert with the leading notation, [*COMMAND*] as shown in the image below:

PS Console events with agent 2_1_15x

 

For devices that use Protect agent 2.1.1584 and later for Windows OS, Powershell Console events will alert as, PowershellConsole:

PS Console events with agent 2_1_1584 and newer

PS Console events with agent 2_1_1584 and newer - Protection Script Control

Selecting Block PowerShell console usage can prevent Microsoft System Center Configuration Manager (SCCM) from performing needed functions (deploying patches, inventory tasks, etc). SCCM utilizes multiple different flows of execution for executing PowerShell. There are different techniques that need to be implemented based on the SCCM flow of execution. There is not a universal solution at this time for SCCM if Block PowerShell Console Usage is enabled. Once the flow of execution has been identified and captured (for example, by capturing the script execution with a tool like Process Monitor), options can be explored to allow the script to execute. SCCM allows you to use vbscript or jscript instead of PowerShell, as these languages are not impacted by the Block PowerShell Console Usage setting. 

 

  Windows 8 handles the Run with PowerShell right-click option differently than Windows 7. Using Run with PowerShell on Windows 8 causes PowerShell scripts to be run as a one-liner. 

Approving Scripts

Scripts can be allowed to run using the Approve scripts in these folders (and subfolders) option. You can specify folders to allow any script in that folder and its subfolders to execute without generating an alert or being blocked with Script Control enabled.

If you want to exclude a specific script file, you MUST use a wildcard exclusion. 

  • See the Wildcard Exclusions section for more information.

Folder Exclusions

  • Folder paths can lead to a local drive, a mapped network drive, or a universal naming convention (UNC) path.
  • Any specified folder path includes all subfolders.
  • The relative path has a 255 character limit and does not provide an error message if the path is over 255 characters.
  • When authorizing a folder, make sure the folder is not world-writable.
    • The world-writable restrictions apply not only to the direct parent folder, but to all parent folders, all the way to the root.
    • In Windows, world-writable identifies that the Everyone / World SID (S-1-1-0) is present in the Access Control List (ACL) of the folder.
    • In Block mode, Script Control blocks all scripts in world-writable folders and writes an error in the Windows Event Log.
    • Approved scripts also work on network folders with any ACL that is less than world-writable.
  • If you utilize Windows Junction Points, each Junction Point can serve as a valid folder exclusion as long as the script is invoked from the Junction's path.
  • When a script is executed, the action is reported by the Agent UI (under the Scripts tab) as well as the Console (on the Protection page and on the Device Details page, under the Script Control tab).
  • Script folder exclusions must specify the relative path of the folder or subfolder. Any part of the relative folder path after the domain name (for example, company.sharepoint.com) can be excluded. Exclusions for web-based documents require Agent version 1410 and later.
  • The exclusions listed below 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 (company.sharepoint.com) can be excluded. Exclusions for web-based documents require Agent version 1410 and later and are as follows:
    • Correct: 
      • \sites\SiteName\Shared Documents\ScriptsAllowed\
      • /sites/SiteName/Shared Documents/ScriptsAllowed/
      • \shared documents\ScriptsAllowed\
      • /shared documents/ScriptsAllowed/
    • Incorrect:
      • \sites\SiteName\Shared Documents\ScriptsAllowed\Allowedscript.vbs
      • \ScriptsAllowed\Allowedscript.vbs

Folder exclusions must not contain the script or macro file name as the agent ignores these entries. 

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 the "Running PowerShell Scripts From An UNC Path (Share)" article at this link for additional authorization options. 

Wildcard Exclusions

BlackBerry supports the use of wildcards when creating script control exclusions. Wildcards can exclude a folder, a script or a process. Using script control exclusions with wildcards should reduce the number of alerts that display in your console. By allowing the exclusion of full or partial script names, administrators do not need to exclude an entire folder. By allowing the exclusion of partial script names, administrators can exclude a portion of the script name that is common for a group of scripts that they want to exclude.

If you want to exclude a specific script file, you MUST use a wildcard exclusion. 

  • And you must replace at least one character of the script file name with the * wildcard.
  • For example, to allow the following script file: C:\folder\test\script.vbs
    • Use this exclusion: /folder/test/scrip*.vbs

Although using wildcards provides flexibility in allowing exclusions, it can also lower your security stance if the exclusion is too broad. For example, excluding the entire \Windows\Temp folder is not recommended. However, if a program or file you trust places a script in the \Windows\Temp folder and CylancePROTECT blocks it, you can use a wildcard as part of the file name to exclude that script. 

Note the following about wildcard support:

  • BlackBerry Protect Agent version 1490 and later is required
  • BlackBerry Protect Agent version 1580 and later is required for process exclusions
  • Wildcard exclusions must use Unix-style slashes for Windows systems. For example: /windows/system*/*
  • The only token support for wildcards is *
  • Folder exclusions with a wildcard must have a wildcard at the end of the path to specify between a folder and a file, as follows: 
    • Folder exclusion: /windows/system32/*
    • Folder exclusion: /windows/*/test/*
    • Folder exclusion: /windows/system32/test*/*
  • File exclusions with a wildcard must have a file extension to differentiate between a file and a folder, as follows: 
    • File exclusion: /windows/system32/*.vbs
    • File exclusion: /windows/system32/scrip*.vbs
    • File exclusion: /windows/system32/*/scrip*.vbs
  • One wildcard is permitted per folder level
    • The /folder/*/scrip*.vbs matches \folder\test\script.vbs or \folder\exclude\script.vbs, but does not work for \folder\test\001\script.vbs. This would require either /folder/*/001/scrip*.vbs or /folder/*/*/scrip*.vbs.
    • Two or more wildcards per level are not allowed. For example, /*olde*/test/001/scrip*.vbs is not allowed.
  • Wildcards support full and partial exclusions.
    • Full wildcard example: /folder/*/*.vbs
    • Partial wildcard example: /folder/test*/scrip*.vbs
  • If you can identify a common relative path, you can exclude Universal Naming Convention (UNC) paths with a wildcard. For example, devices with the DC01 – DC24 names could use /dc*/path/to/script/.
  • The following network paths can also be excluded:
    • /hostname/application/*
    • /host*/application/*
    • /*name/*/application/*
    • /hostname/*
  • Process exclusions with a wildcard must have a file extension to differentiate between a file and a folder.
  • Add the name of the process regardless of the directory as follows:
    • Local drive: /my*.exe
    • Network drive: //my*.exe
  • Add a process from a directory as follows:
    • Local drive: /directory/child/my*.exe
    • Network drive: //directory/child/my*.exe

Example Exclusions

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 that it includes variants.

  • The /users/*/temp/* would include the following:
    • \users\john\temp
    • \users\jane\temp ​
  • The ​/users/*/temp/* would not include the following:​
    • \users\folder\john\temp
    • \users\folder\jane\temp
  • The second example above require /users/*/*/temp/* 

 

  • The /program files*/app/script*.vbs would cover the following:
    • \program files(x86)\app\script1.vbs
    • \program files(x64)\app\script2.vbs
    • \program files(x64)\app\script3.vbs ​
  • The ​/program files*/app/script*.vbs would not cover the following:
    • \program files(x86)\app\script.vbs
    • \program files\app\script1.vbs 
  • The first example shown above would require /program files*/app/scrip*.vbs or /program files*/app/*.vbs 
  • The second example would require /program files/app/script*.vbs or /program files/*/script*.vbs 

 

  • The /*example.local/sysvol/script*.vbs would cover the following:
    • ​\\ad.example.local\sysvol\script1.vbs ​
  • The /*example.local/sysvol/script*.vbs would not cover the following:
    • \\ad.example.local\sysvol\script.vbs
  • The /users/*/*/*.vbs would cover the following:
    • \users\john\temp\script.vbs

Script Control Safelist by Hash

BlackBerry Protect administrators can add a script hash (SHA256) to their Global Safelist to allow specific ActiveScript and PowerShell scripts to run in their organization.

  • This feature requires Agent version 1470 and later
  • Scripts residing on a mapped network drive requires Agent version 1480 and later
  • Safelisting Scripts by hash does not include Office macros. Only folder exclusion paths (with or without a wildcard) are supported for Office macros

Safelist Scripts from the Threat Protection page

Complete the following steps:

  1. Log in to the Cylance Console
  2. Select Protection from the left-side menu
  3. Click Script Control near the top of the page
  4. Select one or more scripts from the list
  5. Click Safe
  6. These scripts are now added to the Global Safelist

 

Safelist Scripts from the Global List page

Complete the following steps:

  1. Log in to the Cylance Console
  2. Navigate to Settings > Global List
  3. Click Safe
  4. Click Scripts
  5. Click Add Script
  6. Enter the SHA256 hash, File Name (optional), and a Reason for safelisting the hash
  7. Click Submit
  • Adding a script to the Safe List will not remove it from the Threat Protection page. 
  • To see if a script has been added to the Safe List, navigate to Settings > Global List, then locate the script in the list. 

 

Common Reason for Errors when Safelisting a script by Hash

  • One of the selected scripts is already in the Global Safe list for Scripts
    • This will cause all selected scripts to fail to be safe-listed at that time
  • The script has a “generic hash” the BlackBerry Protect Agent uses when a hash cannot be generated for a script.
    • GENERIC HASH: FE9B64DEFD8BF214C7490AA7F35B495A79A95E81F8943EE279DC99998D3D3440
    • Examples of when a hash might not be generated include:
      • If the script doesn't execute properly
      • The file doesn't exist
      • There are permission issues
    • This generic hash will also be used by the BlackBerry Protect Agent when a PowerShell one-liner is used and a hash cannot be generated for a script
    • This generic hash is also often used for MacroScripts

Script Control Safelist by Certificate

To sign scripts you need to obtain a Standard (non-EV) Authenticode Code-Signing certificate. These types of certificates can be obtained from your internal Public Key Infrastructure (PKI) or from an external, commercial CA. You can also create a self-signed certificate, but this is only recommended for testing purposes and should not be deployed to multiple devices. The root of the certificate chain needs to be present in the Trusted Root Certification Authorities certificate store for the local Computer account in order for BlackBerry Protect to validate the signature present on script files. 

  • Safelist by Certificate for Script Control works with PowerShell and ActiveScript.
  • Office Macros are not supported.
  • Server Core does not support for Safelist by Certificate for Active Script due to missing OS functionality. Safelist by Certificate for PowerShell is still supported on Server Core.

Example: Self-Signed Certificates

 

  • 1. Creating a Self-Signed Certificate
    • On Windows 10 or Windows Server 2016 or greater, run the following PowerShell command, replacing Testing with the desired Common Name and Issuer:
      • New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Subject "CN=Testing" -KeyExportPolicy Exportable -KeyUsage DigitalSignature -Type CodeSigningCert

Opening the PowerShell console and attempting to run PowerShell commands are blocked if "Block PowerShell console usage" is checked. 

 

  • This command outputs a thumbprint and the requested subject, as shown below.
    • PS cert test output

 

  • 2. Exporting the Self-Signed Certificate to disk
    • Run the following PowerShell command, replacing SHA1THUMBPRINT with the thumbprint from the previous command:
      • $cert = (Get-ChildItem -Path cert:\LocalMachine\My\SHA1THUMBPRINT)
    • Run the following PowerShell command, replacing C:\Temp\test.cer with the desired output location and file name:
      • Export-Certificate -Cert $cert -FilePath C:\Temp\test.cer
    • This command outputs Mode, LastWriteTime, Length and Name values, and write the self-signed certificate to the specified output location, as shown below
      • Mode LastWriteTime Length and Name - PS Output
  • 3. Importing the Self-Signed Certificate to the Certificate Store
    • Run the following PowerShell commands, replacing the C:\Temp\test.cer with the location of the code-signing certificate
      • Import-Certificate -FilePath C:\Temp\test.cer -CertStoreLocation Cert:\LocalMachine\Root
      • Import-Certificate -FilePath C:\Temp\test.cer -CertStoreLocation Cert:\LocalMachine\TrustedPublisher
    • This places the code-signing certificate into the Certificate Store for the Local Computer account under Trusted Root Certification Authorities > Certificates and Trusted Publishers > Certificates. You can validate this by opening an Microsoft Management Console (MMC) console, adding the Certificates snap-in, target the Computer account, and then navigating to the certificate paths mentioned above.
  • 4. Signing a script file with the Self-Signed Certificate
    • In this example, C:\Temp\SignMe.ps1 contains a simple PowerShell script with the following contents:
      • Write-Host “Hello, World!”
    • Run the following PowerShell command, replacing C:\Temp\SignMe.ps1 with the location of your script.
      • Set-AuthenticodeSignature C:\Temp\SignMe.ps1 $cert
    • The script should now look similar to the below:Hello World script example
  • 5. Adding the Self-Signed Certificate to the Certificate safe list:
    • In the console, select Settings > Certificates
    • Click Add Certificate
    • Upload the certificate used to sign the script
    • Select Script
    • Click Submit
  • 6. Any script signed with the code signing certificate is now allowed to run without interruption

FAQ - Frequently Asked Questions

How does script control work?

  • 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.

What is causing a script to run?

  • The BlackBerry Protect Agent does not run the script that is triggered. Script Control depends on the device policy setting to detect and react to a script.
  • Script Control does not provide additional contextual information about the offending script. It's possible that the detected script may trigger due to a third-party application, an add-on, or simply trigger by design.
  • Because of this, BlackBerry Support cannot troubleshoot or determine why a particular script is being detected.

What are Active Scripts?

  • With Script Control, the Agent can detect two Active Scripting engines, VBScript and JScript, that run from the Windows Script Host (WSH).
  • WSH is a language-independent scripting host and provides an environment for scripts to run by invoking the appropriate scripting engine.
  • In this case, it is referring to the Active Scripting engines - VBScript and JScript.
  • WSH can run in GUI-mode (wscript.exe) or command-line-mode (cscript.exe).

Is JScript the same as JavaScript?

  • No, JScript and JavaScript are different scripting engines but have similar functionality.
  • Both JScript and JavaScript scripts that are executed via CScript or WScript
  • Both are detected by Script Control, and any actions applied (Alert or Block).

If these scripts are invoked via a web browser, Script Control will not detect or take any actions on these scripts. 

Why are scripts runniing from PowerShell ISE not detected?

  • Script Control only detects PowerShell scripts from the PowerShell Interpreter, not the PowerShell ISE Interpreter.

Does Script Control protect against browser-based scripts?

  • No, Script Control only detects scripts that run natively on the device operating system.

What are the [*COMMAND*] events that I see in Script Control?

  • This applies to devices that use Protect agent 2.1.1578 for Windows OS and older.  When PowerShell is set to Block and Block PowerShell console usage is enabled, any attempts to run the PowerShell console (or one-liner commands) will be blocked and logged. The exact commands, up to 250 characters, will be reported in the filepath/filename field.

If Script Control for PowerShell is set to Alert, do I have visibility into the PowerShell console usage?

  • No, visibility into PowerShell console usage and the ability to block it requires that PowerShell be set to Block, and Block PowerShell console usage must also be enabled.

Does Script Control for PowerShell protect against one-liners?

  • Yes, when PowerShell is set to block, access to the PowerShell console is also blocked by default. Approved scripts can still be invoked by using the -F parameter in the Command Console (cmd). Otherwise, any attempts to use PowerShell commands (one-liners) will be blocked per policy.
  • Example: If c:\temp\approved\sample.ps1 is an approved script (as indicated in the exclusion folder, set in a policy), this script can be invoked by typing Powershell -F c:\temp\approved\sample.ps1 in the Command Console (cmd.exe).

C:\_unknown_document_path_\unknown_document

NOTE: Script Control Macro events only alert for devices using agents 2.1.1578 and below. For later agents, macro events are reported as Exploit alerts. Also reference, Cylance: Protect - Exploit Attempt Exclusions (sonicwall.com) 

  • This applies to devices that use Protect agent 2.1.1578 for Windows OS and older.
  • The file path C:\_unknown_document_path_\unknown_document is reported by the BlackBerry Protect Agent when it detects a macro script but is unable to determine the path that the macro script originated from.
    • If this occurs, the BlackBerry Protect Agent generates C:\_unknown_document_path_\unknown_document
  • This issue could occur if:
    • Third-party add-ons execute a script before an office document opens.
    • A script is run outside of the confines of a document.
    • A script runs faster than a document can open.
    • Script Control does not currently handle macro scripts that do not originate from office documents.
      Examples of applications that load Visual Basic DLLs and run macro scripts natively are SOLIDWORKS and EMC Captiva.
      • These types of macro scripts will be blocked by default.
        The scenarios described above are not caused by the BlackBerry Protect Agent, as the script or add-on would be from a third-party and potentially designed to function in that manner.
  • BlackBerry Support cannot troubleshoot or determine the location of these scripts. 

Allowing “unknown_document”

  • Use the following folder exclusion:

\__unknown_document_path__\

  • Using this path requires Agent version 1470 and later. 

Please Note: The script exclusion \__unknown_document_path__\ does open up a vulnerability to email based spear-phishing attacks. 

  • Unfortunately, this is the security vs usability line we must sometimes walk.

If you would like to discuss some email security options please feel free to reach out to our Sales team (msssales@sonicwall.com).

About Microsoft Office Macros

  • Microsoft Office macros use Visual Basic for Applications (VBA) that allows embedding code inside an Office document (typically Word, Excel and PowerPoint).
  • 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.
  • This is what CylancePROTECT Agents look for, malicious actions originating from a macro that affects things outside the Microsoft Office products.

TIP: Starting with Microsoft Office 2013, macros are disabled by default. Most of the time, you should not be required to enable macros to view the content of an 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.

Related Articles

  • MSS Managed Firewall Best Practice Configuration
    Read More
  • NDR: Integration Guide
    Read More
  • NDR: Windows Server Agent
    Read More

Categories

Managed Security Services
Endpoint Managed Detection and Response
MDR for Cylance
not finding your answers?
Ask the Community