Exclusions for files, folders and processes

Endpoint protection is a necessary component of a multi-layered security stance, which may include email security, firewall(s), intrusion detection, password management, SEIM, SOAR, EDR, and more. Ideally, these systems work together to make it increasingly difficult for bad actors to gain unauthorized access to an organization unnoticed.

Endpoint protection specifically has the responsibility for stopping nasty things from happening on your computer. This traditionally took the form of identifying and isolating malicious software like computer worms, viruses, ransomware, and other unwanted executables. In the constant game of cat-and-mouse between cyber threats and the defenses designed to stop them, malicious software—or malware—has adopted a range of sophisticated evasion strategies to slip past detection, such as:

• Implementing sandbox delays to avoid detection in a virtual machine environment (VME) or sandbox, specifically those that are automated or only operate for a limited amount of time.
• Code obfuscation, which uses a range of techniques to make code difficult to understand in order to hide its intended purpose.
• Living off the Land techniques, in which attackers leverage pre-existing trusted tools and processes to carry out malicious activities while evading detection.

Endpoint protection has evolved in lockstep with these strategies, and one widely adopted approach is to monitor all processes to look for activity indicative of malicious intent. What’s malicious intent, you may ask? Messing around with a lot of files—moving, adding, deleting, and/or encrypting them—in ways that are unusual or inappropriate is a good generic example.

The problem with activity- or behavior-based detection is that there’s a grey area where it’s not 100% clear whether a process is malicious, and this grey area can result in false positives. Err too much on the side of safety and you get more false positives. Err in the other direction and you risk missing some malicious activity.

The Role of Exclusions

Luckily endpoint protection products, Emsisoft included, allow you to configure exclusions, which instruct the software to ignore activity by a particular process or within a given directory. Problem solved, right? Not so fast. Exclusions are helpful for fine-tuning the detection to reduce false positives and can improve system performance, but if poorly implemented they can allow malicious activity to gain a foothold and go unnoticed. To be as secure as possible, an exclusion rule should be as specific as possible, because a very general rule opens the possibility that malware will be excluded either accidentally or maliciously. Excluding a folder and its subdirectories, for example, would potentially allow malware to run freely from that directory structure. Similarly, wildcards and environment variables should be used with care to develop a rule which is as narrow or specific as possible.

Writing Safer Exclusion Rules

Every time an exclusion is added, it opens an opportunity for malware to go undetected, so we want to write the exclusions to be as precise as possible. Let’s consider a number of ways to make exclusion rules as safe, and specific as possible.

• Privileges: It should go without saying, but may also go unnoticed, that only users with administrator privileges should be able to add, modify, or delete exclusion rules.

Why it matters: If someone gains unauthorized access to a computer, it shouldn’t be easy for them to disable your protection. Endpoint protection should always have an administrative password set, so that if someone does manage to gain unauthorized access, they can’t disable your protection and proceed to steal or encrypt your data.

• Some binaries should never be excluded. Some system binaries are known to be exploited as Living Off The Land Binaries, Scripts and Libraries (LoLBAS). By using legitimate Windows tools, there’s no need to use malware which may be blocked by signature-based detection.

Why it matters: The use of these legitimate windows tools to accomplish malicious tasks can be detected and blocked by behavior-based detection, but only if the binaries don’t have exclusion rules. Examples of LoLBINS include: cmd.exe,powershell.exe,regsvr32.exe,rundll32.exe
See the complete list here.

• Limit where rules are applied. Apply the rules to the minimum number of endpoints or users possible.

Why it matters: The less exposure an exclusion has, the less likely it is to be exploited. If an application is used by a few users in accounting, for example, create an exclusion rule that only applies to those users. You never know which device may be compromised.

• Minimize the use of wildcards. Although they can be very helpful, they also open the door to unintended consequences. As with other exclusions, wildcards should be as specific as possible. For example:

C:\Users\*\temp\*.exe ❌
vs
C:\Users\jdoe\temp\Update*.exe ✅

Why it matters: Applying as much detail as possible to a path leveraging a wildcard can minimize the possibility that it opens the door to malicious abuse.

• Never exclude entire drives, or generic folders. Folders that are used by many different applications should never be excluded. Examples of excluding a drive or generic folders include:

C:\
C:\users\username\appdata\roaming
%temp%
C:\Windows

Why it matters: Just as generic folders are used by many applications, they’re also used by malware, so they open the door for easy access by malware.

• Excluding folders is helpful. Excluding folders (but not generic folders) can be more practical than excluding files.

Why it matters: For example, software updates often can’t readily be excluded by filename if those names change with subsequent versions. Excluding the unique folder from which updates are executed can help to get around this issue. For example:

c:\company\tool\version

Finally, when creating an exception rule, pay particular attention to syntax because a misplaced character can have a significant impact.

Final Thoughts

Configuring exclusions is a balancing act: too broad, and you risk giving malware a free pass; too strict, and you may end up with disruptive false positives. By applying exclusions sparingly, keeping them as specific as possible, and restricting who can create or modify them, organizations can significantly reduce their exposure while maintaining smooth operations.