How to Install Kali Linux Tools on Ubuntu Safely

This guide is not about installing Kali Linux as an operating system inside Ubuntu. You keep Ubuntu and add individual security tools that also ship in Kali—for example:

• Scanners and web testers: Nmap, Nikto, SQLMap, Gobuster, Masscan, ffuf
• Credentials and hashes: John the Ripper, Hashcat, Hydra
• SMB and frameworks: smbmap, recon-ng (recon-ng availability varies by release)

The ethical hacking course hub covers full Kali VMs and labs; this page is for installing tools on Ubuntu using Ubuntu packages, upstream releases, or isolated Kali.

On 26.04 and 24.04, start with Ubuntu’s package when it exists, use the tool’s official upstream release when necessary, and run Kali in a VM or official container when you need Kali-specific package sets (see the decision flow below).

Quick answer

Many tools bundled with Kali Linux are ordinary Ubuntu packages. On 26.04 or 24.04, search the archive and install what you need:

Refresh indexes before installing:

sudo apt update

Install common examples (adjust the list to your lab):

sudo apt install nmap sqlmap nikto

If apt install reports that a package cannot be found, check whether Ubuntu actually ships it on your release:

apt-cache policy nikto

A numbered Candidate line means Ubuntu can install the package from enabled sources; Candidate: (none) means you need upstream or Kali isolation—not Kali repositories on Ubuntu.

Can you install Kali Linux tools on Ubuntu safely?

Yes—for individual tools from Ubuntu apt, when you avoid turning Ubuntu into a hybrid Kali/Ubuntu system.

Kali tools vs the Kali Linux operating system

Searching install Kali Linux on Ubuntu usually means the Kali OS (ISO, VM, or dual boot)—not installing scanners and frameworks on your existing Ubuntu desktop. Use check Ubuntu version if you are unsure whether you run 24.04 or 26.04; package names are often the same, but availability and versions differ by release.

Terms used in this guide

Run the commands on your Ubuntu host unless the step explicitly says you are inside a Kali container or VM.

• APT repository — a software source Ubuntu trusts for packages and dependencies. Kali and Ubuntu build against different package sets, so mixing both repositories can make APT replace Ubuntu libraries with Kali versions.
• Universe and Multiverse — extra Ubuntu software components (still Ubuntu archives, not Kali). Many security tools live in universe; a smaller set (for example some scanners) may be in multiverse or main.
• Upstream — the original project or vendor that develops the tool (for example the Nmap project or OWASP).
• Metapackage — a package that depends on a group of other packages so one apt install pulls in an entire Kali tool set (kali-linux-default, kali-tools-web, …). Install metapackages inside Kali, not on Ubuntu.

Why you should not add the Kali repository to Ubuntu

Kali and Ubuntu both use apt, but they target different rolling and LTS baselines. Pulling kali-rolling onto Ubuntu can:

• Replace core libraries with versions built for Kali’s baseline
• Break desktop sessions or common desktop packages
• Leave apt upgrade in a bad state after mixed dependencies

Kali’s own documentation states that mixing Kali repos into another OS is unsupported and likely to break the installation—historical Katoolin tutorials described the same risk.

The safe pattern is:

┌──────────────────────────────────────┐
│ Need a Kali security tool on Ubuntu? │
└─────────────────┬────────────────────┘
                  ▼
       ┌─────────────────────┐
       │ Ubuntu packages it? │
       └───┬────────────┬────┘
      yes  │            │ no
           ▼            ▼
    ┌────────────┐ ┌───────────────────┐
    │ Ubuntu APT │ │ Official upstream │
    └────────────┘ │ (project docs)    │
                   └────────┬──────────┘
                            ▼
┌─────────────────────────────────┐
│ Need many Kali-only packages or │
│ Kali metapackages?              │
└────────────────┬────────────────┘
                 ▼
      ┌──────────────────────┐
      │ Kali container or VM │
      └──────────────────────┘

┌─────────────────────────────────────────┐
│ Never: Ubuntu + kali-rolling repository │
└─────────────────────────────────────────┘

Choose the right installation method

Kali tools available in Ubuntu 26.04 and 24.04

Kali menu names do not always match Ubuntu package names. You cannot run sudo apt install amass-common on Ubuntu just because that name exists on Kali.

Availability varies by Ubuntu release. The table lists Ubuntu Candidate versions at time of review (October 2026); always confirm on your system with apt-cache policy before you pick another install path.

Ubuntu 22.04 often matches 24.04 for older tools but can differ on individual packages; treat 22.04 as a compatibility check, not the primary target for this guide.

Check whether a tool exists before installing it

On the Ubuntu host, use the apt-cache command to see whether a package has a candidate and which component supplies it:

apt-cache policy nikto

