Aug 11, 20267 Min ReadDiscovery & Classification

The Oldest Trick in the Book: Sensitive Data Hiding in "Plain Text"

Why some of the riskiest files in your environment are the ones your tools already marked clean, and how Sentra now sees through them.

Ron Reiter

A text file is never "just text"

Ask your team which files in your data stores worry them least, and plain text files will be near the top of the list. No macros, no attachments, no executable code. Just characters.

That assumption is exactly what makes text files a great hiding place.

There's a technique as old as email itself: take any file, a ZIP archive full of customer records, a PDF contract, a database export, and run it through a simple, freely available encoding called base64. The result is a wall of ordinary-looking letters and numbers that can be saved as notes.txt:

UEsDBBQAAAAIAJ1mVFvGm1MTYwAAAG0AAAALAAAAc2VjcmV0cy50eHQL

Ti5LLXJyzs9Ny0xO9UvMTVUIttJPS8xJTtVLrKjkStFRyEvMTQVKKTh6

BbsoGJmYWuiZAKGFQmaxQnJ+XklqXglXaLCVQkhicaqOgquzoTlXsK9P

...

(Illustrative and truncated. A real encoded database export runs to megabytes of this.)

To a human reviewer, that's noise. To most scanning tools, it's a clean text file: it matches no patterns for credit cards or national IDs, contains no sensitive keywords, and classifies as nothing. The scan completes successfully. The report says the file is safe.

Decode it, a one-line operation anyone can perform, and it's a ZIP archive containing fifty thousand rows of names, emails, and credit card numbers.

Why this should be on a CISO's radar

The danger here is not a failed scan. It's a successful scan that tells you the wrong thing. The file enters your data inventory marked clean, and every downstream decision inherits that error:

Your risk picture is wrong. Data security programs run on an inventory of where sensitive data lives. A disguised file is sensitive data your inventory says doesn't exist. You can't protect, restrict, or delete what you don't know you have.
It's a proven exfiltration pattern. An insider staging data for removal doesn't need sophisticated tooling. Encoding a customer database into a "text file" takes one command, and it sails past controls that would have flagged the same data in its original form.
It accumulates by accident, too. Not every case is malicious. Developers routinely encode files this way to move them between systems, and those encoded copies end up in file shares, code repositories, and backups, then sit there for years. The intent is innocent; the exposure is identical.
It complicates breach response and compliance. If an environment is compromised, your ability to scope what was exposed depends on knowing what was actually there. Files your tools misread as empty text become the gap between the breach you report and the breach you had.

The important nuance: this encoding is not encryption. Nothing about it is secure or hard to reverse. It works purely because most tools never think to look, a gap we had too, until now. It is concealment at the cost of one command, defeated the moment a scanner knows to check.

What we found when we went looking

We built this capability because we suspected the problem was common. It's more common than that.

Across the environments we scanned during development, encoded files disguised as plain text appeared in 40% of them. Most were exactly what you'd expect: build artifacts, config blobs, engineering convenience. But in nine cases the payload contained regulated data, customer names alongside email addresses and payment card numbers, in one instance a member export with diagnosis codes attached, sitting in a shared cloud storage bucket that had been scanned and reported clean fourteen times over eight months.

None of those were attacks. That's the part worth sitting with. A technique simple enough to be an exfiltration tool is also simple enough that engineers reach for it casually, and the resulting exposure looks identical either way. One customer's first scan surfaced 23 encoded archives in a financial services data lake, the oldest dating to 2019, copies of a production export someone had moved between systems and never cleaned up. Their inventory had been wrong about it since before the team that owned it was reorganized.

How Sentra closes the gap

Sentra's classification engine now recognizes when a supposedly plain text file is actually a disguised, encoded file and treats it as what it really is.

In plain terms:

It notices the disguise. When a text file's content has the telltale shape of an encoded payload, Sentra doesn't take the "text file" label at face value. This covers base64 along with hex, base32, gzip, and uuencode, non-standard alphabets, and payloads wrapped in more than one layer. Base64 inside gzip inside base64 is still a file, and still gets read.
It checks before acting. Plenty of legitimate content looks superficially similar, including lists of system-generated identifiers, technical logs, and reference codes. Sentra verifies that a real file is actually hiding inside before treating it as one, so ordinary text files are never misclassified.
It scans what's really there. The hidden file is opened and put through the same full classification as if it had been stored openly, including anything nested inside it, layer after layer. A customer list hidden inside an archive, hidden inside an encoded text file, is found and classified exactly as if it sat in a folder unprotected.
It flags the concealment itself. Every finding from a hidden file is recorded as having come from behind an encoding layer. It appears in your data catalog tagged Concealed Payload, with the decoded file's own classification attached, and flows through the policies, alerts, and SIEM and ticketing integrations you already have wired up. That distinction matters: customer data in a spreadsheet is a data hygiene issue; customer data deliberately wrapped to evade inspection is a signal worth investigating. Your team sees not just what was found, but that it was hidden.

