The question "what do I need to study to become an ethical hacker" has an answer that no course gives, because it is not a list of subjects. It is an order, and the order is the only part that counts.
Those who get the order wrong stay stuck. And those who get it wrong in a specific way end up in a very common situation: they know how to use three tools, they do not know how they work, and when the tool fails they have nothing to fall back on.
This article is not a pathway with star ratings. It is the answer to the question: what has to be true, and in what order, at the end of the first year.
A note on the content of this article: here we talk about how to learn the trade. When you get to actually doing it, the rules we wrote in the Hacker’s Vademecum apply, and the first is that you need systems on which you have written authorisation. Learning on your own computers requires no permission: this is the starting point and it must not be neglected.
The answer in one line, if you are in a hurry
First systems, then programming, then networks, then security. Not the other way round. And programming comes before security, even though that is the thing nobody wants to hear.
The reason is that security is a specialisation. You cannot understand why a SQL injection is possible without knowing what a query is, and you cannot understand why a machine is vulnerable without knowing how a process’s memory works. Those who learn "pentesting" before programming learn a series of procedures, and procedures break at the first thing that is not the one expected.
Phase 1: systems, and why they come first
This is the phase almost nobody does, and it is the one that separates those who understand from those who run scripts.
You do not need to study computer architecture like a course. You need to understand three things, and you can understand them in a few weeks if you actually look for them:
what processes are and how the operating system decides who uses the CPU and the memory;
what virtual memory is and why two programmes cannot read each other’s memory;
what permissions are and how the system decides whether an operation is allowed.
The reason they come first is that they are the basis of almost every vulnerability you will see in an assessment. A buffer overflow is not a network mystery: it is a programme that writes beyond the space assigned to it, and you only understand why that happened if you know how processes are built.
A concrete test to work out whether you have understood: explain why a programme with an overflow bug cannot, on its own, read the memory of another programme. If the answer comes to you without hesitation, the phase is done. If it seems obvious that it "can read everything", it is not.
Phase 2: programming, and which kind
Here the choice matters more than it seems, and almost everyone chooses badly.
Python is the best choice to start with, and not because it is the most powerful. It is the best choice because it lets you build real things in very few lines, and a real thing done today is worth ten syntactic exercises. I wrote the details of why it suits offensive work in Python for ethical hacking.
But there is one thing that needs saying because almost nobody says it: learn a second language with a static type, and learn it well enough to understand the difference. Not to become productive in C. To understand what a buffer is and why it exists.
The reason is that the jump from Python to C is the jump that makes the secure side of the trade readable. Those who have understood why an array in C does not check its own limits really understand a buffer overflow. Those who have only done Python use the copy function but do not know why it is dangerous, and this shows up the moment the automatic tool is wrong.
One practical requirement only: learn enough to read other people’s code. Not to write an operating system. To read it.
Phase 3: reading other people’s code, which is the real skill
This is the phase no course includes, and it is the one that makes you independent. If you skip it, you stay tied to what the tools do.
The method is simple and uncomfortable: take a small project and read all of it. Not in a tutorial way, not "skipping the difficult parts". All of it.
A reference project that runs on your system and has honest documentation is
a good first candidate: they are bigger than a tutorial and smaller than an
operating system. In C, for example, a shell like dash or a network tool
like a DNS resolver: they can be read in a few evenings and they show you
how a programme that talks to others is really built.
While you read, keep one question in mind: "what happens if this value is not what I think it is?". It is the question of the input error, and it leads straight to most of the traps.
There is also a second, faster way to make progress sooner: public issues. A project with two thousand stars has an issue for every discussion held. Reading the most heated issues from the first year is worth more than any tutorial, because you read them the way the maintainer would: "here someone said it works, but if the input is null something else happens".
Phase 4: networks, and the point at which they become useful
We described networks in detail in the article on layered architectures, and I will not repeat the theory here. What I will say is when to get to them.
After you have understood processes and have written a few lines of code that run. Not before, and not after.
The reason is that networks on their own are learnt by heart: you know that port 443 is HTTPS, and you do not know why a connection to a service can succeed without anyone having opened anything. It is the difference between knowing and understanding, and it is the same difference that counts in every phase.
And at this point comes the turning point of the pathway, which is only one and needs to be said well: learn the trade from those who do it, by looking at real work. A real assessment, with its boring parts, is worth more than a laboratory.
The laboratory: the mistake to avoid is choosing it badly
Here is the advice I find myself giving most often, because I have seen it done well and badly many times.
The aim of a laboratory is to understand how a machine works, not to learn to use a tool. These are two different things and the order is everything.
A useful laboratory has the following characteristics:
you build it yourself, at least in part. A machine you have assembled you really understand, because you cannot make it easier than it is.
it is exposed only where it has to be. A laboratory machine has no reason to exist on the Internet: it sits on your local network or in an isolated virtual machine, and this is not a security detail but a matter of method.
it is not "complete". A laboratory designed to be finished gets finished and teaches you nothing. In the best ones there is a part that does not work as it should, and you have to understand why.
The worst thing you can do, and which I see done every week, is to
start with automatic tools. They give you a machine, you run
sqlmap, and the result is that you do not know why it worked. The day the
tool gets it wrong — and it does — you have nothing.
So: manual first, then automatic. Do the thing by hand once, understand what you did, and only then automate. The opposite is learning a procedure you do not understand.
And do not forget the part nobody includes: always write down what you have found. Every time you find something, even on your own system, write two lines of explanation. It costs you a minute and gives you three things: you understand whether you understood, you have material for a report, and in a year you will not have to remember what you had noticed.
The three things almost everyone gets wrong at first
1. Looking for the course instead of doing the work. A course gives you the vocabulary, not the skill. That is not bad — it saves you the time of working out what to study — but it is not what makes you good. Time is spent doing, and mistakes are a tool with narrow windows.
2. Wanting to move forward too soon. The symptom is the anxiety to "spring forward" into today’s subject. It is almost always a sign that you have not yet understood yesterday’s. It is the best thing that can happen to you.
3. Believing that technical skill is enough. It is the misunderstanding that the trade is not only technical, and it is the only one of the three that costs you dearly. You can be the best technician in the room and still fail to obtain a signed authorisation, and then you cannot do the work.
The rest of the trade — what you write in a report, how you talk to a client who has received unwelcome news, what to do when you find something you should not have found — is the difficult part, and it is not learnt from a tutorial.
What really matters, in order
The practical summary, if you want the short version.
First month. Operating system: processes, memory, permissions. Bash enough to move around. An architecture book, any one. Install Linux and live in a terminal.
Second quarter. Programming. Python to build, and a static language to understand. First programmes that do something real: a script, a parser, a network client.
Third quarter. Networks, with the theory done properly. And the first laboratory, built by you, with the aim of understanding how it works.
First year. Reading other people’s code on purpose. The Vademecum pathway, which is the order in which you look at a system, and which you now have all the foundations to understand. The first tools, and the first report written for someone.
After that. This does not fit in a schedule. It is time spent doing real assessments, with the people who do them.
What is only noise
It is better to say it, because it is half of what you find online.
Courses that promise a job in three months. Nobody gives you a job, and nobody will take it away from you. The certificate is not part of the trade.
Certifications as a goal. They are useful for the curriculum in some organisations and for nothing else. Nobody hires you because you have an exam.
Tools before the foundations. A tool you do not understand does not make you good, it makes you dependent on what works today.
The "required skills" lists on job portals. They are generated, copied and describe no real job. The ones that count are five: reading, understanding the system, writing, being able to communicate, and the ethical part that comes first.
The rule we use
CYBER ONIONS’ reasoning on this subject is a single sentence, and we repeat it to anyone who writes to us:
Do not learn to use security tools. Learn to understand systems: tools change every year, and if you know why they work you do not need to relearn anything.
The pathway is slow, and that is the difficult part. But at the end of the first year you do not have a set of memorised procedures: you have the ability to look at an unknown machine and understand where it starts to break. The day you get there, the trade is already yours.
If only one thing from all this remains: build the laboratory and try it by hand, before automating. Everything else is decoration.