Creating Custom Rules | ThreatLocker Help Center

If you find yourself permitting the same software twice, then you can go in and create custom rules on your own. A custom rule allows you to permit common files that experience frequent hash changes or multiple files that come from similar file paths. When creating a custom rule, it is important to create the rule as restrictively as possible without making it burdensome.

The hash is a one-way encoding of the file, calculated by ThreatLocker using its own hashing algorithm. It is the most secure way of permitting a file. By default, ThreatLocker will always use the hash when it creates Policies and Application Definitions during an automatic learning session.

When you are creating a custom policy, it is generally because the hash has changed frequently and therefore the hash should not be used as one of the parameters. ThreatLocker recommends combining the following parameters when creating a custom rule:

Certificate - A digital certificate is issued by a certificate authority (CA). It serves as a way of saying that the signing company stands behind the file. This is the certificate of the file, not the process using the file. You should not use wildcards for the certificate as certificates do not change often.

- Some companies, such as AnyDesk, have changed their certificate due to it being compromised. Other attackers can make certificates that seem like legitimate ones. Ensure that certificates you are permitting within custom rules are not outdated and come from trusted sources.

- It is not recommended that you permit certificates from companies that have a tendency to sign a broad range of files. Companies such as Microsoft sign many files they interact with, which would allow for many applications to be permitted within your environment you might not permit for some users.

Full Path - The Full Path is where the file is located. Multiple wildcards can be used in the path. For example in c:\users\*\appdata\myapp\* the first wildcard replaces the username and the second wildcard says that anything in c:\users\*\appdata\myapp folder is permitted. You can also use Regular Expressions here if you'd like to be more complex.

- Wildcards can also be used if the file path is unchanging except for the name of the file. Applications can sometimes generate several ‘.dll’ files, so in cases such as the example below, putting a wildcard in place of the file name would limit the amount of files being blocked during an installation.

- - Example: c:\program files\notepad++\plugins\nppexport\*.dll

- - The example above would be permitting all .dll files that come from the c:\program files\notepad++\plugins\nppexport file path.

- When placing wildcards, it is important to put them in parts of the file path that are expected to change regularly, such as usernames, version numbers, or file names. This ensures that more files can be permitted using your chosen parameters.

Process Path - The Process Path is what process or Application is trying to use the file. For example, the file in the photo above was being called by the process pictured below, c:\program files\notepad++\notepad++.exe. If needed, the process path can also contain wildcards. When creating a custom rule for a file that has no process, instead of leaving it blank, use "[]" to specify that this value must remain empty.

- Many Process Paths come from standard Windows file paths, such as system32 or even temp folders. While these can be used within custom rules, it is recommended that this be avoided due to how broad this would make your custom rule. If possible, try only including Process Paths that come from obvious applications, such as the notepad++.exe shown in the picture below.

Created By - The created by parameter is used by temporary files that were just created. If there is a process that creates a new file, using this parameter will help ensure that the file wasn't created by something other than what you want to permit. Created by only works on ThreatLocker Version 6.2 and above. Created by works great for update files that are temporarily created just to update an application. The created by process can also contain wildcards if needed.

- Like Process Paths, the Created By Process can often be from a standard Windows file path. While this can still be used within a custom rule, it is recommended that you only include Created By Processes that come from obvious applications, such as the npp.8.7.8.instaler.x64 (1).exe shown in the picture below.

In the example below, you’ll see that the ‘.dll’ file was called by notepad++.exe, and was created by npp 8.7.8.installer.x64 (1).exe

A custom rule that could be made using this information would be:

Full Path: c:\program files\notepad++\plugins\nppexport\*.dll

Process Path: c:\program files\notepad++\notepad++.exe

Created By: c:\program files\npp.8.7.8.installer.x64 (1).exe

By using these parameters for the process path, it would allow all ‘.dll’ files coming from the Full Path that have the same Process Path and Created By to be permitted by the application the custom rule is put into.

Note: You cannot add custom rules to Built-In applications because they are updated internally by ThreatLocker. For information on what a Built-In application is and which ones ThreatLocker has created, you can review the following article: ThreatLocker Built-In Applications | ThreatLocker Help Center

When creating custom rules, there are a few steps you should follow to ensure a safe custom rule is created:

Permitting by hash is always the most secure method.

Permitting by certificate and at least one other parameter is the next most secure method. You can permit by certificate and path, certificate and process, or certificate and created by. If the option is available, ThreatLocker recommends permitting by three parameters as this enhances the safety of your custom rule. As more are added, it increases the number of parameters an application must meet before being permitted by the custom rule.

After combining certificate and one other parameter, the next best way is to permit by certificate alone, but only from a very trusted vendor that is selective in the files they sign. The best practice is to only allow by certificate if it is a company that you really trust. Even ransomware can be signed. Consider if permitting by certificate alone would be casting too wide a net for a secure environment.
- Note: Permitting Microsoft certificates is not recommended as they sign a broad number of files. This can include files related to IT tools or remote access software, which should be investigated prior to permitting for users.

If you are dealing with a file that is not signed, you can choose to combine the other parameters: path, process, or created by process. If you can combine all 3, that is the most secure option but always combine at least 2. You should always avoid permitting by a single parameter.

For more information, please see our ThreatLocker University Course, Permitting Software.

If you are having trouble figuring out the most secure way to permit a file, contact the Cyber Heroes. They can assist you in making a secure rule, and they will walk you through it step by step.