Hello,
What is a hacker?
Skip to learning paths ↓The content is free. Start with prepared examples in your browser; no lab setup is required. Begin with accounts in AD or a request’s journey in Web, then check your understanding with a short practice.
Today, the word hacker brings a negative image to many people's minds. A man in a hoodie, a dark room, green text scrolling across a screen, someone trying to break into other people's systems without permission. Yet the culture this word came from was very different.
In the late 1950s and the 1960s, around MIT, a “hack” did not mean damaging a system. It meant solving a problem in an unusual, creative and clever way. Rather than settling for using something the way you had been taught, it meant truly understanding how it worked, seeing its limits and finding a way to improve it.
Looking back today, this is also where I see the idea of “doing good” at the heart of hacking. It was not about saving the world in some romantic sense; it was about using your curiosity to understand, improve, share and make something better.
I think this is still hacking in its purest form.
When you look at a system, you do not just ask, “How do I use this?” You ask, “Why does it work this way?”, “What does it trust?”, “What is the assumption here?”, “What happens if that assumption is wrong?”
What sets a hacker apart is often not the commands they know, but their inability to stop asking these questions.
Over the years, the industry grew, tools multiplied and security became a profession. That was a good thing. But it also brought another problem.
Sometimes, people started learning tools instead of systems. Looking at a scanner's finding and moving on without understanding the mechanism behind it, memorising a payload without knowing why it worked, knowing the name of a technique without being able to explain which assumption it broke in the system: all of this gradually became normal.
Now, with AI, we are at the beginning of a much larger version of this.
What will we do in the age of AI?
Today, in a few seconds, we can have code written for us, get error messages explained, generate attack ideas, get a summary of a technology we do not know and even have the tools we need built for us.
I do not think this is a bad thing. Quite the opposite: it is an opportunity far more powerful than anything we had years ago. I do not believe we need to fight AI, either.
But we do need to fight the temptation created by the ease it offers.
Because as the cost of doing something falls, the temptation to do it without understanding it grows.
You can follow an attack path without truly understanding Active Directory. You can try ready-made payloads without knowing how the web works. You can run a Frida script without understanding a mobile application's lifecycle. You can test for prompt injection without understanding the architecture of an LLM system.
And sometimes, you will even succeed.
But getting a result and understanding are not the same thing.
This difference may seem unimportant at first. In the long run, it is exactly what will set you apart in this profession.
Because one day, you will face a problem with no ready-made answer. You will not find it on Google. It will not be in a blog post. The scanner will not tell you. AI will not be able to hand you a ready-made solution.
All you will have in front of you is a system whose behaviour you can observe, and you will need to be able to read that system.
This is why I founded Hacker.Directory.
The aim here is not to teach you hundreds of tools. Nor is it to make you memorise the commands for every attack. Thousands of other resources already do that.
What I want to do here is help you truly understand the thing you are trying to hack first.
If you are studying Active Directory, you need to understand not just attack paths, but identity, trust, Kerberos and why a domain works the way it does.
If you are studying the web, you need to understand not just vulnerability names, but HTTP, the browser, state, sessions, origins and how data moves through the system.
It does not matter whether you work on mobile, cloud, AI, LLMs or another technology ten years from now whose name we do not even know today.
Technologies change; systems still have trust relationships, assumptions, boundaries and failures.
That is why we will start with the foundations as much as possible here. But not to build an academic encyclopaedia.
We will go deep enough to truly understand a system at practitioner level.
After that, you can choose to attack, defend or build something new on top of it.
Because when you understand the foundations, you do not get lost when the tools change.
We will use AI, too. To its fullest.
We will have it write code, do research, ask questions, test our hypotheses and use it to extend what we can do.
AI can think for us. It can analyse, generate options, make connections and do things much faster that would take us hours.
But it cannot understand on our behalf.
Because understanding is not just producing an answer. It is being able to see the assumptions that answer rests on, notice what is missing and understand why something that looks technically correct could be wrong in the real system.
This is why the foundations are becoming more important in the age of AI, not less.
Because in the years ahead, producing answers will become cheaper and cheaper.
Real understanding, on the other hand, will become more valuable.
One of the most important things I have learned in this profession is this: when you learn to break a system really well, after a while you also learn how to defend it better.
You start seeing earlier where mistakes will happen, why a control will be insufficient and which trust relationship will cause problems later.
At that point, defense in depth stops being a term on a presentation slide; you truly understand why it is needed.
For me, the essence of hacking has never been about causing harm.
It has been about understanding, questioning, being curious and using what you learn to make things better.
So use the tools. Use AI. Automate. Learn faster. Build faster.
But do not give up on understanding just because things have become easier.
Because in the years ahead, finding answers will keep getting easier.
The real value will lie in knowing which question to ask.
When a system tells you how it works, look a little deeper.
Find out what it trusts.
Question what it assumes to be true.
And every now and then, remember to ask this question about something everyone accepts as true:
What if it isn't?
This is how I learned to hack.
I founded Hacker.Directory so that this would not be forgotten.
— hacker.directory