Kali Linux: What’s in the Latest Release, How Kali Organizes Tools, and the Essential Commands Every Practitioner Uses
A practical tour of Kali’s rolling toolset, metapackages, and a ready-to-run audit script to export every binary into CSV for compliance or red-team/blue-team inventories.
Kali Linux is a rolling distribution that bundles thousands of security tools into categorized metapackages (kali-linux-, kali-tools-). The project publishes an authoritative “All Tools” index and a set of metapackages for curated installs. For day-to-day work, use focused metapackages (e.g., kali-linux-default, kali-tools-wireless, kali-tools-web) and avoid kali-linux-everything unless you want tens of gigabytes of packages. Below: what changed conceptually in the latest snapshots, how the toolset is organized, an actionable list of the most-used commands, and a reproducible script to export a literal CSV of packages → binaries → metapackages for auditing.
Why Kali still matters to practitioners
Kali isn’t just “lots of pentest tools on Debian” — it’s a curated, maintained, practitioner-focused bundle designed to reduce friction for red-teamers, security engineers, and researchers. Kali’s team organizes tools into metapackages (so you can install specific workflows), maintains an “All Tools” catalog that lists package → command mappings, and publishes release snapshots so you can reproduce lab environments or CI images. The rolling model keeps tools fresh but means you should pin snapshots for engagements.
What’s new in the recent snapshots (practical highlights)
Continued improvements to hardware and firmware support (better Wi-Fi and SDR support), plus GPU toolchain packaging to help hashcat & CUDA workflows.
Menu/UX changes to align the tools menu with MITRE ATT&CK categories (helps match tooling to TTPs).
Continued modularization of tools into kali-tools-* groups (wireless, web, passwords, reverse-engineering, etc.), and ongoing maintenance of the kali-linux-* metapackages.
How Kali organizes its toolset (quick map)
Metapackages — kali-linux-default, kali-linux-full, kali-linux-everything, kali-tools-web, kali-tools-wireless, etc. Install what you need. Kali Linux
All Tools index — authoritative list of every tool KALI packages; visible on Kali’s website and includes package → commands mapping. Use it when you need to confirm which command is provided by which package. Kali Linux
Rolling snapshots — keep your images reproducible by using release snapshots for engagements (or pin apt sources). Kali Linux
Tool categories (short list of what’s in Kali)
Recon & mapping: nmap, masscan, amass, dnsenum
Web app testing: burpsuite, sqlmap, nikto, gobuster, wpscan
Wireless / SDR: aircrack-ng suite, nexmon support, gnuradio, rtl-sdr
Passwords: hashcat, john, hydra, hash-identifier
Exploitation: metasploit-framework, searchsploit
Forensics & memory: autopsy, sleuthkit, volatility
Reverse engineering: radare2, ghidra (packaged), capstone
Network sniffing & MITM: wireshark, tcpdump, mitmproxy, ettercap
(For the canonical, exhaustive list consult Kali’s All Tools index.) Kali Linux
The essential commands (the ones you’ll actually type)
Wireless (aircrack-ng flow)
Exploitation & post-exploit
Packet capture & forensics
(Use these responsibly, on scope, and in isolated labs for real work.)
How to install “everything” — and why you usually shouldn’t
Why not? kali-linux-everything pulls everything (tens of GB)—lots of dev packages, unused GUIs, and less-common firmware. Prefer metapackages for targeted installs. Kali Linux
Audit: produce a literal CSV of every binary and which metapackage pulls it
You asked for a literal package list (every binary) exported as CSV/markdown so you can audit what’s installed by each metapackage. Because this list is large and snapshot-dependent, the most accurate way is to generate it from your current apt sources. Below I include:
a ready-to-run bash script that:
enumerates packages pulled by a metapackage (e.g. kali-linux-everything or kali-tools-web)
downloads each package (.deb) from your configured sources, lists the binary files inside (/usr/bin, /bin, /sbin, /usr/sbin)
writes a CSV: metapackage,package,binary_path,command_name,package_version
a sample CSV excerpt (tiny) so you see output format.
instructions to run and how to interpret the CSV.
Script: kali_audit_to_csv.sh
Save as kali_audit_to_csv.sh, make executable (chmod +x kali_audit_to_csv.sh) and run in an empty working directory on the Kali machine as a regular user (it downloads package files — no root required). It will need apt-get network access and enough disk for the temporary .deb files (consider running for a single metapackage first).
Run as a normal user. Script uses apt-cache and apt-get download to fetch the candidate package files and extracts binary listing with dpkg-deb -c.
For a single metapackage run: ./kali_audit_to_csv.sh kali-tools-web web-packages.csv
For everything (be warned): ./kali_audit_to_csv.sh kali-linux-everything everything.csv — this will download many packages and could require tens of GB and significant time. Consider running per-metapackage and merging CSVs.
The script reports candidate versions from your apt cache; make sure sudo apt update was run recently so versions reflect your configured snapshot.
If you want installed-file lists (instead of package contents from repo), replace dpkg-deb -c with apt-file list "$pkg" (requires apt-file update and apt-file installed), or dpkg -L $pkg if package is installed locally.
Sample CSV excerpt (shows format)
Below is a very small sample to show the CSV format (this is illustrative only — generated manually for a few well-known packages):
Run the script and you’ll get a CSV like this but for every package the metapackage depends on.
Interpreting the CSV for auditing
metapackage — the top-level group you asked the script to analyze (e.g., kali-linux-everything, kali-tools-wireless).
package — Debian package name. Installers / dependents in apt are specified against these.
package_version — candidate version from apt (useful to track what snapshot you audited).
binary_path — file path inside the package that is a binary (common binary directories).
command_name — basename you’ll run from shell (use this to check PATH conflicts or command ownership).
You can import the CSV into Excel, Google Sheets, or use pandas to query things like “which packages provide air* commands” or “which packages added SUID binaries” (filter /usr/bin vs /sbin and run dpkg-deb -c output through stat if you download .debs).
Kali All Tools (authoritative index of packaged tools and their commands). Kali Linux
Kali Metapackages (explanation and list of kali-tools-* groups). Kali Linux
Kali docs on updating/rolling snapshots and installation sizes.
Final notes — honest scope statement
I didn’t hard-copy every binary from the Kali site into the blog because the data is huge and snapshot-dependent; instead I gave you a robust, reproducible way to generate an authoritative CSV tied to your apt sources (so the audit is accurate for your environment). If you want, I can run a one-off scrape of Kali’s “All Tools” page and attempt to build a large CSV here in-chat — but that will produce a snapshot that may differ from your apt sources and the file will be very large. The script above is the safest, most accurate approach. Kali Linux
