Data Splicing Attacks: Breaking Enterprise Data Loss Prevention

Data Splicing Attacks: Breaking Enterprise Data Loss Prevention

Speakers: Vivek Ramachandran, Audrey Adeline

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch the full talk

Reading time: ~8 minutes

TL;DR

Researchers from Square X introduced a new class of attack they call "data splicing" — five distinct techniques that systematically bypass both endpoint DLP and SASE/SSE proxy DLP solutions by exploiting fundamental architectural limitations. The techniques — including alternate binary communication channels, data sharding, encryption, encoding, and invisible character insertion — were demonstrated live, and an open-source toolkit called Angry Magpie was released to reproduce them. The conclusion: most enterprise DLP hasn't materially innovated in fifteen to seventeen years, and the browser is now the most critical — and least protected — data exfiltration surface.

Introduction

Enterprise data loss prevention has a foundational trust problem. Organizations spend heavily on endpoint DLP agents and SASE/SSE proxy solutions, layering them together and assuming that sensitive data moving through the network will be caught. But according to Vivek Ramachandran and Audrey Adeline of Square X, both categories of solution operate with a deeply incomplete view of what actually happens inside a browser — and that blind spot is trivially exploitable.

The research behind this talk grew from a direct question: given that the browser is now the most-used enterprise application, and given that the bulk of enterprise data is created, stored, shared, and accessed through SaaS applications that run entirely in the browser, are existing DLP solutions actually capable of catching data exfiltration through that surface? The answer the team arrived at, after testing multiple enterprise solutions, was an emphatic no.

The five techniques they presented under the umbrella term "data splicing" are not theoretical. They were demonstrated live, each bypassing enterprise DLP in a different way, and the code behind each was released in an open-source toolkit. Perhaps most sobering: Adeline noted that most of the toolkit code was written using the free tier of ChatGPT and Claude.

Why DLP Solutions Can't See the Browser Clearly

▶ Watch: Architectural limitations of endpoint and SASE/SSE DLP (06:00)

Ramachandran and Adeline laid out the two dominant DLP architectures before demonstrating how to defeat them.

Endpoint DLP solutions — agents installed on managed devices — rely on browser APIs exposed by vendors like Chrome to inspect clipboard contents, file uploads, and file downloads. They have no direct visibility into the browser itself. They cannot differentiate between a personal Gmail account and a corporate one. They have no access to page content, network requests, or context about user workflow. And critically, access to those Chrome browser APIs is not open: only vendors whitelisted by Chrome can use them. When the researchers asked the audience to guess how many vendors are currently whitelisted, the closest answer was seventeen. The real number is fewer.

SASE and SSE proxy solutions work differently — they inspect network traffic at the proxy layer — but with their own major constraints. Because sending traffic to the provider's cloud for inspection introduces latency, most major SASE/SSE vendors cap the file size they will inspect at 120 megabytes. Anything larger is either blanket-blocked or blanket-allowed. Binary channels, encrypted files, and third-party app APIs are not inspected at all. The solutions also can't access DOM changes, tab context, or user interaction data that would help distinguish legitimate activity from exfiltration.

The underlying problem, Ramachandran explained, is that modern web applications bear no resemblance to the applications that existed when these DLP architectures were designed. Today's enterprise apps use WebSockets, gRPC, and WebRTC for binary streaming communication. Uploading a file through WhatsApp Web or Telegram sends data over WebSockets, completely bypassing SASE/SSE inspection. The gap between what DLP vendors assume about application behavior and what applications actually do has grown to the point where the architecture's assumptions are simply wrong.

Five Data Splicing Techniques

▶ Watch: Data splicing techniques live demonstrations begin (16:04)

Technique 1: Alternate Binary Communication Channels

The first and broadest technique exploits the complete lack of inspection on binary protocols. WebRTC (used for peer-to-peer audio and video), Firebase Cloud Messaging (push notifications for web apps), and WebTransport (low-latency gaming data exchange) are all completely uninspected by both endpoint and SASE/SSE DLP solutions. An attacker or insider threat can exfiltrate any data through these channels without triggering any policy. The demo showed a file containing credit card numbers uploading successfully through a WebSocket channel after the same upload was blocked through a normal HTTP file upload.

Technique 2: Data Sharding

SASE/SSE DLP detection relies heavily on regular expressions to identify sensitive data patterns — credit card numbers, Social Security numbers, and similar structured data. Data sharding defeats this by breaking a file into chunks smaller than the shortest detectable regex pattern. The individual shards, each too small to match any detection rule, bypass inspection entirely. Once they reach the attacker's server, the file is reconstructed in its original form. The demo used 100-byte shards.

Technique 3: Data Ciphering

▶ Watch: Data ciphering and encoding bypass demos (22:04)

