steghide, veracrypt, and the flags that don’t look like flags
If you’d asked me before the exam which module I was least excited about, I’d have said stego and crypto. Not because it’s useless. Because it felt… niche. Like a puzzle box inside a hacking exam.
Then the exam gave me an image. Just a normal JPEG. No obvious connection to anything. And I had to figure out what was inside.
That’s when I realised: stego isn’t niche. It’s the art of hiding something where no one thinks to look. And in a SOC, that’s terrifying.
From the attacker terminal#
The task was simple on the surface. You’re given a file. Could be an image, an audio clip, a zip archive, or an encrypted volume. Your job: extract the flag.
No IP. No service. Just a file and a clock.
First thing I did: check the file type.
file secret.jpgReturned JPEG image data. Expected. But in CTFs and exams, never trust the extension.
Then basic analysis:
strings secret.jpg | grep -i flag— sometimes a flag is literally in the metadata. Not this time.exiftool secret.jpg— maybe the comment field holds a clue. No luck.binwalk secret.jpg— did someone concatenate a zip file at the end? No embedded files found.
So either it’s clean, or there’s hidden data inside the pixels. I went for the classic stego tool: steghide.
steghide extract -sf secret.jpgIt asked for a passphrase. I tried password. Nothing. Tried secret. Nothing. Tried the target name from the exam environment. Denied.
For a few minutes, I felt that familiar twitch of “I’m missing something.” Then I remembered: the exam often gives you weak passphrases that match a wordlist you’ve used elsewhere. I ran a quick dictionary attack with a small custom wordlist I’d built from clues in the lab environment.
stegseek secret.jpg wordlist.txtstegseek is faster than steghide for brute-forcing. Within seconds, it cracked the passphrase: iloveyou123. (Yes, the same one from the cracked SQL hash in Post 3. I laughed.)
Out came a text file. Flag inside.
Another task: an encrypted zip file. Password-protected. I extracted the zip hash with zip2john and fed it to john:
zip2john archive.zip > hash.txt
john --wordlist=rockyou.txt hash.txtPassword: sunshine1. Unzipped. Flag.
The crypto tasks weren’t cryptographic attacks in the academic sense. They were password attacks on encrypted containers. The real skill wasn’t breaking AES; it was recognising that the password was weak and already in a wordlist.
I did spend too long on one stego task because I didn’t check the most obvious thing: the flag was in the base64-encoded comment field of a PNG. exiftool showed me Comment: RkxBR3tTdDNnMF9zdDNOZzB9 — I stared past it twice before my brain went “that’s base64, decode it.” Decoded: FLAG{St3g0_st3Ng0}. Facepalm. But a good reminder.
From the SOC side#
Stego is a SOC analyst’s blind spot. Why? Because everything looks normal.
A JPEG leaving the network is a JPEG. If someone uses steghide to embed a database dump inside a photo of a sunset, the file size might increase slightly, but most DLP systems don’t flag it. The file type still says image/jpeg. The MIME type matches. The extension matches. No signature alerts.
Unless you’re doing deep packet inspection with stego detection (tools like stegdetect or entropy analysis on outbound files), you won’t see it. Some enterprise DLP solutions offer stego detection as an add-on, but it’s resource-heavy and often disabled. So the reality is: if an insider wants to exfiltrate data via stego, they probably can.
Crypto is a similar problem with a different signature. Encrypted files have high entropy—random byte distribution. A zip file encrypted with AES looks almost perfectly random. If a file with .zip extension leaves the network and its entropy score is 7.9/8, that’s not a normal compressed document. It’s encrypted. Advanced DLP can flag high-entropy files. But again, most SOCs aren’t tuning for that.
For the exam, none of this matters. There’s no SOC watching your lab environment. But as a defender thinking about real-world gaps, stego and crypto are the quiet exfiltration channels that keep CISOs up at night.
I came away with a new respect for the module. Not because it was hard—it wasn’t—but because it made me ask: would my own SOC catch this? The honest answer: probably not without tuning that most teams don’t have time for.
How this played out in the exam#
I passed the stego tasks, but they humbled me. The base64 flag in the comment field? I overthought it for 10 minutes, running stego tools on the image, when the answer was in the metadata staring at me. The moment I decoded it, I shook my head. “Keep it simple.”
The steghide task with iloveyou123 was satisfying because it connected to the earlier SQL hash. Password reuse—the gift that keeps on giving. And the zip cracking was straightforward muscle memory at that point: zip2john → john → flag.
The whole module felt less like hacking and more like treasure hunting. But that’s exactly the point. Attackers hide data. Defenders have to think like hunters.
The two-sides takeaway#
Stego and crypto are not just CTF curiosities. They’re real data-hiding and exfiltration techniques that bypass most network monitoring. As a defender, you need to think about what leaves your network in seemingly innocent files. As an attacker, you need to know where to look—and to check the metadata before pulling out the heavy tools.
The exam taught me: always check the obvious. The comment field. The file name. The base64 string hiding in plain sight. Sometimes the flag isn’t hidden with a tool. It’s just waiting for you to notice.
Tools used
steghide extract→ extract hidden data from images/audio (no network activity, relies on weak passphrase)stegseek→ fast steghide brute-force (same as above but with wordlist, leaves no logs unless on monitored filesystem)exiftool→ read metadata, spot comments and clues (completely passive)binwalk→ detect embedded files (passive analysis)strings→ extract readable text from binary files (passive)base64 -d→ decode base64 strings (not a hack, just a conversion)zip2john+john→ extract and crack zip password (offline, no network noise)- SOC detection → stego is largely undetectable in transit unless DLP does deep entropy/stego analysis; encrypted files flagged by high entropy or unusual file behavior; comment-based stego visible only if metadata is inspected manually or via automated data classification tools



