OSCP common mistakes
OSCP · Understand the traps and how to avoid them.
Runs a single default nmap scan (top 1000 TCP ports, no version detection) and immediately treats the host as fully enumerated, attacking the first open port that appears.
Default scans return fast early results, so the output feels complete; non-standard high ports, UDP services, and services bound to a second interface are never seen, and the candidate anchors on the first hit.
What to do instead
Make a full 1-65535 TCP scan plus a version/script scan a fixed gate before any exploitation, follow it with a targeted UDP sweep of the most common 50-100 ports, and re-run enumeration from every new network position (second NIC, tunnel, compromised host) after a foothold.
Pulls an exploit from searchsploit/Exploit-DB by title match and runs it without confirming the target's exact version or build, then keeps patching the failing exploit for an hour or more.
Exploit titles list many affected versions so a near-miss looks like a configuration problem, and sunk cost pushes the candidate to keep editing a broken proof-of-concept instead of re-enumerating.
What to do instead
Confirm the exact version from the banner, package manager, or file version before choosing an exploit; time-box each exploit attempt to roughly 20-30 minutes; if it fails twice, stop editing the exploit and return to enumeration for a different path.
Browses the web application manually, hits a login form or a 403, and declares the web service a dead end without directory/vhost brute forcing, backup and source file checks, or default credential attempts.
Manual browsing only reveals what is linked, and a login page or 403 feels like a wall rather than an invitation; candidates also assume brute forcing is 'noise' the exam will not reward.
What to do instead
For every web service, always run a directory/file brute force, a vhost/subdomain brute force against the Host header, checks for backup and config files (.bak, .old, .git, web.config), and a small default-credential list before moving on.
Builds a macro, LNK, or HTA payload and delivers it without first confirming that a listener is reachable from the target and that the file actually executes in the target's application version.
The payload is built on the attacking host where everything works; listener bound to the wrong interface, egress filtering, Protected View, or macro-blocking settings are invisible until delivery, and the candidate then blames the payload rather than the chain.
What to do instead
Test the delivery chain with a harmless callback first (a curl/wget or ping back to a listener bound to the correct VPN interface), confirm which outbound ports the target permits, confirm the target application version and macro policy, and only then send the weaponised file.
Uses a recovered credential only against the service where it was found (for example a password from a web config file tried only on SSH) and never tests it across other services, hosts, or usernames.
The credential is mentally filed under its discovery context, and candidates are reluctant to spray for fear of lockout or of 'wasting time' on services already assumed secure.
What to do instead
Keep an explicit credential matrix (username, secret, source host, source service) and test each entry against every exposed authentication point: SSH, SMB, WinRM, RDP, FTP, web logins, databases, and the same service on other hosts; spray one password across a short user list at a time and check the lockout policy first.
Runs an automated Linux enumeration script once, skims only the red-highlighted lines, and never manually checks sudo rights, SUID/SGID binaries, file capabilities, cron jobs, writable service files, or NFS exports.
The script's volume of output is overwhelming, so candidates treat highlighted lines as the complete answer, and scripts miss context-dependent items such as relative paths, PATH hijacks, and environment-preserved sudo entries.
What to do instead
Keep a written manual checklist and verify each item by hand: sudo -l output reviewed line by line against GTFOBins, a find sweep for SUID/SGID and capabilities, getcap, writable cron and systemd unit files, and NFS exports with no_root_squash.
Gets a Windows shell and hunts only for a missing patch, ignoring token privileges (SeImpersonate, SeAssignPrimaryToken, SeBackup), unquoted service paths, AlwaysInstallElevated, stored credentials, and writable service binaries or registry keys.
Patch-based exploits feel like 'the' privilege escalation and are the most discussed, so candidates tunnel on patch level and skip the misconfiguration checks that resolve far faster on the exam.
What to do instead
Run whoami /priv and a fixed misconfiguration checklist before touching patch exploits: token privileges and matching escalation technique, unquoted service paths, service and directory permissions, AlwaysInstallElevated, credential hunting (cmdkey, unattend files, config files), and scheduled task permissions.
Stands up a SOCKS proxy and then runs SYN scans or tools that cannot speak SOCKS through it, or forgets to route DNS, so the scan silently returns nothing and the candidate concludes the internal host is down.
proxychains only intercepts TCP connect traffic from tools that use standard socket calls; SYN scans, raw sockets, and UDP simply bypass or fail, and the empty result is misread as a network fact rather than a tooling artefact.
What to do instead
Through a SOCKS proxy use only TCP connect scans with -sT -Pn and confirm the proxy path with a known-open port before scanning; prefer a tunnel that presents a real interface (ligolo-ng, sshuttle) for anything more than light scanning; record the full pivot chain and clean up routes and proxies when done.
Starts Kerberoasting or AS-REP roasting against Active Directory immediately, without first collecting domain users, groups, ACLs, sessions, share contents, and delegation settings.
Roasting is the most rehearsed AD technique, so it becomes the reflex first move; but without BloodHound-style collection the candidate never sees the ACL edge or the credential in a share that would have finished the box in minutes, and many roast outputs never crack.
What to do instead
Before attacking, run domain enumeration and a BloodHound-style collector, review outbound ACL edges, enumerate SMB shares for readable files and scripts, check for AS-REP-roastable accounts and delegation, and only then move to roasting with the highest-privilege accounts prioritised.
Takes a shell and moves on without capturing the required proof (the target's local/proof file plus a screenshot showing host identity) or keeping structured notes on each host, credential, and hop.
Momentum feels more valuable than bookkeeping, and the candidate plans to 'come back and document later' - by report time the shell is gone and the chain cannot be reconstructed, so points are lost despite full compromise.
What to do instead
Adopt a fixed post-exploitation ritual on every new shell: read the proof file, capture a screenshot showing the file contents alongside hostname/whoami and the interface IP, and append host, credentials, and pivot hop to a running notes file immediately.