Best Practices When Permitting RMM Scripts

8 min. readlast update: 04.14.2025

The ThreatLocker Built-In Application definitions include all 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, 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.   

The 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. This way, 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 that 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 it. 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 see if a particular file is changing hash, select the File History' tab within the desired log of the Unified Audit. 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, 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 ensure that 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. This will help to reduce the potential for an unauthorized script to run. You can toggle the policy’s status by selecting the switch under ‘Active. This can be found in ‘Modules’ > ‘Application Control’ > ‘Policies’. 

 

Note: To view Policies that are disabled (turned off), you will need to select the checkbox labeled 'Inactive/Expired' located to the right of the search bar and filter section of the 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 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' in the screenshot below. If there is no 'Created By Process', please navigate 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 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.  

 

Creating a Custom Rule using ‘Permit Application’ 

Next, select if you are adding this to an existing application or creating a new one. ThreatLocker recommends you create a separate Application for your tested RMM scripts. This way, you can turn the policy off and on to keep control of when these scripts are permitted to run.     

To create a new Application within the ‘Permit Application’ window, select ‘New Install’. 

 

Enter the name of the new Application you will be creating within the entry field. 

 

To create a custom rule, navigate to the section labeled ‘How do you want to allow this software?. Here, you will see that the option for ‘File Hash or Custom Rules’ was selected by default.  

 

ThreatLocker will include the custom ThreatLocker generated hash by default, but selecting the dropdown labeled ‘Condition 1’ will show you all custom rule options for the given log. 

 

For this custom rule, select ‘Full Path’, ‘Process Path’, and ‘Created By’.  Selecting these conditions will automatically populate them in the ‘Value’ field. These values can be edited to your preferences, and it is here that you can delete the ‘Full Path’ and replace it with a RegEx rule instead. You will need to add “regex:” at the beginning of the path as shown in our example below: 

Please note: The following RegEx 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.bat 

Select the ‘Add’ button once your RegEx rule has been added alongside all other values you are using to make your custom rule. 

 

 

If you need assistance with creating this custom application definition or your RegEx rule, please navigate to the ‘Help’ button at the top right corner of your page and select ‘Chat with a Cyber Hero’. 

 

Next, using the ‘Applies To’ section, select who this application will apply to. If only one client is using this RMM, you can select to apply this to the entire organization. Most people create this Application Definition and Policy and apply it to the global level, as it will apply to the parent organization and all child organizations. To select the global level, first select ‘Computer Group’. Within the dropdown menu, select ‘Global’. 

For help creating a global group, please see the associated article: Creating a Global Computer Group.   

 

Within the conditions section, you can set the policy expiration. If you know that users will only need access to this script for a short period of time, you can toggle the slide bar to set an expiration time. By default, the policy will be set to ‘Permanent’. 

 

In the final section, you can set Ringfencing to be applied for this policy. If your RMM script doesn’t need access to your protected files, you can select ‘Restrict this application from accessing files?’ within the different options for Ringfencing. 

 

For help creating exceptions for Ringfencing file access, please see the associated article: Ringfencing File Access | ThreatLocker Help Center. 

Lastly, you can choose to permit elevation for this policy if necessary. 

 

Select ‘Approve’ at the bottom of the popout window, then ‘Deploy Policies’. If you are applying this policy within this organization, select the ‘Deploy Policies’ button at the top of the page. If you are applying this policy at a global level, you will need to deploy Policies from the Organizations page. For more information, please visit our associated KB article: Deploying Policies | ThreatLocker Help Center. 

Creating a Custom Rule without a 'Created By Process' 

If you receive a script that has a ‘Process Path’ but no ‘Created By Process’, you will still be able to make a custom rule for it. Start by selecting the ‘Permit Application' button. 

 

You will then follow the same steps as above, omitting selecting the ‘Created By Process’ option from the ‘Conditions’ dropdown menu.   

 

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

  

  

  

  

 

 

Was this article helpful?