OSEP has a specific failure profile. Candidates get shells, move laterally, reach objectives, and still fail — because the report did not prove the work, or because the evasion that felt clever in the moment does not survive a reviewer’s second look.
These are the mistakes that repeat, in rough order of cost.
1. Treating the report as a final step
The report documents per-objective exploitation, tool development, and evasion decisions. That is a long document. Candidates who start at hour forty produce something rushed and lose points on objectives they already achieved.
Write the finding when it happens. Four minutes then, forty later.
2. Using tools the environment detects
The exam is built around defended hosts. A stock payload from a popular framework is the fastest way to lose a foothold and an hour. The same applies to well-known enumeration binaries that endpoint protection flags on execution.
Test every payload against a current defender before exam day. If it gets quarantined in practice, it will get quarantined under pressure.
3. Confusing obfuscation with evasion
Encoding a payload is not evasion. Behaviour is what gets detected: process ancestry, memory allocation patterns, network callbacks, file writes, and command-line arguments.
An effective chain considers all of those. A base64 blob that launches from a suspicious parent and beacons to a raw IP has evaded nothing.
4. Not documenting the tooling
OSEP rewards custom tooling. A small utility you wrote to perform one step reliably is a graded asset — but only if the report explains what it does, why it was needed, and how it was used.
Candidates build something clever, use it, and mention it in one line. That converts a differentiator into a footnote.
5. Ignoring client-side access
In a hardened network, the perimeter is often a user, not a service. Candidates who prepare only remote exploitation find the first hours unproductive and conclude the network is broken. It is not; the intended path is a document, a link, or a user action.
Practise delivery: payload generation, lure construction, and the execution chain that follows. Then practise it again with the defender enabled.
6. No credential inventory
A corporate network has many accounts and many places each one works. Without an inventory, candidates re-test credentials they already validated, or miss the one that grants the next hop.
One table: account, secret, source, hosts where tested, privilege level. Update it every time something new appears.
7. Burning hours on one host
A host that resists for three hours is usually not the intended next step. Resistance is information: the path is elsewhere. Candidates who interpret persistence as a virtue rather than a signal run out of time with objectives untouched.
Set a hard limit per host and enforce it.
8. Skipping AD fundamentals
OSEP assumes OSCP-level Active Directory knowledge and builds on it. Candidates who arrive without fluency in enumeration, ACL abuse, delegation, and credential reuse spend exam time learning concepts instead of applying them.
If AD still feels uncertain, fix that before PEN-300, not during the exam.
9. Weak remediation advice
“Patch the vulnerability” is not a recommendation a client can act on. OSEP reports are judged as professional documents; remediation should name the control, the configuration change, or the detection that would have interrupted the chain.
For each finding, write two lines: what to change, and what to monitor.
10. No evidence standard
Proof files, command output, and screenshots with host context. The exam grades per objective, and missing documentation can reduce or zero a result regardless of the exploitation behind it.
Capture in a consistent pattern so the report assembles itself: command, output, host, objective file, timestamp.
11. Not testing exploits from a clean state
A payload that works in your current session may depend on a token, a mapped drive, or an artefact you placed earlier. The reviewer runs the documented steps from the beginning.
Run the full chain twice from a clean state before submission. The second run is where the hidden dependency appears.
12. Sleeping badly, or not at all
Forty-eight hours is long enough that fatigue becomes a technical problem. Code written at hour thirty often fails on review; report text written then is vague and repetitive. A planned sleep block protects the work you have already done.
13. Exploring after the objectives are complete
The objectives are finite. Once the required proofs exist, the remaining value is in verification, cleanup of the report, and a final evidence check — not in one more host.
A pre-submission checklist
- Every objective has a proof file and host-context screenshot.
- Every exploit runs from a clean state.
- Custom tools are included and explained.
- Each evasion decision names the control and the mechanism.
- Remediation is actionable for every finding.
- The archive and filename match the requirements.
Where to go next
For the certification overview and study material, see the OSEP certification hub. For the exam structure and a preparation plan, read OSEP exam: 48 hours, evasion and the report that decides it. For pacing across two days, see OSEP exam experience.
Certification names belong to OffSec. This is independent study material, not official course content.
Red team operator working across Active Directory and hybrid estates. OSCP, OSWE, CPTS and CRTO certified. Covers adversary simulation, evasion and report writing for red-team certifications.