• A numbered Candidate line — Ubuntu can install the package from your enabled sources (note the version; it may trail upstream).
• Candidate: (none) — no install candidate; use upstream or Kali isolation.

If a candidate exists and you want metadata before installing:

apt show recon-ng

On the 26.04 lab at time of testing, recon-ng showed:

Package: recon-ng
Version: 5.1.2-2
Section: universe/utils

At time of testing, recon-ng had a candidate on 26.04 but not in the default 24.04 archive—always re-check on your release before you assume the table still matches.

Method 1: Install security tools from Ubuntu APT

Prerequisites

On many standard Ubuntu installations, universe and multiverse are already enabled. Minimal or customized images may differ. If apt-cache policy shows Candidate: (none) because a component is disabled, enable only the component that package needs—do not enable every component blindly.

Example: many tools (including Nmap) live in universe:

sudo add-apt-repository universe

Nikto and some other tools may require multiverse instead:

sudo add-apt-repository multiverse

When add-apt-repository is missing, see add-apt-repository command not found.

Refresh indexes after you change components:

sudo apt update

You need outbound HTTPS for apt and, for upstream installs, the vendor’s download site.

Install one tool

Package installs use the apt command. Refresh indexes:

sudo apt update

Install a single package (example: Nmap, common in nmap command in Linux workflows):

sudo apt install nmap

Confirm the binary path:

command -v nmap

/usr/bin/nmap

Read the packaged version:

nmap --version

