Sponsored by

5 Kali Linux tricks that you may not know

Posted in Articles on November 9, 2018

5 Kali Linux tricks that you may not know

Hi, after our 5 tips to make the most of Twitter as a pentester or bug bounty hunter and 5 things I wish I knew as a junior penetration tester, we continue our series of tips & tricks…

Here are 5 Kali Linux tricks only known by Kali power users!

Install Kali tools anywhere with Kali Linux Git Repositories

I don’t know if this trick is well known because I haven’t seen it documented anywhere. You can install Kali Linux APT packages on any Debian machine. Yes, any Debian, not Kali!.

Why would you wanna do that? Well, let’s say your employer wants you to do tests from a Debian server. It happened to me, they wanted all tests to originate from the same IP and provided a shared Debian server.
Some tools are only available as Kali packages, and can’t be found on Github or anywhere else. Also, installing tools with APT is always better because then they’re easier to update (with apt-get update && apt-get upgrade).

Here is how you do it:

  1. Go to http://git.kali.org/gitweb/
  2. Look for the tool you want. It must be available by default on Kali, like lbd
  3. Click on “packages/lbd.git” (in the “Project” column) & copy the package’s URL
  4. Install the package on your Debian with: git clone git://git.kali.org/packages/lbd.git

Get the latest version of each tool

Tools installed on Kali aren’t always up to date. You can check which version is used by going to the Kali Linux Package Tracker on https://pkg.kali.org/.

Let’s look for “sqlmap”:

We can see some information on the package including which version is installed and the tool’s original link:

As you can see Sqlmap isn’t up to date on Kali:

So the Kali Linux Package Tracker is very useful to:

  • Get information on tools, especially the version installed
  • Check original links & Git repositories
  • If necessary, install the latest versions using these original links

Get the latest ISO with Kali Linux Weekly Builds

Kali Rolling packages are updated very regularly but the main Kali Linux Images (or ISOs) are only released a few times a year. So they don’t include the latest updates.

That’s why when you install an ISO, you have to suffer a humongous package upgrade when you do your first apt-get update && apt-get upgrade.

You can avoid that by using the weekly releases of Kali images, available at http://cdimage.kali.org/kali-images/kali-weekly/:

These are fresh ISOs, released once a week (on Sunday) and ship the latest tools:

Leverage tools available in /usr/share/

The folder /usr/share/ contains many interesting resources that we can leverage during penetration tests.

Here are some examples:

  • /usr/share/wordlists/ contains many wordlists for password, username, file & directory bruteforce and more
  • /usr/share/webshells/ contains some direct & reverse webshells categorized by language (php,jsp, asp…)
  • usr/share/nmap/scripts/*.nse contain the source code of Nmap NSE scripts. So we can check what a script does & if it is safe to use (i.e. no risk of Denial of Service) without using the Internet
  • /usr/share/uniscan/, /usr/share/recon-ng, /usr/share/dnsenum…: contain either the source code of some tools or resources they use (wordlists)
  • /usr/share/background: wallpapers

I particularly love the webshells because they’re clean. When we upload something to a server, we want to know what it does. We don’t want to introduce additional backdoors.

C99.php is an infamous webshell that had a lot of cool functionalities but was backdoored! If you uploaded it to a server, anyone could bypass its authentication and abuse it.

That’s why I prefer using custom made webshells or the ones on Kali even if they have less features. At least, they can be trusted.

Automate OS upgrades & Always do a backup before

Kali rolling isn’t a stable distribution. It’s great because it is continuously upgraded. New features and tools are added all the time. But the downside is that the risk of crashes is high.

Here are two things I noticed from personal experience:

  • The more I waited before upgrading it, the more chances of causing a crash when I did
  • When doing an upgrade, there is always a risk for completely breaking Kali

Two simple actions can help up minimize this risk:

  1. Always do a backup before an upgrade. If using a Virtual Machine, take a VM snapshot. And if using Kali as the main OS, backup your important data. Also, don’t upgrade just before an important mission (see why in the story below…).
  2. Upgrade regularly (I mean really regularly, like every day)

Here is a little script to automate the process:

#!/bin/bash
echo '########################### aptitude update'
aptitude update
echo '########################### aptitude safe-upgrade'
aptitude safe-upgrade
echo '########################### aptitude dist-upgrade'
aptitude dist-upgrade
echo '########################### aptitude clean'
aptitude clean

Copy these contents to update_os.sh then run it manually:

chmod +x update_os.sh
./update_os.sh

You could also run this script as a cron job for totally automated upgrades, and use the -y option (aptitude safe-upgrade -y) to avoid being prompted for confirmation.
Being a paranoid, I prefer the manual approach.

For the little story, I once had the great idea to upgrade my Kali the night before a pentest. Right after, all text displayed looked like this: [][].
Some critical fonts were uninstalled and ALL TEXT was rendered as little rectangles! I had to look for information on a second device, and install common fonts one by one until it was solved…

Since this bad night’s sleep, I never use the -y option and always check the packages that will be removed by an upgrade:


That’s it for today! What did you think of these tips? Do you have other less know tricks to share with us?
Let’s continue the conversation in the comments or on Twitter!

As always, you’re welcome to share with your friends, like & retweet to spread the word, leave questions, requests, suggestions, etc.

See you next time!

Top