Help CenterThe ThreatLocker Built-In Application definitions cover the components needed to run the RMM software on your machines; RMM scripts are not included in this Built-In Application. To permit a script to run in your environment, you will need to permit it separately from the RMM Built-In itself.
ThreatLocker does not recommend creating rules to whitelist scripts from your RMM to run automatically. In the event your RMM gets compromised, then you would have a Policy that permits all scripts coming from your RMM to run.
Please note: Creating a rule to permit scripts will only permit the execution of the script itself. PowerShell Ringfencing still applies. And any files that the script attempts to download will still need to be approved.
Best practice is to permit scripts from your RMM as you use them, and maintain control of your environment. It is also worth noting that any scheduled jobs you do have running from your RMM will get picked up during your initial onboarding learning process and be permitted by hash. So, provided nothing changes, you will not have to utilize Learning Mode every time they run.
The most secure way of permitting scripts that don't change hash, regardless of what environment they are being run in, is to permit them by hash. Hash is the number one way to ensure the integrity of the file remains intact.
Permit By Hash
To permit a script by hash, place a single computer into Learning Mode and run the script on that single learning computer. Then, the Policy that is created through Learning Mode can be applied at the organization level you deem appropriate. Once the new Policy has been deployed, you can then push the script out through your RMM and it will be permitted to run at the level you applied the Policy.
To check to see if a particular file is changing hash, click the 'View File History' button as shown below. Please note that the File History may not work with some RMM scripts because they tend to change frequently.
When looking at the file history, keep in mind that it may not always be the same file due to the way ThreatLocker recognizes them. There may be variables within the filename that may be mismatched. Keep this in mind when you are looking at the file history and pay attention to the details that the history provides.
If you discover a file that is changing hash, you may decide to either approve each script as it needs to run by placing a computer in Learning Mode or to create a custom rule.
Custom Rule Creation
If you decide to create a custom rule to accommodate scripts executed by your RMM, care must be taken to be sure the rule you are creating is as restrictive as possible. For example, you could create a separate Application containing the custom rule with a separate Policy for it and turn it off when you are not using it to restrict the window of opportunity for exploitation, helping to reduce the potential for an unauthorized script to run.
Please note that in order to view Policies that are disabled (turned off), you will need to select the checkbox next to 'Include disabled and expired Policies' at the top right of the Application Control > Policies page.
When viewing the file in the Unified Audit, if there is a 'Created By Process', you should always use that as one of the parameters you use when creating your rule. This will ensure that even if someone were to switch out the file in the background, it would be denied. You can see the 'Created By Process' highlighted in the screenshot below. That being said, if there is no 'Created By Process', please scroll down to the subsection entitled, "Creating a Custom Rule without a 'Created By Process".
Utilizing RegEx for Custom Rules
To maintain extra layers of restriction, you can utilize RegEx rules when creating custom rules for RMM scripts. Each RMM has its own file naming convention for its scripts, so you won’t be allowing scripts from other RMMs to run.
RegEx will allow you to limit the file's naming convention to specifically what fits your RMM's use case, as opposed to opening up the entire directory.
Using RegEx, you can specify the number of characters and whether they are letters, numbers, or both. The filename or path must follow that exact pattern otherwise it will be denied. Using wildcards will allow any number of alphanumeric characters in the filename or path, which is not recommended when making custom rules for RMM scripts.
Steps For Creating A Custom Rule and Policy
Click the 'Permit Application' button from an entry in the Unified Audit. This will open the Application Request window.
Next, select if you would like to add this to an existing Application or create a new Application. ThreatLocker recommends you create a separate Application for your tested RMM scripts that way you can turn the policy off and on to keep control of when these scripts are permitted to run.
You will need to select 'Create a new Application Definition' to make a custom rule. Insert a name for your new Application.
To create a custom rule, you will need to select 'Manually choose options'. Select the checkbox next to Path, Process, and Created By. ThreatLocker will automatically populate the information. In the Path textbox, you can delete the path and replace it with a RegEx rule. You will also need to add "regex:" at the beginning of the path as shown in our example below.
Please note: The following RegRx rule is for demonstrative purposes only and may not apply to your specific situation.
regex:c:\\programdata\\centrastage\\packages\\[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}#\\command.ps1
If you need assistance with creating this custom application definition or your RegEx rule, please click the 'Get Help from a Cyber Hero' button in the bottom right corner of the ThreatLocker Portal.
Select the action for this rule. You can select 'Permit the application without restriction' or 'Permit the application and add Ringfencing restrictions'. If your RMM script doesn't need access to your protected files, you could add file Ringfencing to your 'Action'.
After that, you will need to select where to apply this Policy. If only one client is using this RMM, you can select to apply this to the entire organization for that client. However, most people create this Application Definition and Policy and apply it at the global level so that it applies to the parent organization and all child organizations. To select the global level, first select 'A computer group', and from the dropdown menu, select your global group.
For help creating a global group, please see the associated article Creating a Global Computer Group.
Don't forget to click the 'Save' button in the top left corner, and to click the 'Deploy Policies' button. If you are applying this Policy at a global level, you will need to go to the Organizations page and deploy Policies from there. For more information, please visit our associated KB article located here, Deploying Policies.
Creating a Custom Rule without a 'Created By Process'
For the following screenshot, you can see an entry in the Unified Audit for a script that does not have a 'Created By Process'. In this example, to create a custom rule, click the 'Permit Application' button.
Then you will follow the same steps as above, but without selecting 'Created By'.
Please remember that this futureproofing rule will allow future scripts to run, but it won't permit the files that follow the script to run. And PowerShell Ringfencing will still be enforced.
Please reach out to Cyber Hero Support if you would like assistance in creating a custom rule to permit your RMM scripts.
If you would like more information on applying Ringfencing to your RMM Agent, please visit Ringfencing your RMM .