Kali Linux Ethical Hacking, Part 4: Thinking Like a Defender
Series: Kali Linux Ethical Hacking, Part 4. Previous: Part 3, web app testing basics on OWASP Juice Shop. Next: Part 5, keeping Kali healthy and up to date.
You use Kali defensively by pointing its tools at systems you own: you list what listens on your own machine, scan your own lab target for exposed services, audit your Kali VM with Lynis, check a suspicious Office file with oletools, and turn every finding into a short, prioritised fix list someone can act on.
First, the legal bit
Disclaimer: This post is for education and authorized security testing only. Scanning, auditing or accessing a computer, network or account without permission is illegal, including under India’s Information Technology Act, 2000 and similar laws in other countries. Only check systems you own, or systems where you have clear written permission from the owner before you start.
Everything below runs on your own Kali VM and the practice target from Part 1, on a host only network. If a device or file isn’t yours, leave it alone.
Why should an ethical hacker think like a defender?
The first three parts were about finding things: live hosts, open ports, weak spots in a web app. That work only matters if someone fixes what you found. A test that ends with a list of problems and no plan is half a job.
Offensive tools, defensive goals
The same Nmap scan that maps a target can show you what your own machines expose. My day job sits close to network detection and response, and from that side the most useful report is a short one that says what is open, why it matters and what to change first.
What you’ll build in this part
By the end you will have run four checks on systems you own and written them into a one page fix list. The checks are: local listeners, an Nmap view from the lab network, a Lynis audit of Kali itself, and an oletools check of an Office file.
Which tool versions are current?
As of 23 October 2026, these are the versions on primary sources:
- Kali Linux: the newest release post on the Kali blog (checked 23 Oct 2026) is still Kali 2026.2, from 29 June 2026. That release added oletools to the Kali repositories.
- Lynis: the CISOfy/lynis repository lists 3.1.7, released 25 June 2026 (GitHub API, checked 23 Oct 2026). It is GPL 3.0 licensed, and Kali rolling ships
3.1.7-1, according to the Kali package tracker. - oletools: the latest release is 0.60.2, from 2 July 2024, on both PyPI and GitHub (checked 23 Oct 2026). Kali rolling has
0.60.2-0kali1, according to the package tracker. The release is older, but the repository saw commits as recently as February 2026. - Nmap: 7.992 upstream, as covered in Part 2.
What do you need before you start?
- Your Kali 2026.2 VM, updated and rebooted.
- Your practice target from Part 1 on the host only network. The examples use
192.168.56.101; replace it with yours. - Internet on Kali’s NAT adapter for the installs only.
- A notes folder for today:
mkdir -p ~/lab-notes/$(date +%F)/defender
cd ~/lab-notes/$(date +%F)/defender
How do you audit services on machines you own?
Step 1: Install the tools
sudo apt update
sudo apt install -y lynis oletools nmap
lynis --version
Expected output: apt installs or confirms the packages, and lynis --version prints 3.1.7 or newer.
Step 2: List what listens on your own Kali VM
Start from the inside. On Kali, run:
sudo ss -ltnup | tee 01-listeners.txt
Expected output (sample, yours will differ):
Netid State Local Address:Port Peer Address:Port Process
tcp LISTEN 127.0.0.1:5000 0.0.0.0:* users:(("python3",...))
tcp LISTEN 0.0.0.0:22 0.0.0.0:* users:(("sshd",...))
Read each line and ask two questions. Does this need to run? Does it need to listen on every address (0.0.0.0), or would 127.0.0.1 do? A service on 127.0.0.1 only answers your own machine. A service on 0.0.0.0 answers anything that can reach it.
Step 3: See your target the way the network sees it
Now look at your own practice target from Kali, as Part 2 taught:
sudo nmap -sV --top-ports 100 192.168.56.101 -oA 02-target-exposure
Expected output (sample for a Juice Shop target):
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH (version shown here)
3000/tcp open http (web app details or a fingerprint)
For each open port, write one line in your notes: what it is, who needs it, and whether it should be reachable from the lab network at all.
Step 4: Audit Kali itself with Lynis
The Lynis README (checked 23 Oct 2026) describes it as a security auditing tool that runs on the system itself, tests security defences and gives tips for further hardening. Run it on your own Kali VM:
sudo lynis audit system --quick | tee 03-lynis.txt
Expected output (sample, numbers will differ): a long series of sections with [ OK ], [ WARNING ] and [ SUGGESTION ] markers, ending with a summary block like:
Hardening index : 62 [############ ]
Tests performed : 250
Then pull out the parts you’ll act on. Lynis also writes every finding to its report file, each on its own line:
sudo grep -E "^(warning|suggestion)\[\]" /var/log/lynis-report.dat | head -20
Expected output (sample format): lines such as suggestion[]=SSH-7408|Consider hardening SSH configuration|..., each starting with a test ID. Don’t try to fix everything. Pick the three that apply to how you actually use this VM.
How do you check a suspicious Office file with oletools?
Macro laden Office documents remain a common way in. oletools lets you look inside a file without opening it in Office. The oletools README (checked 23 Oct 2026) describes three tools we’ll use: oleid to spot characteristics often found in malicious files, olevba to extract and analyse VBA macro code, and mraptor to detect malicious VBA macros.
Step 5: Make a safe test file
Never download malware samples to practise. Create a harmless document of your own instead:
sudo apt install -y libreoffice-writer
echo "Quarterly lab notes. Nothing to see here." > note.txt
soffice --headless --convert-to docx note.txt
ls -l note.docx
Expected output: a line saying note.txt was converted, then note.docx listed with its size.
Step 6: Run oleid
oleid note.docx | tee 04-oleid.txt
Expected output (sample): a table of indicators such as file format, container format, encryption and VBA macros, each with a value and a risk level. For your clean file, VBA macros should show as none and the risk column should stay low.
Step 7: Run olevba and mraptor
olevba note.docx | tee 05-olevba.txt
mraptor note.docx | tee 06-mraptor.txt
Expected output (sample): olevba ends with the line No VBA or XLM macros found., and mraptor puts the file in its No Macro result row. That is what a clean file looks like. Keep these outputs as your baseline.
Step 8: Use it on a real file you received
The next time you get an unexpected Office attachment in your own mailbox, save it to your Kali VM without opening it, and run Steps 6 and 7 on it. If olevba lists macros, especially ones that run automatically when the file opens, or mraptor flags it as suspicious, don’t open it. Report it to whoever runs your email security. Only analyse files you received yourself or are authorized to handle.
How do you write a fix list someone will act on?
Findings without priorities get ignored. A one page fix list works better than a long report.
Step 9: Create the fix list
cat > 07-fix-list.md <<'FIX'
# Fix list, DATE
| # | Finding | Where | Why it matters | Fix | Priority |
|---|---------|-------|----------------|-----|----------|
| 1 | | | | | High |
| 2 | | | | | Medium |
| 3 | | | | | Low |
Evidence: 01-listeners.txt, 02-target-exposure.*, 03-lynis.txt, 04 to 06 oletools outputs
FIX
sed -i "s/DATE/$(date +%F)/" 07-fix-list.md
cat 07-fix-list.md
Expected output: the table printed back with today’s date in the heading.
Step 10: Fill it in with plain words
Write each row for someone who wasn’t there. For example: “SSH listens on all addresses on the Kali VM. Anyone on the lab network can try to log in. Bind it to the host only address or turn it off when not needed. Medium.” Rank by what an attacker could do with it, not by how scary the tool output looks.
Step 11: Check your fixes
After you change something, run the same check again and save it with a new name, for example 02-target-exposure-after. Comparing before and after files is the simplest proof that a fix worked.
You can also prove a fix with packets: capture your lab traffic before and after and look for the resets.
What to do next
- Run Steps 1 to 4 on your own Kali VM and practice target, and save every output.
- Make the safe test document and run oleid, olevba and mraptor on it to learn what clean looks like.
- Fill in a three row fix list and apply one fix.
- Re run the matching check and keep the before and after files side by side.
- For more open source tools on the defending side, browse my security GitHub repos roundup for October 2026.
- If you’d like an AI agent to help summarise findings, the hands on MCP setup for Kali shows how to keep it inside your lab.
In Part 5, we keep Kali itself in shape with snapshots, the new sources file and a monthly routine: keeping Kali healthy and updated.
Leave a comment