Pentesting With Kali

Review: Penetration Testing With Kali Linux

The web page for the class states “Penetration Testing with Kali Linux is an entry-level course …” For a few years I had ruled out taking the PWB (now PWK) class specifically because of that statement. I was also told on good authority that I would be done with the class in only a few days. I thought, okay whatever, maybe I’ll pick something up but at least I get a few CPE’s in the process to feed the other cert that I’ve bothered to maintain. I came into this class seriously underestimating what it was all about.

So about the course. The material is good, better than most, you recieve a (PDF) book, and series of videos, you are also provided RDP access to a Windows client in the lab for working on some of the exercises. The exercises are very clear, and if you pay attention and follow along, you will be writing your own exploits from scratch in no time. I was actually surprised about how easy and how clear that they made some of the topics. But really, it is very much like any other training class. Until you get to the labs.

The offsec labs really set this course apart. There are many more challenges than I expected. I was anticipating half a dozen, maybe a few more machines to exploit, but no. More. A lot more. Over the course of a few months I compromised more than forty machines in the labs, and I still had more to go. I would have liked to keep going, but I needed to get back to having a life; I liken the offsec labs very much to the best video game ever. It’s addicting, be warned.

Finally, the last part of the course was the certification challenge. Twenty-four hours to perform and report on a pen-test of a small network of machines with no prior-knowledge of the challenge. No vulnerability scanners and no autopwn allowed. It was exactly as difficult as I expected, having worked through most of the labs I was ready—very ready—and didn’t need the full time allotted. That said, by the time I was done I was tired, and glad that I started with the hardest challenges working towards the easier—I was making mistakes by the end that would have likely changed the outcome if I had worked from easy to hard.

Entry level course? Sort-of. The class covers the basics. But getting through the labs requires not just an understanding, but mastery of the basics; so ya the class is entry-level in that sense, but getting root on every machine in the lab is far from basic. My goal was to get everything on the larger “public” network in the labs, and I fell short by one system. Unless you are already very good, and some of the students I met on IRC were, expect to need a lot of lab time. If you are serious about getting the certification, then just start out with as much lab time as you can afford.

Some Advice For Surviving the Labs

Organization is the key to getting through this course. Not only for getting through the work, but the documentation requirement. Keeping all this organized in your head is hard enough, putting it into a report, well that’s where the money is. My advice is to keep good notes. Not just good notes, but print-ready notes. Having notes that are already formatted for your final report will save you hours and hours (days?) of work at the end of the course. I tried using many different programs for this, from the suggested keepnote (great for taking notes, but atrocious for getting them out and into a report,) to evernote, onenote, and I finally settled on using Curio.

Backups are a very good idea. I would suggest going even further and to use a full-blown revision control system, git, svn, whatever. Put everything you do related to the course into it. It will be huge, but being able to un-do mistakes, or bring up a new Kali image in the cloud and have everything synced up quickly is worth the trouble.

Running Kali: I tried a lot of different ways of running Kali, local VM, in the cloud, and finally settled on running it on bare metal. I did this because I wanted to be able to work from anywhere, desktop, laptop, work computer etc. And carrying around my VM on a USB stick isn’t great. Running it in the cloud is easy (just install whatever Debian-7 image the provider has, change your repositories and you have Kali on whatever VPS hosting provider,) but high memory and powerful CPU servers are expensive. Bare metal was the best. I setup OpenVPN, and X2go to supplement using SSH with Socks for my browser. X2go works great, except there is a key-mapping problem when using the Mac client with Gnome—LXDE doesn’t have that problem. Fonts look pretty awful by default in Debian, and this carries over to Kali; using X2go makes it even more obvious, so taking a few extra minutes to setup infinality for rendering will make it look nice and smooth. The other trick is to use a tiling terminal, I prefer iterm2 for my mac, and terminator on Linux. Either allow you to setup pre-defined window arrangements, so you can have the same arrangement up and running … ssh’ed in, msfconsole, htop, vpn connection, all ready to go with a couple of clicks. Between X2go, iterm2 window sets, and a git repository I was able to pick up my work from anywhere in just a few minutes.

Vulnerability scanners (nessus, nexpose, openvas, saint etc.): don’t bother. If you want to learn how to use them, the lab isn’t a bad place, but you don’t gain any advantage by using them in the labs. More likely you will just annoy other students by consuming resources on a lab target that they are working on. More than once I had to deal with someone trying to bruteforce a login password which effectively DoS’ed the machine I was working on.

Metasploit … use it. But most importantly, use it correctly. Metasploit is a bit notorious for making complicated exploits and attacks easy. Yes, it does that, but that’s not where, in my opinion, it shows it’s strengths. Really metasploit has transformed pen-testing. The most important aspect in this class is 1) that it integrates the tools it provides with a database, and is a great resource for storing raw information about the attacks. And 2) it provides so many ancillary tools: encoders, payloads, post-exploitation tools, and pivoting, well the pivoting is pretty awesome. There is some confusion amongst new students working through the labs, that metasploit should be avoided. Mostly because there are specific rules of engagement on the exam regarding the scope of its use. Don’t be afraid to use it, but any part of it that you use you should be able to perform on your own, pivot, post, etc. That’s another philosophical area where I overlapped directly with the offsec course’s core tenants … if you are using a tool, you should be able to perform what it is that the tools can do, without the tool. (I admit however, writing my own staged shellcode by hand is a bit beyond my capabilities, so I’m not quite to where I’d like to be.)

Exploits: Keep track of the exploits that you use throughout the course, and manage them in a way that you know what it does, where it came from, and what modifications you made. I used a naming scheme like wnt.w2k8-local-2013-2660-edb25912-epathobj-system.cmd.exe ya it’s long, but I know what OS, that it’s a priv escalation exploit, the cve, where I downloaded it (exploit db number) and the modifications I made (in this case it’s been modified to run cmd.exe using system() instead of the ShellExecute function.) Serve these up from your web root so they are easily accessible in the labs. My advice, is to go and download the most popular exploits at the beginning of the course, and have them ready for use. There’s a number printed between the exploit description and platform on the search results page on exploit-db.com, that represents how many times it’s been downloaded—that is a good indicator of what exploits are likely to be your best bets.

IRC … as you work through the labs, use the IRC channel. Meet your peers, make some friends, maybe learn a new technique or two.