Using Application Control & Allow / Deny Listing to Protect against Malware, Threat Actors, & LotL Exploits

The terms allow list, block list (also called deny list), and application control are frequently referred to in IT security. However, while these terms are often used interchangeably, it’s important to understand the distinctions of each.

The idea of controlling what can and cannot be accessed using lists is not a new concept, in-fact, it’s been around for decades and is a staple of many security controls, ranging from firewalls, email spam filters, and antivirus to application control. In this blog, I will focus on exploring the pros and cons of allow listing and deny listing in comparison to application control, as methods of controlling the execution of code on a computer. I will also highlight how some of the common drawbacks of application control can be overcome by smartly coupling it with privilege management. In fact, this pairing can unlock significant security and operational synergies.

Block Listing Explained

Block listing (also called deny listing) is probably the oldest form of security control. For more than 30 years, block listing served as the backbone of antimalware products. These deny lists are still broadly used today. Blocks operate on the simple concept of blocking something from running or executing, based on whether it exists on a known list of hashes in a policy or database. If the application hash hits a match in the list, it is denied from executing. On the other hand, if there is no match, then the application is allowed to execute.

If an application or piece of software is known to be bad, then denying it is the straightforward and ideal remedy. Antimalware products depend on this approach to keep known malware at bay.

However, not all things that are bad, are known. In fact, it’s now widely understood that as little as 40% of all malware is known. Thus, block listing – even though still needed to stop the 40%, is insufficient by itself to keep your computer safe

Many malware strains mutate fast. It is not uncommon to see strains with a unique hash exist in the wild for only a few hours. This means that a deny list approach that targets based on file properties cannot easily keep up. Another consequence is that IT ultimately ends up maintaining a list of thousands of files they will never see again in the wild. In February 2021, there were 17.85M new malware samples detected, and likely millions more eluded detection.

Even with modern techniques like behavioral and heuristic analysis, detection is still based on a set of rules to differentiate good and bad. And whether it’s a hash, a behavior, or any other identifier, malware creators remain one step ahead by exploiting weaknesses in those rules. Ultimately, deny / block lists are a reactive technology as they are entirely dependent on knowing about something in advance.

Deny lists are only marginally effective when it comes to controlling user access to applications. If you try to stop something from running or installing with a deny list, it is trivial for savvy users to work-around the rules; often as simple as downloading a different version (you may even inadvertently be driving your users to nefarious websites in their goal to get that software they want to use). If, for whatever reason, a block list fails to stop malware, or an unapproved application, it is referred to as a false negative; the control incorrectly assumed that, because there was no match against the list, the application/software must be good.

Allow Listing Explained

Allow listing is basically the opposite of deny / block listing; rather than a list of applications to deny, it is a list of applications to allow. Allow lists provide a much stronger defense mechanism against malware than block lists because, instead of attempting to identify every known piece of malware that exists, or every bad application you want to deny, it just allows you to focus on the applications that you DO want running—which represents a significantly smaller list in comparison. With that said, traditional allow listing approaches still largely rely on using hashes, and herein lies the problem.

A typical OS install involves thousands of applications. And, once you have installed a bunch of applications, there could be thousands more, each of which is subject to the approval of an allow list. That means each application must be present on the list or it will be denied. Accomplishing this entails a heavy amount of up-front scanning and configuration before you can roll out the policy. And with every change to any of those files, the allow list would need to be updated.

Every time Microsoft rolls out a patch or an update, old files will be replaced with new files. The same goes for patches of other installed applications. And when this happens, your allow list will be outdated, and can (and often does) result in software errors.

Although allow listing is perhaps the strongest form of system hardening, it is also the most error-prone due to false positive blocks on legitimate binaries.

Practical Allow and Deny Listing with Privileged Access Management (PAM)

Due to the complexities and management costs, many organizations struggle to roll out successful allow and deny list implementations. Despite the obvious benefits they bring to endpoint security, these types of lists are too restrictive, too labor-intensive, and too expensive to keep up-to-date. Thus, their use is often limited to small deployments in datacenters and kiosks – where changes are much less frequent and much more predictable. However, when you implement allow and deny listing as part of a privilege management strategy, things can and do become a considerably more straightforward.

Users who log on with local admin rights have full read and write access to the operating system, and every application in every folder – including system folders like Windows and Program Files. So, allow lists need to include every application in those system folders – as I mentioned before, that’s a lot of applications, which are updated too frequently to keep up with. Even though these folders should be considered secure and trustworthy, they cannot be trusted if users (and malware) are able to add new applications or overwrite existing applications.

