Hello Everyone! I am back again with another OSCP post!
Hours Spent: ~120 Hours
It’s really hard to keep track of hours perfectly, so give it a plus or minus 10 hour deviation!
Amount of Days in the Course: 14
Amount of Boxes Rooted: 14
Firstly, there is a good reason I haven’t made a post in about a week, and it is because I wanted to dive deep into the labs before making recommendations! Now that I have successfully rooted 14 boxes I feel I can make a well informed post about the labs. So let’s get started!
So far, the labs have been absolutely great. At first I was anxious to just pop a box or two. I really wanted to prove that I could get into an OSCP machine, and this was a bad decision! It is truly about taking the time, figuring out a methodology first, and the rest will come later. I have grown immensely in this past week and my thinking has changed for the better. I am becoming much more comfortable with these labs, and now it has turned into a fun game. These labs are like being dropped into a huge maze blindfolded. At first you’ll be dazed, and probably a little confused! I know I was! My last post was the beginning of the end of that confusion and anxiety. I have now settled into a much better rhythm, and these boxes are dropping like flies! Over these 14 machines I have learned a lot, and I am here to share tips with everyone on what to expect and how to prepare for these labs (at least what I have encountered so far).
Tip 1: Use the OSCP custom machine, and DO NOT UPDATE IT.
This stems from my 11th box. A couple of nights ago I was attacking my 11th box, and all was going well. I had enumerated this box to the best of my ability and I had about 14 different services/softwares with versions in hand. I searchsploit’d and googled. A lot. I could not for the life of me find a working exploit against this machine! I had a fountain of information against this box, yet I could not even pop a shell! What the hell! So, I decided to allow myself to peruse the forums fully, and gather as much information as possible. I did, and everyone pointed to one service. Now, I knew about this service, but none of my scans could fingerprint the version number! How am I supposed to attack a service with no version number? This is a very popular service with LOTS of known vulnerabilities. To blindly attack this service would be like finding a needle in a haystack. After many hours a fellow student gave me some hints via the IRC chat. This went on for another hour or so. Finally, we realized that he was getting a different output for the same exact command I was running. In the end, it turned out to be a bug with one of the enumeration tools, due to me issuing an update on the Kali machine. Lesson learned: Use their machine, do not update the machine!
Tip 2: You don’t know what you don’t know, and that’s okay.
Throughout these 14 machines I have learned a valuable lesson, and that is that “trying harder” isn’t always the answer. Sure, try hard, try really hard. But also, you don’t know what you don’t know. It is hard to identify gaps in one’s knowledge without even knowing that there is such a concept/tool/tactic. On multiple machines throughout these labs I thought I had done “everything” and nothing was working! I was stumped! I am not going to lie, the student admins are a hit or miss. Sometimes they will ask the perfect questions to steer you in the right direction without spoiling anything, and other times they will be of absolutely no help. I do not fully agree with this methodology, as the certification is to gain a strong foundation in the basics of penetration testing, and the course materials do not come close to teaching you everything you need to know. It is a very valuable teaching experience to learn things yourself, but in the beginning, it is okay to lean sometimes! I have used the IRC channel multiple times for help (see above) and that is the only thing that kept me out of spinning in circles endlessly. Lesson learned: Try hard, try really hard, but if you cannot get it, ask for help!
Tip 3: Know when to quit.
I am a very determined person, and sometimes that gets in the way with these labs. Once I dive into a problem, I struggle letting go of it until it is solved. This has caused me to waste a good chunk of time due to tunnel vision. I have now learned to create a middle ground with this issue of mine. As I said in my last post, I use a piece of paper for every box. This has really helped me along the way. When I write down the open ports, services, and possible exploits it helps me gain a better view of the box as a whole. Whenever I get stuck I go grab a fresh sheet of paper, and re-write down everything. This has allowed me to catch many mistakes! Lesson learned: Know yourself, know when to quit, or at least devise a reset strategy for yourself.
Tip 4: Start on a certain box!
Once I had already popped a few boxes I learned about a box that there was an official walk-through for. Ironically, I actually found this out while looking through some OSCP forum threads. For everyone’s first box I recommend identifying the box with the official Offsec walk-through and following along. This will allow you to piggy back off of a great methodology, and I still look back at that post sometimes for reference. I will not say the boxes name here as that might be considered a spoiler, but it’s not hard to identify. Go on the student forums and you’ll find it!
Tip 5: Post-Exploitation Enumeration.
I have already spoken with many fellow students who are getting hung up in the later parts of the labs due to failure of post-exploitation enumeration on previous boxes. After you root a box, poke around for 15-30 minutes. Have fun and see what you can uncover! I have actually been able to get a GUI on some of the boxes I have rooted. It is pretty cool getting to remote into a box you hacked! If there is a SQL server, dive in and see what you can find! See if this computer talks to anyone else, maybe it is somehow connected to another machine in the network! Dump the hashes, and crack those passwords! And don’t forget to grab that proof.txt too!
Tip 6: Take detailed notes on how to regain entry to each box.
I have a folder in my home home directory named “Labs.” Within that directory I have an individual folder for each box I have rooted. Within each folder I put the proof.txt, hashes/passwords, interesting information, any exploits needed to re-root, and a HowTo.txt. I make a very detailed how to guide on each box after I root it to ensure that if needed I can easily follow my HowTo.txt and regain entry. This allows me to reflect on each box after I attacked it, and has already served a very useful purpose! On a couple of inter-dependency boxes I have needed to go back and obtain some information here or there. Do it, you’ll thank me later!
Tip 7: Map out the maze.
I have also made a “Connections” directory. Every little piece of information that I find out about the network as a whole I toss in there. It has allowed me to gain easier entry into some boxes, and steer clear of other boxes that I know have dependencies. This has already played a critical role in a couple of machines! Knowing who you are attacking and how they are intertwined within the network will save you a lot of time! Trust me!
Ultimately, these labs have been really great so far. The beginning was a little bit of a rocky start, but now I am really starting to get the hang of it. As always, feel free to email me or drop a comment for any questions you have.
I am really proud of my progress within these past 14 days. Completing all of the material, and successfully rooting 14 boxes in a two week time span is definitely a feat! I promise I’ll continue to work hard and report back with my lessons learned. Until the next time.