How to Start Ethical Hacking in 2026: The Roadmap Nobody Gives You Straight
Every week someone posts the same question on forums, Discord servers and LinkedIn comments: where do I start with ethical hacking? And every week they get the same three answers. Learn Kali. Do CEH. Watch this 12 hour YouTube course.
All three are bad advice for a beginner, and here is why. Kali is a toolbox, not a skill. CEH is a multiple choice exam that will not teach you to find a bug. And a 12 hour course watched passively leaves you exactly where you started, except now you feel like you should know more than you do.
This roadmap is the order that actually works. Six steps, four to six months of honest effort, and a clear checkpoint at the end of each stage so you know whether to move on or stay put.
One thing before we start. Ethical means authorised. Testing a system you do not own, without written permission, is an offence under the Information Technology Act in India and under equivalent laws almost everywhere else. Everything below happens inside your own lab or inside programs that explicitly invited you.
Who this roadmap is for
You need no security background. This is written for the college student, the support engineer switching tracks, and the self taught learner who has watched a lot of content and still cannot answer “so what can you actually do?”
What you need:
- A laptop with 8 GB RAM and an SSD
- Six to ten focused hours a week
- Patience for the first two months, where progress feels invisible
What you do not need:
- A computer science degree
- An expensive certification
- A gaming laptop or a dedicated server
What this is not: a shortcut. Anyone promising you a security job in thirty days is selling a course, not a career.
Step 1: Learn the fundamentals
Time needed: 3 to 4 weeks
This is the step everyone skips, and it is the reason most people stall around month three. Burp Suite and Nmap only make sense once you understand what a request, a port and a permission actually are. Without fundamentals, every tool becomes magic you cannot debug. You will run a scan, get output, and have no idea whether the result matters.
Networking
You do not need a CCNA. You need a working mental model.
- The TCP/IP model, and where HTTP, DNS, SSH and SMB sit inside it
- TCP versus UDP, the three way handshake, and why a port scan reports
filtered instead of closed
- DNS record types: A, AAAA, CNAME, MX, TXT, NS, and how subdomain resolution actually happens
- Common ports and the services behind them: 21, 22, 25, 53, 80, 139, 443, 445, 3306, 3389
- NAT, private address ranges, and what your home router is doing to your traffic
Linux
You will live in a terminal. Get comfortable.
- File system layout: what lives in
/etc, /var, /home, /tmp, /opt
- Users, groups, file permissions, and SUID binaries. SUID matters more than you think right now, it is a primary privilege escalation path
- Processes, services, cron jobs, and how to read logs
- Core commands:
grep, find, awk, sed, curl, ssh, nc, plus writing a bash loop without looking it up
Web fundamentals
Most entry level security work is web work, so this is the highest return area.
- The full request and response cycle: methods, status codes, request and response headers
- Cookies, sessions and tokens, and how a server knows who you are across requests
- HTML forms, and enough JavaScript to read what a page is doing
- The difference between the web server, the application, and the database behind it
One scripting language
Python, unless you have a strong reason to pick something else. You are not becoming a software engineer. You need:
- Variables, loops, conditionals, functions
- File reading and writing
- The
requests library, enough to loop over a wordlist and send HTTP requests
Checkpoint: you can explain out loud, without notes, everything that happens between typing a URL and the page appearing. You can move around a Linux box without searching for every second command. If you cannot do both, stay here. This month saves you three later.
Common mistake: installing Kali in week one. You will end up running tools, getting output you cannot interpret, and concluding that you are just not smart enough for this. You are. You just skipped the foundation.
Step 2: Set up your lab
Time needed: 2 to 3 days
You need a place where breaking things is free and legal. That means virtual machines on your own hardware, not a friend’s website and not something you found in a Shodan search.
Attack machine
- Kali Linux or Parrot OS, running in VirtualBox or VMware Workstation Player. Both are free
- 4 GB RAM minimum, 8 GB if your host can spare it, 60 GB disk
- Install guest additions. Copy paste between host and VM will save you hours
Target machines
- Metasploitable 2: deliberately vulnerable Linux box, good for network level practice
- DVWA: the classic web vulnerability playground with adjustable difficulty
- OWASP Juice Shop: a modern JavaScript application, much closer to what real targets look like in 2026
- A Windows evaluation VM: needed later for Active Directory and Windows privilege escalation
Network hygiene
- Put every vulnerable VM on a host only network. A deliberately broken box should never be reachable from the internet, and definitely not from your home network
- Take a snapshot right after each clean install. A broken exploit should cost you two minutes, not two hours of reinstalling
- Keep one folder for notes and one for tools, and back up the notes folder somewhere else
Checkpoint: your Kali VM can reach your target VM, neither can reach anything on your home network, and you have a snapshot to roll back to.
If your laptop cannot handle VMs: browser based labs remove the requirement entirely. You can complete the whole of Step 3 without installing anything locally and come back to local VMs later, when you need Active Directory or custom targets.
Step 3: Practice on real labs
Time needed: every week, from here on
This is where the actual learning happens. Reading about SQL injection teaches you the definition. Solving a machine that has one teaches you how to find it when nobody told you it was there. That second skill is the entire job.
Where to practise, roughly in order
- TryHackMe: guided rooms designed for people starting from zero. Follow a structured path, not random rooms
- Hacklido Labs at learn.hacklido.com: browser based labs and CTF challenges with per user isolated environments, including web, API and cloud security paths. Nothing to install, which makes daily practice realistic even on a weak machine
- PortSwigger Web Security Academy: free, and still the best structured set of web vulnerability labs anywhere
- Hack The Box: move here once you can work without step by step hints. Start with retired easy machines, attempt them first, then read the official writeup
- CTF events: weekend competitions. Start in the web category. The real value is in reading other people’s writeups after the event ends
How to practise so it actually sticks
- One machine solved properly beats five machines followed along with a video
- Time box yourself. Stuck for forty minutes, take a hint. Stuck for three hours with zero progress teaches you nothing except frustration
- After every box, write down three things: what you tried, what failed, and what finally worked
- Repeat a machine a week later from memory. If you cannot, you did not learn it, you watched it
Checkpoint: ten easy machines or lab sets solved independently, each with notes. Those notes turn into Step 5.
Common mistake: keeping a walkthrough open in a second tab. It feels productive and teaches close to nothing. Struggle first, then read.
Step 4: Learn hacking concepts
Time needed: 4 to 6 weeks
Now the vulnerabilities themselves. Learn the bug class first and the tool second. Tools get deprecated, rewritten and replaced. The underlying logic has barely changed in twenty years.
Core vulnerability classes
Injection. SQL injection, command injection, template injection. The common thread is untrusted input reaching an interpreter. Learn to spot the pattern, not just the payload.
Cross site scripting. Reflected, stored and DOM based. Understand why output encoding is the actual fix and input filtering is not.
Broken access control. IDOR, forced browsing, horizontal and vertical privilege escalation. This class pays the most in bug bounty because scanners are terrible at it. A scanner does not know that user 1001 should not be reading user 1002’s invoices.
SSRF. Making the server issue requests on your behalf. Learn why cloud metadata endpoints turn a medium finding into a critical one.
File handling. Unrestricted upload, path traversal, local file inclusion, and the chains that turn them into code execution.
Authentication and business logic flaws. OTP bypass, weak password reset tokens, race conditions, missing rate limits, negative quantity in a cart. These require thinking, which is exactly why automation misses them.
Tools worth real time
- Burp Suite: proxy, repeater, intruder, decoder, comparer. Learn this one deeply. It is your main workspace, not just another tool
- Nmap: host discovery, service and version detection, and the scripting engine
- ffuf or dirsearch: content discovery, parameter fuzzing, virtual host discovery
- sqlmap: for exploiting injection you already found manually. Running it blindly at a target is how beginners get banned from programs
- Wireshark: for actually seeing traffic instead of imagining it
- subfinder, amass, httpx: recon, once you start working on real scope
The methodology that ties it together
- Recon: map the attack surface before touching anything
- Enumerate: list every endpoint, parameter, role and feature
- Test: one vulnerability class at a time, across the whole surface
- Exploit and escalate: prove real impact instead of stopping at an alert box
- Document as you go: screenshots and raw requests, captured while you work, not reconstructed from memory afterwards
Checkpoint: given a login page and a dashboard, you can list ten things you would test and explain why each might break. That is methodology, and it is exactly what interviewers probe.
Step 5: Build real skills and proof
Time needed: ongoing, starting now
Nobody can see what you know. They can only see what you documented. This step is what separates people who watched tutorials from people who get interview calls.
What to build
Writeups. One per machine or challenge you solve, published on a blog. Twenty writeups is a portfolio. If you want an audience while you are at it, Hacklido runs WRAP, a monthly writers reward program where members publish technical posts and earn rewards for them. Writing for an audience also forces clarity, which is a real skill.
One full professional report. Pick a single finding from a lab and write it the way a client would receive it: title, severity with a CVSS vector, affected endpoint, steps to reproduce, proof of concept, business impact, remediation, references. Most beginners have never written one. Doing it once puts you ahead of a surprising number of applicants.
A small tool. A subdomain checker, a security header auditor, a wordlist cleaner. Simple is fine. Working and documented is the point.
A public profile. GitHub with clean READMEs. A LinkedIn that shows work instead of claiming passion.
Report writing, the skill nobody practises
Reports are most of the actual job. A tester who finds great bugs and writes badly gets fewer repeat clients than an average tester who writes clearly.
- Write impact in business language. Not “IDOR present on invoice endpoint”, but “any authenticated user can read every other customer’s invoices, including names, addresses and amounts”
- Steps to reproduce must work for someone who has never opened the application
- Always include a fix. That is what turns a report into something a developer can act on
Checkpoint: you can send a link that shows ten writeups and one full report. At entry level, that is worth more than any single certificate.
Step 6: Start bug hunting
Time needed: from month four onwards
Bug bounty is where your practice meets real targets, legally. It is also where most beginners quit, because the first months are mostly duplicates and informatives.
How to start properly
- Pick one platform. HackerOne, Bugcrowd or Intigriti. Filter for programs that explicitly welcome new hunters
- Read the scope. Every single time. Out of scope testing gets you banned, not paid. This includes automated scanning where it is prohibited
- Go narrow and deep. One program, one vulnerability class, for weeks. Shallow scanning across a hundred targets finds only what a hundred other people already reported yesterday
- Hunt where automation is weak. Business logic, access control, multi step flows, and anything involving two user roles. Scanners cannot understand intent
- Report well. Clear title, reproducible steps, honest impact, suggested fix. A well written medium gets triaged faster than a badly written high
What the first year actually looks like
Months of duplicates and informatives before your first accepted finding is completely normal. Your first payout will probably be small, and its real value is the validation plus a writeup you can now show. Most people who quit, quit in month three, which is usually right before it starts working.
Treat bug bounty as practice on real targets and as portfolio material, not as a first income. The job pays the bills. The bounties build the name.
A realistic six month schedule
This assumes six to ten focused hours a week. More hours compresses the timeline, but the order does not change.
| Period | Focus |
|---|
| Month 1 | Networking, Linux and web fundamentals. Lab setup in the final week |
| Month 2 | Guided labs almost daily. First ten easy machines, notes for every one |
| Month 3 | OWASP Top 10 in depth, Burp Suite deeply, PortSwigger labs end to end |
| Month 4 | Methodology practice, harder machines, first published writeups, first bug bounty program |
| Month 5 | One full practice report, portfolio cleanup, resume built on evidence, start applying |
| Month 6 | Interview preparation, continued hunting, pick a specialisation |
Where this leads
Ethical hacking is one door into a wide field. Once you have fundamentals plus lab evidence, these are the usual first roles.
- SOC Analyst. Defensive work: SIEM, alert triage, incident response. Still the highest volume of entry level openings in India
- VAPT Analyst. Offensive work: web and network penetration testing, client reports. Consulting firms hire in batches
- Application Security. Code review, secure SDLC, working next to developers. Pays well, expects coding comfort
- Cloud Security. IAM misconfigurations, storage exposure, container security. Fastest growing demand, fewest qualified people
- Threat Intelligence. OSINT, IOC analysis, MITRE ATT and CK mapping, adversary tracking
- AI Security. Prompt injection, model abuse, agent and MCP attack surfaces. Brand new field where almost nobody has five years of experience, which is exactly why it is worth looking at early
When certifications actually help
Certificates open HR filters. They do not replace skill, and buying one too early is the most common money mistake beginners make.
- Months 1 to 3: none. Spend that money on lab subscriptions instead
- Offensive path: OSCP remains the certification hiring managers actually recognise for penetration testing roles
- Defensive path: a SOC oriented certification plus hands on SIEM experience beats a generic security cert
- GRC and compliance: ISO 27001 and similar, if you are heading towards audit and risk work
Whatever you choose, take it after you can already do the work, not as a way to learn it.
Frequently asked questions
Do I need a degree?
No. Entry level hiring rewards demonstrable skill, and most managers will take a candidate with solid writeups over one with only a certificate. A degree helps clear HR filters at large companies. It is not a gate on the skill itself.
How long until I can get a job?
Four to eight months of consistent weekly practice to be interview ready for an entry level SOC or junior penetration testing role. That assumes hands on work, not passive watching.
Can I learn all of this for free?
Yes. Free guided rooms, PortSwigger Web Security Academy, browser based labs and public writeups cover this entire roadmap. Paid training buys structure, feedback and speed. It does not buy secret knowledge.
Should I learn programming first?
Not a full programming course. Enough Python to automate repetitive tasks, and enough JavaScript to read what a page is doing. Deeper coding matters later if you move towards application security.
Is ethical hacking legal in India?
Testing systems you own or have written authorisation for is legal. Testing anything else, including a casual scan out of curiosity, can fall under the Information Technology Act. Stay inside your lab and inside authorised program scope.
The part that decides everything
The roadmap above is not the hard part. Finding it took you ten minutes. Everyone has seen a roadmap.
The hard part is month two, when the fundamentals are boring, nothing feels like hacking yet, and a new tutorial promising faster results shows up in your feed. The people who make it are not smarter. They are the ones who kept solving one box a week while everyone else kept switching roadmaps.
Pick this one, or pick another one. Just stop picking.
Start with Step 1. Write down what you learn. Come back in four weeks with ten machines solved, and you will already be ahead of most people who asked the same question you did.
Practising on the labs at learn.hacklido.com or writing your own progress log? Publish your writeups on Hacklido. Documenting what you learn is how you turn practice into a portfolio, and how the next beginner finds their way in.
