Before I Learned to Hack, I Learned to Investigate

I wanted to solve crimes.

Not in a TV-drama way, but in a real, scientific, evidence-chain way. Forensic science seemed like the perfect intersection of curiosity and purpose. Crime scene analysis, digital evidence, cybercrime investigation — the kind of work where your findings change the outcome of a real case. Internationally, the field looked like exactly what I wanted.

So when I joined for my B.Sc. in Forensic Science, I was genuinely excited. I was going to be the person who reconstructed what happened, from evidence, with precision.

Then I started learning what the landscape actually looked like.

The Reality Check Nobody Warned Me About

Here's the truth that nobody tells you at the admissions office: a B.Sc. in Forensic Science gets you almost nowhere professionally.

The jobs that actually exist government forensic labs, investigative units, law enforcement support roles require an M.Sc. at minimum. And even with a master's degree, you're not competing just with forensic science graduates. You're competing with general B.Sc. Chemistry graduates who qualify for the exact same positions with a less specialised degree.

Three years of focused study, and the person with a generic science degree could walk into the same interview room.

I remember sitting with that realisation. Not dramatic frustration — more like a slow, quiet recalibration. The feeling of having invested in a direction and discovering the destination wasn't what the brochure described.

But here's what I kept coming back to: the thinking itself I loved.

Reconstructing events from incomplete evidence. Tracing every action back to its origin. Refusing to conclude before the data supported it.

I didn't want to leave that behind — I needed to find a different arena for it.

That classroom moment was the answer I didn't know I was looking for.

The Classroom That Changed Everything

He didn't walk in like a lecturer.

He walked in like someone who had been up at 2am doing this for fun — Parrot OS already running, terminal open, a script on screen that he had written himself.

Our topic that day was digital forensics and cybercrime. SIM cloning was on the syllabus.

But the way he taught it wasn't academic.

He showed us how information gets gathered — not conceptually, but operationally. His own OSINT script pulling data in real time. SIM cloning explained not as a definition to memorise for an exam, but as a real attack: how it works, what it enables, what the victim experiences, and how an investigator traces it back.

"The whole room was watching the screen. I was watching him."

Not the terminal. Not the output. Him.

What stood out wasn't the tools — it was the relationship he had with them. Most people who demo software are narrating what's on screen. He wasn't narrating. He was thinking out loud, and the tools were just keeping up with him.

When something returned unexpected output, he didn't pause to check notes. He already knew why. When a query came back with more data than expected, he knew exactly what it meant and where to go next.

That was N Vishnu Venkatesh — Cyber Forensics Expert, DFIR Specialist, Assistant Professor, patent holder, and active cybercrime consultant working with law enforcement. Certified Security Analyst, CHFI certified, someone who had trained 200+ professionals and officers — and it showed in every minute of that class.

There was no performance in it. No attempt to impress. Just someone operating from a depth of knowledge that made everything look effortless — and made me acutely aware of how different that was from simply knowing which commands to run.

I went home that evening and started searching.

Not for SIM cloning tutorials. For the world behind what he was showing us.

And somewhere in that search, I hit a question I couldn't shake:

How does this tool actually make decisions?

Not "how do I use it." Not "what command do I run." But — what logic is it running? Who built it? What assumptions did they make? Where does it fail?

That question changed everything. It still drives everything I write.

What Forensic Thinking Actually Gave Me

I didn't expect the forensic science background to matter in offensive security. The technical skills didn't transfer directly. But the cognitive habit did — and it turned out to be more valuable than any tool I've learned since.

In forensics, you reconstruct events from incomplete evidence. Every action leaves a trace. You build conclusions carefully from what the data actually shows, not from what you assumed before you looked.

Offensive security is that process run in reverse.

A penetration tester isn't just running tools against a target. They're reconstructing what an attacker would see — in what order, through which paths, and why each step enables the next. And to do that well, you need to understand what your tools are actually telling you — not just read the output and copy the next command.

When I started doing real web application testing, I wasn't just running Burp Suite through the motions. I was asking: what does this response tell me about the framework behind it? What does this error message reveal about the architecture? What does this header expose that the developer didn't intend?

That's forensic reasoning applied to attack surfaces.

Building the Skills — No Clean Path

What followed wasn't linear.

TryHackMe rooms at midnight. HackTheBox machines I failed multiple times before something clicked. Courses I started and didn't finish. Documentation I read twice. Discord servers where I asked questions I was embarrassed to ask. CTF competitions where I came last and learned the most.

Alongside that, internships where I got my first exposure to real environments — vulnerability assessments at Cyber Secured India, network scans and CVE validation at Razz Security, and a month at the Cyber Economic Narcotics Branch Police Station analysing actual cybercrime case files and supporting active investigations. That last one felt like two worlds briefly colliding in the best possible way.

There was also a lot of self-doubt in this period. Moments where I could run something but couldn't explain what it was doing. Moments where a tool produced output I didn't fully understand and I had to decide whether to move on or dig in.

I almost always dug in. That habit, more than anything else, is what moved me forward.

Towards the end of this period, I reported security findings independently to organisation. Both verified the findings and acknowledged them with formal recognition and a monetary reward in Euros. The money was appreciated, but it wasn't what stayed with me. What stayed was the confirmation: thinking carefully about systems, rather than just running tools at them, produces results that matter to real organisations.

The Person Who Taught Me Methodology

Then came Zarthi — and with it, someone who changed how I approach the work entirely.

My Functional Lead, Angad Singh, is a cybersecurity specialist with a background that spans penetration testing, network security, and security operations. CCNA certified, ISC2 Certified in Cybersecurity, and someone who had spent years working offensive security before I ever met him. What made him distinctive wasn't the credentials — it was what he did with the knowledge behind them.

