Windows Nano Server “Instance DefaultGateway already exists”

While building out a lab environment for my MCSA 2016 studies, I came across an error while deploying one of my Nano Server images:

I received the “Instance DefaultGateway already exists” error. This error occurs when you add the default gateway, change the IP address or enable DHCP, and then try to use the same IP address and gateway as before. For me, I set the IP and gateway, enabled DHCP, decided not to use it and disabled it, and then tried to manually set a hardcoded IP again. Nano Server kept the default gateway ( in the routing table, so when I tried to toggle DHCP and set the IP address again manually, it still had the default route stuck.


The FIX:

Go back to the Recovery Console, then go to Networking, select your network adapter, and then press F10 to alter the routing table. After that, find the index for your gateway route (in my case, route index 3), press the DELETE key, and then type in the index number and press enter. If you don’t immediately see your route in the Routing table, you may have to use the down arrow to scroll. After deleting the route, you’ll now be able to add in your Default Gateway IP address in the IP Configuration area.



How I Prepared for the PWK Course and OSCP Exam + OSCP Exam Review

Now that the dust has settled and I’ve had a moment to catch back up on work and personal life, I wanted to write an article detailing how I prepared for the OSCP exam and share some helpful tips and tricks on how to get the most value out of the course and prepare for the exam. I’ve also received a lot of questions via LinkedIn on how to best prepare for the exam, so I think this can also be helpful to those individuals as well. For some background, the Penetration Testing with Kali Linux (PWK) course is meant to prepare you for the Offensive Security Certified Professional (OSCP) exam. I’ll elaborate more on the course below, but for now, the general path to passing the exam is PWK -> OSCP. It took me about 5 months of study time with about 13-18 hours of study time each week on average. There were some weeks where I spent the entire week tucked away in my home office studying (3+ hours each weekday, 12+ hours on the weekend), and there were some weeks that, due to school or traveling for work, I didn’t even look at the material.


Preparing for the PWK Course

Everyone has heard just how difficult the OSCP exam is and how it is one of the hardest cyber security certifications, and possibly IT certifications, to pass. In my particular case, this the difficulty made the certification a little more enticing to obtain but more importantly, it made me want to ensure that I would pass by over preparing. In doing my research of what other people had to say of the course and exam, I read countless stories of people who failed multiple times or ran out of lab time due to life and needed to extend the lab time multiple times, etc. I also came across success stories, and noticed that many of those who passed the exam recommended that if you are pressed for cash and/or time to spend on the labs, do as much preparation as possible before enrolling for the course. This is a sentiment that I will echo as well, as I prepared before the course and STILL ran out of lab time after having started with 90 days initially. Given that I was going to pay for the PWK course 100% out of pocket, I wanted to make sure that I prepared as much as possible to reduce my time in the PWK labs. I won’t re-invent the wheel by creating a prep guide, but instead will link (and give credit where it’s due) to the prep guide that I followed before starting the PWK course – Tulpa’s Preparation Guide. The Cybrary videos referenced in the prep guide cover the same content as in the book, so you can either read or watch videos – whatever you prefer. The videos are free but you would have to buy the book, which runs ~$16 used on Amazon.

To complement this guide, I also recommend that you setup a home pentest lab. This doesn’t have to be anything too crazy, but just setup a Kali Linux system as well as an unpatched Windows 7 or XP system and test out what you are learning. Microsoft has Windows 7 VMs that you can download and test here. For Windows XP, you may have to reach in your closet for an old disc or after going through the Google-FU section of the preparation guide, use your newfound skills to see if anyone has left any XP ISOs hanging out on their public webserver that may have *cough* “Index Of /” in the title of the page…*cough* (sorry I gotta get that cough checked out). [As an aside, I’m about 80% done with writing a guide on how to build your own full-blown pentest lab with the oVirt hypervisor. I was writing the guide prior to starting the PWK course and got caught up with that. Now that I’m done, I should be finishing up that article soon.] You can choose to deploy these VMs on your local system using VirtualBox/VMware (type 2 hypervisor) or if you want to be fancy, you can use ESXi/Proxmox/Hyper-V/etc (type 1 hypervisor). My recommendation would be to use a type 2 hypervisor for now, since you’ll probably want to be able to easily access the desktop/GUI of the Kali machine to run tools. Setting up the lab is essential because the OSCP is a 100% practical exam – there are no multiple choice/fill-in-the-blank/short answer questions. It is a 100% evaluation of applied skill by way of demonstrating that you know which tools and methodologies to employ to hack a system. Simply reading about all of these tools and techniques and jotting down notes won’t cut it, so make sure that you’re getting the full value of your time.

Another major benefit to setting up a lab and going through this guide is that it will quickly let you know where your gaps lie and what you’re already good at. While preparing, I found out that I don’t know Metasploit as well as I thought I did. I’ve spent my entire security career being a defender. As such, I’ve only used Metasploit three or four times in the past 5 years and the prep revealed that I didn’t remember much about how to use it (though I do know how to detect its use on a network). That was definitely a skill I sharpened before starting the PWK course, whereas Google dorks, scripting (both bash and Python), and traffic capture were all skills that I am more than decent in. In my preparation (and in the PWK course as well), those were all sections that I skimmed over.

The last point I’ll make about going through this prep is that you also get to gauge how much time you can spend studying. Think of this prep guide like a trial run – if you find that you can spend a solid 10-15 hours a week going through this guide, watching the videos, and testing out what you’re learning in the lab, you should be good to continue on with the PWK course.

The best part of this prep is that up until now, everything is 100% free (minus the $16 for a used copy of the book should you choose to buy it – which I recommend) and can be done at your own pace.

TL; DR: Follow Tupla’s prep guide, setup a home pentest lab with Kali and a Windows system, and sit up before you crawl (take the PWK course).


Taking the PWK Course

After making it through the preparation guide, I signed up for the PWK course with 90 days of lab time. The course teaches you the pentest life-cycle and tools in a hands-on way by giving you access to a virtual lab where you can (legally) use the tools and exploits you learn about to hack the systems in the lab environment. The lab is meant to simulate a corporate environment (thinc.local), where you can optionally make your way all the way to the admin network by leveraging lateral movement techniques. Below is a quick picture from Offensive Security showing the layout of the lab:

From the picture, you can see that there are some machines that may be linked to the Dev network, and some machines that are linked to the IT network, and some IT assets that are also connected to the admin network. This setup is no different than what you’d find in a corporate environment – some users have more access than others and can reach more network segments than others. Your job then, is to find these systems and use them to pivot to the other more trusted systems. The discussion about pivoting is getting a little ahead of myself, but I wanted to point it out since its hard to ignore when looking at the picture. Before worrying about pivoting into different networks, you’ll be dropped into the Public network first, which has about 39 machines.

The course comes with a PDF and accompanying videos to help guide you through the course material. Each chapter comes with exercises at the middle and/or end that help you reinforce a topic and apply what you’re learning. If you went through the prep guide I discussed above, the first 4 chapters should be a breeze and easy to comprehend. The following 13 chapters go over more hacking techniques and tools, and the last chapter of the guide and video gives a simulated walk through of how a pentester can traverse a multi-segmented network and eventually make their way to the admin network and compromise an Active Directory Domain Controller. Before jumping into trying to hack lab machines, I strongly recommend that you finish all of the course material, do the exercises, and take notes. I understand that everyone is different and there’s no one-size-fits-all approach to this, but there are a lot of benefits to completing the course material before jumping into the labs:

    • This course is unlike most traditional certifications in that you aren’t hand-held or guided (too much), which is by design because this is not how hacking or pentests in the real world are conducted. You won’t learn a hacking technique/tool and immediately know what server to practice it on. As mentioned earlier, you’re dropped into the public network with 39 machines and you’re not given any context as to what techniques or tools can and/or will work against that machine, however most of what you need to know to hack the lab machines can be found in the course material somewhere.
    • This is more of a personal preference, but I like to over prepare, or in this case, be prepared. Continuing the point above, as you come to new systems in the lab, you want to make sure you have a toolbox of exploits and techniques that you can draw from to hack the machines. If all you’ve learned so far is buffer overflow exploits but the system can only be compromised via a SQL injection,  you’ll spend your time banging your head against a wall wondering how to gain access to the machine when simply reading through that one lesson in the course material would have you immediately know what to do or try next.


Note Taking & Keeping Organized

To take notes, I used OneNote on my actual Windows computer for the cloud syncing functionality. Others have reported using CherryTree or KeepNote inside their actual Kali VM, but I haven’t used those tools and can’t comment on how well they work or don’t work. The most important thing though, is that you are taking notes and that they are organized. The utility of CherryTree/KeepNote/OneNote is that you get to create tabs and pages to help you keep organized. You should be taking notes for each of the chapters in the course, and also taking notes when you hack machines so that you know how to get back in. Below is a screenshot showing how I took notes for each machine (the [+] represents machines that I’ve hacked):

For any files containing exploits or enumeration script outputs, I stored them directly on my Kali machine. I created a folder called “machines” on my Kali VM, and then created a folder for each lab machine and stored the scripts in there:

It also worth noting that you can earn an extra 5 bonus points on your OSCP exam attempt if you write a pentest report for 10 lab machines, as well as provide screenshots/documentation of completing the course exercises. For this reason, it may be worth it to write your lab notes in a semi-pentest report format instead of just dumping in a bunch of screenshots (see my screenshot above). This way when it comes time to do your lab report and you pick 10 machines for your report, you don’t have to do too much extra writing. They do provide you with a Pentest Report Template, so you won’t have to worry about creating your own format and style (but you are more than welcome to).

Building a Pentest Methodology

This is technically part of note taking, but I believe it should be called out in its own section. You should build a pentest methodology to help you enumerate, and ultimately, hack lab machines. Your pentest methodology should be built in a if-this-then-that format, to where you know what commands/tools/techniques you should try as you hack each lab machine. As you successfully compromise each system in the lab, you should be making sure that all steps that you took are captured in the pentest methodology so if those same conditions re-appear on another system, you immediately know what to do. I’ve provided a screenshot example of what mine looks like:

Now you may have noticed that I fuzzed out most of my methodology doc…and that’s because I don’t recommend that you use someone else’s methodology document – it’s more worthwhile to build your own. The pentest methodology is more valuable to you and, in my opinion, makes more sense if you’ve gone through the manual processes to build the techniques, tactics, and procedures (TTPs) captured in the methodology. Some of the value from learning is lost if just following a pre-made script that someone else made. To clarify, there are Windows privilege escalation guides as well as those for Linux, and those are fine to reference.


There are awesome tools such as Reconoitre that can automate a lot of the enumeration processes for you. I would recommend avoiding these scripts in the beginning of your lab time so that you can learn the tools individually and gain an intimate understanding to their strengths, limitations, and purpose. Once you know how the enumeration tools work, and you don’t feel like re-inventing the wheel, feel free to go ahead and use scripts made by others. For a more engaging/valuable experience and if you have the time to spare, I’d recommend that you create your own automated enumeration scripts, especially if you are new to scripting and programming. Either way, as you compromise more systems, you should make sure you’re automating the enumeration process to make yourself more efficient.

Looting Machines

One thing that I enjoyed about the labs is that certain machines contain interesting, and sometimes hilarious, text documents and email exchanges between the fictitious co-workers at “thinc.local”. After successfully gaining root/Admin privileges on each system, I recommend that that you dig around and see what you can find. This is your chance to be as nosy as you want to be and often times, you’ll be rewarded for doing so. Sometimes you may find a text file that a user saved to “remember to replace X Anti-Virus software on Y’s computer next week”, instantly telling you what AV software one system is using, or you may find a script that has a plaintext password saved in it. While we’re on the topic of passwords, make sure that you are dumping  and saving passwords when and where possible. Remember, this lab environment is made to simulate the real world. Just like how users (unfortunately) re-use passwords, you may come across some instances where a user’s password found on one system is the key to compromising another. Below are some examples of how I kept my dumped passwords organized:

If you get to a system that requires a password and you already know the username, immediately jump to your password store and see if you have a password for that user.

Exam Preparation

Now to the question I’m sure most people are hoping to have answered after reading this post – How many machines should I hack before I should consider myself ready for the exam? Are you ready for an underwhelming answer? No? Well that’s all I have unfortunately, heh. The answer is, I don’t know. I REALLY wish I had a more concrete answer to give you, but the truth is, I don’t know and anyone giving an answer is, at best, guesstimating. There are some people who hacked 25 machines and passed, and there are some that hacked 35 lab machines and failed. Being the over preparer that I am, I wanted to make sure that I hacked all of the machines in the public network and at least make it to the admin network before attempting the exam. I ended up being able to hack 48 machines – all of the systems in the Dev and Admin Networks, all of the systems in the public network except for one, and only two systems in the IT network and technically passed the exam in 10 hours (I’ll get into that in my exam experience). Here’s where and why things become a tossup in regards to how many machines you need to hack in order to pass:

  • Having passed the exam, I can say there is one technique in particular that I learned from a lab machine that I used to help me hack an exam machine. I feel very confident that if I had not hacked that specific machine in the lab and learned that technique, I probably wouldn’t have quickly recognized that I needed to use that technique on the exam. It may have been possible that I would have (eventually) hacked the machine, but keeping in mind that the exam is timed to 23 hours and 45 minutes, you’ll want to make sure you get through the machines as quickly as possible. It’s possible that someone can hack just the right machines in the lab and learn everything they need to pass, and someone can hack all the machines in the lab BUT the one(s) that would help them on the exam and fail.
  • Experience also plays a huge factor in how ready someone is. Someone who is green to pentesting or offensive skills may need to hack more lab machines than someone else who has more experience in that arena. I probably could have passed having hacked less machines, but I don’t think that, being as green as I was, I could have gotten away with hacking only 25 machines and taking home the prize.
  • How much you absorb in the course also plays a huge role. There are times where I could have simply blindly download someone else’s exploit script and ran it, or even worse, just use a Metasploit module to hack into a system, get root/Admin privileges, take my screenshots, and just call it a day. But if I did that, I wouldn’t really have learned much. There are subtle things you learn by looking at someone else’s exploit scripts and trying to figure out why they did what they did, and you wouldn’t learn these subtleties if you just blindly ran something that automatically gave you access to the system. Of all the 48 machines I compromised, I only used Metasploit for 4 of them. This gave me lots of opportunity to experiment with scripts and manually exploiting systems. More importantly, on the exam you can only use Metasploit once, so I did not want to get hooked on it. Ultimately, if you really want to learn, keep in mind that this is a process – a long distance goal and not a sprint.

For the reasons given above, I would recommend that you try to hack as many lab machines possible before taking the exam and build a solid pentest methodology.

Before taking the exam:

  • Make sure that you have a pentest methodology of some sort (I know what you’re thinking, “If this guy says pentest methodology one more time…”). This can bail you out if you get stuck in a rabbit hole or don’t know where to go once you reach a certain point. There’s many times where I relied on “muscle memory” to hack systems and then get stuck for 40+ minutes, trying things that I think should work and failing when the next step was already written down in my pentest methodology. Just to hammer that point home, the pentest methodology should be a checklist of things to look out for as you gain access to a system and as you elevate your access to a system, you should be enumerating and consulting your methodology to help guide you if you get stuck. Also go back through your lab machine documentation and make sure that each enumeration/exploit tactic is captured in the pentest methodology.
  • Have some automated enumeration scripts, either self-authored or something like Reconoitre
  • Plan to take the exam when you will be most awake and alert. I’m a mid-morning person and feel best when I wake up at 8AM, so I scheduled my exam for 9AM
  • Secure a quiet, distraction-free zone for you to take the exam. If you have a significant other, let them know that you’ll be M.I.A for 24 hours and may have some odd nap/sleeping patterns that day
  • Study/review what you feel you are weak on up until the day before your exam. The day before your exam should be spent relaxing and doing something else other than trying to cram last minute information in your head. You want to make sure that you approach the exam with a fresh set of eyes that haven’t already been exhausted because they’ve been staring at the computer screen all day prior.
  • Become familiar with the exam requirements. On the day of the exam, you will be given a set of instructions to follow for how to document your exploits on the various hosts. It helps to know the expectations before the exam, so you don’t waste exam time reading it and getting familiar with it for the first time.

TL;DR: Do all course modules before jumping into the lab machines, take great notes, build a pentest methodology, write your own scripts if you have time to spare/want to learn more scripting, loot machines, and make sure you do plenty of crawling (hacking systems) before you attempt to walk (take the exam).


Taking the OSCP Exam

My exam was scheduled for 5/21 and I made sure to take that day off, as well as the day afterward so that I could write my pentest report and catch up on any sleep I lost on the exam day. The day of the exam, the Offensive Security team will send you an email package containing an OpenVPN file for connecting to the exam environment, instructions on which IP addresses are targets for the exam, and a link to the exam control panel. I won’t go into too much detail on how the exam works, as the Offensive Security team has already done a good job detailing exam guidelines here. Instead, I’ll highlight my experience with the exam and give some of my tips at the bottom. If you read the earlier portions of this post, you may remember that I mentioned that I technically passed the exam in 10 hours. I’ll go more into detail on that….This is quite a bit embarrassing and a huge facepalm moment, but in the spirit of full transparency I’ll share my not so hot moment: I was using my my lab IP address (10.11.0.x) instead of the exam IP address (192.x.x.x) for the shellcode that I was generating, so none of my exploits were working. Sigh…I quite literally smacked my forehead once I figured out why none of my exploits were working. For some reason, it didn’t even click to me even after noticing that the exam IPs were in a Class C subnet. I guess I was so focused on making sure that I passed the exam in time that I missed that (not so little) detail. With that said, I wasted ~12 hours of exam time trying to get exploits working, partially because I’m stubborn, but mostly because I KNEW I was doing everything 100% correctly but I just couldn’t get a reverse shell back. What made this the perfect storm was that I almost expected the exam to be non-straight forward and difficult, so the fact that I was having issues getting a reverse shell only further played into my feeling that the exam was difficult and that I needed to try harder. I have more of my experience detailed below with a time-frame breakdown:

9:00 AM CST

I received the email with the exam connection information exactly at 9 AM. I immediately connect to the exam VPN, and start creating my folders for each exam IP and start my enumeration scans. While the scans are going, I’m reading through the exam guidelines on how I should capture my proofs and record my exploit steps. One of the first exam systems that caught my eye was a machine that had a vulnerability that I had practiced exploiting two days prior, so I knew that would probably be the easiest machine to go after. I then go through the motions of compiling the exploit, generating the relevant shellcode, and then tried to run it and…nothing. “Ok, maybe I screwed up on one of my steps,” I thought. I went through the steps pretty quickly and took a shortcut for a few of them, so I figured that I must have accidentally skipped a crucial step that was causing it not to work. I then went through the process again, making sure that I followed each step correctly in my abbreviated notes. I ran the exploit again and…nothing. “Ok, maybe I screwed up my abbreviated notes,” I thought, so I went back to the course material and followed the steps again, making sure that I followed each step again, and ran the exploit….again. Still no dice. I even went back and watched the course videos on that section, ran through all the steps again, and had no luck still.

2:00 PM CST

They say the definition of insanity is doing the same thing over and over again, and expecting different results. Well, that day I was insane. I continued trying to manually go through the exploit steps from start to finish for ~5 hours for that one system. I persisted out of stubbornness and partially because I was desperately hoping that in one of my attempts, I’d have a wonderful breakthrough (despite doing the same thing over and over again). At this point, I decided that I was going to move on to another machine and come back to this one later. I moved on to another machine and it was more of the same – I tried generating shellcode and was (unknowingly) using the wrong IP address, so it didn’t work. Again, I felt confident that I was doing the right thing, but tried many different ways to replicate the exploit but no dice. I even spent a fair amount of time trying different exploit scripts found from different sources – still nothing.

4:00 PM CST

That whole insanity thing? Yea…apparently I couldn’t get enough of it. I tried the previous machine for a few hours while also trying to research what I could be doing wrong. At this point, I started to feel defeated, but still felt like maybe I just needed to find my footing. I moved onto another machine and…you guessed it – still no dice. I started feeling dejected and pissed off, and took my first break of the day. I would take microbreaks here and there to check social media and Reddit, but this is the first time that I got up from my workstation and walked away.

6:45 PM CST

After my break, I came back determined to figure out what I was doing wrong and immediately jumped back to it. I also turned on the Cavaliers vs Celtics game and was lightly watching that in the background while I worked. I decided to move onto a third server and ran into the same issue as before – I just couldn’t get a reverse shell no matter what I tried. I repeatedly tried going about exploiting the vulnerability and fell flat on my face.

9:00 PM CST

At this point, I accepted that I was probably going to fail the exam. I wasn’t having any luck on the past 3 machines that I was targeting and was getting nowhere fast. Just about 12 hours had passed and I spent them stubbornly trying to force myself to hack those three servers. I seriously contemplated giving up and just turning off my computer out of frustration and watching the game instead. I was angry and confused at how I could exploit so many lab machines but couldn’t get at least one machine on the exam. It wasn’t until I switched to a 4th machine and finally found something interesting that everything began to turn around for me.

9:12 PM CST

Switching to the 4th system gave me the breath of fresh air that I needed. I gained an initial foothold on the system and eventually made my way to get a low privilege shell. While in the shell, I ran the netstat command and was looking for my lab IP address (10.11.0.x) but didn’t see it. “Wait, what the…” I thought. “Where’s my IP?” I re-ran the command to make sure what I was seeing was correct, and then I saw the port I knew I was connecting to on the remote machine and an IP I’ve never seen before. I immediately ran ifconfig on my Kali machine and saw that the exam VPN added the tap1 interface (tap0 was still connected to the lab network) and I had a different IP address for the exam. I felt like I was trying to play golf for hours and someone walked up to me and told me that I’ve been holding the club upside down the entire time. After literally smacking my forehead and yelling some obscenities, I continued working on the fourth machine, taking note that I have a different IP address.

11:30 PM CST

After getting pretty far with the 4th system and hitting a wall, I tried my hand at the 5th system. Based on point value, I assume that it was the hardest. I wanted to see if I could immediately find anything exploitable on the machine but quickly lost interest as I was more anxious to see if my IP address issue would resolve the problem I was having with the exploits on the other systems.

12:00 AM CST

I went back to the very first system I attempted to exploit and made sure to use the right IP address for the shellcode I was using. After swapping in the relevant shellcode and running the script, my terminal window showed me something that I was all too relieved to see – my netcat listener received a connection back from the victim. While grinning ear to ear, I made sure to take all the relevant screenshots and capture the contents of the proof.txt file. I still remember thinking at this point, “Well, at least you’re going down with somewhat of a fight. You’ll get the exam next time.”

1:18 AM CST

Immediately after hacking the first machine, I went back to the second one I was poking at. In a similar fashion, I made sure to update my exploit with the proper shellcode and tried it, but it didn’t work. It turned out that I was using the wrong exploit, but after finding the right one and making sure to use the correct IP address, I was able to hack this machine as well in about 1 hour and 45 minutes. With a slight bit more confidence, I decided to continue trudging on to see if I could add any more machines to my victim list before I failed the exam.

2:21 AM CST

While working on the second machine, I thought of something that I could try on the 4th one to help gain additional access. I re-read through my pentest methodology and found an enumeration command that helped me find something interesting. From there, I was able to exploit the interesting thing I found and compromise the machine to get full admin privileges. All of the tactics and techniques used to exploit that system made me feel right at home, like I was in the lab network all over again. “Don’t get too excited now,” I thought to myself. Even though I had 3 machines at this point, I still hadn’t scored enough points to pass, and time was still ticking.

3:18 AM CST

I switched to back to machine 3, updated my shellcode with the new IP, and then used the same exploit that I had been trying before. Much to my surprise, the exploit immediately worked and I gained low privilege access to the system. I felt myself getting a little happier, but for whatever reason, I had it burned into my mind that I was going to fail so I didn’t allow myself to get too much hope.

4:09 AM CST

After about 50 minutes on this host, I was able to gain full admin privileges on this system as well, making it the 4th machine that I compromised. After typing in “whoami” and seeing the terminal say I had admin privileges, I got out of my chair in disbelief. My mind was both confused and happy at the same time. I was happy obviously because I just hacked this machine, but at the same time oddly confused because I wasn’t sure if this meant I passed or not. I immediately opened up my exam panel and started adding up the points for all of the systems I had hacked so far. My caffeine had been wearing off so I wasn’t entirely sure my mind wasn’t playing tricks on me. I pulled out a sheet of paper and manually wrote down the IP addresses of the systems I compromised along with their associated point values. After adding up all the points, I checked the exam guidelines and it showed that I had passed. More confusion washed over me because just a few hours ago, I was moments away from turning off my computer and walking away from this exam and now I’m calculating my points and finding out that I’ve passed. A few minutes passed by and it finally sunk in that I passed. As excited as I was at that point, the only thing I could feel was sleepiness – I woke up at 7:30 AM the morning prior and it was creeping up on 4:30 AM. I set an alarm for 7 AM so I could take a quick nap and then try my hand at the last exam machine.

7:55 AM CST

After hitting my phone’s snooze button 3-4 times and laying in bed for a few minutes to mentally wake up, I finally crawled back to my desk. I tried to give the 5th machine a good college try but I knew that I was strapped for time (my exam was ending at 8:45 AM) and that I had already passed – there was no need to exert myself too much on this one. In the last 20 minutes of my exam, I found something interesting that I wish I had more time to poke at since I think that may have been a way into the machine. Either way, at 8:45 AM sharp, my VPN connection dropped and I was immediately kicked out of the exam network.


I then spent the next day taking naps to get my sleep schedule back on track, organizing my screenshots, and writing the pentest report. I submitted the report at 3:41 AM 5/23 (I had until 9AM to submit it) and received my “You’ve passed” email back at 5:34 AM 5/24, so there was about a 26 hour turnaround time for my report to be graded.


My Thoughts on the Exam:

Like I mentioned a bit above, after reflecting on my exam experience I realized that I effectively passed the exam in 10 hours due to an oversight on my behalf. However even though I spent a fair amount of time being stubborn and not moving on to other machines, I’d like to believe the most important takeaway is that because I gained a lot of experience from exploiting many lab machines and I actually knew what I was doing, once I fixed my oversight, I hit the ground running. With that aside, I felt that the exam was pretty fair and that if you are doing the labs, absorbing all the little details,  and building a good pentest methodology (okay, okay, last time I’ll mention it!), you should be prepared to pass the exam or at least come 10-15 points shy of passing. Again, there’s no magic number of lab systems to hack before you’re ready for the exam or before you can pass, but if I absolutely had to make a recommendation, I would suggest no less than 23 machines in the public network, and try your best to work your way to the IT network, and get one or two systems in the admin network.

Exam Day Tips:

  • Your IP address for the exam will be different from the IP you use in the lab environment, so keep that in mind. Yea…I shouldn’t need to say this one but there could be more people like me running around out there, so fair warning :)
  • Before exam day, be familiar with the exam requirements. The requirements are open for you to read and get familiar with how the exam is conducted and what is expected of you during and after the exam. Don’t spend too much time reading the rules on the day of the exam – every minute is precious!
  • Don’t spend more than 2 1/2 hours on a machine. If you are poking at a machine and getting nowhere, make sure you’ve documented what you’ve done so far, and come back to it later. This keeps you from stubbornly trying to force something to work when it’s not supposed to or if there’s another avenue you should be pursuing. In my case, I would have found out about the IP address issue sooner rather than later. It’s very possible that when you eventually make it back to the machine, you’ll realize that you didn’t enumerate it as well as you thought you did, or missed something in your enumeration tools’ output.


