From PDF to Hidden Payload: Analysing Steganographic Document Attacks

Security teams analyse thousands of PDF attachments daily. The mature tooling around PDF security focuses on well-known attack surfaces: embedded JavaScript, /OpenAction triggers, /Launch commands, URI actions, form submission exploits. These checks catch a genuine class of threats, and every SOC has them automated. What they do not check is whether the images inside those PDFs contain hidden data. A product brochure with a photograph, an invoice with a company logo, a report with a chart: each of these embeds images as stream objects within the PDF structure. Those images render normally in every viewer. They pass every structural scan. And they can carry kilobytes of encrypted executable code that no PDF parser will ever see.

This is not a theoretical concern. In 2019, EdgeSpot documented a PDF exploit that concealed JavaScript inside an embedded JPEG. After a full year on VirusTotal, the sample had a detection rate of 1 out of 57 antivirus engines. The technique worked precisely because it existed in a gap between what PDF analysis covers and what image analysis covers. Neither discipline, applied alone, was sufficient.

The three-layer problem

The challenge with steganographic PDFs is structural. A malicious PDF of this kind is not one thing. It is three nested things, each requiring a different type of analysis, and each invisible to tools designed for the other layers.

The first layer is the PDF itself. PDF is a container format built around numbered objects, stream data, cross-reference tables, and a trailer that ties everything together. Structural analysis at this layer identifies JavaScript blocks, action triggers, embedded files, form objects, and URI references. Tools like pdfid, pdf-parser, and YARA rules targeting PDF internals operate here. They are effective at what they do. They parse the container.

The second layer is the embedded image. PDFs store images as stream objects, typically JPEG, PNG, or occasionally BMP. These streams are compressed (FlateDecode, DCTDecode, JPXDecode) and referenced by page content operators. To a PDF parser, an image stream is just another object with a filter and some bytes. To an image viewer, it is a photograph or graphic that renders as expected. Neither tool looks further.

The third layer is the steganographic payload. Data hidden in pixel values via least significant bit encoding, appended after image termination markers, embedded in PNG ancillary chunks, or concealed in EXIF metadata fields. This data is invisible to the PDF parser (which sees only a valid image stream) and invisible to a casual image viewer (which displays the image normally). Detecting it requires steganographic analysis: entropy measurement, structural anomaly detection, statistical tests against expected pixel distributions.

And there is often a fourth consideration. The extracted payload is almost never plaintext. It is encrypted, compressed, obfuscated through multiple layers, or all three. A steganographic extraction that produces a blob of XOR-encrypted Base64 has solved one problem and revealed another.

Layer 1: PDF Structure     → Structural analysis (objects, streams, actions)
Layer 2: Embedded Image    → Image extraction (JPEG, PNG, BMP from PDF streams)
Layer 3: Hidden Payload    → Steganographic detection (LSB, EOF, chunks, metadata)
         ↓
Layer 4: Obfuscated Script → Multi-layer deobfuscation (115+ techniques)
         ↓
Output:  IOCs, YARA, Sigma, MITRE ATT&CK, Analyst View

Each layer has its own detection requirements. PDF parsers understand layer 1. Image viewers understand layer 2. Neither understands layer 3. And even specialised steganography tools typically stop at extraction, leaving layer 4 to manual analysis. The full chain, from document to actionable intelligence, requires all four stages to execute in sequence. That sequencing is precisely where existing tooling breaks down.

Real attack chains

The three-layer pattern is not a thought experiment. Multiple documented campaigns have exploited the gap between PDF analysis and image analysis, ranging from targeted espionage to commodity malware distribution.

EdgeSpot PDF Exploit (2019). Security firm EdgeSpot identified a family of malicious PDFs that embedded JavaScript inside JPEG images. The PDFs appeared to contain ordinary content with small icon-like images. Those images were valid JPEGs that displayed normally in any viewer. Hidden within them, using steganographic JavaScript extraction techniques, was executable code that targeted CVE-2013-3346, a vulnerability in Adobe Reader's JavaScript engine. The exploit chain was elegant in its simplicity: the PDF loaded the image, extraction code pulled the JavaScript from the image data, and the JavaScript executed the exploit. From the outside, every component looked legitimate.

XWorm StegoCampaign (2025). Documented by ANY.RUN, this campaign used PDFs as the social engineering entry point in a multi-stage infection chain. The PDF itself was not the exploit. It served as a convincing lure that directed victims through a sequence of actions: opening a .REG file, which triggered PowerShell, which launched VBScript, which downloaded a JPEG from attacker infrastructure. That JPEG contained a steganographic payload: a hidden DLL that, once extracted and loaded, deployed XWorm, a remote access trojan with credential theft, keylogging, and ransomware capabilities. The PDF's role was purely social engineering, but its legitimacy as a document format was essential to the chain. Recipients trusted the PDF. The PDF led them to the image. The image carried the weapon.

