Somewhere right now, someone opened a JPEG file they received on WhatsApp/social-media  and didn't think twice about it. It looked like a meme. Maybe a wedding photo. Maybe a forwarded screenshot. The file opened normally. The image displayed fine.

But inside that file, tucked into structural regions that no image viewer ever surfaces, there was something else.

This isn't a hypothetical. Attackers have been abusing multimedia files as delivery vehicles for years. The reason most people don't know this is because it works quietly, it bypasses a lot of standard defenses, and frankly the security community hasn't spent enough time looking at this surface.

I built SilentEye because of this exact gap. This post is about the problem first, the mechanics of how these attacks work, what real-world campaigns actually used them, and then what we built and what we honestly found.

The Assumption That Gets People Killed

The mental model most users and honestly, a lot of developers operate under is simple:

● .exe = dangerous

● .jpg = safe

● .pdf = safe (mostly)

● .mp4 = safe

This is completely wrong, and it's been wrong for a long time.

A file extension tells you what the file claims to be. It does not tell you what the file actually contains. The actual format of a file is determined by its internal structure magic bytes, headers, chunk layouts, container schemas. An attacker who understands this gets a lot of room to work with.

Multimedia formats in particular are interesting attack surfaces because they were designed with complexity in mind. JPEG has quantization tables, multiple chunk types, comment fields, EXIF metadata, and APP marker regions. PNG has ancillary chunks that parsers are supposed to ignore. AVI has nested RIFF containers. SVG is literally XML that supports embedded JavaScript. PDF is one of the most abused formats in the world, and for good reason — it was designed to support scripting, embedded objects, and external references.

That complexity is exactly what attackers exploit.

How These Attacks Actually Work

There are a few distinct categories here, and it's worth understanding them separately rather than lumping everything under "steganography" as if it's all the same thing.

1.LSB Steganography

The classic Least Significant Bit steganography works by replacing the last bit of each pixel's color channel with one bit of your payload data. A pixel with RGB value (142, 87, 201) might become (143, 86, 200) after embedding. Visually? Indistinguishable. Statistically? You can detect it if you know what to look for.

The problem is that simple LSB embedding creates measurable statistical anomalies in pixel value distributions. Pairs of pixel values that should have natural variation start showing unusual patterns. Statistical detectors like the RS analysis and chi-square test can catch basic LSB embedding. The more sophisticated steganography tools try to minimize these distortions.

2.DCT-Domain Steganography (JPEG-Specific)

JPEG doesn't store pixels. It stores Discrete Cosine Transform coefficients. Steganography tools like Steghide and JSteg embed data by modifying the least significant bits of these DCT coefficients after the JPEG encoding process.

This is different from spatial-domain LSB. You're working in frequency space, which makes it harder to detect visually and statistically. The image quality degrades slightly, but with high-quality source images, the degradation is imperceptible. Then there's J-UNIWARD a newer algorithm that uses a distortion-minimizing approach to decide which DCT coefficients to modify. It specifically tries to embed in regions where the statistical impact is minimal. This matters a lot, and I'll come back to it when I talk about what SilentEye couldn't handle.

3.File Overlay / Polyglot Files

This one is simpler in concept but effective in practice. Many file formats define a boundary where the valid file data ends. Anything appended after that boundary is ignored by the primary reader. A JPEG file ends at the 0xFFD9 marker. If you append a full ZIP archive after that marker, a JPEG viewer displays the image normally. A ZIP utility sees a valid ZIP archive. The same bytes are simultaneously a valid JPEG and a valid ZIP. These are called polyglot files.

AVI container formats have a similar issue data can be embedded in regions outside the RIFF container structure. MP4 has atom/box structures that leave room for undeclared data. PDF has overlay regions after the %%EOF marker.This is how a lot of initial-access payloads are staged. The multimedia file is the decoy. The embedded payload is a second file, a script, or a binary that a downstream process extracts and executes.

4.SVG Script Injection

SVG files are XML They support XML External Entity (XXE) attacks that can read local files on the target system.

When a browser or an email client renders an SVG file, it executes embedded scripts. This isn't a vulnerability in SVG parsers — it's the intended behavior of the format. The problem is that users treat SVGs like image files and don't expect them to run code.

5.Office Macros and OLE Object Embedding

