As I’ve been focusing more on learning security topics lately, I have come across Kali Linux. If you are interested in penetration testing, computer forensics, or “hacking”, then this is the de facto standard.
This blog post summarizes many, many hours I’ve spent with this – so I wanted to sum everything I’ve learned (at least for the OS level) into one post.
What is it?
Kali Linux is a Debian-based Linux distribution specifically designed for digital forensics and penetration testing. This means that the operating system is already set up optimally for “hacking” type activities. That is, all network services are turned-off (to protect from counter attacks) and it has the entire Kali/Backtrack suite of tools pre-installed.
Backtrack Linux was a collection of tools put together for “hacking”, ethical or otherwise.
However, that distribution became Kali in 2013 when Offensive Security funded a project to build a Linux distribution from scratch explicitly for pentesting – and now includes 600+ tools. It seems that they did that primarily because they are a cybersecurity company AND they also offer training classes on pentesting, forensics, etc – and it made sense to have a stable, controllable platform.
Meanwhile, everyone else also gets the benefit because Kali is ready-to-go, right out of the box. It’s the closest thing to turn-key pentesting you are going to find at the moment. If you are interested in more about how Kali came to be, here is an interesting interview with one of the creators.
Using the Backtrack/Kali tools on another Linux distribution:
My first reaction is that I don’t like several things about the Kali/Gnome setup. I wanted to change many things, but when I attempt to change ANY thing, it tends to break several other things. The default Kali Linux installation feels like logging into some other persons laptop which has all of their annoying settings – and when you try to change anything, it breaks everything!
So, one of my first ideas was: why not use a super-friendly distro of Linux like Ubuntu (another compatible, Debian-based distro), and then just install all of these tools there? It turns out that’s not a great idea because Ubuntu has a pretty big attack surface area. Kali conversely has all network services turned-off. But still – if you wanted to, how would you do it?
There are two ways I found to do this – and neither was completely successful.
OPTION 1: Point to launchpad.net and install packages one by one
First, know that this isn’t the real/core repository. Also, the versions of products here are several versions old. So, this is not ideal at all. With that said though, add the following to your apt repositories (in Ubuntu go into Software and Updates – a.k.a Synaptic):
then do a “apt-get upgrade” to pick up the new sources.
Then, using some command-line magic, run this:
$ grep-dctrl -sPackage . /var/lib/apt/lists/*kali*_Packages | grep dns | sed ‘s/^.*: (.*)$/1/’
to show all of the “dns” related packages. From there, just “sudo apt-get install thepackagename” to install each package. If you want to come up with a list of ALL of the Kali packages to install – this is by far the most complex Linux command I’ve ever constructed:
$ echo -n “sudo apt-get install ” ; grep-dctrl -sPackage . /var/lib/apt/lists/*kali*_Packages | sed ‘s/^.*: (.*)$/1/’ | sort | uniq | tr “n” ” ” ; echo -n ” -y”
- echo – creates the first part of the command: “sudo apt-get install “. The -n excludes a carriage return at the end.
- grep – gets all of the lines that have package in it. Comes back as “Package: package-name-here” format
- sed – finds the “:” and returns whatever is to the right of it.
- sort – sorts the list alphabetically (will be one package, per line)
- tr – find all carriage returns and replaces them with a space. This turns rows of package names into space-delimited package names
- echo – concatenates a “-y” to auto-confirm the install of packages. Otherwise, you’d get a yes/no prompt for every single package!
After all of that, when I ran this command I got TONS of dependency errors and it only successfully install a small portion of the Kali tools!
OPTION 2: Point to kali.org
This option will give you the newest versions of the tools, but this too did not work completely. Start by editing the apt repository list:
$ sudo nano /etc/apt/sources.list
then, add the following repositories:
deb http://http.kali.org/ /kali main contrib non-free
deb http://http.kali.org/ /wheezy main contrib non-free
deb http://http.kali.org/kali kali-dev main contrib non-free
deb http://http.kali.org/kali kali-dev main/debian-installer
deb-src http://http.kali.org/kali kali-dev main contrib non-free
deb http://http.kali.org/kali kali main contrib non-free
deb http://http.kali.org/kali kali main/debian-installer
deb-src http://http.kali.org/kali kali main contrib non-free
deb http://security.kali.org/kali-security kali/updates main contrib non-free
deb-src http://security.kali.org/kali-security kali/updates main contrib non-free
Then, get the public key of the server, register it, install all of the Kali packages, make sure everything is upgraded, and then make sure the OS is also upgraded to the latest:
$ wget -q -O – http://archive.kali.org/archive-key.asc | gpg –import
$ gpg –keyserver subkeys.pgp.net –recv-key 44C6513A8E4FB3D30875F758ED444FF07D8D0BF6
$ gpg –recv-keys AED4B06F473041FA
$ gpg -a –export AED4B06F473041FA| sudo apt-key add –
$ gpg –keyserver pgpkeys.mit.edu –recv-key ED444FF07D8D0BF6
$ gpg -a –export ED444FF07D8DOBF6| sudo apt-key add –
$ sudo -s
# apt-get update
# apt-get install kali-linux –force-yes
# apt-get install kali-linux-full –force-yes
# apt-get upgrade -f
# apt-get dist-upgrade
Again, I got a ton of errors using this method too.
Which, is why I’m writing this blog post because it would seem you MUST use the Kali Linux distribution if you want to use many of those tools.
Running on a physical laptop:
I picked up a cheap, new (refurbished) laptop on eBay for super-cheap (~$145) – a Dell Inspiron 14.
I maxed out the RAM and got an SSD for it. As you might know, an SSD hard drive makes any computer feel very fast! I primarily wanted a laptop for some testing because I wanted access to physical hardware like a Wi-Fi network card and Bluetooth. If you are hosting the operating system within a virtual machine, then you likely won’t be able to work with those.
Plus, having a physical machine gives you even more hardware options:
That means you could have gigabit Ethernet, onboard Wi-Fi, onboard Bluetooth and up to 3 other dongles for other things like extra storage drives, multiple Wi-Fi or Bluetooth adapters, etc.
Anyhow, most of the Kali stuff worked fine on this hardware. It recognized the onboard Wi-Fi and Bluetooth, AND it recognized the USB hub above, the Ethernet port, and the Wi-Fi dongles too. The only problem I had/have is that with video hardware acceleration turned on (which it is by default), the OS freezes after I log into the console.
You might know that with X-Windows, you can go CTRL+ALT+F1, F2, F3, etc to scroll through terminal windows which are also running beyond X11. To switch back to the X11 interface, it’s CTRL+ALT+F7 on my computer.
So, using the other consoles, I was able to install SSH (see the “Caveats and gotchas!” section, below) and remote in. I tried many, many things to fix this and it did work, but not consistently. I need to dig back into it and see if I can get a permanent, reproducible fix – otherwise, I can remote into the laptop or use the full-screen TTY sessions, but I can’t use X11 on it!
This is still worth pursuing though because if I were to go on a pentesting gig, I’d want a standalone workstation from which to work (see “Potential Setups…”, below).
Running in Hyper-V:
Which leads me to how I mostly use Kali Linux at the house. If you don’t need the portability/anonymity of a laptop, and if you don’t need access to physical hardware (like WiFi and Bluetooth), then setting up Kali in Hyper-V is super-simple. In fact, I don’t have much more to say about it beyond that!
In my case, I installed SSH and xrdp so that I can have terminal sessions and full-screen Remote Desktop and it works great!
Running in Raspberry Pi:
WHAT?! Yes, Kali Linux is also available for ARM-based chipsets too. This means that you can install it on tablets, or more significantly (to me) – a Raspberry Pi.
To do this, it’s very similar to how you run other operating systems on a Pi – you download an SD card image, and burn it to your SD card. For Kali on Pi, go here for the image:
there are a couple of things different about this version. This DOES come with SSH pre-installed and available (default username/password is: root/toor). Also, it doesn’t have most of the Kali tools installed, but it is already pointing to the Kali repositories so you can just “sudo apt-get install” whatever packages you need.
In fact, just to see, I installed X11 (and then xrdp) on a Raspberry Pi 2 (which is a quad-core with 1GB of RAM) and it’s a little slow, but very useable!
Even more impressive is that WITH X-Windows running, the memory footprint is still ridiculously small (208 MB!):
Now, why would you care about running Kali on Raspberry Pi? What comes to mind for me is there are pretty potent drones.
They are VERY small, you could easily have 4-8 of these in your bag. When you are onsite, power them up and use them as a botnet to go run your recon or your attacks. OR another use is to physically hook a Pi up to a network segment to which you wouldn’t normally have access, and have that Pi reach outward to your machine (callback) to give you a back door.
The ideas are endless! Having the ability to run Kali on such a small form-factor (the size of a credit card) could be used in lots of creative ways!
Running on a tablet:
This is something I did not do, and don’t plan to. As mentioned above, Kali can run on ARM chips, so you could in theory pick up a cheap Android tablet and put Kali on it. To me, the potential value here isn’t to sit and type commands, it would be more valuable to simply monitor/control a pentest attack. If you are at a client site, you could walk around the office (I guess?) and watch/adjust as the attack unfolds?
I can’t really think of any other benefit of having this on tablet.
Caveats and gotchas!
One issue I mentioned above, which is that Kali freezes upon login to X-Windows and I still don’t have this resolved.
So, just bear in mind depending on your hardware, things may not go smoothly.
However, the whole reason for me creating a separate section for this – is something quite significant! To keep the OS “safe”, if you install software that normally opens a TCP/UDP port, it will be disabled by default! That means if you install SSH, xrdp, a web server, or anything that would normally listen on a TCP/IP port, it will disabled upon boot-up.
This took me quite some time to track-down – that is, until I read the screen carefully!
For example, I can’t stand VNC (for several reasons), and prefer RDP. If you install “xrdp”, this lets you connect via Remote Desktop, the console doesn’t need to be logged-in, AND it creates a full-screen session for whatever side your RDP client is. That is, as opposed to regular VNC which just let’s you screen-share if the console is logged in, at that resolution, etc. ANYHOW, to install xrdp, we run:
$ sudo apt-get install xrdp
and if we look in the output – it tells us that it can’t find how to set up the service for each runlevel:
It turns out that Kali Linux has their own version of “update-rc.d”, the thing that registers services. In that script:
$ sudo nano /usr/sbin/update-rc.d
it specifically disables anything that is a network service, by default:
If you truly want to start that service upon boot-up, do something like this:
$ sudo update-rc.d xrdp enable
And you can use:
$ chkconfig –l xrdp
before and after to see if the service will start with the various runlevels:
So the bottom line here is that if you install a package that uses a network service, Kali (specifically) will disable it from starting up boot-up and your MUST use “update-rc.d” to manually change it to enable.
As I’ve been learning this OS and layout, it seems to me there are several setups one might have – which address different problems.
Generally-speaking, if you are doing security testing, it seems there is a standard level of professionalism that you need to have! Companies may have aggressive counter-measures and immediately try to start attacking you, the moment you attack them. Assuming a best-case (and hopefully ONLY) scenario of a white-hat, Red Team, paying contract that you are working on:
How unprofessional would it be if your client broke into YOUR system and stole YOUR information while you were testing THEIR system?
In my opinion, this needs to be completely impossible. This can be accomplished with some simple operational security (OPSEC) steps that you do for every engagement:
- Use a laptop with a fresh build (no network services enabled – ssh, rdp, etc.)
- Don’t have anything personally-identifiable on the system, not even your companies Wi-Fi connection
- Don’t connect to e-mail or any other personally identifiable service. Don’t cross-contaminate information!
- Yes, bring a SECOND personal laptop for project management and your personal work!
- Use a USB thumb drive or SD card to get data off the laptop, don’t connect to Wi-Fi (where the Wi-Fi password can be hacked)
- Don’t create a super-user account – just use root
- Use public Wi-Fi or at the very least, don’t connect from inside of your own network
- Use a VPN service
- Use Tor
- Optional – use VirtualBox to install a generic, non-identifiable version of Windows so that you can run Windows-based utilities like Cain and Abel from this same laptop
- When done, rebuild the laptop
You might have different needs, but this is what comes to mind for me:
- In-office, testing your own systems – use anything, but I mostly use a VM with SSH and xrdp installed. That exposes two ports on the network, but at the office it doesn’t matter. This trades security (which isn’t needed) for convenience.
- In-office, testing other real systems – I would never do this. The recent Hacking Team hack shows that a poor operational security (OPSEC) can/will be the downfall of a cybersecurity company. Even with VPN and Tor, the last thing you want is THIS sort of network traffic coming from your company’s internet connection!
- Remote, testing other real systems – depending on your location, use a fresh laptop, public Wi-Fi, VPN, and Tor. If you have extra plugs, bring a handful of Raspberry Pi’s (also freshly formatted) to give you extra bandwidth and who can act as botnet to accomplish a lot more at once. Each PI has a quad-core CPU, 1GB of RAM, and a gigabit network card – but they are the size of credit card, and can run all of Kali! Imagine the things you could run in parallel?!
- On-Prem, testing other real systems – use a fresh laptop, and definitely bring some Pi’s to offload the work. If possible/allowable/needed, you could also plant the Pi’s behind routers where you wouldn’t necessarily have access, to create a callback connection. That would depend on the engagement, but the Pi’s give you lots of possibilities.
With all of that said, I use a VM at home to test my “victim” machines, which is why I have SSH and xrdp installed. However, for a real engagement, I just wanted to clarify that I would never do that with a live setup. Instead, I’d likely take an approach like above.
If you are going to do pentesting or computer forensics, using the Kali Linux distribution is pretty much the default way to go. Again, it comes with 600+ utilities including everything you might expect like: nmap, metasploit, burp, wireshark, etc.
This distribution already helps you keep your installation safe from hacking, but it can’t do everything. If you don’t pay attention to OPSEC, you could end up in real trouble. If from this laptop – you connect to Wi-Fi, check your e-mail, have data still on there from your last engagement, have a username/password that you also use to log into your bank… you know, all the same stuff YOU would look for! If you do that with your “attacker” laptop, you could not only be hacked, but you could compromise your former clients, and even your personal data.
Have a dedicated machine for doing attacks – wipe it early and often. Don’t cross-contaminate your personal credentials, Wi-Fi passwords, etc!
So, Kali gets you well on your way, but it’s equally important that you are careful how you manage your pentesting and forensics efforts!