I have some extra time on my hands, so I decided to explore something I've been curious about for a while: penetration testing. A week or two into it, I've broken into web apps, bypassed logins (at least in my head), and understood why my virtual machine crashed in the middle of an update. And I've barely started. This is the story of how I began learning penetration testing, with all the stumbles, the doubts, and the small wins that keep me going.
The first real obstacle showed up before I'd hacked anything. I needed to set up Kali Linux inside a virtual machine, and it didn't go well. My first attempt filled the disk to 100% in the middle of an update. The second gave me a kernel panic, which is Linux's version of a blue screen. I had to reinstall from scratch, twice, which felt like a failure. But looking back, it was my first real lesson: a big part of this work is debugging. Reading a cryptic error message and figuring out what it means isn't an interruption from learning. It is the learning.

Once the machine was stable, I started with TryHackMe, a guided platform for learning Linux basics. When I wanted something that forced me to figure things out more on my own, I moved on to OverTheWire Bandit, a free game where each level asks you to find a password using Linux commands to move on to the next.
The first few levels were manageable. Then they weren't. Somewhere around a level with compressed files nested inside each other, and later one involving SSH keys, I got genuinely stuck. It felt like I couldn't actually do anything on my own. But that wasn't true. I was the one at the keyboard. I typed every command. I read the output and understood what it meant. When a file changed names on me, I was the one who figured it out. Asking for help and reading how others solved things isn't cheating. That's how almost everyone learns this. The difference between learning and copying comes down to one question: do you understand why it worked afterwards?
After Linux came networking, and with it Nmap, a tool for mapping which ports a machine is listening on. A port is like a numbered door on a server. Different services sit behind different doors: SSH on port 22, web traffic on port 80, and so on. My first scan took forever and produced a bunch of warnings. My second failed because I put a space in the wrong place in the command. When it finally worked, something clicked: the report came back saying 'port 22 open, running OpenSSH version X', and I could see the path from 'there's an opening' to 'this version has a known vulnerability'. That's when I started seeing how the detective work fits together.

The next part of the journey was with PortSwigger's Web Security Academy and SQL injection. The idea is to sneak your own code into an input field, tricking the database into doing things it shouldn't. When I solved my first lab and a hidden product list appeared on screen, I started to understand why people get hooked on this.
Then came cross-site scripting, or XSS, where you inject a malicious script into a page so it runs in someone else's browser. With it came an honest rough patch. I couldn't figure out the solutions on my own. I watched how others did it. It felt like I was cheating my way forward. But then I realized that learning this stuff happens in stages. First you understand nothing. Then you understand when you see the solution, but can't find it yourself. Eventually, after enough variations, you start seeing the pattern and solving things on your own. Being in the middle stage isn't failing. It's exactly where you're supposed to be.

When I finally sat down and properly revisited SQL injection, something good happened. I could explain in my own words why OR 1=1 works: it turns a condition that might be false into one that's always true, so the database returns everything instead of filtering. I understood the difference between tricking a database and just swapping an id in a URL (that second one is a completely different vulnerability called broken access control). And I reasoned my way to how a developer protects against SQL injection. That's when I realized I actually could think through this myself. I had just confused "needing help along the way" with "not being capable."
I'm still very much a newbie. There's a lot ahead. But I've gone from feeling stupid to understanding how an actual intrusion works. Next I want to keep going on PortSwigger and work through more vulnerability types, especially access control. Eventually I want to work through a full machine on my own, from first scan to compromise, without a guide. That's where everything I've learned so far would have to chain together. It scares and excites me in roughly equal measure.