This is the most widely abused category and the one most people are vaguely aware of. Office documents support embedded objects (OLE), VBA macros, DDE fields, and remote template injection. A DOCX file with no macros can still phone home to fetch a remote template that contains macros when it's opened.

The attack surface here is wide, and it's been the delivery mechanism for some of the most impactful malware campaigns of the last decade.

Real Campaigns That Used This

This isn't theoretical. Let's talk about actual attacks.

Turla APT — Instagram C2 (2017)

Turla is a Russian threat group with a history of creative techniques. In 2017, researchers at ESET documented a Turla campaign where the group was using Instagram comments to host command-and-control infrastructure.

The infected machines would pull a specific Instagram post, parse the comments, and extract a bit.ly URL that pointed to the actual C2 server. The URL was hidden using LSB steganography in the comments section — not in the image itself, but in public text visible to anyone. The brilliance of this was that pulling Instagram comments over HTTPS looks like completely normal browsing traffic. There was no suspicious binary download. No unusual domain. The C2 traffic was indistinguishable from a user scrolling Instagram.This is what operational steganography looks like. It's not about making the attack "invisible" it's about making the traffic blend into expected behavior.

ImageGate — Locky Ransomware via Facebook and LinkedIn (2016)

In late 2016, researchers at Check Point documented what they called ImageGate a campaign distributing Locky ransomware through malicious image files shared on Facebook and LinkedIn.

The attack used malformed image files  specifically crafted to force the browser to download the file rather than display it inline. The downloaded file appeared to be an image but was actually an .HTA file (HTML Application) with a .jpg extension. When users opened the downloaded "image" manually, they were executing the HTA file, which downloaded and installed Locky. This was a two-part social engineering + format confusion attack. The malicious file wasn't steganographically hiding a payload inside a valid image  it was a completely different file type masquerading as an image through extension spoofing and format structure manipulation. The scale was significant. Facebook's CDN was actively distributing these files before the platform caught it.

Witchetty APT — Backdoor Hidden in Windows Logo BMP (2022)

This one is interesting because of how brazen it was. In 2022, Symantec's Threat Hunter Team documented the Witchetty group (suspected to be linked to the TA410 threat actor, which has been connected to China) hiding a backdoor payload inside an XOR-encoded bitmap image of the Windows logo.

The group used steganography to embed an encrypted backdoor in a BMP file. The malware downloader would fetch this image from a public GitHub repository, extract the hidden payload, decrypt it, and execute it in memory. Because the network request was pulling a BMP file from GitHub which looks completely benign it was difficult to detect through network monitoring alone. The payload was never written to disk in a form that traditional AV could easily scan. The image was legitimate enough to pass inspection. The XOR encoding used to protect the payload was simple, but the delivery mechanism made it effective.

Operation Sharpshooter — DOCX Malware Targeting Defense Contractors (2018-2019)

Documented by McAfee, Operation Sharpshooter used malicious DOCX files sent to defense and government contractors as part of a targeted phishing campaign. The DOCX files contained embedded OLE objects and remote template injection, pulling a macro-enabled template from an attacker-controlled server at the time of opening.

The initial document looked like a legitimate job application. It contained no macros. Traditional static analysis would see a clean DOCX. The actual malicious code wasn't present until the document reached out and fetched it during rendering. This is exactly the kind of behavior that static analysis can't fully catch — and also one of the reasons behavioral analysis and sandboxing still matter.

Stegosploit — PoC: JavaScript in JPEG IDAT (2015)

Not a threat campaign, but an important proof of concept. Saumil Shah's Stegosploit research demonstrated hiding executable JavaScript inside the pixel data of JPEG and PNG files, in a way that the image could be embedded in an HTML page and the script would execute in the browser's context.

The concept an image that is simultaneously valid JPEG and executable code showed that the parser boundary between "image data" and "executable content" isn't always enforced. This research influenced how the security community thinks about polyglot and self-executing image attacks.

Why Antivirus Mostly Misses This

Standard AV operates on a few core mechanisms: signature matching, heuristics, and behavioral monitoring. The signature matching problem with multimedia steganography is obvious if the payload is embedded using LSB modification, there's no recognizable binary signature in the file. The bytes that would normally identify malware are fragmented across a carrier file in a way that signature scanners don't look for.

