The OSCP is NOT HackTheBox

A first time OSCP Failure story.

So you’ve got 30+ boxes done in HackTheBox, you’ve mastered the Buffer Overflow and you’ve even done a few hard boxes from vulnhub or somewhere else. All of the hackers on twitter, all of the articles, and maybe even a personal mentor has told you that you’re ready.

That was me three days ago. I had a mentor tell me I was ready back in 2019 and since then I’ve studied even more. So this will be cake right? Well…

I just failed the OSCP and I know exactly all the reasons why. So let’s get into it.

Now, before we jump into this, I will say that a massive part of my failure was sleep deprivation and medicating with caffeine. I had scheduled a 10AM and for some reason the schedule for the exam got dropped on the Offensive Security side, suggesting I reschedule. In a panic I grabbed the next time on the list, 9PM. Horrible choice. With that being said. Let’s talk about why I failed…

Let’s first review a summary of all of the things I’ve heard going into this.

• If you can do easy and medium boxes in HTB you’re probably ready.
• It’s a methodology test, if you’re methodology is good then you’ll be good.
• Doing enough boxes will give you intuition on what direction to go
• oh and “Try Harder”

These are fine tips, and I won’t say they are false. But I want to talk about each one and make some slight adjustments.

Part I — Older HTB Easy & Medium Boxes Prepares you for the OSCP

Yes good. Great advice. HackTheBox has been my study buddy for years now. The way I was taught to use HTB was to find a box, try your hardest to get into it, have a writeup nearby for when you get stuck (have multiples really), read up to the point you’re stuck. Stop reading. Pivot. Keep working until you’re stuck again. Finish it however you have to. Make your own writeup afterward to force yourself to review the process from top to bottom. Screenshots and all. Three to four weeks later, go back and do it after you’ve forgotten the details, and this time don’t look at anything. I did some of these boxes four times.

This will quickly make you a professional at breaking into boxes on HTB. You’ll start to get a feel for what works and what doesn’t. For example, when I was just getting into this I always would lean towards SSH. It was the first thing I looked for in nmap, and I would immediately search the SSH version for exploits. I can hear some of you laughing, I know I know! If you’ve been doing these for awhile, you’ll know that it’s very seldom that SSH is the issue. I quickly learned better things to lean into. Often vulnerabilities aren’t just CVEs but the way in which the user has decided to use it, or neglect it. But CVEs! Speaking of…

You’ll also get a feel for the CVE hunting part. You’ll learn to quickly spot what you need in a sea of CVEs and exploits you find online. If you’re like me, you will have learned to nmap -sV -sC and -A and no matter what you get back, you’re googling versions immediately for the satisfaction of finding that exploit-db page with that sweettt sweettttt checkmark. Then you exploit the box and you’re in. That’s it. Got it. Let’s do more of that over and over until it’s burned a spot in your brain.

A spot that will bite me in the ass come OSCP time…

Not all HTB boxes are like this, but so many of them feel this way. If you expect the OSCP to feel similar, please hear me out. This ain’t it chief.

Imagine a box with 3 extremely promising exploits publicly available but none of them work. How often have you practiced that with HTB boxes? Chances are you’ve bumped into it once or twice, but not enough. So considering that, these easy and medium boxes surely helped you learn what you need to know, they are nothing like the OSCP boxes you’re about to encounter.

If you study like this, you have created a problem. What has happened is the building of a concrete poured, steel enforced methodology box. Walls up around your thinking to get you to success the quickest and with the least amount of failures. A methodology jail if you will. This was the largest contributing factor to why I failed the OSCP.

The box brings me to my next point.

Part II — The OSCP Is A Hacking Methodology Test.

Oh yes, this is certainly true. So true in fact that I can almost promise you that you’re not going to fail the OSCP because of your lack of knowledge on finding vulnerabilities, or the techniques used to exploit them. Even if you don’t know how to do something on the test, chances are you’ve gotten pretty good at googling for a better technique and then quickly applying it. You’re not going to fail due to a lack of technical know-how. It’s going to be methodology. Specifically the part where you enumerate the machine.

Focusing on HackTheBox machines taught me to enumerate for HackTheBox, not OSCP.

Here is my biggest piece of advice. Start low tech. Start at the bottom of the barrel and move up when it comes to enumeration. Take a moment to look through a few things before pounding out exploits.

Your methodology of focusing on vulnerable versions, CVEs, public exploits isn’t always the answer. And unlike HTB, if you make progress on one thing, doesn’t mean it’s a “clue” to going the right direction.

Example:

After my buffer overflow box was done I started on the 10 pointer. This box took me 3 hours. The reason? I was trying to force exploits just because they existed. FTP anonymous login? That has to be involved right?!?! Wrong. What about the gaining of access to a admin panel of a web app using ‘Admin’ as the username and password? This surely is a “clue” to me going the right direction right? No! Two hours in I noticed a port in my nmap that I haven’t even looked at because I was too busy pounding out my HTB methodology. It was an up to date Apache server. Went to it and the answer was right there. Didn’t need a beefy exploit. It was just hanging out. The user hadn’t configured a few things right and all it needed was for me look at it. A little sprinkle of RCE, and a quick whoami and boom. Root. If I would have skipped all the big hacker mumbo jumbo I would have finished this box in less than an hour.

It was like I had spent years developing this 6th sense for the right vulnerability to bust open but now, my 6th sense was just flat out lying. This brings me to my next point.

Part III — HackTheBox helps build intuition

Yes, for doing HackTheBox machines. Remember, HackTheBox at the end of a day is a game. It is a puzzle. And just like any other good game, you spend a few levels fumbling around, and as a well developed game tends to dish out rewards and punishments for your actions, HackTheBox does as well.

