kali-linux

name	kali-linux
description	· Administer Kali: apt, branches, metapackages, images, live USB persistence, NetHunter, wireless/GPU. Triggers: 'kali', 'kali rolling', 'kali snapshot', 'kali-tweaks', 'nethunter'. Not for exploitation (use lockpick).
license	MIT
compatibility	Requires Kali Linux or Kali images with apt and Kali repositories
metadata	{"source":"iuliandita/skills","date_added":"2026-04-22","effort":"high","argument_hint":"[issue-or-workflow]"}

Kali Linux: Kali Administration, Tooling, and Lab Workflow

Administer Kali Linux without flattening it into plain Debian or into a bag of offensive tools. Start by identifying which Kali lane you are actually on - rolling install, last-snapshot, live USB, VM image, Purple image, NetHunter, or a throwaway lab box - then separate base OS health from tool-selection questions, branch hygiene, hardware support, and engagement scope. Kali is Debian-shaped, but the places where it goes wrong are usually Kali-specific: branch mixing, metapackage sprawl, stale images, persistence mistakes, hardware edge cases, or people using the wrong tool family for the job.

Versions worth pinning (verified May 2026):

Only pin versions or dated anchors here when they materially affect compatibility or troubleshooting shape. For ordinary package work, prefer the live branch and repo state over a stale package table.

Component	Version or date	Why it matters
Current dated Kali image release	2026.1	current image baseline and release notes
Branch docs	May 2026 recheck / verify live	branch behavior and safe lane selection matter more than a single package version
Metapackage docs	2025-07 / verify live	tool-family grouping and install scope matter more than memorizing one package list
Kali 2026.1 kernel lane	6.18	release-image baseline for hardware and driver expectations

When to use

• Package management on Kali with apt, dpkg, apt-cache, repo sanity checks, keyrings, or branch validation
• Kali image and install questions: live ISO, netinst, ARM and SBC images, VM images, persistence, and recovery
• Kali branch and source-list questions: kali-rolling, kali-last-snapshot, selective branch use, and mirror hygiene
• Metapackage planning: kali-linux-default, kali-linux-everything, focused kali-tools-* bundles, desktop metapackages, and kali-tweaks
• Selecting the right Kali tool family for the job before installing half the archive by accident
• Kali desktop and laptop work: Xfce, GNOME, KDE, i3, PipeWire, GPU drivers, capture tooling, and VM guest behavior
• Wireless, SDR, Bluetooth, RFID, HID, USB, and offensive-hardware support that is really a Kali host or package problem
• NetHunter and mobile-adjacent Kali questions where the issue is image, package, kernel, or host-tooling shape rather than exploit technique
• Safe lab setup, intentionally vulnerable practice targets, snapshot workflow, and separation between lab and production systems
• Base Linux ops on Kali when the Kali-specific repo, branch, image, or tool context matters more than generic Debian advice

When NOT to use

• Generic Debian, Ubuntu, Mint, or Pop!_OS administration without Kali-specific context - use debian-ubuntu
• Shell syntax, quoting, or script portability - use command-prompt
• Network architecture, DNS, VPNs, reverse proxies, or firewall design - use networking
• Docker, Podman, image builds, or container runtime issues - use docker
• Hypervisor configuration, passthrough wiring, or VM platform issues where the fault is clearly outside the Kali guest - use virtualization
• Kubernetes cluster or manifest work - use kubernetes
• Fleet-wide Linux configuration via playbooks - use ansible
• Exploitation, privilege escalation, lateral movement, or post-exploitation on live targets - use lockpick
• Novel vulnerability hunting, reverse engineering depth work, fuzzing, or proof-of-concept research - use zero-day
• Defensive hardening, vuln triage, or broad security review - use security-audit
• OPNsense or pfSense appliance work - use firewall-appliance

---

AI Self-Check

Before returning Kali commands or tool recommendations, verify:

• Kali lane identified: rolling install, last-snapshot, live USB, VM image, Purple image, NetHunter, or a custom lab box. Advice diverges fast.
• Not flattened into plain Debian: do not give generic Debian advice without checking Kali branches, metapackages, and package origin first.
• Branch model understood: kali-rolling vs kali-last-snapshot vs partial or development branches such as kali-experimental, kali-bleeding-edge, and kali-dev. Do not mix them casually.
• Repo state is clean: no blind Debian repo additions, no stale image assumptions, no broken kali-archive-keyring, and no contradictory source lists.
• Upgrade path is coherent: prefer apt update plus apt full-upgrade on Kali when package transitions matter. Do not cargo-cult apt upgrade and call it done.
• Image mode identified: installed system, live media, persistence-backed live media, VM image, or mobile image. Recovery steps differ.
• Metapackage scope is intentional: do not suggest kali-linux-everything when a focused kali-tools-* bundle is the sane answer.
• Tool family matches the task: information gathering, vulnerability assessment, web, passwords, wireless, reverse engineering, exploitation, post-exploitation, forensics, reporting, or labs.
• Authorization boundary respected: Kali tool recommendations still require authorized scope. A tool index is not permission.
• Lab packages are treated as intentionally vulnerable: kali-linux-labs exists for controlled practice, not for everyday workstation installs.
• Wireless and hardware path is real: chipset, firmware, monitor mode, injection support, SDR stack, USB passthrough, and kernel modules match the actual hardware.

