DCat

Malware Analysis: Persistence, Obfuscation & Steganography

A deep dive into a malware sample hiding inside a fake PDF — emoji-obfuscated batch scripts, C2 communication, and payloads embedded in JPEGs using steganography.

malwarereverse-engineeringsteganographyobfuscationsecurity

I received a suspicious file that didn’t look right. Embedded files weren’t structured normally — so I spun up a Windows sandbox VM and started digging.

The File

The sample arrived disguised as a PDF. It was actually an LZH archive — a pretty uncommon format, which is exactly the point. The compression also uses encryption to slip past automatic detection. First anti-detection measure: check.

Inside: a .bat file. The entry point.

Persistence via Startup Folder

The first thing the batch script does is copy itself into the Windows Startup folder:

@echo off
setlocal
set "scriptPath=%~f0"
set "desiredName=slappers.bat"
set "startupFile=%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\%desiredName%"
copy "%scriptPath%" "%startupFile%" >nul 2>&1
endlocal

Simple, effective. Every time the system boots, slappers.bat runs. No payload is stored locally — it gets pulled from a C2 server at runtime. This keeps the disk footprint clean and makes static detection harder.

You can detect or disable this manually by checking %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\.

Obfuscation with Emojis

The batch file itself is obfuscated using emoji substitution — variables are named with emojis, making the script unreadable at a glance:

@%additive%e%bigwiggery%c%erraticalness%h%maize%o%aromochelys% %pings%o%Gg%f%superfamilies%f%enouncement%

At the bottom of the file, those emojis get substituted out:

set "misdirection=%misdirection:🖼💪😋🖹🎆⚞🐴🍬🔆🔗♌🔷🌄♡🍏=%"

Which resolves to a base64 string, and ultimately the C2 server address.

Exposed C2 Directory

Weirdly enough, the server’s directory was fully exposed. Inside it: the same opa.bat file we were analyzing, a bunch of .txt, .vbs, .js files, and several images.

There was also a Death Note reference apparently left on purpose. Either a flex or a lure for curious analysts.

JavaScript Obfuscation

Following the chain leads to an HTML file and rems2.js, which points to a Pastebin-like site hosting heavily obfuscated JavaScript:

var Ummon = ([]+[
  ([]["hierarchically"]+[])[0] + ([]["saone"]+[])[1] + ([]["twinchargers"]+[])[2] +
  ([]["downstage"]+[])[3] + ([]["saltiered"]+[])[4] + ([]["nonmodern"]+[])[5] +
  ([]["Feisal"]+[])[6] + ([]["saoneMap"]+[])[7] + ([]["marbleized"]+[])[8] +
  ([]["slice"]+[])[9]]["saltiered"])[0];

This is a classic JSFuck-style encoding — constructing strings character by character from array property names. The file is massive and still needs full deobfuscation.

Hybrid Analysis Results

Running the sample through Hybrid Analysis confirmed:

Finding Detail
File types .bat, .js, .vbs
Purpose Persistence, remote file fetching, C2 setup
Suspicious files .txt, .vbs, and image files potentially hiding payloads
Obfuscated scripts Especially rems2.js

Collected files:

  • Batch: opa.bat
  • JavaScript: rems2.js, asim.js
  • VBScript: 4sar.vbs, OK.vbs
  • Text files: 4sar.txt, ascn.txt, ast0603.txt, and more
  • Images: 01.jpg, n01.jpg, new_image.jpg, and others

Steganography in the Images

Something felt off about the image files. Running exiftool on n02.jpg:

File Name     : n02.jpg
File Size     : 4.3 MiB
File Type     : JPEG
Image Width   : 1920
Image Height  : 1080
Megapixels    : 2.1

4.3 MB for a 1080p JPEG. That’s not normal. Running binwalk confirmed it:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             JPEG image data, JFIF standard 1.01
748616        0xB6C48         Sega MegaDrive/Genesis raw ROM dump, Name: "3sAAApv9wAACgoFL"
1415119       0x1597CF        ZBOOT firmware header, header size: 32 bytes, load address: 0x47415151

There’s hidden data embedded inside the image. The Death Note JPEG isn’t just bait — it’s carrying a payload. Classic steganography.

The other images likely carry data too. The executables in the C2 directory look like honeypots — meant to catch analysts who poke around carelessly.

What’s Next

This is just the surface. Still pending:

  • Full deobfuscation of rems2.js and 4sar.vbs
  • Extracting and analyzing the payload hidden in the images
  • Mapping the full C2 communication flow
  • Checking if the other images also carry embedded data

The actual payload is probably inside those JPEGs. I’ll cover the extraction and reverse engineering in a follow-up article.

Full Hybrid Analysis scan: View report