DEV Community: Rahul

I Thought Learning Ethical Hacking Started With Kali Linux. I Had the Order Backwards.

Rahul — Tue, 13 Oct 2026 09:46:15 +0000

When I first started looking into ethical hacking, I did what seemed logical. I started with the tools.

Kali Linux. Nmap. Burp Suite. Metasploit. Wireshark. The names alone make it feel like you've begun, and almost every tutorial opens with one of them.

Then I looked at what one of those tools actually prints. This is a typical first scan against a practice machine:

$ nmap -sV 192.168.56.101 

PORT     STATE SERVICE VERSION 
 21/tcp   open  ftp     vsftpd 2.3.4 
 22/tcp   open  ssh     OpenSSH 4.7p1 
 80/tcp   open  http    Apache httpd 2.2.8 
 3306/tcp open  mysql   MySQL 5.0.51a

And I asked myself an uncomfortable question: if this appeared on my screen today, could I explain a single line of it?

The honest answer was no. I knew the names of the tools. I didn't understand the world behind them.

The scan I couldn't read

The output was not the problem. My questions were.

Why is port 3306 open to the whole network, and should it be?
What does "open" mean at the packet level? What did Nmap send, and what came back?
Why does the version number matter more than the port number?
If port 80 is a website, what happens between a browser and that server?

Anyone can run the command. I could not explain the result. A tutorial would tell me what to type next, but the moment the target looked slightly different, I'd be stuck.

That was the point where I stopped treating ethical hacking as a tool list and went back to the ethical hacking basics I was about to skip.

What I thought I needed vs. what I needed first

The left column is tools. The right column is ethical hacking fundamentals. The tools only make sense once the right column does.

The four foundations

1. Networking

A port scan is a conversation. Nmap sends a SYN packet; an open port answers SYN-ACK, a closed one answers RST, and a filtered one usually says nothing. Once I understood that, "open", "closed" and "filtered" stopped being labels and became observations.

Learn first: IP addresses and subnets, TCP vs. UDP, the three-way handshake, DNS, and what common ports are for.

2. Linux basics

Most targets and most tools live on Linux. You don't need to be an admin. You need to move around without a tutorial open.

ls -la /etc          # who owns what, and who can read it 
 ps aux               # what is running 
 ss -tulpn            # what is listening, and on which port 
 grep -r "password" . # how fast secrets turn up in plain files

3. HTTP and the web

Before opening Burp Suite, send one request by hand (output trimmed):

$ curl -v http://192.168.56.101/login 

> GET /login HTTP/1.1 
 > Host: 192.168.56.101 
 > 
 < HTTP/1.1 200 OK 
 < Set-Cookie: PHPSESSID=abc123; path=/

Methods, headers, status codes, cookies. That cookie has no HttpOnly or Secure flag, and noticing that is already a finding. Burp Suite is this same exchange with a pause button.

4. Authentication and common vulnerabilities

Some common beginner-level findings involve weak or reused passwords, missing access checks, unvalidated input such as SQL injection or XSS, outdated software, and phishing. Learn why each one happens. vsftpd 2.3.4 in the scan above matters because a compromised release of that exact version carried a backdoor. The version string is the clue, and it is the line beginners scroll past.

Two words are worth separating early, because they sound alike:

Authentication: who are you?
Authorization: what are you allowed to do?

Say you log in successfully. Authentication worked. Now you change /account/1041 to /account/1042 in the URL and see someone else's data. That is an authorization failure, and no scanner flag explains it. You catch it only if you know how the application is supposed to control access.

Where the tools actually fit

Every security tool automates a question you could ask by hand, only slower.

If you can't ask the question without the tool, the tool's answer won't mean much. That is the whole lesson of the unreadable scan.

The tools also map onto a process. The classic attack lifecycle has five phases: reconnaissance, scanning, gaining access, maintaining access, and covering tracks. An ethical test follows the same path with permission and ends in a report. Nmap belongs to phase two. I had been starting in the middle.

Build a lab before you touch anything real

One rule comes before every technique: only test systems you own or have written permission to test. Scanning systems you don't own or don't have permission to test can have serious legal and ethical consequences. "I was learning" isn't a substitute for permission.

A safe lab costs nothing:

