The Open Door Policy: How Trusted Apps Became Hackers' Favorite Smuggling Routes

Imagine you've hired a security guard for your house. They're diligent, well-trained, and vigilant about anything that looks suspicious. But they also have a list of people they've been told to let through without question — the mail carrier, the cleaning service, the dog walker. Now imagine a thief figures out that list and shows up wearing a postal uniform.

That's essentially what's happening every day inside networks running standard antivirus configurations. Attackers aren't punching through your defenses anymore. They're walking through the front door wearing a uniform your AV recognizes and trusts.

The Whitelist: Necessary Evil or Security Liability?

AV whitelisting exists for good reasons. Security software that flags every PowerShell script, every cloud sync operation, and every remote desktop session as suspicious would grind most businesses to a halt within hours. So vendors maintain lists of trusted applications, processes, and behaviors — things the AV engine is trained to look past.

The problem is that this trust is largely binary. Either an application is trusted or it isn't. And once something earns that trusted status — whether through vendor designation, admin configuration, or simply being widely used enough — it gets a pass. Not a conditional pass. Not a "we'll still watch what you're doing" pass. A full bypass.

For attackers who've done their homework, this is the most valuable intelligence they can gather about a target environment.

PowerShell: The Swiss Army Knife That Cuts Both Ways

Few tools illustrate this problem more clearly than PowerShell. It's deeply integrated into Windows administration, used by IT teams everywhere for automation, configuration management, and remote management. It's also, by a wide margin, one of the most abused tools in modern attacker playbooks.

Microsoft has added logging and constrained language mode to address some of this. But in practice, many organizations run PowerShell with minimal restrictions because locking it down breaks legitimate workflows. And most AV products, even those with behavioral detection capabilities, treat PowerShell executions from admin accounts as presumptively legitimate.

A community member who works in incident response shared a case — anonymized and stripped of identifying details — where an attacker who'd compromised a service account spent three weeks using scheduled PowerShell tasks to compress and stage sensitive HR and finance data. The AV never fired. The SIEM generated alerts that got buried in noise. The data left the building through an SFTP connection to a cloud storage endpoint that was also whitelisted because the finance team used it for vendor file transfers.

Every single step in that chain was "trusted." The attacker never touched anything that looked like malware.

Cloud Sync: The Exfiltration Channel That Looks Like Productivity

Dropbox. OneDrive. Google Drive. Box. These services are whitelisted in virtually every corporate AV deployment because blocking them would cause immediate, visible pain for end users and generate a flood of helpdesk tickets.

Attackers know this. The technique — sometimes called "living off the land" exfiltration — involves staging stolen data in a folder that syncs to a cloud service the attacker controls. No custom malware. No suspicious outbound connections. Just a file appearing in a synced folder and disappearing into the cloud.

Variants of this technique have been documented in incident reports from the Cybersecurity and Infrastructure Security Agency (CISA) and in threat intelligence publications from multiple vendors. It's not obscure. It's not new. It keeps working because the fundamental trust problem hasn't been solved.

Remote Access Tools: The Most Dangerous Category of All

If PowerShell and cloud sync are the silver medals, legitimate remote access tools (RATs — yes, the acronym is doing some work here) are the gold. Tools like AnyDesk, TeamViewer, ConnectWise ScreenConnect, and Zoho Assist are explicitly designed to give someone remote control of a machine. They're also explicitly trusted by most AV configurations because IT departments use them constantly for support.

The abuse case is straightforward: an attacker who gains an initial foothold installs one of these tools (or finds one already installed), establishes a persistent remote access channel, and uses it for everything from reconnaissance to data collection to final exfiltration. The AV sees a known, signed, trusted application communicating with a known cloud endpoint. It sees nothing to act on.

This technique appeared prominently in reporting around the Conti ransomware group's leaked playbooks, where operators were explicitly instructed to use legitimate remote tools to maintain access rather than custom backdoors that might trigger detection.

Auditing Your Own Whitelist: A Community-Sourced Starting Point

The NoDAVG community has been building out practical guidance for this problem, and the core advice from contributors with enterprise security backgrounds boils down to a few actionable steps:

Pull your AV whitelist and actually read it. This sounds obvious, but most organizations inherit whitelists from previous admins, add entries reactively when things break, and never review the cumulative result. Schedule a quarterly review. Look for entries that are broader than they need to be — entire directory paths whitelisted when specific executables would suffice.

Log what your trusted applications are doing. Your AV might not flag PowerShell, but your SIEM can still capture what those scripts are doing. Enable PowerShell script block logging. Log cloud sync client activity at the network level. The trust your AV extends doesn't have to extend to your logging infrastructure.

Apply the principle of least privilege to whitelisting. A cloud sync client doesn't need to be trusted to run in a directory containing your customer database. A remote access tool used only by IT doesn't need to be whitelisted on every endpoint. Scope your trust relationships as narrowly as the business workflow actually requires.

Get behavioral on your trusted apps. Some modern endpoint detection platforms offer the ability to monitor behavioral anomalies even within trusted application contexts — large volumes of file reads before a sync event, for example, or PowerShell making outbound connections to unusual endpoints. If your current AV can't do this, that's a gap worth knowing about.

Treat your whitelist as a threat model input. When you're thinking about what an attacker could do inside your environment, the whitelist is basically a roadmap of what they can do without triggering alerts. Walk through it with that lens.

The honest takeaway here isn't that whitelisting is wrong — it's that whitelists represent decisions that were made at a point in time, and those decisions accumulate into a trust architecture that most organizations have never fully mapped. Attackers map it for you. It's worth doing that work yourself first.