Why Your "Trusted" Software Is Just a Trojan Horse Waiting to Execute

TLDR: Traditional vendor risk assessments like SOC2 reports fail to account for the reality of modern supply chain attacks, where trusted software is weaponized to execute arbitrary code. By analyzing the lifecycle of vulnerabilities in tools like Microsoft Exchange and the pervasive risk of third-party components like Apache Log4j, it becomes clear that endpoint security must shift toward strict application allowlisting and ringfencing. Pentesters should stop focusing solely on network perimeters and start auditing the execution privileges of every binary in the environment.

Vendor risk management is broken. We spend weeks chasing SOC2 Type 2 reports and filling out security questionnaires, only to be blindsided when a "trusted" piece of software in our environment turns against us. The reality is that the software you install is often more dangerous than the external threats you spend your budget trying to block. When you grant a binary execution rights on a server, you are effectively handing the keys to the kingdom to whoever wrote that code, whether they are a reputable vendor or a compromised third-party developer.

The Illusion of Trust in On-Premise Software

The Microsoft Exchange vulnerabilities from a few years ago serve as a masterclass in why we need to stop trusting software by default. Attackers didn't need to find a zero-day in the OS; they simply exploited the trust we placed in the Exchange server itself. By manipulating the Offline Address Book (OAB) URL, they triggered remote code execution.

The mechanical reality of this attack is simple: the server was configured to allow the software to perform actions that it had no business doing. When a user or an automated process triggered the OAB download, the server executed a series of batch files and PowerShell scripts. If you are a pentester, you know that once you have code execution on an Exchange server, you have effectively compromised the entire Active Directory domain. The server is a high-value target because it is inherently trusted by the domain controllers.

Weaponizing Features, Not Just Bugs

We often obsess over OWASP A06:2021 – Vulnerable and Outdated Components, but the real danger lies in the weaponization of legitimate features. Take the example of an IT management tool or an RMM agent. These tools are designed to push updates, run scripts, and manage configurations across thousands of endpoints. If an attacker gains access to the management console, they don't need to write custom malware. They just use the tool's built-in "feature" to push a malicious payload to every machine in the fleet.

This is the "living off the land" technique taken to its logical extreme. When you run a binary, it inherits your user context. If that binary is a piece of software with administrative privileges, it can access every file, network share, and system setting that you can. It can launch PowerShell, spawn reverse shells, or modify the registry to ensure persistence.

Consider the SolarWinds Orion incident. The attackers didn't need to break the software's security; they injected malicious code into the build process itself. The software remained "signed" and "trusted" by the vendor, allowing it to bypass traditional endpoint detection and response (EDR) solutions that were looking for known malicious signatures rather than anomalous behavior.

Why Your Network Perimeter Is Irrelevant

Pentesters frequently encounter environments where the network is locked down, but the endpoints are wide open. We see developers running tools that have full access to the local file system, the ability to spawn child processes, and the freedom to initiate outbound connections to the internet. If a piece of software is compromised, it doesn't matter if you have a state-of-the-art firewall. The software is already inside the perimeter.

To mitigate this, you have to move toward a zero-trust endpoint model. This means implementing strict application allowlisting. If a binary isn't on the list, it doesn't run. Period. But allowlisting alone isn't enough. You need to implement ringfencing to restrict what those allowed applications can do.

For example, why does your word processor need to spawn a command shell? Why does your PDF reader need to initiate an outbound connection to an unknown IP address? By restricting the capabilities of these applications, you can prevent them from being used as a conduit for an attack, even if the application itself has a vulnerability.

The Path Forward for Researchers

If you are performing a red team engagement, stop looking for the "cool" exploit and start looking for the "trusted" path. Audit the software installed on the target machines. Look for binaries that run with high privileges and have broad access to the system. Ask yourself: if I were to compromise this specific application, what could I do?

The answer is usually "everything."

Defenders need to stop relying on the vendor's word that their software is secure. You need to assume that every piece of software in your environment is a potential backdoor. Start by auditing the execution flow of your most critical applications. If they don't need to talk to the internet, block them. If they don't need to run PowerShell, prevent them from doing so. The goal is to shrink the attack surface until the only thing an attacker can do is crash the application, rather than take over the entire machine.

Stop chasing the noise of every new CVE and start focusing on the structural weaknesses in how we allow software to interact with our systems. The next big breach won't be because of a missing patch; it will be because we gave a piece of software too much power and then acted surprised when it used that power against us.