Turla LightNeuron (2019). ESET documented this state-sponsored campaign by the Turla group, which used steganographic email attachments as a command-and-control channel for compromised Microsoft Exchange servers. The LightNeuron backdoor intercepted emails containing PDF and JPG attachments, extracted hidden commands from the image data, and executed them on the server. Commands were encrypted with AES-256 before being embedded steganographically. In one investigated victim environment, the backdoor had processed over 7,000 JPG images, of which only 178 contained actual commands. The remaining images were legitimate traffic that the backdoor examined and discarded. This ratio, 178 commands hidden among 7,000 innocent images, illustrates the needle-in-a-haystack problem that steganographic C2 creates for defenders.

Campaign overview

The campaigns span different threat actors, different objectives, and different technical approaches. What they share is the structural insight: PDFs are trusted containers, images are trusted content within those containers, and the space inside images is unmonitored. The technique works across the spectrum from commodity malware to state-sponsored operations because the detection gap is fundamental, not implementation-specific.

Why existing tools miss this

The tooling landscape for PDF security is mature. The tooling landscape for steganographic analysis is growing. The problem is that these two landscapes do not overlap.

PDF analysis tools such as pdfid, pdf-parser, and PDF-focused YARA rules examine the document structure. They identify suspicious objects, extract JavaScript, flag action triggers, and detect known exploit patterns. They are designed to answer the question: does this PDF contain malicious structural elements? An embedded image with a steganographic payload does not register as a malicious structural element. It is a valid image stream object, properly formatted, correctly referenced. The PDF parser sees nothing wrong because, at the PDF layer, nothing is wrong.

Image analysis tools such as stegdetect, zsteg, and StegExpose work on standalone image files. They measure entropy, test for LSB encoding patterns, scan for appended data, and flag statistical anomalies. They are effective when pointed at a suspicious image file. But they cannot extract images from PDFs. They expect a file path to a JPEG or PNG, not a PDF document containing compressed image streams encoded with FlateDecode or DCTDecode filters. The images must first be extracted from the PDF, decompressed, and saved as standalone files before these tools can operate on them.

Sandbox environments take a different approach entirely. They execute the document and observe runtime behaviour: network connections, process creation, file system modifications. This can catch steganographic attacks when the full chain executes successfully. But sandbox evasion is well-understood by attackers. Environment checks, delayed execution, user interaction requirements, and geographic targeting all reduce the probability that a sandbox triggers the complete infection chain. And when the chain does not complete, the sandbox sees a document that opens, displays content, and does nothing suspicious.

The fundamental issue is that no widely available tool chains all three analysis stages into a single pass. An analyst who suspects a steganographic PDF must manually extract the PDF structure, identify and export embedded images, run steganographic analysis on each image, and then decode whatever the extraction produces. Each step requires a different tool, a different skill set, and time that most teams do not have when processing volume.

The automated pipeline

KlaroSkope was built to close this gap. The platform chains every stage of the analysis into a single automated pass, from the moment a PDF is uploaded to the final output of indicators, detection rules, and analyst-ready decoded content.

The process begins with structural analysis. The platform parses the PDF's object tree, identifies streams, catalogues embedded resources, flags JavaScript and action triggers, and attributes known exploit kit patterns. This is the standard first layer of PDF analysis, but it serves a dual purpose here: in addition to identifying structural threats, it maps every embedded image in the document for subsequent extraction.

Each embedded image is then extracted from its stream object, decompressed from whatever filter encoding the PDF uses, and reconstructed as a standalone image. This is the bridge between layer 1 and layer 2 that manual workflows require separate tooling to cross.

Steganographic detection runs against every extracted image. The platform applies multiple detection methods: entropy analysis across pixel data and chunk structures, appended data detection beyond format termination markers, PNG ancillary chunk inspection, EXIF metadata analysis, and LSB statistical tests. When hidden data is identified, it is extracted and passed to the next stage.

The extracted payload then enters the deobfuscation pipeline. Over 115 decoder techniques handle the layers of encoding, encryption, and obfuscation that attackers apply to steganographic payloads. XOR decryption, Base64 decoding, compression decompression, string manipulation reversal, character code resolution, format operator evaluation: the engine applies each technique iteratively, peeling layers until the payload is fully resolved or no further progress can be made. For a deeper look at how multi-layer deobfuscation works, see The Multi-Layer Problem.