Install VirtualBox on your own machine.
Run Kali Linux as one VM (now it has a job).
Run a deliberately vulnerable target as a second VM: Metasploitable 2, or a Linux VM hosting DVWA or OWASP Juice Shop.
Put both on a host-only network so nothing leaks to your home network or the internet.
Take a snapshot before you break anything.

The 192.168.56.x address in my examples is VirtualBox's default host-only range. Everything in this post stays inside that box.

The order I'd follow if I started again

Networking: ports, TCP/UDP, DNS, the handshake.
Linux command line: files, permissions, processes, services.
HTTP: read raw requests and responses with curl -v or browser dev tools.
The ethical hacking process: the five phases, and where permission and scope fit.
Reconnaissance and footprinting: what can be learned without touching the target.
Common vulnerabilities: passwords, injection, misconfiguration, phishing.
Tools: now Nmap, Burp Suite and the rest have something to attach to.
Lab practice and write-ups: explain each finding in plain language.

Tools arrive at step seven. I had started there.

One caution in the other direction: don't spend six months on networking before touching a lab. That is another way of never starting. Learn a little, try something small, get confused, learn the concept you were missing, and try again. You need enough foundation to know what you're doing, why you're doing it, and whether you're allowed to do it.

Mistakes I'd skip next time

Copying commands without predicting the output. Guess first, then run it. The gap between the two is where the learning is.
Collecting tools instead of concepts. Ten installed scanners teach you less than one request read line by line.
Skipping the write-up. If I can't explain a finding to someone non-technical, I don't understand it yet.
Treating "ethical" as a formality. Scope and permission are the difference between a security professional and a criminal.

The shortcut: one structured course

The slow part of all this is assembling the order yourself from scattered tutorials. If you'd rather follow one structured path, LearnKartS' Ethical Hacking Fundamentals course on Coursera picks up at step four of that list and covers the ethical hacking essentials from there, with each tool demonstrated next to the concept it serves:

Foundations: the attack lifecycle, the hacker mindset and ethical boundaries, with Kali Linux and Burp Suite set up by demo
Footprinting and OSINT: Shodan, WHOIS and Google dorks, before you touch a target
Network scanning and vulnerability assessment: Nmap port scanning and OS discovery, which is the scan at the top of this post, explained
Enumeration: pulling useful detail out of network services such as DNS, SMTP and SNMP
Social engineering and phishing: how the attacks work and how to detect them
Web application security: server architecture, common attacks, and demos of authentication bypass and API exploitation
AI in security: how AI is changing both attacks and defences

It is beginner level and needs no coding background: 8 modules, about 7 hours, self-paced, with a shareable certificate. More than 19,000 learners have enrolled, and it is rated 4.6. It is also part of the LearnKartS Ethical Hacking Specialization, so there is a clear next step when you finish.

Start Ethical Hacking Fundamentals on Coursera.

Whichever route you take, the order matters more than the source: foundations first, tools second.

What I'm exploring next

I'm now looking at how AI tools change reconnaissance and vulnerability triage, and where they confidently get it wrong. That will be the next post.

Your turn: what did you learn in the wrong order? And if you work in security, what is the one fundamental you wish beginners learned before they opened Kali?

"Review This Code" Is the Worst ChatGPT Prompt. Here Are 5 Better Ones for the Same Buggy Function.

Rahul — Fri, 09 Oct 2026 11:45:50 +0000

There is a bug in these six lines. Find it before you scroll.

`def get_discount(price, user): 
     if user.is_premium: 
         discount = 0.2 
     if price > 100: 
         discount = discount + 0.1 
     return price - price * discount `

Most of us would paste this into ChatGPT with three words:

Review this code.

It's the kind of prompt that's incredibly easy to type. You will get an answer. You will also have left the model to guess everything that matters.

What "review this code" leaves out

When a prompt leaves those blank, the model fills them with the most average answer available: a tidy list about naming, docstrings, type hints and "consider adding error handling". The real bug may be in there, as one bullet among eight, with the same weight as a missing docstring.

ChatGPT prompt engineering is mostly the work of filling in those blanks on purpose. Here are five ways to do it, all on the same function. The answer to the bug is further down, so you can test each prompt before you read it.

Prompt 1: Give it a role, a goal and a context

`You are a senior Python engineer reviewing a pull request. 
 This function runs in the checkout path of an online store. 
 A wrong result means a customer is charged the wrong amount. 

Goal: find anything that could produce a wrong price or a crash. 
 Ignore style unless it hides a bug. 

[paste the function] `

