Filenames Are Data Too: A Blind Spot in Removable-Media Telemetry

We went into this expecting the boring answer. Most Organizations treat USB the same way: either block it outright, or allow it and lean on the EDR to identify and log who moved what, so at least there's a paper trail. At Bulkhead Security we do the latter on purpose—removable media is permitted, and the telemetry is the actual control. So when we set out to test that assumption, we weren’t looking for a way to move data off a USB stick without permission. That permission already existed. We were more interested in seeing if we could move data off a USB stick without being detected.

Short version: We encoded a meaningful amount of data into filenames, wrote a pile of zero-byte files carrying those names to a USB drive, walked away with the drive, and reconstructed the original data byte-for-byte on another machine. Ideally, the username and hostname of the device used should have been flagged by the telemetry software as “files written to removable media”, however, it wasn’t there at all.

Starting from the assumption we were trying to break

Before touching anything clever, we needed to establish a baseline. We copied a normal file with real content to a USB device and confirmed it showed up in the removable-media activity view exactly as expected: filename, size, hash, timestamp, all present. Good. The control works when a human does the thing it was designed to catch.

From there we started looking at what "the thing it was designed to catch" actually means under the hood. Most host-based file monitoring on Windows works by hooking filesystem driver activity, typically at the point where a process asks the OS to write bytes into a file. That's a deliberate design choice: if you want to compute a hash of what left the building, or flag a .docx full of customer records, you need the content, so you hook the write path and capture what flows through it. It's a reasonable place to instrument if your goal is "catch data exfiltration by inspecting data."

But a file doesn't have to contain data to carry data. A filename is a string, up to 255 characters on most filesystems, and nothing stops that string from being your payload instead of a label. If I never call a write operation with actual content, only a create operation with an information-dense name, does the same telemetry pipeline even notice?

The technique

We chunked the data we wanted to move, encoded each chunk using a plain reversible encoding, and used each encoded chunk as the filename for a zero-byte file. No content, no write, just a create call and a close. A larger payload becomes more files rather than one bigger file, which is a fair tradeoff for how much data disappears from view.

To reconstruct, we read the directory listing off the USB device on a second machine, sorted the filenames back into order (a numeric prefix per chunk handles this), decoded each name, and concatenated the results. Byte-for-byte, it matched the source. The entire "transfer" a defender would care about (the actual bytes) happened purely through metadata that most content-focused monitoring never looks at.

We ran this at a scale meant to make the point unambiguous, not a token handful of files, and checked the removable-media dashboard afterward expecting to at least see device-connection noise. There was nothing tying that volume of activity to our session at all.

A public proof-of-concept called MetaTransfer implements the identical idea as a pair of shell scripts: an encoder that base64-encodes a source file, splits it by line, and writes one zero-byte file per line named after that chunk, and a decoder that sorts the resulting filenames back into order and reconstructs the original data, verifying the result with a SHA-256 comparison. Its own documentation states the purpose plainly: demonstrating a telemetry visibility gap in a specific, widely deployed EDR platform's monitoring of files written to removable media. That two independent efforts landed on the same technique, and that one of them already ties it to a named product publicly, tells us this isn't a one-off oddity in whatever agent we happened to be testing. It's a structural blind spot in how a category of tooling instruments file activity.

The result and why it matters

The abuse scenario here isn't exotic. Most organizations decide USB is a business necessity and accepts the risk in exchange for visibility: if someone walks out with sensitive data, at least there's a record of what and when. That trade only holds if the visibility is real. This technique lets someone move an arbitrary volume of data through a permitted channel while the specific control meant to provide accountability for that channel logs nothing. It's worse than "no logging at all" being a known limitation, because the dashboard doesn't come up empty in a way that prompts suspicion; it comes up looking normal. An investigator has no reason to go looking for a gap they don't know exists.

It also chains uncomfortably well with the fact that USB is supposed to be allowed here. If USB were blocked outright, this technique would still work but would also require bypassing a prevention control, which tends to leave its own trail. Because the write itself is sanctioned, the only thing standing between "sanctioned use" and "invisible exfiltration" is the telemetry, and that's precisely the piece that goes dark.

Root cause

The underlying pattern is trusting a file's content to be the only place data can live, and building detection accordingly. Filesystem metadata—filenames, extended attributes, alternate data streams, timestamps—is treated as inert bookkeeping rather than an attacker-controlled channel, even though every one of those fields is just as writable as file content and, in most tooling, dramatically less monitored. A write-hook is a fine primary signal but makes for a bad only signal.

Fix guidance

• Log file creation/rename events on removable media regardless of size. This closes the specific gap directly, since zero-byte creates would generate a record. The tradeoff is log volume: legitimate zero-byte files (lock files, placeholders, git artifacts) exist in normal usage, so this needs to be scoped to removable-media volumes specifically to stay manageable, not applied fleet-wide to every filesystem.
• Alert on anomalous filename characteristics rather than logging everything. High-entropy filenames, unusually long filenames, or a burst of zero-byte file creates in a short window are all decent heuristics for this specific technique. This is cheaper than universal logging but is a detection rule, not a visibility fix, meaning it can be tuned around once an adversary knows it exists, and it will need false-positive tuning against legitimate batch tooling that happens to produce lots of small files.
• Fall back to policy-level restriction where telemetry can't be trusted. For sensitive host groups, read-only USB or full prevention sidesteps the question of whether the write is logged, because the write never happens. This isn't a fix for the telemetry gap so much as an acknowledgment that, for some populations, "permit and monitor" isn't a safe posture until the monitoring is proven to cover metadata channels too.

None of these are a patch you apply and forget. They're a statement about what your removable-media control is actually promising, and matching the engineering to that promise.

What other researchers should take from this

If your organization's security model for a permitted channel rests on "we'll see it in the logs," go find out what specifically "it" means to the tool generating those logs. Content-based monitoring answers "what data left," not "what activity occurred," and those are different questions with different blind spots. The generalizable test here isn't limited to USB: any control that inspects content to decide whether to log or block an action is a candidate for a metadata-only bypass. Try it against your DLP, your file-upload scanners, your outbound proxy logging. If the mechanism triggers on payload bytes, ask what happens when there are no payload bytes at all.

Glossary: Terms used in this post

• EDR (Endpoint Detection and Response): Security software installed on individual computers that monitors activity (files, processes, network connections) and reports it to a central system for detection and investigation.
• Telemetry: The stream of activity data (events, logs) that security tooling generates and sends for analysis, as opposed to the tooling's ability to actively block something.
• Removable media: Storage devices that can be physically disconnected from a computer, most commonly USB flash drives.
• Zero-byte file: A file that exists (it has a name and an entry in the filesystem) but contains no data. It has a size of 0.
• Write hook / write path: The point in an operating system where a program's request to save data into a file gets intercepted, commonly used by security software to inspect what's being written before or as it happens.
• Filesystem metadata: Information about a file other than its contents, such as its name, size, timestamps, and permissions.
• Encoding (Base64): A method of representing binary data (like raw bytes) as text made up of a limited set of printable characters, so it can be safely stored somewhere that expects text, such as a filename.
• Entropy (in a filename/data context): A measure of randomness. A filename like "invoice.pdf" has low entropy; a filename that's a long string of encoded, seemingly random characters has high entropy, which can itself be a signal something unusual is going on.
• Alternate data streams: A Windows filesystem feature allowing a file to hold additional hidden data beyond its main content, another example of a metadata-adjacent channel that content-focused scanning can miss.
• Covert channel: Any method of moving data through a system using a mechanism that wasn't designed or intended to carry that data, in a way that evades the controls meant to observe or prevent data movement.