OSC common mistakes
OSC · Understand the traps and how to avoid them.
Skipping UDP and full-port TCP sweeps and pivoting straight to a service-specific tool on the default port of the first host, so services like SNMP/161, DNS/53, or a management interface on 8443 are never seen and the intended foothold is missed.
Candidates under time pressure trust a single fast SYN scan of the top 1000 ports and treat the first reachable host as the target, because they have practiced with narrow scans and never built a repeatable enumeration checklist.
What to do instead
Run a documented sequence before touching any exploit: full 65535 TCP sweep, then a UDP top-ports scan, then version and default-script scanning against only the open ports. Record each host and port in a notes table with the command that produced it, and do not move to exploitation until every in-scope host has been through the same sequence at least once.
Discovering a valid credential or hash and immediately spraying it across every host in scope, or reusing it against services without noting which credential was tried where, causing account lockouts and losing track of which pair actually worked.
The quick win of a single success encourages broad spraying, and candidates do not keep a credential matrix, so lockout policy and per-service results are never tracked.
What to do instead
Maintain a credential-to-host-to-service matrix in the notes and fill it in after every attempt. Check lockout policy first (net accounts on Windows, pam_tally or faillock config on Linux) and cap attempts per account below the threshold. Prefer targeted single-account attempts against confirmed services over spray-and-pray, and mark each cell success, failure, or locked.
Treating a low-privilege shell as done and never running local enumeration, so sudo misconfigurations, SUID binaries, writable service paths, or unquoted service paths are never found and privilege escalation stalls.
Candidates spend their effort on the initial foothold and then improvise, lacking a fixed post-shell checklist, and they often lack a stable interactive shell (no TTY), which blocks many enumeration and exploitation steps.
What to do instead
Immediately after a shell, stabilize it (pty upgrade, or a proper reverse shell) and run a fixed enumeration pass: sudo -l, SUID/SGID and capabilities, cron jobs and writable scripts, PATH and LD_* variables, kernel and package versions, then service and scheduled-task enumeration on Windows. Log findings as you go and only then choose an escalation vector.
Enumerating Active Directory only with a single tool's default collection and never mapping relationships (group membership, ACLs, delegation, sessions, trusts), so an obvious path such as GenericAll on a group or an unconstrained delegation host is missed.
Candidates learn one collection command and stop, because they do not know which relationships are abusable and therefore do not know what to query or how to read the output.
What to do instead
Build an explicit AD map: users, groups and nested membership, computers with delegation flags, ACLs on high-value objects, sessions and local admin rights, then trusts. Query each category deliberately (for example BloodHound collection plus targeted LDAP or native queries) and annotate each edge with the abuse technique and required privilege before executing it.
Exploiting a vulnerability without first confirming the exact version and configuration, or firing a public exploit blindly and assuming success when the output is ambiguous, then building later steps on a false foothold.
Time pressure and pattern-matching to a familiar CVE lead candidates to skip version confirmation, and exploits that return partial output are misread as success.
What to do instead
For every candidate vulnerability, record the evidence (banner, version string, config file, response behavior) and match it to the exploit's stated affected range. Test the exploit in a controlled way, verify the result with an independent check (id, whoami, a unique marker file), and only then record the host as compromised.
Pivoting by opening a new route to a host and then running tools that cannot traverse it, or forgetting to route traffic for the tool's own protocol, so internal hosts appear unreachable and the candidate concludes the network is segmented.
Candidates learn one pivoting method (for example a SOCKS proxy) and do not understand which tools honor proxy settings, so they misdiagnose a tooling limitation as a network control.
What to do instead
Choose the pivot based on what the next tool needs: SOCKS proxy with proxychains for TCP tools that support it, port forwarding for single services, or a tunnel for full IP. Verify the pivot with a known-reachable target before scanning, and document the tunnel command and the tools that work through it.
Collecting flags or proof files but not capturing the exact command, timestamp, and host context, so the final report cannot substantiate a finding and the candidate has to redo work or leaves claims unsupported.
Candidates treat note-taking as overhead and capture only the end result, not the reproducible path that produced it.
What to do instead
Adopt a capture habit per action: command, output, host, user, and time, stored in one running log (a plain text or markdown file). Before moving on from a host, confirm the log contains enough to reproduce the step. Build the report from this log rather than from memory.
Escalating on Windows by assuming the first service or scheduled task found is exploitable and modifying production-like services, or failing to check permissions on the service binary and directory before attempting a replacement.
Candidates memorize escalation techniques as recipes and skip the permission check that determines whether the technique applies, and they act destructively without considering impact.
What to do instead
For each candidate (service path, scheduled task, always-install-elevated, token privileges), first query the actual permissions on the binary, its directory, and the task definition. Confirm writability with a harmless test before replacing anything, prefer non-destructive techniques, and record the before-and-after state.
Losing track of scope and permissions during lateral movement, so the candidate reuses a local administrator hash on hosts outside the authorized range or against a domain controller without confirming the account's rights.
Candidates treat a recovered hash as universal and do not distinguish local from domain accounts, nor do they re-check scope after each hop.
What to do instead
Before each lateral movement, confirm the target host is in scope and the credential's scope (local account, domain account, or machine account). Test with a low-impact command first, record the credential used and the host reached, and stop and re-verify scope whenever a new subnet or domain is entered.
Writing the report as a chronological narrative of every command run, burying the exploitable findings and their business impact, and omitting remediation or evidence for the key issues.
Candidates draft from the raw log at the end under time pressure and have no report structure planned, so the document reads as a diary rather than an assessment.
What to do instead
Outline the report structure at the start (executive summary, findings by severity with evidence and remediation, path narrative, appendix). During the engagement, tag each log entry as a finding or a step. Write the findings section first from tagged entries, then the narrative, and give each finding a reproducible proof and a concrete fix.