Nmap version 7.98 ( https://nmap.org )
Platform: x86_64-pc-linux-gnu
Compiled with: liblua-5.4.8 openssl-3.5.5 libssh2-1.11.1 libz-1.3.1 libpcre2-10.46 libpcap-1.10.6 nmap-libdnet-1.18.0 ipv6

Install several tools

Install only what your lab needs so apt does not pull large dependency trees you will not use:

sudo apt install nmap sqlmap nikto john hydra

On the 26.04 system used for this guide, that install placed sqlmap 1.10.4 and Nikto 2.1.5 (Ubuntu’s Nikto build—often much older than upstream).

Check SQLMap’s version string:

sqlmap --version

1.10.4#stable

Nikto prints a short banner:

nikto -Version

---------------------------------------------------------------------------
Nikto Versions
---------------------------------------------------------------------------

For Gobuster-specific usage after apt install gobuster, see install Gobuster on Ubuntu.

Verify the installed tools

Use command -v and each tool’s --version (or vendor flag) rather than running scans against targets from an install guide:

command -v sqlmap

SQLMap prints its build tag on stdout:

sqlmap --version

List installed package rows with the dpkg command:

dpkg -l nmap sqlmap nikto | grep '^ii'

ii  nikto    1:2.1.5-3.1build1  all          web server security scanner
ii  nmap     7.98+dfsg-1          amd64        The Network Mapper
ii  sqlmap   1.10.4-1             all          automatic SQL injection tool

Ubuntu’s build may trail Kali’s rolling versions for the same tool name—that is expected on an LTS-style archive.

Method 2: Install a tool from its official upstream project

When Ubuntu does not package the tool

If Ubuntu does not provide the tool—or the packaged version is too old—use the project’s official release instead of adding foreign apt repositories. OWASP Amass is a common case: confirm with apt-cache policy amass on your release; when there is no suitable candidate, follow OWASP Amass install documentation.

General fallback order:

• Read the tool’s official install documentation.
• Prefer an official .deb (see install a .deb file on Debian for apt install ./package.deb and dpkg -i patterns—the same commands work on Ubuntu), signed binary, or vendor package repository.
• Consider a container image published by the project or by Kali when you need a package from Kali’s archive.
• Avoid random PPAs and unofficial “all Kali tools” apt sources on Ubuntu.

When Ubuntu’s version is older than you need

If apt-cache policy shows a candidate but the version is too old for your coursework or lab, check whether the upstream project ships a newer build for Linux. Install that build in a dedicated directory or container so you do not replace system libraries through foreign apt sources.

Document which version you installed; keep Ubuntu’s packaged copy unless you deliberately replace it with upstream’s uninstall steps.

Method 3: Run Kali separately

Use Kali when Ubuntu apt and upstream installs are not enough—especially for metapackages and large tool sets. A rolling Kali container tracks current Kali packages; it does not pin a historical version unless you choose a specific image snapshot.

Kali container vs Kali VM

Kali documents official container images such as kalilinux/kali-rolling (updated about once a week). Pull only from Kali’s documented registry paths. Install Docker or Podman on the Ubuntu host first—the must-have Ubuntu apps roundup includes docker.io from apt when you need a quick engine install.

The examples below assume Docker is already installed. If you use Podman, replace docker with podman where the syntax is compatible.

Pull the rolling image:

docker pull kalilinux/kali-rolling

Start a throwaway shell session in that image:

docker run --rm -it kalilinux/kali-rolling

The base image is intentionally minimal—install individual Kali packages you need with apt inside the container. Kali’s Docker documentation also documents kali-linux-headless when you intentionally want Kali’s standard headless tool bundle in a container; prefer single packages when one tool is enough.

Do not configure the container’s Kali sources on your Ubuntu host.

Use a Kali VM for the full toolset

For a full attacker VM with Metasploitable-style targets, follow pentest lab setup on VirtualBox.

Download an official image from Get Kali. Prebuilt VMware or VirtualBox images are documented on the same site.

After installation inside Kali, install metapackages such as kali-linux-default or kali-tools-web per Kali’s metapackage documentation:

sudo apt update

On Kali, install the default tool metapackage:

sudo apt install kali-linux-default

Run that apt install only on Kali, not on Ubuntu. Ubuntu remains the host system; the VM holds the full Kali environment and lab targets.

Why Katoolin is not recommended on current Ubuntu

The original LionSec Katoolin is a Python 2.7 script that added Kali apt sources and installed tool categories on Ubuntu. It remains in old search results (including high-traffic Ask Ubuntu threads), but it is a poor fit for 24.04 and 26.04:

• Python 2 is not available on current Ubuntu, so the original script does not run as documented.
• It works by mixing Kali repositories into Ubuntu—the pattern Kali’s documentation warns against.
• Its category lists are stale; bulk installs fail on missing package names.
• The original Katoolin README tells users to remove Kali repositories before updating Ubuntu.

Community rewrites such as Katoolin3 (Python 3) still expose Kali packages on non-Kali systems and carry similar cross-distribution warnings. Treat Katoolin-style tools as historical—not a supported install path on current LTS releases.

Do not clone Katoolin or run python2 katoolin on a supported Ubuntu LTS. Use Method 1, upstream releases, or Kali isolation instead.

Update security tools on Ubuntu

Refresh indexes:

sudo apt update

Upgrade only the tools you installed, so you can review the transaction:

sudo apt install --only-upgrade nmap sqlmap nikto

Remove installed tools

Remove selected packages:

sudo apt remove nmap sqlmap nikto

Preview orphaned dependencies before autoremove:

sudo apt-get -s autoremove

If the dry run lists only packages you intend to drop, run:

sudo apt autoremove

For autoremove previews and orphan package hygiene after large tool installs, see remove unused packages on Ubuntu.

Troubleshooting

Unexpected Kali repository in APT sources

Search list files and DEB822 .sources fragments:

grep -RniE 'kali|http\.kali\.org' /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

On Ubuntu, you should not see kali-rolling entries you did not deliberately add for a non-Kali workflow. Open the reported path in an editor, remove the Kali URIs/Suites block or delete the drop-in file, then update:

sudo apt update

Removing the Kali source stops further mixing but does not automatically revert libraries or tools already installed from Kali. Compare package versions and origins (apt-cache policy, apt list --installed) before you run broad upgrades. If core system libraries were replaced, recovery may require targeted package downgrades—or, on heavily mixed hosts, reinstalling Ubuntu. Kali’s documentation notes that users often end up reinstalling after repository mixing.

If you added foreign apt sources while experimenting, avoid sudo apt full-upgrade until Kali (or other non-Ubuntu) sources are removed and apt update completes cleanly.

Do not paste broad rm commands across /etc/apt without checking which file introduced Kali.

Summary

You can run many Kali-associated security tools on Ubuntu 26.04 and 24.04 without installing Kali as the host OS:

• Ubuntu apt — individual packages when apt-cache policy shows a candidate
• Official upstream — when the archive has no package or the version is too old
• Kali container or VM — metapackages and large Kali-only sets; pair a VM with the pentest lab layout when your lab expects an attacker guest

Do not add kali-rolling to Ubuntu—Kali documents that mixing its repository into another distribution can break the system and is unsupported. The original Katoolin is obsolete, and Katoolin-style rewrites still rely on the cross-distribution package approach this guide avoids. Check each tool with apt-cache policy or apt show because packages such as recon-ng appear on 26.04 but not on every 24.04 image.

Keep authorization in mind for every scanner or exploit framework you install. When you remove tools:

• Run targeted apt remove for packages you no longer need
• Preview sudo apt-get -s autoremove before you drop dependencies
• Follow how to remove software on Ubuntu for broader apt, Snap, and Flatpak cleanup

References

• Kali Linux — Installing on other operating systems (repository mixing warning)
• Kali Linux — Official Docker images
• Kali Linux — Metapackages
• Kali Linux — Get Kali
• Ubuntu documentation — Repositories (universe and multiverse)
• OWASP Amass — GitHub repository