How Attackers Exploit the Application Data Gap

In a previous article, I explained why Data Loss Prevention isn’t enough to protect your application data. DLP protects email and web data brilliantly, but completely misses the 80% of business-critical data living in desktop applications. M&S, Knights of Old, JLR all had DLP. They all got breached, and as a result, they all shut down because they had no confidence about what application data was at risk.

Knowing the gap exists is one thing. Understanding how attackers weaponise it is what enables you to make different decisions during incidents.

I’ve spent 40 years watching attack patterns evolve. The sophistication increases, but the fundamental exploitation method remains consistent: attackers go after what security tools don’t monitor. Today, that’s application data flows.

Understanding how application data can be stolen during an attack is what facilitates post-breach operational resilience.

Here’s how attackers do it.

The SolarWinds attack changed how we think about supply chain security. A trusted vendor, a legitimate software update mechanism, thousands of organisations downloading what they believed was a routine patch. Instead, they got malware that turned their own applications into data exfiltration channels.

The attack worked because it exploited trust at every layer. The software was digitally signed. The update came from a legitimate vendor infrastructure. Traditional security tools saw “SolarWinds communicating with SolarWinds servers” and permitted it.

DLP focuses on content inspection – scanning emails for sensitive data, monitoring web uploads for policy violations. But during a supply chain attack, the attacker isn’t transmitting via email or web. They’re using the compromised application itself to exfiltrate data through legitimate-looking network connections.

Your DLP sees application traffic to vendor infrastructure and assumes it’s legitimate. It can’t see that the application update process has been poisoned, redirecting data to attacker-controlled endpoints that masquerade as vendor servers.

When you discover a potential supply chain compromise, you face an impossible decision: shut down every application that might be affected, or maintain operations and risk ongoing data theft.

Without confidence about which applications are transmitting data to legitimate vendor infrastructure versus attacker-controlled endpoints, shutdown is your only defensible choice. Customer-facing services stop. Operations halt, and revenue stops.

But not every application needs to shut down. If you could verify in real-time that Microsoft Word is actually sending data to Microsoft-owned infrastructure, rather than to an IP address masquerading as Microsoft, then you can make strategic decisions about which systems to isolate versus which can safely continue.

ZORB validates destination IP addresses directly against vendor infrastructure ownership using Autonomous System Number (ASN) verification. We don’t trust DNS responses. We don’t trust domain names. We verify the actual network ownership of the destination IP.

When Microsoft Word attempts to transmit data, we validate that the destination IP belongs to Microsoft’s registered ASN ranges. If a supply chain attack redirects that transmission to attacker infrastructure, we detect the ASN mismatch and block it, regardless of what DNS says, and regardless of how convincing the domain name looks.

Even if the attacker compromises the application update mechanism, they cannot compromise the fundamental network infrastructure ownership records. They can make malicious IPs look like Microsoft domains, but they cannot make those IPs actually belong to Microsoft’s network.

This is supply chain attack immunity. Not post-event detection, but real-time prevention.

DNS poisoning is less dramatic than supply chain attacks, but significantly more common. Attackers compromise DNS infrastructure and redirect application traffic to malicious destinations. Security tools trust what DNS tells them, so they permit the redirected traffic.

Microsoft, Symantec, ProofPoint, etc, all have DNS dependencies in their security architectures. They query DNS to validate domains, then permit traffic based on those responses. If DNS is compromised and returns malicious IP addresses for legitimate domains, these tools get fooled because they trust the DNS response.

This isn’t a theoretical vulnerability. DNS attacks happen regularly. They’re relatively simple to execute and devastatingly effective because most security tools have this same architectural weakness: they trust DNS.

During a DNS poisoning attack, your applications believe they’re communicating with legitimate vendor services. Your DLP sees domain names that match approved policies. Everything looks normal. Meanwhile, your business-critical application data flows to attacker-controlled infrastructure.

By the time you detect the compromise, you don’t know what data was stolen or how long the attack persisted. This uncertainty forces extended shutdowns while forensics teams investigate. Customer-facing services stay offline. Revenue stops. Recovery time extends because you can’t confidently identify which systems were affected.

The ICO’s breach notification guidance requires demonstrating what steps you took to mitigate ongoing risk. “We shut everything down because we didn’t know what was compromised” isn’t a compelling operational resilience narrative.

ZORB doesn’t query DNS at all. We validate the actual destination IP address in every outbound packet against known vendor infrastructure ranges, independent of DNS responses.

When your applications query DNS and receive IP addresses, we don’t care how they obtained those IPs. We verify whether those destination IPs actually belong to the legitimate vendor’s network infrastructure. If DNS has been poisoned and returns attacker IPs, we detect the infrastructure mismatch and block transmission.

This creates DNS attack immunity. Even if attackers completely control your DNS infrastructure and redirect every single application query, we validate actual IP ownership against vendor ASN records. The redirect fails because the destination infrastructure doesn’t match the expected vendor.

Your applications continue operating. Data protection remains intact. You gain time to remediate DNS without panic shutdowns.

External attackers get the headlines, but insider threats cause significant operational disruption. An employee with legitimate access to business applications deliberately exfiltrates data, such as customer lists, financial models, strategic plans, by using the same applications everyone else uses.

DLP monitors email and web traffic for policy violations. If an insider emails customer data to their personal Gmail account, DLP catches it. But if that same insider uses Excel to export customer data and uploads it to personal cloud storage via the Excel upload feature, DLP doesn’t see it.

That’s because the application, be it Excel, Word, CRM system, etc, is inherently trusted. The user has legitimate access, so from a traditional security perspective, everything looks normal. The insider exploits this gap, using authorised applications through legitimate channels to exfiltrate data without triggering alerts.

