← Back to Journal
Security12 min read

How I Used AI to Learn Security (Without Being a Hacker)

BY MANISH KUMAR
May 31, 2026

I'm not a hacker. I'm not a security researcher. I'm just a developer who got curious one day about how websites break.

The problem was everything I read assumed I already knew the basics — packets, ports, handshakes, all that networking stuff I slept through in college. I tried following tutorials and gave up three times before I figured out a workflow that actually stuck.

What worked: I used AI as a translator. Hit a concept I didn't get? Ask. Tool spat out cryptic output? Paste it in and ask "what does this mean?" Slowly it clicked.

Before You Start Anything

You need three things before you run a single command:

A target you own. Set up a local VM, use a lab like HackTheBox, or get written permission. Do not skip this. I know it's tempting to poke around random sites — don't. It's not worth the legal headache and honestly, you won't learn much guessing in the dark.

The tools installed. Pick one method below:

# macOS — what I use
brew install nmap gobuster ffuf hydra john sqlmap nikto whatweb nuclei
pip3 install wfuzz theHarvester sublist3r

# Or Kali Linux (everything comes pre-installed)
# Or Docker (works everywhere)

A wordlist. Without this, half the tools won't do anything useful:

git clone https://github.com/danielmiessler/SecLists.git
# Or grab just the essentials:
curl -O https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/common.txt
curl -O https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/DNS/subdomains-top1million-5000.txt

Where AI Helped Me Most

Throughout every phase I used AI the same way:

  • "Explain this error." — paste output, get plain English
  • "What flag should I use?" — skip the man page paralysis
  • "Am I doing this right?" — describe what I'm trying to do
  • "What does this CVE mean?" — no way I'm reading a 50-page advisory

Saved me hours. Treat AI like a patient tutor who never gets annoyed at basic questions.

The Tool I Use For Everything: nmap

If you learn one tool, make it nmap. It's the Swiss Army knife of security testing.

The first time I ran it, I got a wall of output and had no idea what I was looking at. Here's what I wish someone told me:

# This is your starting point — quick scan, common ports, version detection
sudo nmap -sV -T4 -F target.com

# sV = tell me what's running (version detection)
# T4 = go faster (I'm impatient)
# F  = only the top 100 ports (I don't have all day)

The output will look something like:

PORT     STATE  SERVICE  VERSION
22/tcp   open   ssh      OpenSSH 8.9p1
80/tcp   open   http     nginx 1.20.1
443/tcp  open   https    nginx 1.20.1
8080/tcp closed http

The numbers on the left are ports — think of them as doors into the server. The service is what's behind that door. The version is what you actually care about, because versions tell you what vulnerabilities might exist.

How AI helped me here: I literally copied that table into ChatGPT and asked "what should I investigate next?" It pointed me to the nginx version being outdated and suggested specific NSE scripts to run.

A Few Scans You'll Actually Use

# Full port scan — slow but thorough
sudo nmap -sV -T4 -p- target.com

# Vulnerability check — nmap checks known issues
sudo nmap -sV --script=vuln target.com

# Web-focused — only look at web ports
sudo nmap -sV -p 80,443,8080,8443,3000 --script=http-* target.com

# Stealth — slower but less obvious
sudo nmap -sS -T1 -f target.com

The --script=vuln flag is where nmap goes from "port scanner" to "vulnerability detector." It runs hundreds of checks against your target.

Recon: Playing Detective

Reconnaissance is just a fancy word for "find out everything you can before touching the target." I split it into two parts:

The No-Contact Phase (Passive)

You never touch the target's servers. You query public data.

# WHOIS — who owns this domain?
whois target.com

# DNS — what's publicly configured?
dig target.com A +short        # IP address
dig target.com MX +short       # Mail servers
dig target.com NS +short       # Name servers

# Tech stack — what are they running?
whatweb target.com

# Historical data — what did this site look like before?
# https://web.archive.org/web/*/target.com

I once found an old admin panel URL in the Wayback Machine that had been taken down but was still accessible. Not a major finding, but it made me feel like a detective.

The Direct Phase (Active)

Now you actually talk to the target — but gently.

# Check the headers — they tell you so much
curl -sI "http://target.com" | grep -iE '(server|x-powered|set-cookie)'

# Check the SSL certificate
echo | openssl s_client -connect target.com:443 2>/dev/null | openssl x509 -noout -dates -subject

What to look for: The Server header tells you the web server and version. X-Powered-By tells you the framework. Set-Cookie tells you how sessions work. Missing security headers (CSP, HSTS, X-Frame-Options) are worth noting — they're low-hanging fruit.

Enumeration: Poking Around

If recon is about finding the front door, enumeration is about finding every door. Hidden pages, admin panels, backup files, subdomains — they're all out there, and bruteforcing is how you find them.

Finding Hidden Pages

ffuf is the fastest tool for this. Give it a wordlist and a target, and it tries every word:

ffuf -u "http://target.com/FUZZ" \
  -w /usr/local/share/seclists/Discovery/Web-Content/common.txt \
  -t 100 -c -fc 404
  • FUZZ is where ffuf inserts each word
  • -fc 404 filters out "not found" responses
  • -t 100 runs 100 concurrent requests

Status codes you'll see:

  • 200 — page exists and is accessible
  • 301/302 — redirect (still exists)
  • 401/403 — exists but locked down (interesting!)
  • 500 — server error when accessing it (also interesting)
  • 404 — not found (ignore)

Finding Subdomains

Sometimes the real app lives at admin.target.com or dev.target.com:

gobuster dns -d target.com \
  -w /usr/local/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  -t 50

Framework-Specific Checks

If you found Next.js in the headers (I see it everywhere as a frontend dev):

# This lists every page in the Next.js app
curl -s "http://target.com/_next/static/*/_buildManifest.js"

# Check for source maps (original uncompiled source)
curl -sI "http://target.com/_next/static/chunks/pages/*.js.map"

WordPress:

curl -sI "http://target.com/wp-admin/"
curl -sI "http://target.com/.wp-config.php"

Laravel:

curl -sI "http://target.com/.env"
curl -sI "http://target.com/storage/"

Reading JavaScript Like a Pro

Frontend JavaScript is a goldmine. Every API endpoint the app calls, every route it supports, sometimes even hardcoded API keys — it's all sitting in plain text in the browser.

# Download all JS files from the page
curl -s "http://target.com" | grep -oE 'src="[^"]+\.js"' | sed 's/src="//;s/"//' | while read js; do curl -s "http://target.com$js" >> all.js; done

# Find API endpoints
strings all.js | grep -E '/api/|/auth/|/graphql|/v1/' | sort -u

# Find secrets (don't get your hopes up, but check)
strings all.js | grep -iE '(api[_-]?key|secret|token|password)'

The really juicy find: Source maps (.js.map files). If they're exposed, you get the original uncompiled source code with comments, descriptive variable names, everything. Check for them even when you don't expect to find them — I've been surprised before.

Finding the API

Once you've identified the API base URL from the JavaScript, confirm it works:

for prefix in /api /api/v1 /v1 /rest /graphql /server /backend; do
  echo -n "$prefix => "
  curl -sI -o /dev/null -w "%{http_code}" "http://target.com$prefix"
  echo
done

If you get 405 (Method Not Allowed) — that means the endpoint exists but you're using the wrong HTTP method. That's actually a find.

The real jackpot is OpenAPI docs:

curl -sI "http://target.com/server/docs"
curl -sI "http://target.com/server/openapi.json"

If those return 200, you've found the entire API specification — every endpoint, every parameter, every auth requirement, all documented for you. Download it, parse it, understand the whole attack surface.

Breaking Authentication

This is where things get interesting. Most of the time you'll find nothing — properly built apps have rate limiting, proper password hashing, and session management. But when they don't, here's what you check.

Rate Limiting

for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST \
    "http://target.com/api/login?username=admin&password=test$i"
done | sort | uniq -c

If you don't see any 429 responses, the app has no rate limiting. That means you (or a real attacker) can try passwords all day.

User Enumeration

curl -s -X POST "http://target.com/api/login?username=real@email.com&password=wrong"
curl -s -X POST "http://target.com/api/login?username=fake123@nothing.com&password=wrong"

If the error messages are different ("User not found" vs "Invalid password"), an attacker can figure out which emails are registered. It's a small thing, but it makes social engineering much easier.

SQL Injection (the classic)

# The simplest test
curl -s "http://target.com/api/login?username=admin'%20OR%20'1'%3D'1&password=test"

If this returns a successful login, you've found a SQL injection. This is rare in 2026 but still exists in older or poorly maintained apps.

IDOR — The Most Common Bug I've Found

Insecure Direct Object Reference is exactly what it sounds like: you can access someone else's data just by changing a number in the URL.

curl -s "http://target.com/api/users/1" -b "session=valid"
curl -s "http://target.com/api/users/2" -b "session=valid"
curl -s "http://target.com/api/users/3" -b "session=valid"

If user 1 can see user 2's profile by changing 1 to 2, that's an IDOR. I've found this more often than any other bug.

Letting the Robots Do the Heavy Lifting

After you've done the manual exploration, run the automated scanners. They find things you'll miss:

# Fast web server scan
nikto -h http://target.com

# Template-based scanning (hundreds of checks)
nuclei -u http://target.com

# SQL injection automation
sqlmap -u "http://target.com/page?id=1" --batch

Important: Scanners produce noise. Lots of it. Don't report everything they find — manually verify each finding. False positives are common, and nothing ruins your credibility like reporting a vulnerability that doesn't actually exist.

Checking for Known Vulnerabilities

Once you know the software and versions, check if there are known CVEs:

# nmap can do this automatically
nmap --script vulners -sV target.com

# Or check manually:
searchsploit nginx 1.20
searchsploit fastapi

Output shows if any services have known exploits. You're not finding new bugs — you're checking if they forgot to patch old ones.

My flow for a new target: nmap quick check → dig deeper → enumerate directories and subdomains → read JS → test API → auto scan → CVE check.

When I get stuck — which is often — I ask AI. "What does this nmap result mean?" "Is there a way to bypass this auth?"

Most bugs aren't fancy. Buffer overflows make headlines but I've found more just changing a number in a URL and seeing someone else's data. That's it.

Document what you run. I didn't at first and kept re-running the same scans because I forgot the flags.

AI is good for explaining stuff you don't get. It's not good at replacing the part where you actually have to understand what you're doing. Use it to unstick yourself, not to think for you.

If you're a developer curious about security — pick one target you own, run nmap on it, and see what comes back. Google the things you don't understand. That's how everyone starts.