Package Management

Every piece of software on your system arrived through a package manager - and every outdated package is a potential door an attacker can walk through. Understanding how software installs, where it lives, and how to keep it fresh is table stakes for both offense and defense.

What is a package manager?

A package manager handles downloading, installing, updating, and removing software - along with all its dependencies - so you never have to compile from source manually. On Debian-based distros (Ubuntu, Kali, Parrot OS), that manager is APT (Advanced Package Tool), backed by the lower-level dpkg.

Think of it like npm or pip but for your entire operating system.

APT - your primary tool

Keeping the system current

sudo apt update          # Refresh the package index from repositories
sudo apt upgrade         # Install newer versions of all installed packages
sudo apt full-upgrade    # Like upgrade but also handles dependency changes

Installing and removing packages

sudo apt install nmap          # Install a single package
sudo apt install nmap curl jq  # Install several at once
sudo apt remove nmap           # Remove but keep config files
sudo apt purge nmap            # Remove AND delete config files
sudo apt autoremove            # Clean up orphaned dependencies

Searching for packages

apt search keyword             # Search package names and descriptions
apt show nmap                  # Detailed info: version, deps, description
apt list --installed           # Everything currently installed
apt list --upgradable          # Packages with available updates

dpkg - the low-level engine

dpkg is what APT calls under the hood. You'll reach for it directly when you have a .deb file you downloaded manually.

sudo dpkg -i package.deb    # Install a local .deb file
dpkg -l                     # List all installed packages
dpkg -l | grep nmap         # Check if a specific package is installed
dpkg -L nmap                # List files installed by a package
dpkg -S /usr/bin/nmap       # Which package owns a given file?

Where do binaries actually go?

When you install a package, its files land in predictable locations:

When you install something manually (not via APT) it often lands in /usr/local/bin/ - that subtree is reserved for locally compiled/installed tools and takes precedence in $PATH over /usr/bin.

Repositories and sources.list

APT knows where to look because of /etc/apt/sources.list and the files in /etc/apt/sources.list.d/.

Format: deb [url] [distribution] [components]

• deb - binary packages; deb-src - source packages
• kali-rolling - the release branch (like main on GitHub)
• main / contrib / non-free - licensing tiers

Adding a third-party repo

# Download and trust the GPG signing key
curl -fsSL https://packages.example.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/example.gpg
 
# Add the repo
echo "deb [signed-by=/usr/share/keyrings/example.gpg] https://packages.example.com/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/example.list
 
sudo apt update
sudo apt install example-tool

pip and git - the hacker's extra package managers

Many security tools live on GitHub or PyPI, not in APT:

pip install impacket          # Python hacking toolkit
pip install --upgrade impacket
 
# Install from a git repo directly
git clone https://github.com/Tib3rius/AutoRecon.git
cd AutoRecon
pip install -r requirements.txt
python3 autorecon.py --help

A note on pip vs apt versions

The same tool can appear in both APT and PyPI, often at different versions. The APT version is more stable but potentially older. For pentesting tools, the PyPI or GitHub version is usually what you want.

Outdated packages as attack surface

This is where the defender mindset kicks in. Every installed package - especially those with network-facing components - is potential attack surface. The CVE database is full of vulnerabilities in specific package versions.

How to audit installed packages

# Show all packages with available updates
apt list --upgradable 2>/dev/null
 
# Cross-reference installed tool versions against exploit-db
searchsploit openssh 8.4
 
# Check a specific package version
dpkg -l | grep openssh-server

The attacker's perspective

During a penetration test, after gaining access to a target, one of the first things you do is inventory installed software:

dpkg -l                          # Full package list
cat /etc/os-release              # OS version
uname -r                         # Kernel version
apt list --installed 2>/dev/null # Cleaner output

That version list feeds directly into your vulnerability research. Old kernel? Check for local privilege escalation exploits. Old web server? Check for RCE.

Key takeaways

• apt update refreshes the index; apt upgrade actually installs updates - always run both.
• dpkg -i installs local .deb files; dpkg -L shows what a package owns.
• Installed binaries live under /usr/bin, /usr/sbin, or /usr/local/bin (for manual installs).
• Repositories are configured in /etc/apt/sources.list and /etc/apt/sources.list.d/.
• pip and git clone cover the vast majority of security tools not in APT.
• Every installed package is potential attack surface - patch regularly, and know what's installed.