The OffSec Experienced Penetration Tester exam is not a theory test. It checks whether you can think clearly, move through a lab with purpose, and solve problems under pressure. That makes preparation different from many other security exams. You do not need more notes. You need a system. This guide is for learners who already work with offensive security, web testing, wireless, Kali Linux, Active Directory, scripting, or SOC workflows and want a focused 30-day plan for OSEP and PEN-300. The goal is simple: build the technical depth, speed, and discipline needed to perform in a hands-on exam without wasting time on random practice.
Who should use this OSEP study guide
This guide fits best if you already have some practical experience and want to tighten your process.
It is a good fit for:
- Penetration testers who want stronger evasion, pivoting, and advanced attack tradecraft.
- Red team learners who need a structured month of practice instead of open-ended lab time.
- Web and internal network testers moving toward more mature, post-exploitation-focused operations.
- SOC analysts and defenders who want to understand how modern payload delivery, lateral movement, and bypass techniques work in practice.
- Kali Linux users and exploit development learners who are comfortable in the terminal but need exam-focused repetition.
If you are still shaky on basic Linux commands, networking, simple web attacks, or Windows enumeration, spend time there first. OSEP preparation assumes you can already navigate systems, troubleshoot tooling, and read output without getting stuck on basics.
What the exam is trying to measure
The exam is designed to test applied offensive security skills, not memory. You are expected to chain techniques together, adapt when one method fails, and document your work clearly. In practice, that means several things.
- You need range, not just one favorite tool. If your normal approach gets blocked, you need a second and third option.
- You need clean lab habits. Good note-taking, careful command logging, and organized loot handling save time later.
- You need to understand the reason behind a technique. For example, a payload is not useful just because it runs. It is useful because it matches the target environment, avoids breaking the host, and supports the next step in the attack path.
- You need endurance. Long hands-on exams punish poor pacing more than weak theory.
The most common mistake is treating OSEP like a giant checklist of payloads. That approach fails because real exam tasks often depend on choosing the right method for the host, user context, controls in place, and your current access.
Prerequisite knowledge and tools
Before starting a 30-day plan, make sure your base is solid enough to support advanced practice.
You should be comfortable with:
- Windows and Linux fundamentals: processes, services, file permissions, scheduled tasks, logs, shell navigation.
- Networking: routing, ports, DNS, SMB, HTTP/S, RDP, WinRM, SSH, and basic troubleshooting.
- Web application testing basics: requests, sessions, common injection paths, authentication issues.
- Active Directory basics: domains, users, groups, Kerberos concepts, shares, trust of administrative paths.
- Scripting: enough Bash, PowerShell, or Python to modify small scripts and automate repeated tasks.
- Documentation: keeping reproducible notes, screenshots, timestamps, and proof files.
Set up your tools early so the month is spent practicing, not fixing your environment. Keep your stack simple and stable.
- Kali Linux VM with snapshots.
- A note system such as plain text, a wiki, or a structured notebook. What matters is speed and searchability.
- Terminal logging so your command history is preserved.
- A repeatable folder structure for each target: scans, creds, shells, privesc, screenshots, report notes.
- A small set of trusted tools you know well, plus time to test backups for each major task.
A useful rule: for every important action, know one primary method and one fallback. Example: one way to transfer files over HTTP and one backup using SMB, certutil, PowerShell, or another simple path.
30-day OSEP preparation plan
This plan is built around five phases: foundation, domain review, practice questions and drills, weak-area repair, and final revision. The reason for this order is simple. You first stabilize your workflow, then review the technical domains, then stress-test recall and decision-making, then fix weak spots, and finally rehearse exam execution.
Days 1–5: Foundation and environment setup
- Build your note template for host enumeration, credentials, local privilege escalation, pivoting, and reporting.
- Clean your Kali VM and test your core tools.
- Create or refine your command cheat sheets, but keep them short. One page per topic is enough.
- Practice initial host triage on a few machines: port scan, service review, quick web checks, user context, and likely attack paths.
- Time yourself. Aim to move from fresh target to a first action plan within 20–30 minutes.
Why this matters: many candidates lose time because they have knowledge but no workflow. A stable routine reduces decision fatigue.
Days 6–12: Domain review
Split these days across major OSEP-relevant areas. Keep each day practical.
- Day 6: Payloads, shell upgrades, file transfer, and AV-aware delivery choices.
- Day 7: Windows privilege escalation review. Focus on reasoning from user rights, services, tasks, installed software, and token context.
- Day 8: Active Directory enumeration and attack path thinking. Do not just run tools. Interpret what access leads to what opportunity.
- Day 9: Pivoting, tunneling, and multi-host movement. Practice routing clearly and verifying each tunnel before using it.
- Day 10: Web attacks that can support initial access or credential theft. Work through request analysis, auth bypass ideas, and post-auth abuse.
- Day 11: Wireless or adjacent niche topics in your study scope. Focus on process and troubleshooting.
- Day 12: Evasion concepts, process migration choices, execution tradeoffs, and OPSEC basics.
At the end of each day, write three short notes:
- What worked fast
- What broke
- What signals should have told you the right next step earlier
That last point matters most. It trains pattern recognition instead of blind command repetition.
Days 13–18: Practice questions, drills, and scenario repetition
Even for a hands-on exam, targeted question practice can help if used correctly. The goal is not to memorize answers. The goal is to expose weak understanding, especially around technique selection, troubleshooting, and attack flow.
- Do one timed block each day.
- Mix short concept checks with practical mini-drills.
- After each block, review every mistake and explain it in your own words.
- Recreate at least one related action in a lab the same day.
Example: if you miss a question about choosing a lateral movement method, do not just note the answer. Ask why one method fits the host, privileges, ports, and controls better than another. Then test a small version in a lab.
Practice with the relevant page only: OffSec Experienced Penetration Tester (OSEP, PEN-300) Practice Test
Days 19–24: Weak-area repair
By now, patterns should be obvious. Maybe your enumeration is fine but your pivots are messy. Maybe you can gain access but waste time escalating. Choose only two or three weak areas. Going wider at this stage usually hurts more than it helps.
- Rebuild your cheat sheets for those weak areas.
- Run the same style of exercise repeatedly until setup feels automatic.
- Practice troubleshooting on purpose. Break a tunnel, use the wrong architecture, or test a blocked transfer path and recover.
- Document one “decision tree” per weak topic. Example: if file transfer fails over one path, try these next options in order.
This phase is where scores often improve. Not because you learned something flashy, but because your weak spots stop draining time.
Days 25–27: Full-chain simulations
- Pick one or two long sessions that mimic exam fatigue.
- Start from reconnaissance and work through access, post-exploitation, and documentation.
- Limit tool switching. Use your exam-day stack only.
- At the end, produce a short report summary from your notes.
Why include reporting practice? Because poor notes turn solved work into lost points. If you cannot explain what you did and show proof cleanly, the technical win does not fully count.
Days 28–30: Final revision
- Review your personal notes, not the entire internet.
- Re-run a few short drills in topics that must stay fresh: shell handling, file transfer, tunneling, privesc checks, and AD enumeration.
- Do not try to learn a major new technique now.
- Check your VM snapshots, directories, aliases, and backup tools.
The goal in the final three days is confidence and sharpness, not volume.
How to review explanations without memorizing answers
This is one of the most important habits in OSEP preparation. Memorized answers break as soon as the environment changes. Understanding survives variation.
Use this review method:
- State the principle. Example: “This method works because the service runs with elevated rights and loads a modifiable path.”
- List the signals. What clues in the output or host state point you toward that method?
- Name one alternative. If the main path fails, what is the next best option?
- Recreate a tiny version. Even five minutes in a lab is better than passive review.
- Write one sentence in plain English. If you cannot explain it simply, you likely do not fully own it yet.
A good example is payload choice. Do not memorize “use X for Y.” Ask:
- What architecture is the target?
- What interpreter or binary support exists?
- What transfer methods are likely to work?
- What level of noise is acceptable?
- What do I need this shell to do next?
That kind of thinking is what the exam rewards.
Hands-on lab workflow checklist
This checklist is useful for your own prep and also works as a clean reference for security training creators building practical content.
- Before touching the target
- Confirm VPN, routes, DNS, and time sync.
- Open note template and create target folders.
- Start terminal logging.
- Initial triage
- Run port and service discovery.
- Identify likely user-facing services first.
- Capture screenshots and raw output early.
- Enumeration
- Record versions, banners, auth methods, and reachable interfaces.
- Separate facts from guesses in your notes.
- Map findings to likely attack paths.
- Access
- Test the least disruptive method first.
- Track payload type, listener, and transfer path.
- Verify shell stability before moving on.
- Post-exploitation
- Confirm user context and host identity.
- Collect creds, tokens, services, and routes methodically.
- Decide whether local privesc or lateral movement is the better next step.
- Pivoting
- Draw the route you are building.
- Test one hop at a time.
- Keep backup access in case the main tunnel drops.
- Proof and reporting
- Capture proof files, command output, and key screenshots immediately.
- Write short notes while the context is fresh.
- Store remediation ideas only after the exploit chain is fully documented.
Final-week readiness routine
Your last week should feel controlled. If it feels chaotic, simplify.
- Sleep on a fixed schedule. Exam thinking drops fast when sleep is poor.
- Use one workstation setup only. Same terminal layout, same notes, same folder structure.
- Review your top 10 friction points. These are the exact places where you usually lose time.
- Run 60–90 minute mini-simulations. Short and focused is better than all-day burnout right before the exam.
- Prepare a calm-start checklist. VPN, tools, logging, notes, snacks, water, and break plan.
Also decide in advance how you will handle getting stuck. A simple rule works well: if no progress after a defined period, step back, re-read your notes, verify assumptions, and try a different path. That prevents emotional over-commitment to one bad idea.
FAQ
How many hours a day should I study for 30 days?
For most working professionals, 2–4 focused hours on weekdays and a longer weekend block is realistic. Quality matters more than raw hours. Three disciplined hours with notes and lab repetition beats six distracted hours.
Should I spend more time on questions or labs?
Labs should take most of your time. Use questions to diagnose weak understanding and improve decision-making. If a question exposes a gap, turn it into a small practical exercise the same day.
What if I feel weak in one major area, like AD or pivoting?
Narrow your focus and repair it early. Big weak spots rarely fix themselves through general practice. Build a mini-plan for that area: core concepts, one cheat sheet, three repeated drills, and one simulation where that skill is central.
How do I know I am ready?
You are close when your workflow is stable, your notes are organized, and you can recover from failure without panic. Readiness is not about knowing every trick. It is about making good choices under pressure.
Should I memorize commands?
Memorize only what improves speed for tasks you perform often. For everything else, understand the logic and keep concise notes. The exam rewards applied thinking more than perfect recall.
What about retakes?
If you need a retake, do not restart from zero. Review your notes from the attempt, identify where time was lost, and rebuild around those failure points. Most retake improvements come from better process, not from collecting more random techniques.
Final thoughts
OSEP preparation works best when you train the way the exam thinks. That means practical repetition, careful review, and strong workflow discipline. In 30 days, you probably will not master every edge case. You do not need to. What you need is a reliable method for enumeration, access, escalation, pivoting, and documentation, plus the judgment to switch approaches when the first idea fails. If you follow a structured plan and review the reasons behind each technique, you give yourself a much better chance of performing well when it counts.
