As you know, the files within your endpoint folders can hurt you. Most of those that are malicious files have been reused by attackers often. Detection-based defenses deal with these well. Diligent attackers, however, use tools to modify malicious files to evade detection. Enterprises need to supplement their detection-based defenses with tools that do not have to recognize malicious files to defeat them. This blog strives to explain to executives what their technical people need them to understand at a high-level.

Blog Summary

• Forget Full-blown Application Control
• Why User-Space Folders Pose More Risk than System-Space Folders
• Least Privilege: End-users Ought to Run PCs without Elevated Privileges
• High-Risk Apps make some System-Space Folders High-Risk
• Workstation vs Server Risks and Mitigations
• Malicious Files in Folders, Detection-alone is Not Enough
• You Need Default-Deny for Malicious Files within High-Risk Folders
• Why Application Control is Overkill and yet Not Enough for Malicious Files
• AppGuard is an Easier and Better Solution for Malicious Files in Endpoint Folders

Forget Full-blown Application Control

Deploying and operating Application Control is onerous. Despite many vendors specifying the dreaded ‘allow lists’, they still are. And worse, it’s not enough anyway; but that’s a different topic.

It’s important to know that Application Control strives to restrict launches and loads of executable and script files from each and every folder on endpoints. Unlike smart executives that handle high-risk things differently from low-risk things, Application Control generally treats all folders alike, creating much unnecessary work.

Why User-Space Folders Pose More Risk than System-Space Folders

Remember, risk is not just about potential impact but also the likelihood of impact. 

User-space is a Microsoft concept coined for laptops and desktops. It consists of folders where end-users without elevated privilege can save and alter files. System-space consists of folders that the operating system (OS) doesn’t allow end-users to save and alter files without elevated privileges. OS and application files belong in system-space...originally. Google helped change that with Chrome many years ago by making Chrome installable into user-space so end-users could use Chrome in the enterprise without having to get IT to install Chrome into system-space. Now, user-space is typically full of applications, legitimate and malicious. 

Adversaries have always “dropped” malicious files into user-space. For example, if an end-user opens a weaponized document with Microsoft Word or visits a website that hacks the web browser, any files these hijacked applications might write to disk cannot normally get into system-space if the end-user lacks elevated privileges. But they can always write into user-space. 

While the potential impact of malicious files in system-space is greater, the likelihood is much lower. Now, with both legitimate and potentially malicious executables and script files in user-space, the enterprise has a dangerous attack surface to handle. 

Least Privilege: End-users Ought to Run PCs without Elevated Privileges

Let’s digress for a moment for an important cause. The above user-space and system-space distinctions should make more clear to you the importance of insisting that end-users do not use their workstations while logged in as administrators. It makes system-space more accessible to adversaries. Tell your IT/Sec-Ops people that you’ve got their back on this cause.

High-Risk Apps make some System-Space Folders High-Risk

Enterprise servers are used by applications more so than by end-users. User-space folders exist on Windows Server. They still represent an attack surface because any hijacked application can write to them. However, in servers, some applications must be allowed to write to folders in system-space. If these applications pose a high-risk of compromise, then those system-space folders must be regarded as high-risk as well. Your security controls must mitigate file launch and load risks from both user-space and these high-risk system-space folders. The others pose some risk too but less.

Workstation vs Server Risks and Mitigations

The impact from a compromised server generally far outweighs that of a workstation. You might think that the likelihood of a compromise is much higher on workstations. That’s true, but sophisticated adversaries that take the time to modify their malicious files prefer targeting servers. Fortunately, as servers exist primarily to host applications instead of unruly end-users, servers can be more aggressively locked-down to mitigate risks with less likelihood of disrupting legitimate activities.

Malicious Files in Folders, Detection-alone is Not Enough

Your detection tools strive to tell good from bad files. Some will upload a signature or the file itself for cloud analysis of good versus bad. Long story short, these detection methods are successful for most files but struggle when adversaries take time to use files modified to evade detection. Adversaries have cloud services too. Unlike VirusTotal where each file submission informs the detection vendors, the adversary cloud services do not. Proficient adversaries know before they attack how likely their malware will be detected.

You Need Default-Deny for Malicious Files within High-Risk Folders

We’re mostly concerned with three classes of files: executables, script files, and dynamic link libraries (DLL, Windows). Sec-Ops don’t want the malicious executables to launch and the malicious script and DLL files to load. IT-Ops want the legitimate ones to launch/load. The best answer is to add a deterministic control to deal with those files that fool detection. Such controls leverage digital signatures. This represents a zero-trust principle applied within the endpoint, only allowing the demonstrably trustworthy to launch/load.

Why Application Control is Overkill and yet Not Enough for Malicious Files

Any Application Control tool can restrict file launches and loads to files with valid, trusted digital signatures, or even hashes. Consider two common user-space applications: Zoom and Chrome. The industry observed zero-day exploits in the wild for these and other common user applications this past year. Once allowed to launch, exploited applications conduct malicious actions. With a simple privilege escalation technique, these hijacked applications can then add or alter files in system-space.

Most Application Control tools, such as Microsoft’s, do not control what applications can do after they are allowed to launch. Those that do are so difficult to use that most customers only use the launch controls. Consequently, Application Control tools must restrict launches for the entire endpoint rather than just the high-risk folders. This means the policy “allow” lists are 100  to 1,000 times larger (i.e., more administrative burden and risk of disrupting legitimate work) than if only focused on high-risk folders. Is it any wonder why market analysts say there are few new Application Control deployments?

AppGuard is an Easier and Better Solution for Malicious Files in Endpoint Folders

It consists of three basic controls: launch, containment, and isolation. Containment and isolation might seem unrelated to the problem of malicious files in endpoint folders. Their relevance will be explained soon.

AppGuard’s launch controls are applied only to high-risk folders, though administrators can apply them to other folders if desired. Most high-risk folders are already so designated in AppGuard’s default policies. AppGuard launch controls do not deal with ever-changing file hashes. Instead, AppGuard relies on digital signatures by trusted publishers, which simplifies ‘allow’ policies considerably.

As for those user-space applications that get hijacked, AppGuard applies the containment control. This can be applied per publisher (i.e., contain any application signed by the publisher), per folder (contain any application within a folder), and/or per application. A contained Zoom, for example, runs normally but if ever it gets hijacked, AppGuard does not allow it to add or alter files in system-space. By not letting high-risk applications alter system-space, the necessity for applying launch controls to all those folders is greatly diminished. Only a few standard folders in system-space warrant launch control, which restricts launches to files signed by select publishers. 

AppGuard’s containment operates on other dimensions beyond the file system, including Windows registry, process memory, child processes, process privilege, and network communication. The point of containment is to protect the host from what is contained.

Isolation is the opposite of containment. Isolation protects an application, folder, and/or object from the rest of the host. AppGuard is layered protection. Should something malicious somehow someway run unrestricted, isolation rules protect the contents of select folders from the rest of the host. For example, Chrome caches passwords in a file on disk. An isolation rule ensures that only Chrome can access it.

In summary, AppGuard provides the easiest and most effective means to mitigate risks to the enterprise posed by whatever files are in the folders of its endpoints.