Kali Linux Ethical Hacking, Part 7: Auditing Your Own Lab Passwords
Series: Kali Linux Ethical Hacking, Part 7. Previous: Part 6, reading your own lab traffic with Wireshark. Earlier: Part 4, thinking like a defender.
You audit passwords safely by creating a weak test account on your own Kali VM, extracting only that account’s hash, running John the Ripper against it with a local wordlist, recording the result as a finding, then fixing the password and confirming the hash no longer matches. This Kali Linux password audit never leaves your lab.
Where we are: This is still the Part 1 lab: Kali at 192.168.56.102 and lab-web-01 at 192.168.56.101 running Juice Shop on a host only network. Parts 2 to 5 mapped that lab, tested Juice Shop, wrote a defender fix list and kept Kali updated. In Part 6 you captured that same link with tshark and, if your Part 4 fix list closed port 3000, proved it with packets. Now you turn to passwords on Kali itself.
First, the legal bit
Disclaimer: This post is for education and authorized security testing only. Cracking or attempting to recover passwords for accounts you don’t own, or accessing any computer, network or account without permission, is illegal, including under India’s Information Technology Act, 2000 and similar laws in other countries. Only work with password hashes from systems you own, or systems where you have clear written permission from the owner before you start. Never dump or crack hashes from production systems you don’t control.
Everything below uses a test account you create yourself on your own Kali VM from Part 1. Delete it when you’re done.
Why audit passwords you already control?
A weak password on a lab VM is a finding, not a crime. Finding it yourself before anyone else does is the point of this series. Parts 2 to 6 showed you how to see what’s open and what crossed the wire. This part asks a different question: would a stolen hash from your own machine survive a common wordlist?
My day job sits close to network detection and response. Credential theft is still one of the most common ways in, and a short password audit of your own accounts is one of the cheapest ways to close that door.
Which tools and versions are current?
Checked on 26 October 2026:
- John the Ripper on Kali: the package tracker lists
1.9.0-Jumbo-1+git20211102-0kali11in kali-rolling. That “Jumbo” build is the community version with many extra formats, and it’s the package this post uses. - Hashcat: the hashcat.net download page lists v8.0.0, dated 25 October 2026. Kali rolling still has
7.1.2+ds1-4according to the Kali package tracker. Hashcat is the GPU option when you have one. This post sticks to John on the CPU so the lab works without a graphics card. - Wordlists: Kali ships
rockyou.txtunder/usr/share/wordlists/, usually gzipped. Use only against hashes you own.
What do you need before you start?
- Your Kali VM, updated with the routine from Part 5.
- John installed (Step 1).
- A notes folder:
NOTES=~/lab-notes/$(date +%F)/password-audit
mkdir -p "$NOTES" && chmod 700 "$NOTES"
cd "$NOTES"
Keep this folder private. Hash files and cracked passwords are sensitive, even in a lab.
How do you create a safe test account on your own Kali?
Step 1: Install John and prepare the wordlist
sudo apt update
sudo apt install -y john wordlists
john --list=build-info | head -5
Expected output (sample): a line naming John the Ripper and a Jumbo build date. Then unpack rockyou if needed:
sudo gunzip -k /usr/share/wordlists/rockyou.txt.gz 2>/dev/null || true
ls -lh /usr/share/wordlists/rockyou.txt | awk '{print $5, $9}'
Expected output (sample): a size around 133M and the path. The -k keeps the gzipped copy.
Step 2: Create a throwaway lab account with a weak password
Use a password you know is bad, on purpose, and only for this test:
sudo useradd -m -s /bin/bash labaudit
echo 'labaudit:password123' | sudo chpasswd
id labaudit
Expected output:
uid=1001(labaudit) gid=1001(labaudit) groups=1001(labaudit)
Your uid may differ. Do not reuse this password anywhere else.
Step 3: Extract only that account’s hash
Never copy your whole /etc/shadow. Extract the one line for labaudit:
sudo getent shadow labaudit | tee labaudit.hash
chmod 600 labaudit.hash
cat labaudit.hash
Expected output (sample):
labaudit:$y$j9T$................$................:20320:0:99999:7:::
The $y$ prefix means yescrypt, which modern Kali uses. Older installs may show $6$ for sha512crypt. Both are fine for this exercise. The file mode 600 keeps it readable only by you.
How do you run John against your own hash?
Step 4: Start a wordlist attack
john --wordlist=/usr/share/wordlists/rockyou.txt labaudit.hash 2>&1 | tee john-run.txt
Expected output (sample): progress lines, then something like:
password123 (labaudit)
1g 0:00:00:01 DONE
Times vary with your CPU. If John finishes with no password found, the wordlist didn’t contain it, which for password123 would be surprising. Check the hash file and try Step 5.
Step 5: Show the cracked password
john --show labaudit.hash | tee john-show.txt
Expected output (sample):
labaudit:password123:20320:0:99999:7:::
1 password hash cracked, 0 left
That line is your finding: this account’s password was recoverable from a public wordlist. Treat it like any other finding from Part 4.
Step 6: Record it as a fix list row
cat >> "$NOTES/finding.md" <<'FIX'
# F01 password audit, own lab, DATE
Finding: lab account "labaudit" uses a password present in rockyou.txt
Evidence: labaudit.hash (mode 600), john-show.txt
Fix: set a unique passphrase of 16+ characters, or remove the account
Priority: High (credential recovery from a common wordlist)
Status: open
FIX
sed -i "s/DATE/$(date +%F)/" "$NOTES/finding.md"
cat "$NOTES/finding.md"
Expected output: the table printed back with today’s date.
How do you fix it and prove the fix?
Step 7: Change the password to a strong one
echo 'labaudit:correct-horse-battery-staple-lab-only' | sudo chpasswd
sudo getent shadow labaudit | tee labaudit-after.hash
chmod 600 labaudit-after.hash
Use your own long passphrase, not this sample. Store it in a password manager, not in a chat or a screenshot.
Step 8: Confirm the old cracked password no longer matches
john --show labaudit-after.hash
john --wordlist=/usr/share/wordlists/rockyou.txt --max-run-time=30 labaudit-after.hash 2>&1 | tee john-after.txt
Expected output (sample):
0 password hashes cracked, 1 left
and after the short wordlist run, still no cracked password. That is your after evidence. Update the finding:
echo "Status: fixed $(date '+%F %R'); after evidence: labaudit-after.hash, john-after.txt" >> "$NOTES/finding.md"
Step 9: Remove the test account
sudo userdel -r labaudit
getent passwd labaudit || echo "labaudit removed"
Expected output:
labaudit removed
Step 10: Clean up sensitive files
cd "$NOTES"
shred -u labaudit.hash labaudit-after.hash john-show.txt 2>/dev/null
ls -l
Expected output (sample): the finding notes and john run logs remain; the hash files and the cracked password output are gone. Keep finding.md if you want it as evidence, but never paste hashes or cracked passwords into public posts or AI chat tools.
When would you use Hashcat instead?
John is enough for a single lab hash on a laptop CPU. Reach for Hashcat when you have many hashes you own, or a GPU. Upstream Hashcat v8.0.0 shipped on 25 October 2026. Kali’s package is still 7.1.2, so for v8.0.0 you’d download from hashcat.net and check the signature on that page. The same rule applies: only hashes you own or are authorized to test. GPU cracking also draws a lot of power and heat, so keep sessions short on a laptop.
How does this fit the rest of the series?
- Part 2 mapped open services. An open SSH port plus a weak password is a real risk.
- Part 4 asked you to write a fix list. Step 6 above is one more row for that list.
- Part 6 showed you what a scan looks like on the wire. A cracked password is quieter and often more damaging.
- For AI help summarising findings without sending hashes to a cloud model, see the AI-Powered Ethical Hacking series.
What to do next
- Run Steps 1 to 3 and confirm you extracted only the
labauditline. - Crack it with Steps 4 and 5, then write the finding in Step 6.
- Fix, retest and remove the account with Steps 7 to 9.
- Shred the hash files in Step 10.
- Repeat the idea on any other lab only accounts you created for practice, never on shared or production systems.
- Add the finding to the fix list habit from Part 4.
- Keep Kali and John updated with the Part 5 routine.
- For more open source auditing tools, browse my security GitHub repos roundup for October 2026.
Next up: In Part 8 you harden this same Kali host with SSH keys, UFW limited to the host only subnet, and a listen port recheck, so a weak password stops being a way in because password logins over SSH are switched off.
Leave a comment