“Ah yes, you see my robots.txt page and the only thing here is /wp-admin/, yes very good, be enticed. Comee thiss wayy.”

-HTB if HTB could talk.

Almost always a HTB box will have clues, or at some point you’ll find a small thing that is this signal that you’re doing the right thing. Like any other game would do. The OSCP doesn’t care about gamification or little awards here and there. It’s a machine with loads of bad mess and misconfigurations, and not all of it is related or matters. They are just there. Then somewhere, there is one little hiding thing on that machine will allow you in. In other words, you’re playing a whole different game now buddy.

Learn to not commit, be sneaky and poke around. Learn to be a creeper on the box before being a hacker.

So Hack The Box is Bad?

Before I dive into the last part. Let me be clear. Keep doing boxes! Learn to be comfortable and learn how to enumerate different things. You will learn something on each box you do. Just be aware.

Part IV — “Try Harder” no no no. “Try Something Else”

When I was a young lad I was a band geek, and something stuck with me. When I practiced I would always just play the few things I really liked and was good at. I guess I thought the more I did it the better it would get. I remember running through a piece of music two or three times and finally the director stopped everything.

“Why have you played this part the same exact way over and over? Nothing has changed. When you preform you can play it the same, but we are at practice. At least change something. It’s the only way to get better.”

This has stuck with me over the years. Every once in a while something happens and it just comes back to me. And the OSCP definitely slapped me with a big fat reminder. The whole “Try Harder” thing can be misleading. In my mind it meant making my payload better. Switching from bind to reverse TCP over and over, changing encoding. Changing delivery methods. That seems like trying harder to me. But the key seemed to be in just doing something different. Try. Something. Else. Enumerate more. Step away from the machine and forget this one thing you’ve been trying for 3 hours. If it doesn’t work in 1 hour, it’s probably not the way in.

Example:

Let’s say you find a vulnerable server. You do some research to see what is possible.

You see 3 exploits in searchsploit. Two of them are the same, just built for manual and Metasploit. Wait, metasploit has it? That must mean it’s pretty good. Let’s keep checking.

Found it on Exploit-DB and it has a green check. Even if it was built for the wrong OS, it has instructions on how to msfvenom a new payload specific to the target.

All fingers point towards success!

And this was my downfall. Payload after payload I kept firing it off. At this point, it was midway through the second day with only 4 hours of sleep. I was so exhausted that my level of hard headed and stubborn was exponentially higher than usual. I wanted this to work. I had already tried it 4–5 times and put so much time into it, leaving it would mean I’ve wasted hours. And if it has the green check mark, it works for someone! It’s been proven! It has to work!

Why did I focus on this so intensely? If it wasn’t working, why did I put so much faith in Searchsploit and Metasploit and Exploit-DB. What about the other exploit?

I completely exhausted my bandwidth thinking about this exploit and by the time I moved from it, I was drained. I went to some other application that had an RCE published online and attempted that. Same story. Same effort. Same frustration. Now we are about 6 hours into this box and got nothing.

Let’s rewind. Look at this again.

The other exploit was Directory Traversal. Not as tasty as a Buffer Overflow and a shell. But it’s something. I glanced at it one time. Googled it once even. I found the exploit online and.. well look.

EDB said no so I will also say no without even looking at it. Silly silly silly. Much later in the day, after I had given up but continued poking at things considering the money I had paid just for access, I came back to this and started playing around with what was actually in the exploit. Read through it. And this was it. This was the answer. I was able to look through files on the system and within that were more answers. But it was too late. I had 2 hours left and still needed to write a report.

TL;DR — My Advice to You, and Myself

Let’s just bullet point this out. All of my advice in bullet points.

• 1 hour max. That’s how much you have on a single method. Come back later if nothing else works. But don’t over commit.
• Try the easy stuff first. Easy as in ‘Admin Admin’, or taking a peek at the source code. Take a look at the url as you click around. See a language argument? See a .php with ?= anywhere? Type a real quick ../../../passwd here and there.
• If you’re going to go to exploits early, go head, just don’t focus on one. Start firing off anything you can find. It can’t hurt. There is a reset button for a reason. Pew pew away.

Other Advice

A few other tips that are sort of unrelated to this post.

• Stop getting all of your payloads and reverse shells from sites, learn how to use msfvenom.
• Read the exploit first. Period.
• When doing CTFs — enumerate ports even if you don’t think they are the answer. Don’t know how to enumerate? Find a port-service specific guide on enumeration.
• check to make sure your python2 and python3 are running well. Most older exploits are python2.
• Learn to take shady exploits from Github and write your own from them, or find the actual payload and use that. Typically there is a lot of TCP connection and argument passing housekeeping in the exploit that isn’t needed for you to test it out.
• The proctoring software runs on Chrome and about 6 hours in it will start to chomp on RAM. Adjust your VM settings as needed.
• Don’t schedule for 9PM.
• Don’t change your diet. I went out and bought 2 cases of redbull and cokes. Which my body was not used to.
• 20 minute breaks every 1.5 hours will actually buy you time by keeping you from banging the same failing exploit out over and over.

Okay that is it. I’m not sure I know everything to pass it next time (I barely got to any PrivEsc stuff) but I know what I did wrong and how to fix it. And that it wasn’t at all technical, but my own habits that caused me to fail. So. I hope this helps someone. Let me know if you think anything I said was dumb or incorrect or if this helps you. If you want to practice together or talk please feel free to reach out. Also let me know if you want to see more writeups and articles. I have loads of drafts and HTB writeups I might move over to Medium if this is where to cool kids hangout. Thanks!

Mehh

Twitter — @Mehhsecurity.