Insider threat investigations consume massive resources. Once you suspect data exfiltration, you need forensics teams analysing logs, trying to reconstruct what data was accessed, what applications were used, where it was transmitted. This process takes weeks.

During this investigation, you face difficult decisions. Do you maintain operations and risk ongoing theft? Do you restrict access broadly, disrupting legitimate business activities? Do you shut down entire systems while investigating?

Without real-time visibility into which applications are transmitting data to unauthorised destinations, you’re operating blind. Investigation time extends. Operational disruption increases. The cost in both resources and business impact can often exceed the value of the stolen data.

ZORB provides forensic visibility that doesn’t require investigation time. We track which specific application process transmitted data to which destination IP address, with complete audit trails.

When Excel uploads data, we know it was Excel (specific process ID), we know where it went (destination IP and infrastructure ownership), and we know the transmission method. If that destination doesn’t match approved corporate cloud storage infrastructure, we block it and generate an alert with complete forensic detail.

For insider threats, this means immediate detection rather than prolonged investigation. Finance Director uploads client data to personal Dropbox? We see Excel transmitting to non-corporate infrastructure and block it in real-time. Investigation time collapses from weeks to minutes.

You maintain operations because you have confidence about what’s blocked versus what’s legitimate. Strategic response rather than broad disruption.

Once an advanced attacker has compromised your defences, they may attempt to steal data through covert channels (legitimate system tools and remote access applications) to exfiltrate data without triggering security alerts. PowerShell, RDP, SSH, and even legitimate business tools like remote support software can all be weaponised for data theft.

DLP operates at the wrong layer to catch these attacks. DLP inspects content in email and web traffic. Covert channel exfiltration happens through system processes and remote access tools that DLP doesn’t monitor.

Even EDR struggles here. EDR detects malicious processes, but covert channel attacks use legitimate processes doing legitimate-looking things. PowerShell running on a system isn’t inherently suspicious. PowerShell is a standard administrative tool. It’s also used by Windows processes, for example, requesting application updates. The question is what data is that PowerShell process transmitting, and where is it going?

During an active incident, you need to know what data is leaving your environment. If attackers are using covert channels, your security stack gives you no visibility. You know something is wrong. Maybe your SIEM flagged suspicious activity. But you can’t see what data is at risk.

This uncertainty forces the same binary decision we keep seeing: shut down everything because you lack confidence, or maintain operations and risk ongoing exfiltration. Neither option is strategic. Both create operational and financial consequences.

The NCSC’s guidance on building resilient organisations emphasises maintaining critical business services during incidents. You cannot maintain services if you don’t know what data is being stolen through covert channels.

ZORB operates at OSI Layer 3 (network) and Layer 7 (application) simultaneously, correlating application process ID directly to destination IP address. When PowerShell transmits data, we know it’s PowerShell (process ID), where it’s sending (destination IP and infrastructure), and the communication method.

If PowerShell starts transmitting to unauthorised infrastructure, such as an attacker-controlled cloud storage, suspicious endpoints or known command-and-control ranges, then we can detect it and block it. The covert channel closes before data theft occurs.

This capability extends to all remote access tools. If legitimate remote support software suddenly starts uploading data to non-vendor infrastructure, we catch it. If RDP connections tunnel data to unauthorised endpoints, we block them.

Process-to-destination correlation provides the visibility that security tools lack. During incidents, you know exactly which processes attempted data transmission, where they tried to send it, and whether we blocked it. Now, this has become a strategic incident response based on facts, not assumptions.

Supply chain attacks, DNS poisoning, insider threats and covert channels are all different attack techniques with the same fundamental exploitation: attackers target application data flows because traditional security tools don’t monitor them.

DLP sees email and web traffic. EDR sees process execution on endpoints. Firewalls see network traffic at Layer 3. None of them correlates which specific application process is transmitting data to which destination infrastructure.

This gap is what forces panic shutdowns during incidents. Without confidence in application data flows, you cannot make strategic decisions about which systems to isolate versus which can safely continue operating.

After 40 years in cybersecurity, I know that this is a solvable problem. Application data theft prevention requires visibility that other security tools weren’t designed to provide. But the technology exists today to provide this visibility.

The question is whether you fill the gap before the next breach, or discover it exists during an active incident when every hour offline costs revenue and customer confidence.

Q: Don’t EDR and DLP working together provide this visibility?

No. EDR monitors endpoint processes for malicious behaviour. DLP monitors email and web content for policy violations. Neither correlates the application process ID to the destination IP address. They operate at different layers and don’t provide the process-to-flow visibility needed to prevent application data theft.

Q: How can I know if my environment has these vulnerabilities?

A proof-of-value assessment reveals actual application data flows in your environment. You’ll see which applications transmit data to vendor infrastructure versus ISP-routed paths, application update requests going through intermediaries rather than direct to vendors, and cloud storage connections you didn’t know existed. Real evidence from your own devices, not theoretical risk.

Q: What about zero-trust architectures?

Zero-trust principles are valuable. They verify every connection, assume breach, and implement least privilege access. But zero-trust frameworks don’t provide process-to-destination correlation for application data flows. You still need visibility into which applications are transmitting what data to which infrastructure. Zero trust sets the policy; application data theft prevention enforces it at the application layer.

Q: If I have application whitelisting, isn’t that enough?

Application whitelisting controls which applications can execute. That’s valuable for preventing malware installation. But it doesn’t control where authorised applications send data. Excel is whitelisted because it’s a legitimate business application. But can your whitelisting solution prevent Excel from uploading to unauthorised cloud storage? Application data theft prevention operates after execution, controlling data transmission rather than application launch.