I finished Penetration Testing with Kali (PWK) and improved Nmap (just a notch)

My experience during the course in preparation for the OSCP and a little rant.

Sep 7, 2018 · 7 min read
Photo by Dil Assi on Unsplash

This week I finished my two month of PWK. I got through most of the machines, even the harder ones and into other subnets. I did it part time, so I worked and did the lab. In short: Two very intense months, but totally worth it. A truly mind bending adventure.

Organizational Matters

Offensive Security is doing a great job! I had no issues at all. No VPN downtime, connection issues or bugs (besides the intended ones, of course). A very well explained setup guide. Everything went smooth. So nice! They even corrected the invoice for me, so that I got no problems to forward that to my company in the right format. Thank you very much!

I have only one point, which is bad, but not really the fault of Offensive Security. (Read my rant at the end of the article.)

The Lab

Everyone says: Start with the course material, then look at the videos and then start the lab. Of course I ignored that. What should I say? I learn a bit different than other people. I like to see the problem and then work on the solution, not the other way round. But I have some experience in penetration testing, so I compared my skills with the course syllabus and tested myself.

I was pretty pleased that I got far more machines than I expected in the first two weeks. Then I grabbed the course materials, read through the PDF and watched the videos. It was entertaining in two ways: The first was that I learned a lot during the exercises, which are mostly fun. The second was the face palming while reading all examples, which gave away one or more entry points for machines in the lab.

The Learning Curve

You feel a bit dumb at that point. Of course I should have known better. I taught students myself for years and did the same thing to them. So if you are stuck on a machine: RTFM! The student forum is a big help, too! Maybe you are still stuck, you can dig up some pointers. There is really no need to bang and slap a service for hours, when it is the wrong one.

I scanned and enumerated every machine I could get my fingers on and after I was finished, I made a top 3 list of attack vectors. Then I read in the forum the posts about initial compromise. So I could measure, if I was right or not. I improved drastically. The first machines took me long and I was often wrong, but the later ones were a lot faster and more precise. In comparison these machines had roughly the same difficulty. I did the same with the privilege escalation.

German Efficiency

In the lab you can spend days on one machine. But during the exam you have only a few hours per machine. This was my biggest focus. Get fast enough and still see the needle in the needle stack. (Yes, there are a lot of rabbit holes and I spent days in them. Its fun. It teaches you something. But you do not want to do this in the exam, right?)

The second focus was to use as little Metasploit as possible. You can only use it on one machine in the exam. So I ported some exploits from Metasploit to Python. I learned a lot, again. Only to find out, that there is something like GitHub, which contains a lot of useful stuff. (Cpt. Obvious has a really hard punch.) I learned again to search not only with Google. Make a list of resources, where you can look up stuff.

Train As You Fight

Don’t get me wrong. I still trained with Metasploit. After I rooted a machine, I tried it with Metasploit. Sure it is easy then, but still you will learn a lot. Some exploits do not have enough space for payload. So you can’t use a non-staged reverse shell. The only one you can fit is a staged meterpreter. Yes you can implement your own staged payload, but maybe not in an exam situation. So I rooted these machines with Metasploit.


There will be a phase, where you get bored, annoyed, angry or mad. For me it was the fact, that I did not root a machine, because my methodology was broken. So do not waste that feel. Make use of it! I banged and slapped a service, which was perfectly fine, for hours. Only to find out that I already discovered the correct way. I analyzed my fail and build a fix, literally.

I scanned all machines in the public network with Nmap using --webxml and saved the scan as XML. I looked at it with Firefox from time to time to keep track of my analysis and direct further enumeration in the right way. I was too lazy to reformat the document, so some parts were outside my viewport. So I missed a piece of information which led to the incident above. It was totally my fault. I was using the document in a wrong way.

So a big shout-out to Benjamin Erb, who wrote the first XSL (aka --webxml) for Nmap. Thank you very much, it served me well for years!

The Fix

I wrote a responsive version of the Nmap XSL, which transforms the XML file to HTML. Details, screenshots and demo document on: https://github.com/honze-net/nmap-bootstrap-xsl/

This got even some attention on Twitter. In retrospective I am very thankful for my mistake. This forced me to build something new. I like that push.

Sharing is caring!

Let’s game it

I scheduled my exam for October. In the meantime I will work on Vulnhub and HTB to stay in shape. This also gives me time to review my notes and work on my weak spots. I decided not to write a lab report and leave the 5 extra points out. There are only some cases where these 5 points will help me and the probability is around 15% to hit this zone. (This does not mean, that I pass the test with 85% probability.) I did better to do more machines and get a better methodology, than to write things up I already knew. This is the kind of game theory I took into consideration.

For starters in the field I highly recommend to do all of the exercises. Not because of the 5 points, but because of the great learning effect. I learned about XSS and SQLi painfully while writing my own content management system 15 years ago. My first buffer overflow exploit was in 2009. I learned a lot about computer architecture during my time at the university. I built a reverse shell with OpenSSL. I love that stuff. So take this with a grain of salt. I specifically trained on my weakest spots. This is how I raised the bar. I wanted to maximize my learning effect. I am very pleased with the result.


I am a different person now. Before the PWK I knew I had some knowledge about penetration testing. After the PWK I know I have everything I need to “hack the planet”. I still use mostly the same tools. But I look at the results in a different way. This is the key.

A Rant Beyond Reporting

I want to end this article with a statistically insignificant, but entertaining poll on Twitter. The only criticism I have, is the way we report our findings. During the course you will learn to write a full-blown document as report. And your exam documentation is a full-blown report, too. This is something you should learn, because it is today the most popular way to report a penetration test. To me, it feels wrong. No, not to learn to write a report. That is perfectly fine. No: Why write a lengthy, inaccessible PDF, DOCX, XSLX or even PPTX? Ever tried to extract source code from PDF? This is only the beginning.

What is a finding in a penetration test? It is a bug, right? Either a sysadmin was lazy or a developer had a bad day, or the other way round. Or even something totally unrelated, because sysadmins and developers are the cool people who are fixing these utterly grotesque findings we report. So why on earth will you squish all your information in such a bad representation format, only that the management can have a printed piece of paper and only read the first two pages?

I get emails by administrators and developers, who ask me to explain the finding, again. Why? They received a simple mail by someone who spent days picking apart your report to distribute the action items:

Hi Bob,

What do you expect? This is hell! Nobody wants to work like that. Why not write a ticket for each finding? So a penetration test report to me is a living document containing:

  • Overview
  • Management summary
  • Technical summary
  • Each finding as ticket, service request, item in a kanban board or whatever suits your company.
  • Note about the status of the report, after closing all tickets. (Accepted risks, wontfixes, etc.)

You can draw burndown charts and report the status automatically to your management, if you like. No manual checking of Excel lists, only to find out that nothing has changed, since the last check. And you, as penetration tester, can read about each and every fix in order to review and improve your reporting skills and quality. (I had one guy, who shutdown https completely, because I said that SSLv2 and 3 are insecure. Lesson learned.)

Repeat after me: PDF is the acronym for Push Down and Forget. DOCX is the acronym for Destroy Other Colleagues eXperience. XLSX is the acronym for eXtorture Life and Sanity eXplicitly. The endboss is PPTX and it is the acronym for Push Problems To eXecutives.

You cannot unsee that. There is no way back! You are welcome!

Thank you for reading. I hope it was half way entertaining and informative.


Written by


www.honze.net — 1+1=10 — München

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade