36. More Essential Kali Tools
Chala mitrano, Part 10 madhe aapan Nmap, Burp, Metasploit, Hydra sarkhe mothe tools shiklo. Pan professional pentester chya toolkit madhe ajun kahi chote pan khup kaamache tools astat: FFUF (vegvaan fuzzing), Amass (subdomain shodh), WhatWeb (website kuthlya technology var chalte), Netcat/Socat (network cha "Swiss army knife") ani Bettercap (network MITM lab). Pratyek tool aapan fakt aaplya lab var vaparu ani tyacha bachav pan shiku. Samjla ka? Chala!
What you will learn in this chapter
- FFUF for fast directory, parameter and virtual host fuzzing
- Amass for subdomain discovery (passive and active)
- WhatWeb and Wappalyzer for technology fingerprinting
- Netcat and Socat for connections, file transfer, listeners and relays
- Bettercap for network reconnaissance and MITM in a lab
- How defenders detect and stop each of these
Lab scope
Run every command only against your host-only lab (Kali 192.168.56.10, Metasploitable/DVWA 192.168.56.20, Chapter 18) or domains you own. Fuzzing, subdomain brute force and MITM against others' systems is illegal.
Concepts in this chapter
- 36.1FFUF: Fast Web Fuzzing
- 36.2Amass: Subdomain Discovery
- 36.3WhatWeb and Wappalyzer: Technology Fingerprinting
- 36.4Netcat and Socat: The Network Swiss Army Knife
- 36.5Bettercap: Network Recon and MITM (Lab)
- 36.6Defence Checklist for These Tools
- 36.7Red vs Blue, Project and Real Incidents
The chapter recap is at the end of the last concept page.
Chapter 36: More essential Kali tools — practice tasks
Open chapter lessons · Full guided lab: defensive command cheat sheet tested (not repeated here)
36.1 netcat listener on localhost
EasyITWhy: nc is a Swiss army knife — practise safely.
What: Send a file over loopback.
How:
- Terminal A:
nc -l 127.0.0.1 4444 > out.txt - Terminal B:
echo hello | nc 127.0.0.1 4444 - cat out.txt
Expected output: out.txt contains hello.
Hint
Bind only to 127.0.0.1.
Answer / how to check
- File matches.
36.2 curl for headers and methods
EasyRetailWhy: curl replaces many GUI clicks.
What: Probe your lab site.
How:
- curl -sI http://127.0.0.1/
- curl -s -X OPTIONS -i http://127.0.0.1/
- Note Allow and Server headers.
Expected output: Status and header lines printed.
Hint
Compare with browser DevTools.
Answer / how to check
- You wrote Server and any Allow methods.
36.3 tmux for long scans
EasyLogisticsWhy: SSH drops kill long jobs without a multiplexer.
What: Run a command inside tmux.
How:
- tmux new -s lab
- Start ping -c 100 127.0.0.1.
- Detach Ctrl-b d; tmux attach -t lab.
Expected output: Ping still running after attach.
Hint
Name sessions by task.
Answer / how to check
- Session lab listed in tmux ls.
Extended teaching notes
Why this lesson matters
Kali tools are dual-use. In this course every run ends with a defensive note: what config would have blocked or detected the activity on a system you own.
Rule
Host-only lab, written scope, no bridging onto real LANs.
Mini case study
Suppose we are on a purple-team exercise for an Indian mid-size company (sample data). Red notes a technique from this lesson against a lab clone. Blue must show the control that stops it, the log that would have fired, and the ticket that hardens production. That is the standard this course trains you for.
Defender's worksheet (do this today)
- Write the lesson title, date and the exact lab target you are allowed to use.
- List three owned systems (VMs, apps, or cloud accounts) where this lesson applies.
- Run one safe check from the lesson on a lab system only. Paste the command and output.
- Write a two-sentence fix you would give a teammate.
- Name one related public advisory (CERT-In, CISA, NVD, or a vendor bulletin) with its date.
Indian workplace (sample data)
Suppose we are a junior analyst at Infosys, TCS, Wipro or a fintech SOC in Bengaluru/Pune. Turn this lesson into one checklist item with an owner, a due date and a place to store evidence (ticket + screenshot).
Global practice
Compare your notes with OWASP, CIS Benchmarks, NIST CSF/IR guidance or a cloud Well-Architected security question. Write five lines on what overlaps.
Everyday analogy
Explain the risk and the fix to a family member without jargon. If they can repeat the warning, you understand it well enough to teach juniors.
Key terms
- Control: a safeguard (patch, config, process, detection).
- Finding: a weakness backed by evidence.
- Remediation: the fix plus how you verified it.
- Scope: systems you have written permission to touch.
- Least privilege: only the access the task needs.
- Defence in depth: several layers so one failure does not end the story.
Common mistakes
- Skipping written permission "just for a quick scan".
- Practising on hostel, office or public targets without authorisation.
- Collecting tool output without writing the fix.
- Copying attack steps onto production to "verify". Defenders verify with versions, configs and patches.
- Publishing screenshots that contain secrets, cookies or internal hostnames.
Recap
- Evidence, fix, owner, date.
- Own lab only.
- Fix > spectacle.
Extra depth
Re-read the original short section at the top of the page, then this expansion. Together they should exceed a solid lesson length. If anything still feels thin, add your own lab screenshot and a paragraph in your notebook — that personal evidence is what interviews ask for.
- Permission before tools.
- Patch and config before exploits.
- Logs and backups before blame.
- Teach one junior the warning from this page.
Ethics reminder: every technique on this page is for labs you own or programmes that list the target. Safe simulation means isolated networks, written scope, and a written defensive fix afterwards — never traffic aimed at the public internet or a neighbour's Wi-Fi.
Interview angle: be ready to explain detection (which log line fires) and prevention (which config stops it) in two minutes without naming attack payload details.