OSCE3 common mistakes
OSCE3 · Understand the traps and how to avoid them.
Treating each target host as an isolated puzzle and re-footholding from scratch on every new machine, instead of chaining credentials, hashes, and sessions already obtained into a single attack graph.
Candidates drill individual techniques (Kerberoasting, ACL abuse, unconstrained delegation) in isolation and never practice the pivot step: taking a recovered hash or ticket and asking 'what else does this principal touch?' Under time pressure the reflex is to restart enumeration rather than mine the loot already collected.
What to do instead
Before the exam, rehearse a written loop: after every credential or ticket gained, immediately run BloodHound collection and mark owned principals, then query outbound control and local admin rights from those nodes only. Keep a running attack-graph note with columns for principal, secret, reachable hosts, and next action. On exam day, never close a host until you have re-run that loop against the new material.
Overwriting or resetting a compromised account's password, or changing group membership destructively, and thereby breaking the environment or the scoring path.
Candidates are used to CTF boxes where the flag is the endpoint, so they treat a domain admin credential as the goal and 'clean up' accounts. In an AD lab, service accounts may be used by scoring checks, and destructive changes can lock out a path you still need.
What to do instead
Adopt a read-first policy: prefer password-spray, Kerberoast, AS-REP roast, and ACL-based takeover that preserve the account. If a password reset is unavoidable, record the original secret first and restore it. Never delete objects or remove group members unless the objective explicitly requires it, and verify the objective wording before any write operation.
Skipping the AD CS and delegation surface because the candidate 'already has a working path' and wants to bank points quickly.
Time pressure and the sunk-cost of an in-progress chain make candidates stop enumerating once one route works. Certificate Services (ESC1–ESC8) and delegation misconfigurations are frequently the intended, shorter path and may be required by separate objectives.
What to do instead
Build a fixed enumeration checklist that runs regardless of current progress: Certipy find with vulnerable-template flags, delegation flags on all computers and users, and ACL scan output. Run it once per domain at the start of each exam block and re-run after any privilege change; score objectives against the checklist rather than against your current shell.
Firing exploitation payloads at a web target before mapping the full application surface, so the candidate misses the actual vulnerable parameter or endpoint and burns hours on a hardened path.
Candidates jump to the technique they practiced most recently. Without a structured crawl and inventory, hidden parameters, alternate methods, and API routes stay invisible, and the visible form becomes a dead end that looks like a false positive.
What to do instead
Allocate a fixed discovery phase: crawl with a proxy recording every request, enumerate directories and parameters, and diff authenticated versus unauthenticated responses. Build an endpoint table with method, parameters, auth level, and suspected sink before testing. Only then select payloads per row, and revisit the table after each finding.
Testing only the browser-visible front end and ignoring the API, mobile, or backend service that shares the same data model and trusts client-side checks.
The rendered page gives immediate feedback, so candidates stay where they can see results. Backend endpoints often lack the same validation and are the intended route, but they require reading JavaScript bundles, source maps, or intercepting app traffic to find.
What to do instead
During discovery, extract all API base paths and route names from JavaScript bundles and source maps, then replay each with the current session token. Compare server-side authorization decisions against the UI by changing IDs and roles directly in requests. Treat every client-side validation as advisory until the server confirms it.
Disabling or bypassing the endpoint protection agent with an obvious, noisy action (service stop, driver unload, known tool drop) and getting the shell killed within minutes.
Candidates learn one bypass during practice and reuse it verbatim. They also prioritize getting a shell over keeping one, so they act before understanding what telemetry the host reports and what the EDR blocks.
What to do instead
Before any payload, profile the host: running security services, drivers, logging configuration, and network egress. Prefer in-memory execution, signed binaries, and living-off-the-land techniques that avoid writing tooling to disk. Test payloads in a matching lab VM first, and have a fallback channel ready before you need it.
Leaving default tool artifacts and high-signal indicators (named pipes, service names, scheduled task names, temp file paths) that reveal the intrusion path and get the objective invalidated or the host reset.
Tooling defaults are convenient and candidates rarely rename them, especially under time pressure. They assume the exam only checks the final objective and forget that defenders and scoring may look at the artifacts left behind.
What to do instead
Maintain a personal artifact-hygiene checklist: rename services, tasks, and binaries to plausible values; avoid well-known pipe names; clean staged files after use; and prefer ephemeral execution. Re-check the host after each action with the same enumeration commands a defender would run, and remove anything that stands out.
Treating binary exploitation as 'find the offset and send the payload' without first confirming mitigations, architecture, and the exact crash condition, resulting in a payload that works in the lab but not on the target.
Practice binaries usually have fixed, known protections. On the exam the binary differs, and candidates skip the recon step, misread the crash as exploitable, or build a ROP chain for the wrong architecture or libc.
What to do instead
Standardize a pre-exploitation checklist: file type, architecture, NX, PIE, canary, RELRO, and the exact bytes at the crash. Reproduce the crash under a debugger, identify the overwritten register and offset with a cyclic pattern, then choose the technique. Verify the chain against the target's actual libc and ASLR behavior before delivering it.
Statically reading disassembly for hours without dynamic confirmation, so the candidate's model of the program diverges from what actually executes at the vulnerable point.
Decompiler output is persuasive and candidates trust the pseudocode over runtime behavior, missing indirect calls, runtime-generated code, or checks that only fire under specific input. Time disappears into annotating functions that are not on the path.
What to do instead
Alternate static and dynamic analysis: set breakpoints at candidate sinks, feed crafted input, and confirm the data flow in the debugger before writing more notes. Use static analysis to choose where to break, not to conclude exploitability. Timebox any function to a fixed interval and move to runtime verification if no concrete finding emerges.
Mismanaging the clock: spending the majority of the exam on one domain or one stubborn objective and leaving whole domains untouched, or failing to record and report work already completed.
Candidates anchor on the first hard problem because it feels close to solved, and they do not track time per objective. Without a scoring log, completed work is forgotten and the final report omits evidence.
What to do instead
Before starting, divide available time across domains with explicit checkpoints and a hard stop per objective. Keep a live evidence log (host, action, result, screenshot or command output) updated at the moment of success. At each checkpoint, rotate to the next domain regardless of progress, and return only if time remains.