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 most SOCs have 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 standard viewers. They pass most structural scans. And they can carry kilobytes of encrypted executable code that a typical PDF parser does not look for.

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: JPEG and JPEG 2000 data kept as they are, or raw pixel data compressed with filters such as FlateDecode. These streams are 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 the image data, or concealed in 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 kept, raw pixels rebuilt)
Layer 3: Hidden Payload    -> Steganographic detection (LSB, appended data, metadata)
         v
Layer 4: Obfuscated Script -> Multi-layer deobfuscation (130+ techniques)
         v
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.

The image is not the only hiding place

A PDF viewer shows the final state of a document. The file itself can hold a great deal more, and several of those extra places are well documented in public PDF security research.

Superseded revisions. PDF supports incremental updates: an edit is appended to the end of the file, with a new cross-reference section that points readers at the replacement objects. The original objects stay in the file. A link, a script or a block of text that was replaced in a later revision is invisible in the viewer and still present in the bytes.

Unreferenced and free-listed objects. A PDF is a table of numbered objects, and a reader only visits the objects it can reach from the document catalog. An object that nothing refers to, or one the cross-reference table marks as free while its bytes remain, is skipped by compliant readers. Lenient parsers can still recover it, which is what makes it useful as a parking spot.

Data after the end marker. A PDF ends with %%EOF, and readers generally ignore what follows. Appending an archive, an executable or a configuration string after that marker produces a file that opens cleanly as a PDF. Object streams offer a quieter version of the same trick: spare bytes inside a compressed container that no object claims.

The text layer. Text can be drawn in an invisible rendering mode, in white on a white page, outside the visible page area, or at a size no reader can see. A font can also carry a character map that makes the viewer display one string while the underlying character codes spell another. Invisible Unicode characters, such as zero-width spaces and joiners, can encode a payload inside otherwise ordinary sentences. Even the spacing numbers between letters can be used as a covert channel.

Metadata and attachments. The document information dictionary and the XMP metadata packet are free-form text that viewers rarely surface. Embedded file attachments can be nested in trees or hung off page annotations, and their names often say little about their contents.

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 common viewers. 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 few widely available tools chain 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 the stages 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 reads the file's earlier revisions, not only the final one, checks the cross-reference data against the objects that actually exist, and works out which objects the document can reach. Content in superseded revisions, unreferenced or free-listed objects, spare object-stream bytes and data after the final end marker is recovered and passed on for indicator extraction. The same pass flags JavaScript and action triggers, notes a known phishing kit producer as a lead for the analyst rather than a verdict on its own, and maps the embedded images for the next stage.

Several structural findings raise the verdict on their own, including a later revision that switches the document over to a different catalog, and a file whose two cross-reference views disagree about which document opens. Ordinary incremental updates are reported but do not yet raise the verdict by themselves: legitimate signing, form filling and editing produce them too, and their weight is being measured against real signed and edited documents before it counts. Embedded files are opened and characterised, so an attachment is flagged as executable by its content as well as by its name. Form fields that ask for passwords or similar credentials, and form actions that submit the form's data, are reported. A credential field counts toward the verdict when the form also has a way to send data out, and is named without weight when it does not. The verdict weighs intent and dangerous capability, not ordinary features. Scripts that only calculate, validate or format form fields are recognised as form logic and carry no weight, while scripts that reach for dangerous interfaces or hide behind obfuscation do. A link in the document is listed, and weighs only when the reader would follow it without a click or when the page is shaped like a lure. The text layer is examined separately for invisible, white-on-white and off-page text, remapped fonts and invisible Unicode, and whatever it hides is passed to the decoder engine.

Embedded images are then extracted from their stream objects, including images nested inside form objects, transparency groups, patterns and annotation appearances, and small inline images written directly into page content. Each is turned into a standalone image the steganography stage can read: JPEG and JPEG 2000 images keep their original bytes, and images stored as raw pixels are rebuilt with their palette and transparency mask intact, so palette and alpha-channel techniques still have something to work on. Scanned one-bit images, stored as JBIG2 or CCITT fax data, are decoded to pixels as well. Full steganographic analysis runs within a per-document image limit and a time budget. Images past either are still catalogued and byte-checked, and each image that was not fully analysed is named in the result with the reason. A PDF found inside an email, an archive or an SVG file goes through the same image stages, with a smaller image allowance of its own.

Steganographic detection then runs against each extracted image, and which checks apply depends on how the image was stored. Images that keep their original file bytes get appended-data, encoded-EXIF-payload and embedded-signature checks, and a JPEG's marker segments are read for signs of added data. Least significant bit tests run only on losslessly stored pixels, because lossy JPEG compression destroys the low bits an embedder would have written. Rebuilt images get the pixel-level tests, including palette and alpha-channel techniques, and one-bit images also have their raw bit planes read as bytes from the top of the image, since a scan can carry data in its pixels without any other alteration. Some methods are outside what this stage extracts: least significant bit data scattered across the image by a key rather than written in sequence, and data hidden in a JPEG's compressed coefficients (the JSteg, F5 and OutGuess family). Those carriers can pass as clean. Their original stream bytes are checked separately for data hidden after the compressed stream and for embedded file signatures. When hidden data is identified, it is extracted, its readable text is scanned for indicators, and it is passed to the next stage. Web addresses written in plain text in the metadata of a JPEG, PNG, WebP, GIF, TIFF or JPEG 2000 image are reported as well, with a note of where each was found. Legitimate photographs routinely carry such links, a photographer's site or a licence page for example, so these are marked as low-confidence indicators, counted separately from the others and kept out of the generated YARA and Sigma rules. When the same address also turns up elsewhere in the analysed content, it is treated as an ordinary indicator.

The extracted payload then enters the deobfuscation pipeline. Over 130 decoding 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 the layers 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    --> Revisions, xref, orphans, trailing data, JS, actions
  |-- Text layer             --> Invisible text, remapped fonts, invisible Unicode
  |-- Image extraction       --> JPEG, JPEG 2000, rebuilt pixels, 1-bit scans, inline
  |-- Stego detection        --> EOF, EXIF, palette, alpha, LSB (lossless), 1-bit planes
  |-- Payload deobfuscation  --> 130+ techniques, 20+ layers
  |-- IOC extraction         --> URLs, IPs, domains, hashes, keys
  |
  v
  Output: YARA | Sigma | IOCs | MITRE ATT&CK | Analyst View

The pipeline runs automatically in a single pass, with no manual image extraction and no stitching together of partial results from separate tools. Where a layer cannot be read, for example an image format that is reported rather than rebuilt, the report says so instead of treating silence as clean. A payload that looks encrypted and could not be decrypted is reported as not decrypted, and a cipher named only from the shape of the data is labelled as a guess rather than a finding. Where a long value, such as a form field, is shortened for display, the report marks the cut and gives the full length, so a shortened value cannot pass for the whole one. The same holds for size: very large documents are analysed up to fixed limits on pages, drawing operations and images, and when a limit is reached the report names it and states how much was not examined. 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 Steganographic 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 removes much of 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. Where the layers can be resolved, the analyst receives the decoded payload rather than an intermediate blob that needs several more tools to interpret.

Frequently asked questions