Hopefully sharing my experience has been insightful or enlightening for someone who’s trying to prepare for the OSCP. I hope you enjoyed reading as much as I enjoyed sharing.

I Passed the OSCP!

Boy, do I feel like a weight has been lifted off of my chest! For the past 5 months, I’ve been studying for the OSCP by way of taking the PWK course. I finally took my lab exam on Monday 5/21, submitted my pentest report 5/22, and found out today that I passed. The day and a half waiting period for the pentest report to be evaluated was a bit unnerving, but it was all worth it once I received the congratulatory email from the Offensive Security team.

I thought I’d have some fun with my exam attempt by doing a timelapse of my 24 hour period. Credit to Austin Scott for giving me the idea, as I saw his video and thought it be cool to make one of my own:



I’ll be writing another blog post detailing how I began preparing for the exam, and also my exam experiences. Stay tuned for more updates.

Setting up FreeRADIUS + OpenLDAP on a Raspberry Pi for Network Device Authentication

One thing that I’ve been meaning to do is setup a central authentication/authorization server for my home network for easier management of network devices and other LDAP-aware software (oVirt). It helps that all of my network devices are either prosumer (Ubiquiti) or enterprise (Juniper/Cisco), so they allow for some form of external authentication via either LDAP or RADIUS. Both aren’t really resource intensive which makes the Raspberry Pi 3 a perfect candidate to run them. This guide covers Raspbian Stretch but can likely be used for any future or older versions of Raspbian.

