Application Control - Part 1 - The dangers of allowing software

ℹ️

This blog post is part of a series of posts that delve into Application Control on Windows. This series will explore the risks involved in not controlling applications, as well as the ways in which we can control what is allowed to execute in our environments.

Why it pays to be careful what software you allow in your org

When approving software for use in your organisation, we all know that we need to be careful. Software can contain vulnerabilities, require excessive permissions, or can store our data in unsanctioned locations. In this article, we will explore some examples that are often overlooked, and why it might be prudent to review your process for software approval.

Knowing what software is actually allowed in your business is often a tricky situation, and more often than not we rely on block lists without considering applications that are “assumed” bad - whilst we assume these to be bad, are we actually blocking them?

There are some great tools around to assist you with blocking applications, URLs and services. Some of these comes with flaws (Process names can be changed, people!) but it all forms part of a wider defence-in-depth strategy when it comes to protecting your environments. For example, you might consider blocking known unwanted, malicious or risky URLs and Certificates - Jay Kerai has a great repository for this, which I have assisted in contributing to: https://github.com/jkerai1/SoftwareCertificates

Application permissions

Let’s take an application like Grammarly. This application might seem harmless, allowing for grammar and spelling checking of your writing and gently nudging you with corrections, but have you ever considered that this is technically a keylogger? The data that is typed into your system is collected and analysed by Grammarly. Do you want your confidential client data or intellectual property to be sent to a service that you have no control over?

The privacy policy

User content, which consists of all the text and documents that you upload, enter, or otherwise transmit to us when you use our products. For information on how we use, process, protect, and store user content, please see "For What Purposes Does Grammarly Use Personal Data?" and "How Does Grammarly Secure and Store Personal Data?" You can also review our Technical Specifications.

When considering the approval of this app (or indeed any app) you should consider the confidentiality of the data that you are processing, and whether introducing a data sub-processor such as Grammarly is an acceptable risk for the gains. Instead, consider alternative solutions such as Microsoft Editor.

Extensions

Browser extensions are not covered by tooling such as Windows Defender Application Control (or App Control for Business) and therefore can be introduced onto a system, oftentimes without an administrator knowing. These extensions have been proven to be a valuable attack path in the past.

When we look at extensions, we should instead be considering the use of whitelisting, and limiting what users can install to a known and approved list of extensions. This also makes management for removing an extension much easier in the future. You can limit Edge extensions using systems such as Intune. You can read more about whitelisting Edge extensions on Microsoft Learn here: https://learn.microsoft.com/en-us/deployedge/microsoft-edge-manage-extensions

Backdoors

Some applications may introduce vulnerabilities or back doors to systems. Take for example, Keypass (not to be confused with Keepass) which is an opensource password management solution. You may think that it is great that a user wants to use a password management solution for their passwords, however Keypass contained a backdoor that allowed access to sensitive password data for users. Taking Keepass as a more well-known example, this had a vulnerability which allowed an attacker to access plaintext passwords in the configuration file: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24055 with proof of concepts available: https://github.com/mandiant/SharPersist/wiki/KeePass

Open Source

I know that open source is a hotly contested topic, and that some enterprises don’t like it from a support and potential supply chain aspect. I’m personally a fan, but I won’t get into arguments either way (even though I can almost guarantee that your closed-source software leverages Open Source components!)

What I will say though, is to be careful with blindly allowing opensource software. Too many businesses fall into the trap of “the source code is open source it’s easy to see if it’s malicious” but how many are actually checking the source code? A very good recent example of this was with Github Actions. tj-actions/changed-files was compromised recently which allowed attackers to access sensitive workflow secrets for projects that relied on this action. This Github action alone was used on over 23,000 Github repositories.

To PWA, or not to PWA…?

Because PWA’s are served exclusively over HTTPS, these can guarantee the encrypted transport of data to and from the server-side infrastructure. As well as this, PWA’s leverage browser-based isolation, which isolates execution and severely restricts access to local file systems and system APIs.

Further, with a PWA the administrators of the environment do not need to worry about updates - The web application is updated by the vendor, and we do not need to worry about changing files or certificates on our Application Whitelisting, whilst standard web controls like Content Security Policy and Subresource Integrity (provided that these have been implemented by the vendor) can provide strong defences against XSS and supply-chain tampering. Finally, the minimal permission model of PWAs (e.g., optional access to camera or location) reduces the overall attack surface and simplifies compliance auditing compared to the elevated privileges often granted to native installs.

Software Updates

As discussed in our To PWA, or not to PWA section, application updates remain one of the biggest challenges in larger enterprise environments. If we’re not carefully monitoring the software in our environments, we cannot be sure that the environment is being kept up-to-date, and this leaves us open to vulnerable components. Taking 7-Zip (a popular file archiver and compression software) as an example, the recent CVE-2025-0411 vulnerability allowed attackers to bypass the "Mark-of-the-web” protection mechanism on affected installations of 7-Zip. This was found to be actively exploited to distribute the SmokeLoader malware.

When we review our software in the estate, we should consider:

What software are we allowing
Why are we allowing the software? What is the business justification
When was the software last updated
Who is the internal owner of the software, who is responsible for timely updates in the event of a vulnerability disclosure.
Who is responsible for testing the updates
How are we testing the updates.

When it comes to how to test the software updates, I created a free and open source tool called Soteria (https://github.com/marshyp/soteria) which can be used for this purpose. Soteria allows users to spin up an isolated Windows Sandbox environment, install the software and baseline its performance. This can then be used to assess potential performance impact to systems between versions.

Further, Soteria will extract information for use in an App Control for Business (ACfB) or Windows Defender Application Control (WDAC) policy. That said, we will discuss in a later blog post in this series how to handle these policies.

Security control bypass

Did you know that some applications are able to bypass enterprise security controls? For example, a simple browser might actually introduce a way to bypass Microsoft Defender for Endpoint Web Content Filtering. Take for example SeaMonkey. Jay Kerai has an excellent post on this here: https://www.linkedin.com/posts/jay-kerai-cyber_wdac-defenderforendpoint-intune-activity-7296143608548651009-kQzQ?utm_source=share&utm_medium=member_desktop&rcm=ACoAACMoYCgBiwq_vgdN_b54xqyXWPtcvOfHzaw

Geopolitical connotations

Some businesses are restricted from doing business with, or leveraging tooling from, some countries due to imposed sanctions. For example, with the Russia/Ukraine war you may be restricted (or have decided to restrict, yourselves) from using Russian software. But do you know what software you have, and where it comes from?

Have you considered the possibility of a backdoor being introduced into the software due to geopolitical uncertainty?

In my next post, I will discuss how to audit what software is currently in your estate, and obtaining telemetry to help you on your journey with Application Control for Business (ACfB) (Previously known as Windows Defender Application Control (WDAC)).