an honest debrief after the exam
The exam ended, and I just sat there.
Six hours. Twenty challenges. A closed room with Bangalore traffic still filtering through the window. My eyes were dry. My brain felt like it had been wrung out. But I wasn’t panicked. I wasn’t celebrating. I was just… empty, in a calm way.
I scored 16/20.
Not perfect. Not a failure. A score that felt, honestly, about right for someone who came in as a defender and learned to think like an attacker for six hours.
What was hard#
The hardest thing wasn’t any single tool or exploit. It was the first two minutes of every task.
Each challenge dropped you into a new scenario. New IP. New file. New web app. And every single time, my brain did this thing: a brief, sharp moment of “I don’t know what to do.” Not panic—just a wall of blank. I’d stare at the screen, too many options flooding in, and I’d have to manually quiet the noise.
Trial-and-error mode is a trap. I learned that quickly. The tasks that went smoothly were the ones where I forced myself to pause and follow a sequence: observe, identify the service or file type, pick the right tool, execute. The tasks where I thrashed? Those were the ones where I started running commands before I understood the problem.
The other hard thing: overthinking. I’ve written about the login form where I ran sqlmap for 10 minutes when the credentials were in the HTML comment. That wasn’t an isolated moment. The exam is designed to test whether you can find the simplest path, and my SOC brain—trained to assume complexity—kept looking for sophisticated attacks when the answer was “guest/guest123.”
What was surprisingly easy#
Recon. Once I had a fixed sequence (whois → dnsrecon → theHarvester → nmap), it became mechanical. The flags hidden in recon tasks were often about coverage, not depth. Run the tools, read the output, spot the anomaly.
Credential reuse. The password iloveyou123 from a cracked hash worked on another service. That felt less like hacking and more like pattern recognition. It was satisfying, but also a little depressing. In the real world, that’s how most breaches happen.
Stego and crypto. I expected to hate this module. It ended up being straightforward: check metadata, brute-force weak passphrases, decode base64 strings. The tools are simple. The real skill is remembering to look.
Where my SOC background helped#
My SIEM-trained eyes caught things others might miss. When I saw open SMB shares, I knew exactly what logs that would generate. When I ran a brute-force attack, I could almost see the 4625 events piling up in a Splunk dashboard. That awareness didn’t make me a better hacker, but it made me a more conscious one. I could feel the noise I was making.
In the stego tasks, the habit of checking metadata first—something I do when analysing suspicious emails in the SOC—saved me time. I didn’t jump to advanced tools; I ran exiftool and strings first. That discipline came from years of triaging alerts.
Where my SOC background slowed me down#
Over-caution. In a real SOC, you don’t run aggressive scans without thinking about impact. In the exam, I hesitated before running certain nmap scripts because my defender brain whispered “that’s loud, that’ll trigger alerts.” But the exam environment doesn’t care. There are no consequences to being loud. I had to consciously silence that instinct.
Overthinking the simple. I’ve already mentioned the guest credentials incident. But there were other moments—looking for encrypted payloads in innocent-looking files, suspecting complex attack chains when the answer was a single command. My SOC brain assumed threat actors are always sophisticated. Sometimes they just guess passwords.
The score, honestly#
16/20. It’s not a score I’ll brag about. But it’s a score that reflects what I set out to do: bridge two worlds. I wasn’t trying to become a master penetration tester. I was trying to understand what an attacker sees, and bring that understanding back to my SOC work.
The four marks I lost? Probably on tasks where I overcomplicated, or spent too long on one step and ran out of time. I don’t know for sure—the exam doesn’t give a breakdown. But I can guess. And I’m okay with it.
What I’m taking back to the SOC#
The biggest thing: empathy. Not for attackers—for the tools. I now know what nmap feels like to run. What a Meterpreter shell looks like from the inside. How easy it is to hide data in a JPEG. That changes how I read alerts. It makes me a more curious, less judgmental analyst.
The second thing: detection gaps I hadn’t appreciated enough. Stego exfiltration. Metadata-based information disclosure. Weak passwords reused across services. I knew these were problems. Now I’ve been the person exploiting them.
The third thing: staying calm under uncertainty. Every task began with confusion. The exam taught me that confusion isn’t failure—it’s the start of figuring it out. Maximum effort. Not maximum certainty.
If you’re thinking about CEH Practical#
Do the labs. Not just once—until the tool sequences become muscle memory. But more importantly: train your mind to pause. The real test isn’t your hacking skill. It’s your ability to manage your own brain for six hours.
If you’re a SOC analyst like me, go in knowing you have a superpower: you already know what the other side sees. That’s the whole point of this series. Two sides of the wire. You’re not starting from zero.
This was the final post. Thanks for reading the whole series—from recon to stego, from an attacker terminal to a SIEM dashboard. If something here helped you, or you have your own CEH story, I’d like to hear it.
Maximum effort, always.
