New Wave of Steganography Attacks: Hackers Hiding XWorm in PNGs

ANY.RUN  experts recently uncovered a new XWorm campaign that uses steganography to conceal malicious payloads inside seemingly harmless PNG images.

What appears to be an ordinary graphic actually contains encrypted loaders that execute entirely in memory, allowing the malware to bypass most traditional detection methods and signature-based defenses.

Let’s break down how this attack works and what analysts and hunters should look for.

Attack Overview with Real-World Example

The infection starts with a malicious JavaScript installer named PurchaseOrder_25005092.JS, delivered through phishing emails and web pages (T1566.001).

The script is obfuscated using an Immediately Invoked Function Expression (IIFE) pattern (T1027) and writes three staged files to: C:\Users\PUBLIC\

Kile.cmd

Vile.png

Mands.png While the .png extension suggests images, these are not image files. Instead, they act as storage containers for Base64-encoded and AES-encrypted payloads (T1036.008); a common trick to avoid quick signature-based detection.

You can view the full attack chain and download an actionable analysis report from a real-world run inside  ANY.RUN’s interactive sandbox :

Steganography attack discovered inside ANY.RUN sandbox

See every stage of execution unfold in seconds, extract IOCs automatically, and transform hidden malware behavior into clear, shareable insights.

Execution Chain Breakdown: What Analysts Need to Know

Below is a concise, step-by-step breakdown of the execution chain to help analysts quickly identify key artifacts and pivot points.

Follow each stage to see where to hunt, which logs to inspect, and which indicators to extract for detection and response.

The JavaScript creates a scheduled task (T1053.005) to maintain persistence after reboot. It checks for required artifacts and recreates them using long Base64 blobs and AES-encrypted strings (T1027.013).

Kile.cmd contains heavy obfuscation: variable noise, percent-substitutions, and chunked Base64 fragments. At runtime it reassembles commands and launches the PowerShell loader (T1059).

Stage 1 – Command runner:  Reads Mands.png, Base64-decodes and AES-decrypts it, then decodes the contained commands and executes them via Invoke-Expression (IEX).

Stage 2 – In-memory assembly loader:  Reads Vile.png, Base64-decodes and AES-decrypts it to raw bytes, then loads a .NET assembly directly into memory and invokes its entry point (T1620). The combined result is a fileless, in-memory loader that launches XWorm.

Pro Threat Hunting Tips: Detecting Fileless and Steganographic Loaders

Below is a focused checklist for analysts and hunters to identify steganography-backed, in-memory loaders like XWorm. Use these steps to spot unusual patterns early and validate findings through behavioral analysis:

Inspect image files:  Scan .png and .jpg files for unusually long Base64 strings, text chunks, or non-image data. High text-to-binary ratios or embedded AES-encrypted sections often indicate hidden payloads.

Monitor PowerShell activity:  Track commands using Invoke-Expression, FromBase64String, or AES routines. Correlate these with script origins like wscript.exe or .cmd files to spot reflective execution and in-memory loaders.

Correlate scheduled task creation:  Look for tasks created by JavaScript or batch scripts from user directories rather than system paths. Such entries often indicate persistence after initial compromise.

Use dynamic analysis:  Static scans miss many steganographic loaders. Run suspicious scripts and files in an interactive sandbox like ANY.RUN to observe decryption, staging, and memory execution in real time, and extract IOCs from each stage.

How a Sandbox Speeds Up Detection in Steganographic Attacks

Steganographic loaders like XWorm rely on multi-stage execution and memory-only payloads, which makes them nearly invisible to static scanners.

A sandbox environment changes that by showing what’s actually happening under the surface; file writes, decryption routines, and PowerShell commands executed in real time.

With  ANY.RUN’s interactive sandbox , analysts can:

Watch the full chain unfold; from the initial JavaScript dropper to in-memory execution.

Extract and visualize IOCs such as decoded scripts, file paths, and registry modifications.

Confirm persistence and C2 activity without waiting for signatures or EDR alerts. This level of visibility turns a stealthy, fileless infection into a transparent, traceable process, helping threat hunters respond faster and with evidence-based clarity.

Turn Complex Attacks into Clear Evidence in Seconds

Attackers are getting better at blending in; the only reliable defense is to observe their behavior, not just their dropped files.

In nearly  90% of cases, ANY.RUN reveals full attack behavior in under 60 seconds , turning fleeting, fileless activity into concrete evidence analysts can act on immediately.

Key benefits for analysts & threat hunters:

Real-time visibility for faster decisions:  Instantly see how loaders unpack, decrypt, and execute without waiting for static scans or vendor signatures.

Fewer false positives:  Behavioral context makes it easy to distinguish real threats from benign automation or scripts.

End-to-end understanding:  Watch how each process connects, what files are written, and how persistence is achieved.

Time savings in triage and investigation:  Complete analysis and IOC extraction in minutes, not hours.

Seamless workflow integration:  Push results directly to SIEM, SOAR, or case management tools through ready-made connectors.

Collaboration made easy: S hare live sessions, findings, and visual reports across teams for quicker consensus.

Continuous learning and hunting:  Mapped MITRE ATT&CK TTPs and decoded artifacts enrich detection logic and threat intelligence feeds. Ready to see it in action? Talk to ANY.RUN experts and discover how interactive analysis helps your team find and stop threats static tools miss.

Based on reporting by Cyber Security News.