The heuristic side is more interesting. Good heuristic engines look at structural anomalies, entropy characteristics, and suspicious patterns. But most commercial AV products don't run deep structural analysis on every JPEG that comes through your browser or messaging app. The performance cost would be significant, and the detection rates on legitimate steganography threats are low enough that it's historically not been prioritized. The result is that multimedia files get a relatively soft pass compared to executables, scripts, and macro-enabled documents. This gap is real and it's been consistently exploited.

What We Built and What We Actually Found

This is where SilentEye comes in.

The core idea was simple: treat every incoming multimedia file as untrusted and run it through multiple analysis layers before deciding it's safe. No single technique. No "just check the extension." Build a pipeline that combines multiple imperfect detectors and fuses their outputs.

The pipeline we built runs in four stages:

Stage 0 Preprocessing: Check the magic bytes against the claimed extension, detect double extensions, run a SHA-256 hash against a local MalwareBazaar database with roughly one million known-malicious hashes. If there's a match, you're done verdict is malicious, no need to run the rest.

Stage 1 Heuristic Engine: 29 custom YARA rules, entropy analysis, overlay detection, polyglot identification, and format-specific structural checks. This layer looks for files that claim to be one format while exhibiting structural characteristics of something else, or files with suspicious data regions that the format spec doesn't account for.

Stage 2 ML Steganalysis: Four specialized Random Forest classifiers for JPEG, PNG, video, and SVG. Instead of using raw pixel data (which would require GPU and heavy preprocessing), we used 30 hand-crafted statistical features that capture distributional anomalies, entropy variations, and structural irregularities. Keeps the system lightweight enough to run on ordinary consumer hardware.

Hybrid Fusion: The heuristic and ML outputs get combined into a final verdict: CLEAN, SUSPICIOUS, or MALICIOUS.

One of the non-obvious engineering problems was memory. Scanning an 800MB video file naively would mean loading 800MB into RAM. We implemented a smart-read architecture that inspects header and tail regions without reading the full file. The result was scanning an 800MB 4K video using roughly 3.5MB of RAM in under 200ms. That matters if you want this to run on a regular laptop without destroying the user experience.

What This Doesn't Catch

I'll be direct about the limits.

SilentEye is static analysis. It doesn't execute the file. That means:

● Macro-triggered network requests that only fetch the payload at runtime

● Process injection behavior

● Fileless execution

● Anything that only becomes malicious after it reaches an infected environment

SilentEye is a layer before the file gets opened not a replacement for AV, EDR, or sandbox analysis. If you're in an organization that's seriously worried about targeted attacks, you need behavioral analysis running alongside this kind of static inspection. Neither alone is sufficient. What SilentEye is useful for: inspecting files before they enter your environment, catching known threats through hash reputation, catching structural anomalies that standard AV doesn't check for in multimedia formats, and flagging steganographic payloads in images, SVGs, and documents.

The Bigger Problem

The threat model behind all of this is worth thinking about for a second.

WhatsApp has over 2 billion active users. People share images and videos constantly, across every level of technical sophistication. Nobody is running their WhatsApp images through a scanner before opening them. Nobody even thinks to. The file opens, it looks like what it claims to be, and that's the end of the thought process.

The attack surface isn't the technically sophisticated user who reads threat intelligence reports. It's the person who just received a "funny video" from their contact list, or an "important document" from someone pretending to be HR. Mobile platforms make this harder because sandboxing and access restrictions prevent the kind of continuous interception that a desktop tool can do. That's a problem that doesn't have a clean solution right now. But the first step is understanding that the risk exists and that "it's just a JPEG" is not a security posture.

Where to Look Next

If you want to go deeper on the technical side of multimedia steganography, look at the ALASKA2 and BOSSBase benchmark datasets they're the standard evaluation sets for steganalysis research. J-UNIWARD and WOW are the adaptive algorithms that are currently hardest to detect. SRNet is the CNN architecture that currently shows the best results against these adaptive techniques.

For the defensive tooling side SilentEye's code is on GitHub if you want to look at how the pipeline is actually implemented, run the classifiers yourself, or extend the YARA ruleset:

https://github.com/walakeshreyas/SilentEye

The two papers are published in IJERT Vol. 15, Issue 06, June 2026. The systems paper (DOI: 10.5281/zenodo.20844063) covers the full architecture and benchmarks. The survey paper (DOI: 10.5281/zenodo.20846578) covers the comparative landscape of static and ML-based detection approaches for multimedia malware.

Silenteye - Shreyas Walake.