But users who only have access to a standard user account are, by default, unable to make any changes to those secure and trustworthy folders. And, if users cannot introduce applications without authorization, then you can take advantage of the fact that system folders can be trusted, because the only way that changes can happen is through authorized and legitimate ways – like approved installations, system updates, and software distribution. The upshot is that, instead of having to manage a list of thousands of hashes, you only need to manage half a dozen folders.

When you combine allow listing with privilege management, you can achieve the level of security that you need on your endpoints, without incurring the cost or complexity. It’s a true synergy.

The Inbetweeners & Living off the Land (LotL) Threats

Allow listing and deny listing are often used in combination. Deny the bad, allow the good. But there are inevitably applications that do fall under both categories—applications that would normally be allowed by an allow list, but should be denied by a deny list.

Threat actors have adopted methods of working around both allow and deny listing, by using legitimate apps (that are allowed) to perform malicious actions that would normally be denied. These are living-off-the-land (LotL) apps, and both Windows and macOS come pre-installed with a plethora of tools and utilities used extensively as part of cyberattacks.

Let me give you an example: PowerShell – allow or deny?

PowerShell is a core component of all Windows endpoints that is pre-installed and trusted by default. It is signed with the same certificate that all other Windows components are signed with, and it is in a trustworthy area of the filesystem.

PowerShell (by its very name) is an extremely powerful utility and, as a result, is leveraged for an almost endless number of legitimate purposes—ranging from installations and configurations, to maintenance and break-fix task—and is also used as part of many internal OS functions. PowerShell is an application that needs to be allowed to run.

Because of the vast capabilities it provides, PowerShell also sits high atop the kit bag for threat actors and malware creators. Users can leverage PowerShell through script blocks and the command line to compile, obfuscate, and execute code, run commands for surveillance and lateral movement, and, when running with local admin privileges, can modify OS settings and disable other security controls to circumvent defenses, and persist on the endpoint. So, on the other hand, PowerShell is also an application that needs to be denied.

While PowerShell comes with just enough access (JEA) controls, they are difficult to deploy and manage. Even when JEA is in place, threat actors trade craft of ‘living off the land’ allows them to work around the controls and find ways to exploit the commands that are still authorized.

The Grey Area - An Attacker’s Playground

The grey area between allowed and denied is where modern cyberattackers thrive. These attackers mimic legitimate and trusted behaviors to deliver and execute payloads to exploit endpoints.

While other applications may present a straightforward binary decision, applications like PowerShell, which provide powerful, necessary and legitimate capabilities while also are ready-made tools for fileless attacks, present a real challenge. If you cannot determine the difference between a legitimate use of an application and a malicious use, then your focus instead should be on the context. In terms of cyberattacks, the most important context is which process PowerShell is being executed from.

Far and away, the most prevalent attack vector is an end-user computer – more specifically, through phishing emails carrying malware-laden attachments. Documents such as Microsoft Word, Excel, PowerPoint, and Adobe PDFs, have macro’s – code that can be run when the document is opened – and this code can be crafted to run commands on the endpoint, and deliver payloads embedded in the document itself.

Enabling of macros needs to be consented to, but social engineering makes it easy to dupe a user into clicking ‘Yes’. It’s likely you have your own team of recruiters who routinely receive emails from candidates with CV and application form documents. LinkedIn makes it easy to find who your recruiters are and can even show who their candidates are through connections. My point is you cannot rely on your users to make the right call 100% of the time. Even the savviest of users can (and do) get fooled.

Context is the Key to Effectively Defusing Living off the Land Threats

Macros in documents provide an easy way to run LotL applications like PowerShell – one trusted application, running another trusted application. But with Application Control capabilities, as found as part of BeyondTrust Endpoint Privilege Management, you can use context to apply rules that can tell the difference:

• Should PowerShell be allowed to run? Hard to tell…but…
• Should PowerShell be allowed to run as a child of Microsoft Word? Well, that’s a different use case altogether!

This is context, and this is advanced application control. Using these principles, BeyondTrust has created a solution that is highly effective in stopping tricky zero-footprint cyberattacks, because it can differentiate between a legitimate and malicious use of an application. We call this Pragmatic App Control, because, instead of relying on static allow and deny lists, it evaluates the context of every application, and only allows those that are executed in a legitimate way.

About BeyondTrust Endpoint Privilege Management for Windows & Mac

BeyondTrust Endpoint Privilege Management for Windows & Mac is a preventative endpoint security solution that removes excessive admin rights, applies pragmatic application control, enables passwordless administration, and gives users just enough privileges to do their jobs and be productive. The solution blocks the majority of malware and ransomware and protects against both external and internal threats. Utilizing QuickStart policies, organizations receive rapid time-to-value whether deploying the solution on-premises or via SaaS.