For anyone not familiar with Cylance PROTECT, it is one of a few “next gen” antimalware solutions that uses statistics and math (pronounced AI) to interrogate a process in a few very key ways. Protect breaks down a process while it is being written to disk, when it is at rest on the disk, and most importantly as it is being executed. This is a fantastic option when you are looking at threats that are binary based. It is fast, effective and low cost (in terms of resources). It also does not require constant signature updates like traditional/legacy anti-malware. There is a cloud-based AI engine that continually learns about binary based malware. The individual agents talk to it in near real-time when a binary is interrogated. If the agent is offline there is a smaller copy of this engine stored locally. Every so often where there is a statistically significant update in the cloud AI’s understanding of binary based malware the local copy gets updated.

Now all of that is pretty awesome if all you were looking for, or at, was binary based threats. Unfortunately, threat actors have a wide array of other methods to attack your environment and malware can come in many forms. Fortunately, Cylance also added in functions to look for process pivots and script execution (in Windows only for now). It is the script execution piece that will be our focus today, but we need to talk a bit about memory control as well because script control works in tandem with memory control. In fact, you cannot turn on script control without enabling memory protection (Or Cylance Optics for that matter). The functions that work in memory protection to watch process behavior in memory are the same ones that watch script execution, by… you guessed it, different processes.

This leads us to our first potential problem, if you exclude a process from monitoring in memory protection it is going to be ignored in script control. The reason for this is that when you add in a process for exclusion in memory protection you are ignoring any pivots it makes in memory, the memory protection feature does not report on what it is doing any more. That means no script monitoring either. You can see this in newer versions of Protect as when you add a process exclusion in memory protection, it also adds a parent process exclusion in script control. The moral here is; if you do not absolutely need to exclude a process for it to work, don’t.

So what exactly does script control do? Well, it breaks down into a few functions. Monitor for Active Scripts, Macros, and PowerShell scripts. It is also capable of blocking all access to the PowerShell console (including if it is call by a Macro or another script). This covers a wide array of script types although it does not cover them all (Python is not covered). These items are either on or off, but except for PowerShell console blocking you can create exclusions that allow scripts to execute even with blocking turned on.

Next let’s talk about script control exclusions. If you have already worked your way through excluding files and folder in file protection you know that is an absolute path in windows (drive letter:\file\path\).
For memory protection you need to get down to the actual process name, but it is a relative path so there is no need for the drive letter (\path\to\file.exe). With script control you have the option of using a relative path to the folder where the scripts execute (\path\to\scripts\) or use a wild card. Wildcards are fun as they are not 100% intuitive; they are quite handy though. As an example, if you are using Meraki wireless devices, switches etc the software will generate random .tmp files that pop up in the windows temp folder. Using the standard exclusion, it would be \windows\temp\. However, that exclusion means allow all scripts in the windows temp folder to run. Not exactly the best option there. So, in this case you would want to use a wildcard exclusion. For a wild card you flip the slash over so instead of \windows\temp it would be /windows/temp/ to this you would add some common characteristics to the file name. if memory serves all the Meraki scripts start with m_a and have four random numbers then it ends with .tmp. It would look like this m_a4523.tmp the ma and .tmp are the common item so your wildcard exclusion would be /windows/temp/ma*.tmp. This exclusion allows you to let the Meraki scripts run where they are, but not other items that you might not want to run. Something important to note here. As the exclusion is relative, the agent does a lookup and match for that path. That means any folder path that has \windows\temp\ in it would be excluded and all sub-folders in the temp directory. An example would be c:\my\malware\windows\temp\evil\stuff\ would also be excluded because \windows\temp\ are part of the path. The folders my and malware would not be, but temp, evil, and stuff would be wide open.

By now you might be asking, why bother with script control if it is this complicated? Well, the most obvious reason is that many, many forms of ransomware and malware start with a macro that executes a PowerShell script. The script will often try to download malware and execute it on the system, it may also try to attack or disable parts of your malware protect and many, many other things. The scripts can be simple “one sided” attack, or they can be more complex, but they are still very popular especially considering how open Microsoft office products have become in terms of Visual Basic scripts, Macros and other fun things. A clever attacker can inject their script in an email body, a word document, excel spreadsheet and more. Even with the frustrations that you can hit with script control, enabling it properly takes away one more avenue of attack on your endpoints. When you consider how often an attack starts with the compromise of a userland endpoint, it is more than worth the trouble.

While this is certainly a very streamlined explanation of how to configure and tune protect’s script control function it is a good place to start if you are having challenges in getting it rolled out and in blocking mode. Having used Cylance PROTECT and Optics in more than one environment, I can tell you that getting this configured right can make a world of difference in the safety of your organization. Getting it enabled and configured takes time, understanding, and buy in from the top down. It becomes part of the culture of security in your organization when done right. The bumps and blocked macros are not viewed as punitive or a pain in the ass, they become part of the process and something to work with IT and the security team to resolve instead of just something to complain about. So, before you click that block check box talk to your users (email works) explain to them the reasons and the benefit, so they feel part of the process. Then work through the detections slowly, exclude what is needed and leave the rest to be swept up by Script Control.