---

• Current source checked: dated versions, CLI flags, API names, and support windows are verified against primary docs before repeating them
• Hidden state identified: local config, credentials, caches, contexts, branches, cluster targets, or previous runs are made explicit before acting
• Verification is real: final checks exercise the actual runtime, parser, service, or integration point instead of only linting prose or happy paths
• Channel checked: kali-rolling, snapshots, metapackages, and NetHunter advice matches official docs
• Lab boundary explicit: offensive tooling stays in authorized labs, CTFs, or owned systems

---

Performance

• Install task-specific metapackages instead of full tool collections when disk, bandwidth, or update time matters.
• Use snapshots or pinned images for repeatable labs rather than debugging rolling drift mid-exercise.
• Keep wordlists, captures, and VM disks outside small root partitions.

---

Best Practices

• Do not treat Kali as a hardened daily-driver server by default.
• Snapshot before major upgrades, GPU/wireless driver work, or live persistence changes.
• Separate client data, lab artifacts, and exploit tooling with clear storage boundaries.

Workflow

Step 1: Identify the Kali lane first

Lane	Default stance	What changes
Installed Kali rolling	default for most users	continuous updates, package drift matters, repo hygiene is everything
Kali last-snapshot	safer, more frozen lane	release-like behavior between versioned snapshots
Live ISO / live USB	treat as ephemeral first	persistence, overlay state, and storage layout change recovery
VM image	check guest tooling and hypervisor assumptions	shared clipboard, display, USB passthrough, and virtual NIC quirks matter
ARM / SBC image	check board-specific image assumptions first	boot firmware, storage media, peripherals, and package expectations differ from amd64 installs
Kali Purple image	security distro with blue-team flavor	package mix and image choice differ from a standard red-team workstation
NetHunter	mobile and kernel-sensitive	Android host, custom kernels, HID, and wireless support change the answer
Partial or development branch user	slow down immediately	kali-experimental, kali-bleeding-edge, and kali-dev are not casual defaults

Step 2: Gather current system state

Start narrow, then widen only if the failing layer is still unclear.

Baseline checks for every Kali case:

cat /etc/os-release
uname -r
grep -Rhv '^#\|^$' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>&1 || true
apt-cache policy 2>&1 || true
apt-cache policy kali-archive-keyring kali-defaults kali-linux-core kali-linux-default 2>&1 || true
apt list --upgradable 2>&1 | tail -n +2
findmnt /
lsblk -f
dpkg -l | grep '^ii  kali-' | head -40

Add subsystem probes only when the task needs them. On NetHunter or other mobile-adjacent environments, skip desktop or systemd-specific probes that do not exist there.

# services and logs
ps -p 1 -o comm=
command -v systemctl >/dev/null 2>&1 && systemctl --failed 2>&1 || true
command -v journalctl >/dev/null 2>&1 && journalctl -b -p warning..alert 2>&1 || true

# boot and storage
findmnt /boot 2>&1 || true
findmnt /boot/efi 2>&1 || true

# desktop and capture path
echo "Session=$XDG_SESSION_TYPE Desktop=$XDG_CURRENT_DESKTOP"
loginctl list-sessions 2>&1 || true
systemctl status display-manager 2>&1 || true
systemctl --user --failed 2>&1 || true
systemctl --user status pipewire pipewire-pulse wireplumber xdg-desktop-portal 2>&1 || true
command -v wpctl >/dev/null 2>&1 && wpctl status

# hardware, wireless, GPU, and NetHunter
lspci -k | grep -Ei 'vga|3d|display|network|wireless'
lsusb
rfkill list 2>&1 || true
iw dev 2>&1 || true
journalctl -b | grep -Ei 'nvrm|nvidia|amdgpu|i915|xe|ath|iwlwifi|brcm|rtl|mt76|drm' 2>&1 || true
command -v dkms >/dev/null 2>&1 && dkms status 2>&1 || true
command -v airmon-ng >/dev/null 2>&1 && airmon-ng 2>&1 || true
command -v nethunter >/dev/null 2>&1 && nethunter -h 2>&1 | head -20

Step 3: Load only the relevant reference