The image above shows a quick network topology for visual reference. In this guide, the RootDN structure I will be using is, or dc=home,dc=clintonmetu,dc=com.

Installing and Configuring OpenLDAP

First, we need to install the openLDAP packages

apt-get install slapd ldap-utils

After installing OpenLDAP, it should prompt you to setup an admin password. You can type in anything for now, we’re going to reconfigure the package in a moment and you’ll get another chance to set the password. After typing in the admin password, run dpkg-reconfigure slapd to go through the original configuration. We will setup OpenLDAP with the following settings:

Omit LDAP server configuration: No
DNS Domain Name:
Organizational Name: home
<enter in admin password>
Use MDB backend Purge database on slapd removal: No
Move old database: Yes

Once this is done, you should be able to run ldapsearch -x -LLL -b dc=home,dc=clintonmetu,dc=com (or whatever you used as your RootDN) and see some output, similar to this:

This will confirm that the reconfiguration went smoothly. Now, we create an LDIF file to add a new user to our environment. Create a new blank file named newuser.ldif and place these contents in the file:

This will create two new OU’s (Organizational Units) – People and Groups. The Groups OU will contain special groups that we want to add users to (ex. “net-device-users” group for users that have access to network devices, “splunk-users” for users that have access to Splunk, etc.) and the People OU will hold our actual user accounts. Next, we ingest this LDIF into our LDAP server using:

ldapadd -x -W -D cn=admin,dc=home,dc=clintonmetu,dc=com -f newuser.ldif

When it prompts for a password, type in the admin password you created above. Now we have our first user in LDAP, and assigned them to a group.

(Optional) Disable Anonymous LDAP Binding

By default, LDAP allows for anonymous binding so anyone can connect to it and view all of the objects (LDAP Hierarchy, groups you have configured, users, etc) stored within. I recommend disabling this feature to force users to authenticate before they can view the contents of your LDAP server. Create and a new filed named disable_anon_bind.ldif and insert these contents in the file:

Now, import the LDIF with:

ldapmodify -H ldapi:/// -Y EXTERNAL -f disable_anon_bind.ldif

Anonymous binding is now disabled.

(Optional) Setup LetsEncrypt for Secure LDAP (LDAPS)

Since the LDAP server will be used in a home or lab environment, it’s not mandatory to install a CA trusted SSL certificate. I tried to go down the self-signed SSL cert route for LDAP and hit too many walls. If you go down the self-signed SSL route, one thing you’ll have to do is copy the self-signed CA certificate over to each device that will be querying the LDAP server via LDAPS. After going down this rabbit hole for a bit, I decided backtrack and rely on our good friends at Let’s Encrypt to generate certs that are trusted by any device without needing to mess around with the certificate store.

