Steganography in Malware: Detection Guide for Defenders

Steganography used to be the technique you saw in incident reports about sophisticated operators and rarely anywhere else. Commodity malware did not need it; ordinary script obfuscation worked well enough against the defences in place. That changed during 2024 and accelerated through 2025 and 2026. The shift is not about new mathematics or new file formats. It is about tooling. Builder kits and tutorials now automate the embedding step, so an operator who has never opened a hex editor can ship payloads inside images. Image files pass mail gateway content inspection, pass antivirus scans that focus on scripts and PEs, and pass casual analyst review because they are valid images. The carrier files used in the GHOSTPULSE v2, GhostPoster (DarkSpectre lineage), IcedID, and ClickFix-LummaC2 campaigns all open correctly in standard viewers; the malicious content is in places the viewers do not look. This is a working reference for the twelve detection techniques KlaroSkope runs on every uploaded image. Each technique targets a different embedding strategy. The article covers the structural signal each technique looks for, the campaign or family that motivated its inclusion in the analysis pipeline, and what KlaroSkope does with payloads it recovers. There is also an honest section on encrypted payloads: when keys are recoverable, when they are not, and what KlaroSkope reports in either case.

Why Steganography Is Surging (2025-2026)

Three campaign clusters drove the recent shift from APT-only to commodity-level steganographic delivery. None of them invented new techniques; all of them industrialised techniques that already existed.

GHOSTPULSE moved from PNG IDAT chunk embedding (v1, documented from 2023) to direct byte storage inside pixel values protected by a CRC32 integrity check (v2, documented through 2024 and 2025). The v2 shift specifically targeted analysers that inspected ancillary PNG chunks but did not parse pixel data. GhostPoster, the DarkSpectre browser-extension lineage Koi Security catalogued at roughly 8.8 million affected browsers, embedded payloads in extension icon files using delimiter-marker scanning so the loader could find the payload regardless of the surrounding icon content. IcedID has used PNG steganography with RC4-encrypted payloads since 2022, a pattern that the GHOSTPULSE and GhostPoster operators effectively scaled up. Through 2026, Huntress reporting on ClickFix-LummaC2 delivery and Veracode's buildrunner-dev supply-chain disclosure both documented PNG-carrier stages in distribution chains where steganography would not have appeared at this volume two years earlier.

The Twelve Techniques KlaroSkope Detects

Each detection technique below targets a specific embedding strategy. Some are structural (file size, chunk types, EOF markers); some are pixel-level (LSB, alpha, palette, direct bytes). All twelve run on every uploaded image. The aggregate result is a per-technique status table (found, clean, or not applicable) plus the recovered payloads themselves with their cipher identification and entropy classification attached.

Technique 1: Tool Signature Detection

Open-source steganography tools leave fingerprints. Steghide writes specific magic bytes in JPEG comment segments. OpenStego marks PNG payloads with a header string in ancillary chunks. SilentEye uses a recognisable initialisation pattern. KlaroSkope scans the first 64 KB of every uploaded image (case-insensitively, bounded to avoid scanning multi-megabyte pixel data) for these markers. A positive hit narrows the analysis path to that tool's known extraction routine. A negative hit does not rule out tool use; signatures can be stripped or modified by the operator.

Technique 2: Appended Data After EOF

Image formats have explicit end markers: PNG ends at the IEND chunk, JPEG at FFD9, BMP at the size declared in its header, GIF at 3B, ICO at the end of its image directory entries. Image viewers stop reading at the marker. Anything after it is invisible to the viewer but reachable by extraction code. KlaroSkope locates the format-specific end marker, treats the trailing bytes as a payload candidate, and reports its size and entropy. The technique catches commodity stegomalware that simply concatenates a payload to the carrier; its prevalence in long-tail samples is high precisely because the embedding is trivial to implement.

Technique 3: Delimiter-Marker Scanning

Some operators do not append after EOF; they place a recognisable marker (a magic byte sequence, a known string, a builder-specific token) inside the file, with the payload following. The loader scans for the marker and extracts everything after. KlaroSkope checks for the marker patterns documented in active campaigns: GhostPoster's icon-file markers (the DarkSpectre browser-extension lineage), IDAT Loader's chunk-internal markers, and several builder-specific delimiters. A delimiter hit returns a payload candidate plus the offset where the marker was found, useful for clustering samples by builder.