What changes: the model stops reviewing "some code" and starts reviewing a checkout function where a wrong number costs money. Style notes drop away because you said they don't matter.

Use it when: always. This is the baseline, and it takes twenty seconds.

Prompt 2: Show it the answer you want (few-shot)

`Review the function below. Report each issue in exactly this format. 

Example: 
 SEVERITY: High 
 INPUT THAT TRIGGERS IT: quantity = 0 
 WHAT HAPPENS: ZeroDivisionError on line 4 
 FIX: return 0 early when quantity is 0 

Now review this function: 
 [paste the function] `

What changes: one example does more than a paragraph of instructions. The reply comes back in the same four fields, and "INPUT THAT TRIGGERS IT" forces a concrete failing case where a vague prompt gets "this might fail in some situations".

Use it when: the output goes into a ticket or a PR comment, or you run the same review across many functions.

Prompt 3: Make it trace the cases step by step

`Before giving any verdict, trace this function by hand for four cases: 

1. premium user, price 150 
 2. premium user, price 50 
 3. non-premium user, price 150 
 4. non-premium user, price 50 

For each case, state the value of every variable after each line. 
 Only then tell me what is wrong. 

[paste the function] `

What changes: you have replaced "have an opinion" with "do the work". The model works through concrete inputs before it judges, so a bug that lives in one branch has nowhere to hide once every branch is walked with real numbers.

Use it when: the logic has branches and the stakes are real: money, dates, permissions.

Prompt 4: Let it interview you first (flipped interaction)

`I want you to review a function. Before you do, ask me up to three 
 questions about anything you need to know to review it properly. 
 Wait for my answers before reviewing. 

[paste the function] `

What changes: expect questions like "what discount should a non-premium user get?" or "are the two discounts meant to stack?". Those questions are the missing spec, and a lot of bugs are spec gaps. This prompt shows you what you forgot to say.

Use it when: you suspect the problem is in the requirements, not the syntax.

Prompt 5: Turn it into a template you reuse

`ROLE: Senior {language} engineer reviewing a pull request. 
 CONTEXT: {where this code runs and what a failure costs} 
 GOAL: Find bugs that cause wrong results or crashes. Ignore style. 
 METHOD: Trace every branch with concrete inputs before judging. 
 FORMAT: For each issue give severity, triggering input, what happens, fix. 
 IF UNSURE: Ask me before assuming. 

{code} `

What changes: this is prompts 1 to 4 folded into one block. Save it as a snippet and you never type "review this code" again.

Use it when: you review code with AI more than once a week.

The bug

If the user is not premium, discount is never assigned.

Non-premium, price 150: line 5 reads discount before it exists.

Non-premium, price 50: the return line does the same.

Both raise UnboundLocalError. Every non-premium customer crashes the function, and premium customers never notice. The fix is one line at the top: discount = 0.0.

Cases 3 and 4 in Prompt 3 walk straight into it.

The honest trade-offs

A good model may catch this bug with the lazy prompt too. The better prompts are about what comes back first, in what order, with a failing input attached, and how consistently.

Output varies between runs. The same prompt can produce two different reviews. For anything important, run it twice.

Longer prompts cost time. For a throwaway question, three words are fine.

You still read the code. A well-formatted review can be confidently wrong.

Where these patterns come from

None of these five are my invention. Role prompts, few-shot examples, chain of thought, flipped interaction and reusable templates are standard prompt patterns, and there are a dozen more that work the same way on emails, summaries, documentation and test cases.

If you want them taught in a structured sequence, the course I'd point you to is LearnKartS' Prompt Engineering for ChatGPT: Beginner to Advanced.

This ChatGPT prompt engineering course covers the techniques behind the five prompts above and the ones I had no room for: prompt structure, few-shot and chain of thought prompting, ask-before-answer, flipped interaction, reusable prompt frameworks and responsible AI use. As an AI prompt engineering course it is beginner level and self-paced, and the free version of ChatGPT is enough to follow along.

Your turn

Two things I'd like to see in the comments:

Run the lazy prompt. Paste the function into the model you use with only "Review this code." Did it lead with the crash, or bury it under style notes? Post the first line you got back, and name the model.

Share your default. What is the one prompt you reuse most, for code or anything else?

And if you think "worst prompt" is unfair, tell me why. I'll defend the title.