The trick that used to defeat the scan is now, itself, a finding.

What this changes for security team

Concretely, if you're running a data security program:

Your inventory becomes defensible. Not "complete," because no inventory is, but free of a blind spot you now know exists. That's the difference between a record of processing you can put in front of an auditor and one with a category of files you can't account for.
Staged data becomes a detection, not an artifact. An insider encoding a customer database is no longer performing a silent operation. It generates a finding, at the time it happens, marked as concealment rather than as ordinary content.
You get a cleanup list. For most teams the first result won't be an investigation. It'll be a set of encoded copies left behind by people who meant nothing by it, and a decision to make about each one.
Breach scoping holds up. GDPR gives you 72 hours to notify; several US state laws are tighter still. An answer that rests on an inventory with a known blind spot is not an answer you want to defend afterward.

The takeaway

The deeper lesson here isn't about base64.

It's about what we should expect from modern data security.

File extensions, MIME types, and surface-level inspection can tell you what something appears to be. They can't always tell you what it actually contains.

And that problem is only becoming more important. Sensitive data now moves through cloud services, developer environments, SaaS applications, automated pipelines, and AI workflows. It gets copied, transformed, compressed, encoded, nested, and moved between systems, often without a security team ever touching it.

A modern data security platform therefore can't stop at the surface. It needs to understand the content itself, even when that content is encoded, nested, mislabeled, or otherwise difficult to inspect.

Because if your security program depends on knowing where sensitive data lives, "we scanned it" isn't enough.

You need confidence that the scanner actually saw it.

If a tool tells you a file is clean, it should be because it read what's inside, not because it couldn't.

Sentra is built to give security teams that deeper understanding of their data, discovering sensitive information across the environment, identifying exposures that traditional approaches can miss, and helping teams prioritize the risks that matter.

If you're a Sentra customer, this is live now across all supported cloud data stores. It runs automatically on your next scan cycle, no configuration required, so encoded content already sitting in your environment surfaces without you doing anything. Existing findings are re-evaluated as those stores are rescanned.

If you're not, the test is cheap and you don't need us to run it. Base64-encode a file containing test card numbers, drop it in a monitored store as a .txt, and run your scan. Then ask your vendor which encodings they reverse, how deep they nest, and whether the concealment itself is recorded or silently unwrapped.

Data security is full of cheap concealment: encodings, nested archives, files with misleading names. None of them are strong protections. All of them work if your tooling doesn't look. The standard to hold your tools to is simple:

If a tool tells you a file is clean, it should be because it read what's inside, not because it couldn't.

See what your existing data security tools may be missing. Request a Sentra demo.

FAQs

What does it mean when a file is base64-encoded?

Base64 converts any file — a ZIP, PDF, or database export — into a block of ordinary letters and numbers that can be saved with a .txt extension. The content is unchanged, just represented differently. It takes one command to encode and one to reverse.

Why do most data scanners miss encoded files?

Pattern-based classification looks for recognizable structures — card numbers, national IDs, sensitive keywords. Encoded content matches none of them, so the file classifies as nothing and the scan completes successfully. The result isn't a failed scan; it's a successful scan reporting the wrong thing.

How common is this?

Encoded files disguised as plain text appeared in 40% of environments scanned during development. Most were harmless build artifacts and config blobs, but several contained regulated data, including a member export with diagnosis codes in a bucket that had been scanned and reported clean fourteen times.

Why does encoded data matter for breach response and compliance?

Scoping a breach depends on knowing what was actually in the environment. GDPR allows 72 hours to notify and several US state laws are tighter. An inventory with a known blind spot is difficult to defend after the fact.

What encodings does Sentra detect?

Base64, hex, base32, gzip, and uuencode, including non-standard alphabets and multiple nested layers. Base64 inside gzip inside base64 is still unwrapped and classified.

Won't this flag ordinary text files by mistake?

Sentra verifies a real file is present before treating content as a concealed payload, so system-generated identifier lists, technical logs, and reference codes aren't misclassified.

How can I test my current tooling?

Base64-encode a file containing test card numbers, drop it in a monitored store as a .txt, and run a scan. Then ask your vendor which encodings they reverse, how deep they nest, and whether the concealment itself is recorded or silently unwrapped.

Do Sentra customers need to enable anything?

No. It runs automatically on the next scan cycle across all supported cloud data stores, and existing findings are re-evaluated as those stores are rescanned.