Technique 4: EXIF/Metadata Injection

EXIF and adjacent metadata structures (XMP, IPTC, JFIF comments) are designed to carry text fields about cameras, copyright, and editing history. Operators repurpose them as payload storage. KlaroSkope inspects every metadata field for Base64 patterns (with the characteristic alphabet plus padding) and hex strings with sufficient length. Recovered payloads are decoded inline and forwarded to the deobfuscation chain. Webshell distribution often uses this pattern because PHP loaders that parse EXIF are short and easily concealed in benign-looking image-upload code.

Technique 5: EXIF Null-Byte Concealment

A subtler variant of EXIF abuse: instead of writing a payload as a single field value, operators interleave payload bytes with null padding so the field appears empty or short to a metadata stripper that only inspects the visible portion. KlaroSkope walks the binary content of EXIF entries, treats sequences of null bytes as candidate boundaries, and reconstructs the embedded payload from the gaps. The technique is less common than direct injection but defeats sanitisers that only check field length or visible content.

Technique 6: PNG Ancillary Chunk Abuse

PNG defines critical chunks (IHDR, IDAT, IEND) that decoders must process and ancillary chunks (tEXt, zTXt, iTXt, plus arbitrary private chunks) that decoders may ignore. Ancillary chunks are designed for metadata. They become payload storage when an operator writes Base64, hex, or raw bytes into them. KlaroSkope walks every chunk of an uploaded PNG, identifies non-standard payloads in tEXt and zTXt entries, surfaces private-chunk content, and treats raw chunk data above an entropy threshold as a payload candidate. Operators using OpenStego land here because OpenStego's default mode writes to ancillary chunks.

Technique 7: PNG IDAT Chunk Embedding

IDAT carries the actual compressed image data. Most analysers do not look there because anything inside IDAT is compressed image content by definition. Operators exploit this by either inserting marker bytes inside IDAT and embedding payload around them (the IDAT marker pattern), or by writing high-entropy payload bytes into a region of IDAT and relying on the image still rendering visually. KlaroSkope decompresses IDAT, scans for marker patterns, and applies an entropy threshold to flag regions that do not look like compressed pixel data. IcedID and the GHOSTPULSE v1 lineage both used this technique, which is why it has its own dedicated detection pass rather than being folded into general chunk inspection.

Technique 8: Polyglot File Detection

A polyglot file is simultaneously valid as multiple formats. A common pattern in malware delivery is image + archive: the file opens correctly as a PNG or JPEG in an image viewer, and is also a valid ZIP, RAR, GZIP, or PE when read by the appropriate parser. KlaroSkope checks every uploaded image for polyglot signatures (ZIP local-file headers, RAR magic, PE MZ headers, GZIP magic, HTML or PHP shell tokens) anywhere in the file, not just at the start. A polyglot hit returns the embedded format, the offset where it begins, and a payload candidate consisting of the embedded format's bytes. This is a recurring pattern in format-boundary attacks where the carrier traverses parsers that only recognise one format each.

Technique 9: LSB Pixel Encoding (Six Configurations)

Least-significant-bit encoding stores payload bits in the lowest-order bit of pixel channel values. A single-bit RGB encoding hides 3 bits of payload per pixel; a 2-bit encoding hides 6. The visual change is imperceptible because each channel value changes by at most 1 (for 1-bit) or 3 (for 2-bit) units out of 256. The challenge for detection is that operators vary the channel order, bit count, and traversal direction per build, and a decoder configured for the wrong combination produces noise that looks like a failure to detect anything. KlaroSkope tries six configurations per image: RGB row-major (the default in most builders), R-only row-major, BGR row-major (some Windows-native builders use BGR ordering), RGB 2-bit row-major (higher payload density), RGBA row-major (including the alpha channel), and R-only column-major. A payload candidate from any configuration triggers the post-extraction crypto pipeline.

Technique 10: Alpha Channel Difference Encoding

Images with an alpha channel carry a fourth byte per pixel that controls transparency. In most carrier images the alpha channel is either fully opaque or follows a smooth gradient. Operators encode payload bytes as differences in alpha values: instead of storing the byte directly in alpha, they vary alpha by the byte value relative to a baseline. The image looks identical because the alpha differences are too small to perceive. KlaroSkope computes the per-pixel alpha differences against the running baseline and reconstructs the payload bytes. The technique is associated with the Stegano library and its derivatives, including AdGholas-style steganographic carriers.

Technique 11: Palette Encoding

Palette-indexed images (8-bit PNG, GIF, some BMP variants) use a palette of up to 256 colours, and each pixel stores an index into that palette. Operators exploit this in two ways. Palette index abuse: shuffle the palette so the indices spell out the payload when read sequentially while the visible image stays correct (because the palette entries are rearranged to compensate). Palette-as-bytes: write the payload directly into unused palette entries, accepting some visual artefacts in regions of the image that do not reference those entries. KlaroSkope inspects the palette and the index sequence for both patterns. The technique appears in custom 8-bit PNG and GIF builders rather than mainstream tools.

Technique 12: Pixel Value Direct Bytes

The most aggressive pixel-level technique: store payload bytes directly in pixel values, accepting that the image will be visibly modified, and protect the payload with a CRC32 integrity check so the loader can verify it received the correct bytes. The visual modification is acceptable in carrier files designed to be small and unobtrusive (extension icons, tiny PNGs in corners of web pages) where users are not likely to notice. KlaroSkope identifies the technique by looking for CRC32-protected byte sequences in pixel data and by flagging high-entropy pixel regions in carrier images that should not have them. GHOSTPULSE v2 is the documented public example; the technique generalises to any custom loader that prefers CRC32 protection over the silent corruption that LSB and alpha-difference encoding leave behind.

Encrypted Payloads: When Keys Are Recoverable

Recovering an embedded payload is the first step. Most modern stegomalware encrypts that payload before embedding, so the bytes KlaroSkope extracts are ciphertext. The post-extraction crypto pipeline takes over: identify the cipher by entropy and structural signals (AES-aligned block sizes, recognisable GCM tags, statistical XOR fingerprints), recover the key from any of four sources, and run trial decryption.

The four key sources are: image metadata (EXIF fields and PNG text chunks frequently carry the key as Base64 or hex alongside the payload), the payload itself (some loaders prepend the key), OSINT threat intelligence (published campaign keys for AsyncRAT, IcedID, XWorm, and similar families), and the surrounding loader script context when an obfuscated script is recovered together with the image. KlaroSkope checks all four. Any candidate key that produces output passing the quality gate (Q greater than or equal to 0.40) is reported as a successful decryption with the cipher identification and confidence attached.

When the key is derived at runtime from values KlaroSkope cannot observe (the loader fetches a key from a registry hive, computes one from system identifiers, or pulls one from C2 on first contact), the payload stays encrypted. KlaroSkope reports the cipher identification, the entropy classification, the encryption hint (AES-aligned blocks, DES-aligned blocks, stream cipher, or custom scheme), and the unsuccessful trial decryption attempts. The extracted ciphertext is preserved in the analysis output for manual investigation or for reanalysis once the threat-intel community publishes the relevant key. This honesty is the credibility: a tool that fabricates plausible-looking decryption when none succeeded would be worse than a tool that says 'cipher identified, key not recovered'.

How KlaroSkope Handles It in Practice

Upload an image. KlaroSkope runs all twelve detection techniques, attaching to each a per-technique status (found, clean, or not_applicable for techniques that do not apply to the format). Recovered payloads carry their entropy classification and any encryption hint. Encrypted payloads run through the post-extraction crypto pipeline; successfully decrypted output flows into the standard deobfuscation chain alongside the rest of the analysis. The verdict (payload_found, suspicious, or clean) is surfaced at the top of the result, and the decoder chain, recovered IOCs, generated YARA and Sigma rules, and the analyst-view layer breakdown follow. The whole pipeline is static: no execution of recovered scripts, no rendering of carrier images for behavioural analysis, no network. This is the same pipeline covered in steganography detection techniques and steganographic payload extraction, with this article serving as the comprehensive reference for the twelve detection passes themselves.

For analysts, the practical impact is throughput. A single sample that would take 30 to 90 minutes to manually triage with CyberChef, exiftool, zsteg, and a hex editor decodes in seconds with the chain visible end to end. For SOC teams processing dozens of suspicious image samples per week, the math changes investigation throughput from hours per sample to minutes.