He had a particular way of thinking about connection: between systems, between findings, between people. He believed that understanding how things relate to each other — technically and professionally — was as important as understanding them in isolation. That philosophy showed up in everything, from how he approached an assessment to how he built the team around him.

If Vishnu Sir introduced me to the depth that was possible in this field, Angad gave me a structured way to reach it.

He rarely handed me answers. What he did instead was create situations where I had to find them myself — and then sit with me while I explained what I'd found. That second part was where the real work happened.

I'd walk through my observations, my assumptions, my conclusions. Then came the questions.

What else could this lead to? What assumptions are you making? Can these findings be chained together? Is there another path you're missing?

Many times, those questions uncovered things I would have completely overlooked. A single issue became an attack path. An isolated finding became multiple findings. What looked like the end of an assessment avenue often turned out to be the beginning of a deeper one.

We worked across areas that many practitioners treat as separate — web applications, infrastructure, virtualisation, cloud environments, networking devices, and even tried exploring storage technologies like SAN and NAS. What connected all of it wasn't the tools. It was the approach: the same investigative discipline applied across completely different surfaces.

The culture he built around that work mattered just as much. Questions were never discouraged. Titles rarely mattered. When someone encountered something unfamiliar, we learned it together. Different approaches were treated as strengths, not deviations. He consistently invested in the team's growth because he genuinely believed it made everyone better.

Looking back, many of the methodologies and assessment approaches I use today were shaped by those conversations.

Not because someone gave me a checklist to follow.

Because someone taught me how to think beyond one.

What Command-Based Learning Misses

There is no shortage of cybersecurity education. Courses, certifications, walkthroughs, practice platforms — the volume of available material is genuinely impressive, and most of it is valuable.

What I want to name honestly is what it often stops short of.

When you learn a tool through a walkthrough, you learn a sequence: run this, observe this, do this next. That sequence works until the environment deviates from what the walkthrough assumed — which, in real assessments, it does constantly.

The question that follows — why did that not work the way it was supposed to? — is where real understanding gets developed. But it's also the question most resources don't have time to dwell on. There is always another technique to demonstrate, another box to root.

So practitioners end up with something that resembles expertise from the outside: familiarity with tools, fluency with common patterns, confidence in familiar territory. But underneath that, sometimes, there is no mental model. No framework for what to do when the environment doesn't behave the way the tutorial assumed.

This is not a failure of the individual. It is a gap in how the field tends to teach.

Take Nmap as a small example. Most people learn that a SYN scan is "stealthier" than a full connect scan and move on. But understanding why goes deeper than Nmap — it's a lesson about TCP itself. A SYN scan never completes the handshake, so many logging systems only record completed connections and miss it entirely. When you understand that, you stop learning a scan type and start understanding how logging systems decide what to record — and where their blind spots are.

The output doesn't change. What you do with it does.

That's the difference between memorising a flag and understanding a concept. One gets you through a lab. The other gets you through an engagement you've never seen before.

Vishnu Sir showed me what it looked like when that gap was closed. Angad gave me a practice that built it slowly, through every engagement and every review.

Why This Handle Exists

I am not building a tutorial archive. There are better sources for that.

What I am trying to build is the resource I did not have when I started — a place where the question is not what command do I run but why does this work the way it does.

Where the focus is not on reproducing a known sequence but on understanding the reasoning that makes a sequence appropriate. Where a reader who encounters something they have never seen before has a framework for approaching it — not a script, but a way of thinking.

The topics will be technical. But the purpose behind each one will always be the same: to go one layer deeper. To ask what the tool is actually doing, what assumptions it is making, where it succeeds and where it doesn't.

Not "how to run Nmap" — but how Nmap's service detection actually works and what it means when the output is wrong. Not "how to use BloodHound" — but what graph logic it's running and why certain attack paths appear while others don't. Not "run nuclei against your target" — but how a template decides something is a finding and where that logic breaks down.

People who understand the reasoning behind their methods adapt when technology changes. They learn unfamiliar tools faster. They build their own workflows. Eventually, some of them build tools, write methodology, contribute research — adding to the field rather than only consuming from it.

That is the long-term vision behind what I am writing.

Not better command execution.

Thinking that survives the changes that are coming.

This Is Just the Beginning

This is the first article in a series exploring the logic, protocols, and reasoning that power offensive security tooling.

The goal isn't to become dependent on a particular tool.

It's to understand the ideas that make those tools possible in the first place.

Because tools change.

The underlying concepts rarely do.

And practitioners who understand those concepts can adapt, evaluate new technologies, and build solutions of their own when existing ones fall short.

New articles every Thursday.

"The tools will change. The interfaces will change. The commands will change. The mental model stays."

For years, I thought expertise meant knowing more commands.

Now I think expertise means understanding why those commands work.

Vishnu Sir showed me that this depth exists — that you can see it in how someone moves through a system.

Angad showed me how to build it — through methodology, through questions, through the discipline of never accepting the first answer as the complete one.

And if you came into cybersecurity from an unexpected background and spent a while feeling like you were behind everyone else — you're not. Different mental models are an advantage.

The pivot is uncomfortable for about six months.

Then one day you realise you're no longer trying to find your place in this field.

You're building it.

Which security tool first made you stop and wonder what was actually happening behind the output? Drop it in the comments. Some of those answers will probably become future articles.

Acknowledgements

This article would not exist in its current form without the people who shaped how I think about cybersecurity.

N Vishnu Venkatesh: Cyber Forensics Expert · DFIR Specialist · Assistant Professor

Angad Singh: Cyber Security Specialist · CCNA · Certified in Cybersecurity (ISC2)

Connect with me: LinkedIn · GitHub

Tags: Cybersecurity · Penetration Testing · Offensive Security · Red Team · Career · InfoSec