No SASE/SSE solution can decrypt files on the fly during inspection. If the attacker encrypts a file containing sensitive data before uploading it, the DLP solution sees only ciphertext and cannot match any detection patterns. Any encryption technology works for this purpose.

Technique 4: Data Transcoding

This technique — Adeline's personal favorite for its elegance — encodes data into a different format before the DLP inspection occurs, then decodes it after. The example used Base64 encoding. An attacker pre-encodes a file containing credit card numbers or Social Security numbers using Base64. The encoded representation no longer matches any regex pattern the DLP is looking for. The researchers then showed a complete workflow: encoding a file before upload using JavaScript (injected via a browser extension), uploading it successfully past Chrome Enterprise DLP, having it appear normally when opened in Google Drive (decoded via another injected script), and downloading it again using the same encode-before-download, decode-after-download approach. Copy-paste operations were similarly bypassed by encoding on copy and decoding on paste at the destination, covering both possible policy enforcement points.

Technique 5: Data Insertion

The final technique targets printing — a channel insider threats commonly use for physical exfiltration. It works by inserting invisible characters between every character of the sensitive content. Formatted in white text at minimum font size, these inserted characters are invisible to the human reading the printed page, but completely destroy any regex match on the underlying content. The credit card numbers print normally; the DLP sees no detectable pattern.

The Open-Source Toolkit and Broader Industry Failure

▶ Watch: Industry structural failures and the browser as the weakest link (32:05)

The Angry Magpie toolkit implements all five techniques as a browser extension (for the endpoint DLP bypass demonstrations) and as standalone scripts. The fact that its code was generated largely with free AI tools is, Ramachandran argued, the most telling detail in the entire presentation. The barrier to building effective DLP bypass tooling is now effectively zero.

Ramachandran's diagnosis of the industry's failure was direct: the DLP sector hasn't meaningfully innovated in fifteen to seventeen years. The dominant detection mechanism remains regular expressions — a technology that is trivially defeated by encoding, fragmentation, or binary transport. The fact that Base64 encoding, a technique from the early web, still defeats enterprise DLP in 2025 is, he said, "amazingly shocking."

The structural problem runs deeper than vendor inertia. Browser vendors have not opened sufficiently powerful APIs for endpoint DLP solutions to gain meaningful visibility into browser activity. Only a handful of vendors have any access at all to Chrome's DLP APIs, and even those APIs cover only specific data leakage vectors. Meanwhile, virtually all enterprise work now happens in the browser: Google Docs, Figma, Salesforce, Office 365 online, and similar SaaS applications handle the full lifecycle of enterprise data without any files ever touching the local filesystem in a way that traditional DLP can inspect.

Adeline and Ramachandran closed by framing the problem structurally: the browser is a full compute machine. Code runs in it, data is transformed inside it, and it operates largely outside the inspection capabilities of both endpoint agents and network proxies. Until browser vendors expose richer APIs and until DLP vendors move beyond regex-based detection and toward something that understands actual user intent and data context, the browser will remain the most effective — and least monitored — exfiltration channel in the enterprise.

Notable Quotes

"Most of the DLP industry hasn't innovated much probably in the last fifteen to seventeen years. Much of it is still run by regular expressions, which is amazingly shocking in this day and age — you're just going ahead trying to search for patterns and strings."

— Vivek Ramachandran, ▶ 32:05

"The browser is a full compute machine. You can run code, do whatever you want, transform data — encode it, encrypt it on the client side. Fairly easy to go ahead and create bypasses for both cloud as well as endpoint DLP with browser APIs."

— Vivek Ramachandran, ▶ 34:06

"Most of this code was done using the free version of ChatGPT and Claude. So this just really shows you how trivial it is to break enterprise DLP solutions."

— Audrey Adeline, ▶ 32:05

Key Takeaways

• Enterprise DLP has fundamental architectural blind spots in the browser. Neither endpoint agents nor SASE/SSE proxies have meaningful visibility into binary communication channels, encoded data, or the full context of browser-based user workflows.
• All five data splicing techniques defeat DLP using trivial methods. Base64 encoding, 100-byte sharding, WebSocket exfiltration, client-side encryption, and invisible character insertion each independently defeat enterprise-grade DLP. An attacker needs only one.
• The Angry Magpie toolkit is open source and AI-assisted. The barrier to implementing these bypasses is near zero. Any attacker or insider threat with basic JavaScript knowledge can reproduce all five techniques.
• Browser vendors must expose richer APIs. Until Chrome, Edge, and other browsers provide endpoint DLP solutions with genuine application-layer context — not just file upload/download events — the inspection gap will remain structurally unfixable at the network or endpoint layer.
• The browser is the new perimeter. Modern enterprise data doesn't move through traditional file systems or corporate networks in ways that existing DLP was designed to inspect. Solutions that treat the browser as transparent to network traffic are operating on decade-old assumptions that no longer reflect how enterprise software works.