First off let’s get this out of the way. I do not have my OSCP yet. I haven’t even taken the exam yet. (Scheduled, and very excited though).
That being said, I completed all of the coursework and documented it, and have now rooted 32 machines. Because of this, it’s now a good time as my lab access is coming to an end shortly to write my report and reflect on what I’ve learned. This list may or may not be edited to reflect other things I wish I knew.
1. Documentation
The biggest takeaway so far that is driving myself up the wall is my horrible note taking /documentation originally. I started off using KeepNote. In fact, I think it’s pretty good for what it is. And it can certainly get the job done. However, I switched over to CherryTree about halfway into attacking the lab machines. I wish I started with CherryTree from the beginning. I could get into all the great things about it, but chances are anyone reading this has already read a plethora of blogs saying why it’s so great. When I would attack a machine, I kept very little documentation about it. I didn’t think about the end product, the report. I would root a machine and essentially write notes for myself on how to root it again, which is great for me, but not great for a client. Now that I’m writing up my report, I am forced to re-root every machine I’m writing about which is taking up a lot of my time.
If I did the proper documentation the first time, I could be done with this report and working on some other important aspects that may benefit me on the exam. So what do you want to document? The way I see it, I am trying to be as verbose as possible. I want to make it so that I could (but will not), give my notes to someone who has very basic knowledge of Windows or Linux and have them be able to root the machine themselves by following the guide. In doing this, I have all the notes I need to write the report. I may not use everything from my notes, but I wouldn’t have to go back. You’ll want to include every TCP/UDP scan, every command you executed to get what you needed, output from those commands, and keep everything in chronological order.
For example, more often than not I will end up using searchsploit to look up some exploits and vulnerabilities for a service. If I find a vulnerability or an exploit that worked from using searchsploit, it’s getting included into my notes.
One last thing. If you find yourself doing something very specific for a box and you’ve never seen anything like that before, you should really add that to a separate subsection of notes. For example, I compiled an exploit on my Kali machine and transferred it over to my target. When trying to run it, I came across some weird error I’ve never seen before. I googled this error and came across a stackoverflow post with a comment on a different way to compile it. Sure enough it worked like a charm! Right there I just added another weird little trick to my toolbox.
2. Methodology
This is something everyone needs to craft in their own special way. But it should also remain open to change. There are people who post their methodology and outline online and in CherryTree templates that are a great basis to start off with. I started going off of one and used it religiously, but then I realized there were things that I was picking up from reading write ups, tutorials, etc. that I started including in my process. I then would drop certain tools entirely and use others, scan one service before another, etc. I can’t say I’ve got a solid methodology yet, but I do feel more confident every I hit a fresh box.
3. Scripts / Scripting Engines
It’s no secret that there are plenty of scripts on the internet to help with enumeration. Many specifically designed for OSCP students. My personal favorite that I use every single time is nmapAutomator.sh created by 21y4d. Check it out here: https://github.com/21y4d/nmapAutomator. I highly recommend this tool, but to keep an open mind and try out any other you come across to figure out which one you like the most. nmapAutomator is much more than just nmap scanning. It utilizes nmap vuln scans, gobuster, and nikto as well. Once a scan is complete, it will create a directory with everything outputted into their own files that can be retrieved later on.
Now a tool that everyone uses, but not to its full potential….nmap. Nmap has an amazing scripting engine built into it that has really benefited me. For example, smb-share-enum.nse has proved to be useful time and time again. I like to use nmap for this, because sometimes smbclient doesn’t return the shares that are available. With nmap showing me, I can simply smbclient \\10.x.x.x\SHARE$ and attempt an anonymous login. It’s more powerful than just scanning and giving output though. I was surprised to find a sweet script that could execute commands at the SYSTEM level for me remotely, all through nmap. The ms-sql-xp-cmdshell requires credentials, but a penetration tester and a OSCP student will probably find some of these along the way. Anyone not using nmap for it’s scripting engine is seriously limiting themselves. The scripts can be found in /usr/share/nmap/scripts. Take a look through there and see if there’s anything in there that you’ve seen in another lab machine and try it out.
4. NOPS with Msfvenom
This is going to sweet and short. Sometimes when creating an exploit or generating shellcode for a buffer overflow, often times a NOP sled will need to be added to the shellcode. Msfvenom can do this by inherently with adding the “-n” flag. I’m not the best programmer, so I want to keep everything nice and simple with exploits and codes. If I can create a shellcode for an exploit and add my NOPS in right then and there with msfvenom, that is a lot better than telling the program to figure out the shellcode length, subtract it by the necessary buffer size, add the NOPS to the buffer, and then send the exploit.
5. Explain what you’re trying to do out loud
This is a useful technique that can be used for many different times in your life when you’re stuck trying to do something and finding it hard to move on. Plenty of times I’ve found myself trying something over and over again without the desired result, effectively driving myself closer to insanity. What’s helped for me is to take my hands off the keyboard and mouse and look at what I have in front of me and then explain exactly what I’m trying to do to myself out loud as if I was talking to another human. Then once I’ve explained what I’m trying to do, I will explain how and why this vulnerability or exploit should work. Sure, you might look a little (a lot?) crazy, but it just might get you out of that rut and into a shell or a root user. I’ve found this to be effective in the past when I was still in college. I took a very intense Systems Administration class which was my absolute favorite class. Every day before and day of a test, I would ask other students in my group if there was something they didn’t understand or were confused on. This forced me to explain how to do something and why it’s working. In teaching others, you also reaffirm your knowledge and teach yourself. Additionally, you might say something to yourself that you overlooked the first time.
6. The ‘Try Harder’ mentality is good, but not entirely great
I did my absolute best during the labs to avoid using the forums and looking for write ups on similar type machines. I really wanted to try harder and figure out everything on my own. But then it hit me. I’m a student. And on top of that I’ve got limited time with these labs, and it’s not cheap. If I’m spending hours and hours on end trying to escalate my privileges, I should be okay to take a hint or a nudge from someone who has completed that machine before. I find it hard to learn what to do if I don’t know the right questions to ask. How can I be expected to do something without knowing what it is I have to do? The point of the labs is to gain that experience and see all these different methods of rooting a machine. I am not suggesting anyone give up right away after only an hour of attempting, but if it is taking up a serious amount of your life and you’re not making any progress, it’s okay to seek guidance. The exam will be the truest test of Try Harder, so let’s work on that mentality, but not be married to it just yet.
7. The PWK PDF should be referenced a lot
There’s a reason Offensive Security will grant 5 extra points on the exam if you do the coursework. It’s because it’s relevant. I’ve found myself going back to the PDF countless times and Ctrl+f’ing for a term or technique. If I had a physical copy of this material, it would probably be falling off the binding from the amount of times I’ve flipped the pages and thumbed through the content. You will need to find resources on the internet to help you succeed, but the book should still be referenced as well.
These are just some of the things that have helped me make my way through the lab network. If anyone has any questions, feel free to reach out.
