Skip to content

OSCP 03 - Exploitation and Client-Side Attacks

Using known exploits responsibly, understanding buffer overflows at a conceptual level, and client-side techniques.

Authorized testing only. This is exam and lab methodology as taught in PEN-200.

Working with public exploits

  • Finding the exploit - map the exact service and version to a known issue via Exploit-DB or searchsploit.
  • Reading before running - mandatory. Determine what the exploit does, what it targets, and what needs changing: IP addresses, ports, offsets, shellcode, and encoding.
  • Modifying exploits - most public exploits need adjustment to work in a new environment. Fixing hard-coded values is a routine OSCP skill.
  • Compiling - many exploits are C or C++ needing compilation, sometimes for a specific architecture. Compile for the target platform, not necessarily yours.
  • Exploit reliability - some exploits crash the service on failure. Understand the risk before firing at a target you cannot easily reset, and know that the exam has limited resets.

The exam permits public exploits, but restricts automated frameworks. The distinction between running a standalone Exploit-DB script (generally allowed) and using a full exploitation framework (restricted) is one you must confirm in the exam guide.

Buffer overflows, conceptually

Historically a guaranteed part of OSCP; the current exam de-emphasizes stack overflow but the concepts remain examinable and instructive. Understand the shape even if you never hand-write one.

  • The stack - memory holding function local variables and return addresses, growing toward lower addresses.
  • Buffer overflow - writing more data into a buffer than it holds, overwriting adjacent memory including the saved return address.
  • EIP/RIP control - the goal: overwrite the instruction pointer so execution jumps where you choose.
  • The classic workflow - fuzz to find the crash, find the exact offset to the return address, identify bad characters that corrupt the payload, find a reliable jump instruction (a JMP ESP in a non-protected module), and place shellcode.
  • Shellcode - the machine code executed once you control flow, typically spawning a shell or a reverse connection.
  • Bad characters - bytes the target mangles (null \x00, newline \x0a, carriage return \x0d are common) which must be excluded from the payload.

Modern mitigations to recognize

  • ASLR (Address Space Layout Randomization) - randomizes memory layout, defeating hard-coded addresses.
  • DEP/NX (Data Execution Prevention) - marks the stack non-executable, defeating simple shellcode-on-stack.
  • Stack canaries - detect return-address overwrite before it is used.

These make classic exploitation harder and are why modern exploits use return-oriented programming and information leaks. OSCP tests the fundamentals rather than these advanced bypasses.

Client-side attacks

Used where no directly exploitable service exists, relying on a user opening something.

  • The premise - deliver a payload that executes when a user interacts with it: a document, a link, or a file.
  • Malicious documents - macros in office documents, or file formats that trigger a vulnerable handler.
  • Payload delivery - hosting the payload and enticing execution.
  • HTA and script-based payloads - HTML applications and script files that run with the user's privileges on Windows.
  • Detection evasion is out of scope here - OSCP client-side scenarios are about the technique, in a lab where defenses are known, not about evading production endpoint protection.

Client-side is the answer when enumeration shows a workstation with no listening services worth attacking but evidence that a user interacts with delivered content.

Payload generation

  • Reverse versus bind shells - a reverse shell connects out from the target (works through outbound-permitting firewalls); a bind shell listens on the target (needs the port reachable). Reverse is the default choice because outbound is usually allowed and inbound usually filtered.
  • Staged versus stageless - a staged payload downloads the rest after an initial small stub; a stageless payload is self-contained. Staged is smaller but needs a second connection.
  • Platform and architecture - the payload must match the target OS and architecture.
  • Encoding - to avoid bad characters, not to evade antivirus in the OSCP context.

Getting and keeping a shell

  • Catch the connection - a listener ready before you fire the exploit.
  • Stabilize - upgrade to a full TTY immediately.
  • Confirm privileges - identify the current user and their rights, which sets up privilege escalation.
  • Establish a reliable path back - so a dropped shell does not mean re-exploiting from scratch.

Exam pointers

  • Read and understand every exploit before running it.
  • Expect to modify public exploits: IPs, ports, offsets, and shellcode.
  • Prefer reverse shells; outbound is usually permitted, inbound usually blocked.
  • Know the buffer-overflow workflow conceptually: fuzz, offset, bad chars, jump, shellcode.
  • Recognize ASLR, DEP/NX, and stack canaries and what each defeats.
  • Confirm the exam's stance on frameworks versus standalone exploits before relying on a tool.

Official documentation

📖 OffSec PEN-200 syllabus - authoritative content list 📖 OSCP exam guide - allowed tools and restrictions 📖 Exploit Database - public exploits and searchsploit