(Optional) Install phpLDAPadmin

phpLDAPadmin will provide a web-GUI for us to add new users and groups, and manage our existing users and groups so we won’t have to generate LDIF files for every LDAP change we make. If you don’t already have them, we’ll need to install Nginx, PHP, a few PHP modules, and two useful tools git and screen:

apt-get install nginx php-fpm php7.0-ldap php7.0-xml git screen

After these packages are installed, we need to generate a DH parameter file for key exchange. This may take awhile, so we can use screen to run this in the background while we do other things:

screen openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096

This will launch the process, and then you can press CTRL+A+D to exit out of the screen. In ~10 minutes you can use the screen -r command to connect back to the screen and see if it is completed.

In the meantime, use your favorite editor to create a new vhost file for phpldapadmin. I created this new vhost in the file /etc/nginx/sites-enabled/ldap with these contents:

Note: If you are not using an SSL, feel free to leave off the lines that begin with “ssl_”

Now, we fetch phpldapadmin and put it in in /var/www/html/phpldapadmin:

Then use your favorite editor to edit /var/www/html/phpldapadmin/config/config.php and make the following changes:

  1. Uncomment $config->custom->appearance[‘hide_template_warning’]  and set it to true
  2. (Optional) Set a custom name for your LDAP server in $servers->setValue(‘server’,’name’,’Home LDAP Server’);
  3. Uncomment $servers->setValue(‘server’,’base’,array(”)); and replace it with the base dn that you used to create the server