Finally, IOC extraction runs across every layer of the analysis. URLs, IP addresses, domains, file hashes, registry keys, and command-and-control indicators are identified not just from the final decoded payload but from intermediate layers as well. Some indicators appear only in specific stages of the deobfuscation and would be lost if extraction ran only against the final output. The platform generates YARA rules, Sigma rules, maps findings to the MITRE ATT&CK framework, and produces a structured report with the Analyst View showing resolved content alongside the original obfuscated text.

Email attachment received
  |
  v
+--------------------------------------------+
| PDF Document (invoice, report, lure)       |
| +----------------------------------------+ |
| | Embedded Image (looks normal)          | |
| | +------------------------------------+ | |
| | | Encrypted payload (hidden)         | | |
| | +------------------------------------+ | |
| +----------------------------------------+ |
+--------------------------------------------+
  |
  v  KlaroSkope automated pipeline
  |
  |-- Structural analysis    --> Objects, streams, JS, actions
  |-- Image extraction       --> JPEG, PNG, BMP from PDF streams
  |-- Stego detection        --> LSB, EOF, chunks, metadata, entropy
  |-- Payload deobfuscation  --> 115+ techniques, up to 25 layers
  |-- IOC extraction         --> URLs, IPs, domains, hashes, keys
  |
  v
  Output: YARA | Sigma | IOCs | MITRE ATT&CK | Analyst View

The entire pipeline runs automatically. Drop the PDF, get the full picture. No manual image extraction, no switching between tools, no stitching together partial results from three different analysis frameworks. For background on stegomalware taxonomy and the decade of campaigns behind it, see What is Stegomalware?. For the technical detail on specific embedding and detection methods, see Steganography in Malware Delivery, Steganography Detection Techniques, and How Malware Extracts Hidden Payloads from Images.

Why the PDF container matters

It is worth asking why attackers bother with the PDF layer at all. If the payload is in the image, why not just send the image directly?

The PDF provides three things that a standalone image cannot. First, social engineering context. A PDF that appears to be an invoice, a shipping notification, or a compliance document gives the recipient a reason to open it. An unsolicited JPEG attachment is suspicious in most business contexts. A PDF attachment is routine.

Second, the PDF provides execution capability. PDF supports JavaScript, form actions, URI actions, and embedded file launching. A standalone image has no native execution path. The recipient would need to manually extract and run a payload, which is not a realistic attack chain outside of targeted social engineering. A PDF can trigger extraction and execution automatically through built-in features, or guide the user through steps that feel like normal document interaction.

Third, the PDF provides cover. Email gateways, web proxies, and endpoint agents all apply different inspection rules to different file types. PDFs are among the most commonly exchanged business file types. They flow through security infrastructure with relatively low friction compared to executables, archives, or script files. The PDF format itself provides a degree of trust that an image file alone would not receive.

The combination of social engineering plausibility, built-in execution capability, and lower security friction makes PDF the ideal outer container for a steganographic delivery chain. The attacker gets three layers of protection: the trusted file type, the innocent-looking image, and the invisible payload.

The post-extraction problem

Even when an analyst successfully identifies and extracts a steganographic payload from a PDF-embedded image, the work is rarely finished. The extracted data is almost always transformed further. Attackers apply encryption, compression, encoding, and obfuscation to the hidden payload for the same reason they hide it in the first place: defence in depth.

A typical extraction might produce a blob of XOR-encrypted data. Decrypting with the correct key (often embedded elsewhere in the PDF or image metadata) reveals Base64-encoded content. Decoding that reveals a GZip-compressed stream. Decompressing produces obfuscated PowerShell with string concatenation, character code arithmetic, and environment variable slicing. Each layer requires a different decoder. Each decoder requires understanding what it is looking at.

This is where manual analysis stalls. An analyst might successfully navigate the PDF layer and the steganography layer only to spend another hour working through four or five layers of script obfuscation. The post-extraction problem is, in many ways, harder than the extraction itself, because the number of possible obfuscation combinations is vast. For a deeper treatment of why layered obfuscation breaks sequential analysis, see The Multi-Layer Problem.

Automated deobfuscation eliminates this bottleneck. The same pipeline that extracts the steganographic payload feeds it directly into a decoder engine that handles the full range of post-extraction obfuscation. The analyst receives the final decoded payload, not an intermediate encrypted blob that requires three more tools to interpret.

Frequently asked questions