Kali Linux Ethical Hacking, Part 5: Keeping Kali Healthy and Updated
Series: Kali Linux Ethical Hacking, Part 5. Previous: Part 4, thinking like a defender with Kali. Start of the series: Part 1, a safe practice lab.
You keep Kali healthy by taking a snapshot first, checking that your APT sources file matches Kali’s default, keeping the archive keyring current, running a full upgrade, rebooting when asked, and freezing updates during an authorized engagement. A short monthly routine on your own lab VM keeps tools working and avoids surprise breakage.
First, the legal bit
Disclaimer: This post is for education and authorized security testing only. Accessing or scanning a computer, network or account without permission is illegal, including under India’s Information Technology Act, 2000 and similar laws in other countries. Only test systems you own, or systems where you have clear written permission from the owner before you start.
This part only touches your own Kali VM and its update servers. No scanning of anyone else is involved.
Why does Kali need regular care?
Kali is a rolling distribution. Packages arrive continuously, not just at release time, and that is both its strength and its risk.
What Kali itself recommends
Kali’s Updating Kali page (updated 14 May 2026) says a default install should check for updates every few days or weeks. It also warns that, as a rolling release, issues sometimes sneak in and break a tool. Its advice: make sure all tools work before an engagement, and don’t update during one. Kali releases four times a year on a loose quarterly schedule.
Where things stand today
As of 24 October 2026, the newest release post on the Kali blog is still Kali 2026.2, from 29 June 2026. That release retired /etc/apt/sources.list in favour of /etc/apt/sources.list.d/kali.sources, and noted that the polkit upgrade needs a reboot. Both points shape the routine below. If a newer release appears, the same steps apply.
What do you need before you start?
- Your Kali VM from Part 1, with internet through its NAT adapter.
- VirtualBox on your computer (the snapshot commands use
VBoxManage; VMware has the same feature in its menus). - About 30 minutes, plus download time.
- A notes folder:
mkdir -p ~/lab-notes/$(date +%F)/maintenance
How do you prepare before updating?
Step 1: Take a snapshot
Shut Kali down, then on your computer (not inside Kali) run, using your own VM name:
VBoxManage snapshot "kali-linux-2026.2" take "pre-update-$(date +%F)"
VBoxManage snapshot "kali-linux-2026.2" list
Expected output: a progress bar to 100 percent, then a list showing your new snapshot name. If an update ever goes badly, you can restore it with the VM off:
VBoxManage snapshot "kali-linux-2026.2" restore "pre-update-2026-10-24"
Step 2: Record your current state
Start Kali and save a quick picture of where you are:
cd ~/lab-notes/$(date +%F)/maintenance
grep VERSION /etc/os-release | tee 01-version.txt
uname -r | tee -a 01-version.txt
dpkg -l | wc -l | tee -a 01-version.txt
Expected output (sample): a line such as VERSION="2026.2", your kernel version (6.19 on a fresh 2026.2 install, according to the release notes), and a count of installed packages.
How do you check your APT sources and keyring?
Step 3: Compare your sources file with Kali’s default
Kali’s network repositories page (updated 8 May 2026) gives the expected content for a clean install:
grep -v '^#' /etc/apt/sources.list.d/kali.sources
Expected output:
Types: deb
URIs: http://http.kali.org/kali/
Suites: kali-rolling
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg
The same page warns that if your output doesn’t match, you may not be able to install packages or get updates.
Step 4: Convert an older install if needed
If that file doesn’t exist and you only have the old /etc/apt/sources.list, the same Kali page shows how to convert it:
sudo apt update
sudo apt modernize-sources
Expected output: APT lists /etc/apt/sources.list as needing modernizing, explains that it will save the old file as a .list.bak, and asks Rewrite 1 sources? [Y/n]. Answer y, and it reports writing /etc/apt/sources.list.d/kali.sources. Run Step 3 again to confirm.
Step 5: Check the archive keyring
Kali’s GPG key expiry page (updated 21 Jul 2025) explains that every two to three years the team extends or replaces the key that signs the repository, so systems with an old kali-archive-keyring package start failing. Check yours:
apt policy kali-archive-keyring | head -3
Expected output: an installed version matching the candidate. On 24 Oct 2026 the Kali package tracker listed 2025.3 in kali-rolling.
If apt update ever fails with a message like Missing key ... which is needed to verify signature, the same page gives the fix of downloading the current key from Kali’s archive:
sudo wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpg
Use this only when you see that error. The page also notes that an install more than two years old may no longer be supported.
How do you run the upgrade safely?
Step 6: Update and upgrade
These are the two commands from Kali’s updating page:
sudo apt update 2>&1 | tee 02-apt-update.txt
sudo apt full-upgrade -y 2>&1 | tee 03-full-upgrade.txt
Expected output: apt update ends with a line about how many packages can be upgraded. full-upgrade downloads and installs them and returns to the prompt without red E: error lines.
Step 7: Look for reboot hints
The 2026.2 notes pointed out that the polkit reboot hint was easy to miss in the upgrade log. Search for it:
grep -i "reboot" 03-full-upgrade.txt
ls /var/run/reboot-required 2>/dev/null && echo "Reboot needed"
Expected output: either nothing, or one or more lines asking for a reboot. If you see any, reboot:
sudo reboot
Step 8: Clean up
sudo apt autoremove -y
sudo apt clean
df -h / | tee 04-disk.txt
Expected output: a list of removed packages (possibly none), then disk usage for the root filesystem. Keep at least a few GB free so the next upgrade doesn’t fail midway.
How do you check that your tools still work?
Step 9: Run a quick tool check
After the reboot, confirm the tools from this series still start. Each command only prints a version and touches nothing else:
cd ~/lab-notes/$(date +%F)/maintenance
for c in "nmap --version" "lynis --version" "olevba -h"; do echo "== $c"; $c 2>&1 | head -2; done | tee 05-tools.txt
Expected output (sample): a short version or banner line under each heading, for example Nmap 7.991 from Kali’s package (see Part 2). If a tool errors, restore the snapshot from Step 1 or check the Kali bug tracker before your next lab session.
Step 10: Run one lab smoke test
Point one known scan at your own lab target, as in Part 2, and compare it with an old result:
sudo nmap -sV --top-ports 20 192.168.56.101 -oA 06-smoke-test
Expected output: the same open ports as your last saved scan of that target. Use your own lab address, never anything outside your lab.
When should you not update, and what about experimental packages?
Freeze during engagements
Following Kali’s advice, update and test before an authorized engagement starts, take a snapshot, and then leave the VM alone until it ends. A broken tool halfway through a test costs more than a missed update.
Trying newer kernels or tools
The 2026.2 release notes said the Linux 7.0 kernel was available through kali-experimental, while the release stayed on 6.19 because of NVIDIA driver issues. Enabling extra branches is covered on Kali’s repositories page. Only try it on a snapshot you can roll back, and never on a VM you need for real work.
What should your monthly routine look like?
Copy this into your notes and tick it off each month:
[ ] Snapshot taken (Step 1)
[ ] Version recorded (Step 2)
[ ] kali.sources matches default (Step 3)
[ ] kali-archive-keyring current (Step 5)
[ ] apt update and full-upgrade clean (Step 6)
[ ] Rebooted if asked (Step 7)
[ ] Cleaned up, disk space OK (Step 8)
[ ] Tools and smoke test OK (Steps 9 and 10)
[ ] Old snapshots deleted, keeping the last two
To delete an old snapshot, with the VM off:
VBoxManage snapshot "kali-linux-2026.2" delete "pre-update-2026-09-24"
What to do next
- Take a snapshot of your Kali VM today and name it with the date.
- Run Steps 2 to 8, saving every output in your maintenance folder.
- Run the tool check and one smoke test against your own lab target.
- Save the monthly checklist and set a reminder for the same date next month.
- Before any authorized engagement, run the routine, snapshot, and then freeze updates.
- Go back to Part 4 and rerun its Lynis audit after upgrading, to see what changed.
- For new open source tools worth adding to your kit, browse my security GitHub repos roundup for October 2026.
Next, in Part 6, we capture and read this lab’s traffic with Wireshark. If you’d like to add AI to the same lab, the AI-Powered Ethical Hacking (GitHub + Agent Skills) series picks up from here.
Once your Kali is up to date, put it to work reading your own lab traffic in Part 6, Wireshark lab traffic.
Leave a comment