Task type	Reference
apt, sources, keyrings, rolling vs snapshot, mirrors	references/packages-branches-and-repos.md
choosing metapackages and understanding Kali tool families	references/metapackages-and-tool-families.md
live USB, persistence, installers, VM images, recovery	references/images-live-persistence-and-recovery.md
wireless, GPU, SDR, USB, Bluetooth, NetHunter, hardware support	references/wireless-gpu-hardware-and-nethunter.md
scope discipline, vulnerable labs, snapshots, safe practice	references/lab-safety-and-scope.md
recurring Kali breakage patterns and edge cases	references/gotchas-and-special-situations.md

Do not load every reference by default. Pick the one that matches the failure mode, then widen only if the first layer is clean.

Step 3.5: Stay here or hand off

Request shape	Route
install, package, image, persistence, hardware, or tool-family selection on Kali	stay in kali-linux
hypervisor config, USB passthrough, guest display acceleration, or VM platform wiring	use virtualization
exploit, pivot, privilege escalate, or run post-exploitation workflow on an authorized target	use lockpick
fuzz, reverse engineer deeply, hunt a novel bug, or build a PoC	use zero-day
review the target code or service for defensive findings	use security-audit
generic Debian-family host admin with no Kali-specific context	use debian-ubuntu

Step 4: Change one layer at a time

• Fix source lists and package state before debugging tools that may simply be missing or mismatched.
• Fix image or persistence layout before declaring the live USB broken.
• Fix desktop session and capture plumbing before blaming Burp, Wireshark, or browser tooling.
• Fix hardware support and firmware before blaming monitor mode, injection, SDR, or Bluetooth tools.
• Pick the smallest metapackage that matches the workflow instead of installing everything.
• Keep labs and production separate. Prefer snapshots, throwaway VMs, and isolated USB media.

Step 5: Validate before closing

apt-cache policy package_name
command -v systemctl >/dev/null 2>&1 && systemctl status unit_name 2>&1 || true
journalctl -u unit_name -b 2>&1 || true
dpkg -l | grep '^ii  kali-' | head -20
command -v msfconsole 2>/dev/null || true
command -v nmap 2>/dev/null || true
command -v aircrack-ng 2>/dev/null || true

Reboot only when the boot path, persistence story, or kernel change is understood and at least one known-good recovery path remains.

---

Troubleshooting Pattern

Keep triage cross-layer and boring:

1. Confirm the Kali lane, branch, image type, and repo state.
2. Identify the failing layer: packages, image or persistence, desktop session, hardware, or tool selection.
3. Pull the right logs before changing config.
4. Change one layer at a time and retest.
5. Keep scope and safety separate from tool installation.

Core log sweep:

journalctl -b -p warning..alert
journalctl --user -b
dmesg --level=err,warn
journalctl -u unit_name -b 2>&1 || true

Broad pattern sweeps when you need correlation, not first-pass precision:

journalctl -b | grep -Ei 'nvrm|nvidia|amdgpu|i915|xe|ath|iwlwifi|brcm|rtl|mt76|drm' 2>&1 || true
journalctl --user -b | grep -Ei 'portal|pipewire|webrtc|burp|wireshark' 2>&1 || true

When the problem smells like "Kali is broken," check the boring causes first:

• source-list drift or stale keyring
• branch mixing
• huge metapackage install on weak hardware
• USB passthrough or monitor-mode expectations that the chipset cannot satisfy
• live USB persistence corruption
• VM guest additions and display stack mismatch

---

Default Decisions

• Kali means branch hygiene first. The repo state explains more failures than exotic package folklore.
• Prefer kali-rolling unless there is a clear reason not to. It is the main branch most users should be on.
• Use kali-last-snapshot when the user wants calmer release-like behavior. Do not enable it beside kali-rolling just because more sounds better.
• Prefer focused metapackages. kali-tools-* bundles beat kali-linux-everything unless the box truly exists to be a giant toolbox.
• Treat Kali as a workflow distro, not just a package repo. Image choice, persistence, hardware, and scope matter as much as package names.
• Stay package-focused when the ask is package-focused. Installing nuclei, burpsuite, hashcat, or reversing tools stays here until the question turns into defensive review, offensive workflow, or novel vulnerability research.
• Labs should be disposable. Snapshots, throwaway VMs, and isolated media beat hand-maintaining a single sacred pentest laptop forever.
• Tool families come before individual tool bikeshedding. Pick the category, then the tool, then the package.
• Wireless and SDR work are hardware stories first. Chipset support, firmware, passthrough, power, and monitor-mode reality matter more than menu entries.
• Route offensive depth correctly. Kali can install the tools, but lockpick owns exploitation workflow and zero-day owns novel bug discovery.

---

Quick Triage Checklist

