Obfuscated data exfiltration is a pattern where an attacker conceals the theft logic inside an agent skill using techniques like base64 encoding or eval-style dynamic execution, specifically to evade a static, plain-text code review. The underlying goal is identical to any other exfiltration attack. What changes is that a person reading the source directly won't recognize it.

Why encoding defeats a plain read

A reviewer scanning source code is looking for recognizable patterns: file reads, socket connections, suspicious keywords. Wrapping the collected data in base64.b64encode() before it's sent, or reconstructing a payload at runtime through exec() or eval() on a string that's been assembled or decoded on the fly, breaks that pattern matching. The malicious behavior is still there. It's just not sitting in the source in a form that a keyword scan or a human skim will flag.

This is also why obfuscation is a favorite technique against signature-based static scanners specifically. A rule looking for a literal string like "exfiltrate" or a direct call to a known-sensitive function will miss the same logic once it's been base64-encoded or split across a decode step.

What actually catches it

Static inspection can still help here, but only when it's looking for the encoding and execution primitives themselves, not just keywords: unusual imports like base64 or marshal paired with dynamic execution calls, or data structures being built and immediately encoded right before a network call. That's a different signal than searching for the word "exfiltrate" in plain text, and it survives the obfuscation attempt.

The more reliable catch is runtime. Regardless of how the source is written, a sandbox that traces actual system calls sees the same thing every time: successful reads of sensitive files, followed by a socket connection to an external address. Obfuscation changes what a human reviewer sees in the code. It doesn't change what the operating system sees when the code actually runs.

A dynamic analysis layer that directly observes open() calls against sensitive files and a connect() call to an unfamiliar external address can flag this kind of behavior with high confidence, independent of how the underlying code was written or disguised.

FAQ

Is any use of base64 in a script a red flag? No. Base64 is an extremely common, entirely legitimate encoding used constantly in normal software. The concern is the combination: sensitive file contents being collected, encoded, and immediately transmitted externally, not the encoding function on its own.

Why don't scanners just decode everything automatically? Some do, to a point, but encoding can be layered, computed at runtime from variables, or combined with custom logic that a generic decoder won't anticipate. That's part of why runtime observation matters as a complement to static decoding rather than a replacement for it.

Does this technique require a skilled attacker? Not particularly. Base64 encoding and dynamic execution are basic, well-documented techniques. The skill involved is less about the obfuscation itself and more about packaging it inside a skill that otherwise looks and functions like a legitimate tool.

Related reading: "Data Thieves in Disguise: How Malicious Agent Skills Harvest Credentials," "Inside the Sandbox: What Dynamic Analysis Reveals About Agent Skills"