The three lines should then look like:

Last, you need to either add your RootDN to your computer’s hosts file or to your DNS server. After that, you should be able to navigate to https://<your-root-dn>/phpldapadmin and it show the phpldapadmin page.

To log in, you use your admin DN (ex. cn=admin,dc=home,dc=clintonmetu,dc=com) as the LoginDN and then the admin password.

Installing and Configuring FreeRADIUS

To start, we install the FreeRADIUS and FreeRADIUS-LDAP packages:

apt-get install freeradius freeradius-ldap

With FreeRADIUS installed, we can now start configuring it to connect to our LDAP backend. The first thing we are going to do is edit the file /etc/freeradius/3.0/sites-available/default and remove the comments in front of the LDAP authentication module so we can use it. On line 502, you should see the following text commented out:

Remove the comments from these 3 lines, and then save the file. Next, we’re going to edit /etc/freeradius/3.0/mods-available/ldap to insert our LDAP details. We will need to modify/uncomment the following lines:

After making these modifications, we need to symlink our LDAP config from mods-available to mods-enabled:

ln -s /etc/freeradius/3.0/mods-available/ldap /etc/freeradius/3.0/mods-enabled/ldap

This makes the LDAP configuration available for use. With that done, it’s time to restart FreeRADIUS and test things:

systemctl restart freeradius

Then run a radtest to test if FreeRADIUS is able to speak with the LDAP server by using your username and password that you created in the original LDIF using:

radtest <ldap user> <pass> 1 testing123

For example:

You should get output similar to above to show that it works. The “Access-Accept” message on the last line shows that the authentication was successful. The last thing we need to do is create a configuration entry for our clients (network devices) and then add some logic to the post-LDAP auth so it knows how to properly communicate to our clients that we have legitimate permission (authorization) to log in. First, edit the file /etc/freeradius/3.0/clients.conf and add a a client block for each of your network devices:

Lastly, we then edit the /etc/freeradius/3.0/sites-available/default file again, and uncomment “ldap” on line 726 (in the post-auth section), and then insert this code right underneath ldap, so the whole section looks like this:

You may have to look up your network device’s VSA (Vendor Specific Attribute) so RADIUS knows how to properly communicate back what your user’s access privileges should be. The two VSAs that I included work for Juniper, Cisco, and Ubiquiti devices to communicate that anyone in the “net-device-users” group should have all privileges on the device.

Now, the moment of truth. For this example, I will use my Juniper SRX 300 to verify authentication and authorization. I configured my SRX300 as such to use the RADIUS server to authenticate and authorize my LDAP user “clint”:

After logging into the SRX300 using my test LDAP user “clint” and the password “clinton123”, I’m successfully dropped into the CLI:

If everything is working, we can now configure all of our services to start on boot:

Converting VMware (VMX) images with virt-v2v

virt-v2v is a tool that can be used to convert images from VMware/VirtualBox/ESXI/HyperV over to KVM. When using it to convert VMware images over to KVM, you may get an error saying no hard disks were found:

Converting VMX files over with virt-v2v requires that you set one of 4 hard disk types:

"disk" | "plainDisk" | "rawDisk" | "scsi-hardDisk"

To find your image’s disk type, you can grep the .vmx file for ".vmdk":

In my case, I only have one disk in this image, and it’s a SCSI disk. Note that “scsi0.0” means that this disk is the first disk on the first SCSI adapter.  Next, you’ll have to echo the disk device type and SCSI bus and disk number into the bottom of the .vmx file so virt-v2v knows how to handle the disk:

And of course, if there are multiple disks, you want to make sure that you echo a similar line in the bottom of the .vmx file for each disk attached to the image. A VM with 3 disks would look like this:

After that change, virt-v2v should be happy:


Reduce Linux Swap File Size When Using LVM

If you’re looking to free up some space on your hard drive, reducing the swap space may be an option. I wanted to migrate my server’s primary drive from a 750GB spinny disk to a 512GB SSD, so shrinking space where needed was essential.  If your swap “file” is really just a LVM volume, you can reduce the size with lvreduce -L <new size> </path/to/volume> but then when you try to re-add that swap partition:

You’ll get an error that the swap file failed to re-mount. Before you can use the reduced size swap file, you must use the mkswap command on the re-sized partition:

After that, all is well:

My swap “file” went from being 32GB to 16GB.

Blog Reboot

After 2 years and some change, I’ve finally rebooted my blog! My goal is to capture some of my thoughts, projects, and research and share them online to give back to the community. I can’t count the number of times I’ve been wrestling with an issue or batting around an idea, and stumbled across the solution on someone else’s blog, so I want to take mine in the same direction. Hopefully if you stumble on my blog, you find something useful!