Symptom	First checks
apt weirdness after install	source lists, apt-cache policy, keyring package, branch mixing, apt full-upgrade pending
Tool missing even though metapackage was installed	dpkg -l, apt-cache depends, command path, package split, transitional package
Live USB lost changes	persistence partition, mount state, overlay corruption, wrong image mode
VM feels broken or blind to USB gear	hypervisor guest tools, USB passthrough, network mode, display acceleration
Wireless tools do not see monitor mode or injection	chipset support, firmware, rfkill, USB power, passthrough, kernel module
SDR or hardware tools misbehave	package state, udev access, kernel modules, USB permissions, device firmware
Burp or browser capture feels broken	desktop session, CA import, proxy binding, PipeWire or portal path for GUI helpers
NetHunter issue	Android version, kernel support, image flavor, HID and wireless support, mobile package lane
System is huge and slow	metapackage sprawl, desktop choice, background services, kali-linux-everything regret
Nothing makes sense	check gotchas reference - branch mixing, stale keyring, persistence drift, VM passthrough mistakes, and unsupported Wi-Fi chipsets explain a lot

---

Reference Files

• references/packages-branches-and-repos.md - Kali branch model, source lists, keyrings, updates, and package-state recovery
• references/metapackages-and-tool-families.md - what the main Kali metapackages install, how the tool families map to real workflows, and when to hand off to lockpick or zero-day
• references/images-live-persistence-and-recovery.md - installer ISOs, netinst, live images, Purple images, VM images, persistence, and recovery flow
• references/wireless-gpu-hardware-and-nethunter.md - Wi-Fi, Bluetooth, RFID, SDR, GPU, USB passthrough, and NetHunter-specific hardware realities
• references/lab-safety-and-scope.md - disposable lab setup, intentionally vulnerable targets, snapshots, and authorization boundaries
• references/gotchas-and-special-situations.md - recurring Kali breakage patterns and edge cases

---

Output Contract

See skills/_shared/output-contract.md for the full contract.

• Skill name: KALI-LINUX
• Deliverable bucket: audits
• Mode: conditional. When invoked to analyze, review, audit, or improve existing repo content, emit the full contract -- boxed inline header, body summary inline plus per-finding detail in the deliverable file, boxed conclusion, conclusion table -- and write the deliverable to docs/local/audits/kali-linux/<YYYY-MM-DD>-<slug>.md. When invoked to answer a question, teach a concept, build a new artifact, or generate content, respond freely without the contract.
• Severity scale: P0 | P1 | P2 | P3 | info (see shared contract; only used in audit/review mode).

Related Skills

• debian-ubuntu - base Debian-family administration. Use it for generic apt-family hosts; use this skill when Kali-specific branches, images, metapackages, or tool context matter.
• lockpick - exploitation, post-exploitation, and escalation on authorized targets. This skill helps choose and maintain Kali tooling; lockpick handles the offensive workflow itself.
• zero-day - vulnerability discovery, reverse engineering depth, fuzzing, and proof-of-concept work. This skill covers the Kali environment and tool families that support that work.
• security-audit - defensive hardening and vuln review instead of offensive distro workflow.
• virtualization - hypervisor setup, guest provisioning, passthrough, and VM platform issues once the fault is clearly outside the Kali guest.
• command-prompt - shell syntax, wrappers, aliases, and script portability when the real issue is the shell rather than Kali.
• networking - network services, VPNs, DNS, proxies, and firewall design beyond host-level Kali package questions.

---

Rules

1. Identify the Kali lane before prescribing commands. Installed rolling, snapshot, live media, VM image, Purple, and NetHunter differ where it matters.
2. Do not treat Kali like generic Debian with a dragon wallpaper. Branches, metapackages, images, and hardware expectations change the answer.
3. Do not mix branches casually. kali-rolling, kali-last-snapshot, kali-experimental, kali-bleeding-edge, and kali-dev each have a purpose. Random mixing usually ends in package pain.
4. Prefer focused metapackages over giant installs. Install the tool family that matches the job before reaching for kali-linux-everything.
5. Keep lab and production separate. Practice targets, vulnerable apps, and offensive tooling belong on disposable systems or isolated boxes.
6. Respect scope. Recommending Kali tools is not permission to use them outside authorized environments.
7. Treat hardware claims as hardware claims. Monitor mode, injection, SDR capture, HID, and GPU acceleration depend on actual chipsets, firmware, and passthrough support.
8. Live USB and persistence are their own failure domain. Do not debug them like a normal installed root filesystem.
9. Hand off correctly. Once the work becomes exploitation methodology, use lockpick. Once it becomes original vulnerability research, use zero-day.
10. Reach for common Kali failure patterns before exotic explanations. Stale keyrings, branch drift, metapackage sprawl, persistence corruption, and unsupported hardware explain a large share of the mess.