The OSCP — Offensive Security Certified Professional — is unlike any other certification exam in cybersecurity. There's no multiple choice. No study guide you can memorize. You get 24 hours to compromise a set of machines in a controlled lab environment, and then another 24 hours to write a professional penetration testing report. Pass or fail depends entirely on what you do during those 48 hours.
The security community on Reddit, forums, and Discord has produced an enormous volume of advice from people who've passed and failed the OSCP. The tips that consistently show up across hundreds of accounts — the ones that actually matter — can be distilled into a handful of disciplines. That's what this guide covers.
This is the single most repeated piece of OSCP advice, and it's repeated because people keep failing to follow it. When you're stuck on a machine, the answer is almost never to try harder exploits. It's to enumerate more thoroughly. Run nmap again with different flags. Check every open port. Read service banners carefully. Look for hidden directories. Check version numbers against known vulnerabilities. Most OSCP rabbit holes happen because something was visible and wasn't noticed.
Build a systematic enumeration methodology before your exam. Know exactly which tools you run, in what order, on what findings. Automation tools like AutoRecon can run multiple enumeration tools in parallel — use them during the lab and understand the output. When the exam starts, your methodology shouldn't be something you're figuring out. It should be something you execute automatically.
The OSCP exam requires a written penetration testing report that documents your methodology, findings, and proof of compromise. Candidates who fail because of poor reporting often had all the right screenshots but no notes explaining their thought process. The report needs to be reproducible — someone else should be able to follow your steps and reach the same result.
Use a note-taking tool consistently throughout your PWK lab time: CherryTree, Obsidian, Notion, or even organized text files. For every machine you compromise, document: your initial enumeration findings, the vulnerability or misconfiguration you exploited, the exact commands you ran (copy-paste, not paraphrased), and screenshots of proof — typically the contents of local.txt and proof.txt files.
When your exam starts, you're already in note-taking mode. You're not trying to build a system under pressure — you're using one you know.
24 hours sounds like a lot. It isn't. With setup time, enumeration, rabbit holes, breaks, and the pressure of the clock, candidates routinely run out of time. The community has developed guidance on when to move on:
Know the scoring requirements before exam day. You need 70 points to pass. The lab report can add up to 10 bonus points if you've documented 10 PWK lab machines properly. Those bonus points can be the difference between passing and failing.
The OSCP exam includes a buffer overflow machine. It has a known, consistent methodology. If you've practiced it enough times in the labs — scripting fuzzing, finding the offset, controlling EIP, generating shellcode, bypassing bad characters — you should be able to complete it within two to three hours on exam day. That's potentially 25 points you can bank early, which dramatically reduces the pressure on the rest of the exam.
Practice the buffer overflow methodology until you can execute it from memory without checking notes. The steps are the same each time: fuzz → find offset → confirm EIP control → check for bad characters → generate shellcode → adjust for NOPS → shell. If you're shaky on any step going into the exam, you're going to lose time on what should be a reliable machine.
Offensive Security provides a detailed exam guide that specifies exactly what's allowed and what isn't. Commercial exploitation frameworks like Metasploit are restricted — you get one use of the exploit module on one machine, and using it more is a violation. Automated exploitation tools have restrictions. The documentation requirements are specific.
Candidates who get caught violating the exam rules lose points or the entire attempt. The rules aren't obscure — they're in the guide. Read it the week before your exam and re-read the key sections the morning of.
The OSCP exam report is evaluated against professional penetration testing standards. It's not a log of what you did — it's a document a client could theoretically receive and act on. An offensive security engineer will read it and evaluate whether another tester could reproduce your findings.
Your report needs: an executive summary, methodology section, detailed findings for each compromised machine (including enumeration findings and exploitation steps), screenshots with captions, and exact proof of compromise (local.txt and proof.txt contents with your IP address visible). Missing any of these components affects your score.
Don't start writing the report from scratch after the exam. Draft it during the exam — fill in the methodology and findings sections as you go, then complete the executive summary and review at the end. Writing from organized exam notes is much faster than reconstructing a 24-hour session from memory afterward.
From the aggregated advice of hundreds of OSCP passers:
The OSCP certification guide covers what's required to register and what the full certification process looks like from start to finish. If you haven't reviewed it, do that before you commit to an exam date.
The OSCP is one of the most respected certifications in offensive security — partly because it's genuinely hard. The 24-hour practical exam format weeds out candidates who've memorized material without developing real skills. The tips above don't make the exam easy. They make it less unfair — by helping you show up prepared for how the exam actually works, not just how you imagined it would work.
The OSCP community has a saying: try harder. It's Offensive Security's unofficial motto. But the people who've passed will tell you that trying harder without a system just means staying stuck longer. The tips above — systematic enumeration, structured notes, time boxing, buffer overflow mastery, report writing habits — are what trying smarter looks like in practice.
If you haven't scheduled your exam yet, give yourself the time you actually need. The difference between a well-prepared candidate and an under-prepared one isn't just pass/fail on the first attempt — it's how much the certification costs you (exam retakes aren't free) and how confident you are when you're doing the work for real.
Practice the technical skills, build the documentation habits, and walk into your 24 hours knowing exactly how you'll spend them. That's the prep that makes the difference.