PNPT common mistakes
PNPT · Understand the traps and how to avoid them.
Spending the first hours running a full port sweep and automated scanner against every in-scope host before writing a single line of the engagement scope, then discovering the client's rules of engagement excluded a subnet or required notification before active scanning.
Candidates treat enumeration as the clock-starts-now task and skip re-reading the scope document, which they skimmed once during the exam setup. Under time pressure, the instinct is to 'get something running', and scanners are the most familiar tool.
What to do instead
Before any packet leaves the box, write a one-page scope sheet listing in-scope CIDRs, excluded hosts, allowed scan intensity, and any notification requirements, and keep it open beside your notes. Reconcile every scanner config against that sheet before launch. Budget the first 15 minutes for this and treat it as non-negotiable.
Treating OSINT as a single pass of whois and a Google search, then moving on, instead of pivoting discovered identifiers (employee names, email formats, subdomains, leaked credentials) into the external and internal phases.
OSINT is perceived as a low-value checkbox and candidates do not know what a productive pivot chain looks like. Without a repeatable workflow, the output sits in notes and never becomes an attack surface.
What to do instead
Maintain a pivot ledger: every artifact found (email, username, domain, IP, certificate SAN, GitHub org) gets a row with its source and a next-action column. Do not close the OSINT phase until each row has been actioned or explicitly marked dead. Use certificate transparency and DNS history as standing pivots, not one-off lookups.
Firing exploit and C2 traffic straight at the target with default tool profiles, getting blocked by endpoint protection or egress filtering, and concluding the environment is unexploitable rather than diagnosing the block.
Candidates assume a successful payload means successful execution. When nothing comes back they blame the target instead of instrumenting their own delivery, and they rarely check whether the block is at the host, the proxy, or the DNS layer.
What to do instead
Establish a baseline first: confirm egress with a benign callback to a listener you control, test which protocols and ports leave the network, and observe how the endpoint responds to a harmless payload. Only then escalate obfuscation, alternate protocols, or living-off-the-land techniques, and document which layer blocked the default attempt.
Collecting credentials, hashes, and tickets without mapping them to reachable hosts and required privileges, then attempting lateral movement that fails because the account has no local admin rights on the target or the target blocks the chosen protocol.
Tool output lists secrets in isolation and candidates assume 'domain user credentials' equals 'can move'. They skip the access-mapping step because it feels slower than just trying the move.
What to do instead
Build an access matrix before moving: rows are accounts/secrets, columns are hosts, cells record whether you have verified local admin, remote execution rights, or delegation. Test reachability and privilege with a single low-noise command per cell, and only then choose the movement technique (WinRM, SMB, WMI, scheduled task) that matches the verified rights.
Stopping at a single low-privilege foothold on the internal network and declaring the internal phase complete, without attempting privilege escalation or path discovery toward higher-value systems.
The first shell feels like the finish line, and candidates are unsure what privilege escalation looks like on a hardened Windows host. Time pressure pushes them to bank the win and move to reporting.
What to do instead
After every foothold, run a fixed post-exploitation checklist: local group membership, service permissions, scheduled tasks, stored credentials, session and logged-on users, and reachable shares. Record the privilege level and explicitly state what would be needed to escalate. Do not close the phase until you can articulate the shortest path to the next tier or prove none exists.
Attempting Domain Controller compromise directly with a single technique (for example, one Kerberoasting attempt or one unconstrained delegation check) and giving up when it does not yield a path, without enumerating all privilege-escalation routes in the domain.
Candidates learn a handful of named attacks and treat them as a checklist rather than a menu conditioned on what the environment actually exposes. They do not verify preconditions before firing the technique.
What to do instead
Enumerate preconditions first: accounts with SPNs, delegation flags, ACLs granting write or replication rights, certificate template misconfigurations, and local admin overlap on DCs. Rank candidate paths by required privilege and noise, then execute the highest-probability one with a verified precondition. Keep a fallback list so a single failure does not end the phase.
Writing the report as a chronological tool log ('ran nmap, then ran responder, then got a shell') instead of translating findings into business impact with reproduction steps a client engineer can follow.
Candidates mirror their notes because that is the artifact they have, and they underestimate how much of the grade depends on the client being able to act on the report. Impact writing is a distinct skill they have not practised.
What to do instead
For each finding, write four fixed fields: what an attacker gains, the concrete evidence, the exact reproduction steps with commands and outputs, and the remediation with an owner. Lead each finding with the impact sentence, not the tool name. Have a peer read one finding cold and confirm they could reproduce it.
Delivering the debrief as a read-aloud of the report, running over time on technical detail and never reaching the remediation priorities or the questions the client's leadership actually asked.
Candidates rehearse the technical narrative because that is what they are confident in, and they do not structure the debrief around the audience. Nervousness drives them to fill time with tool detail.
What to do instead
Prepare a debrief outline with a fixed time budget: two minutes on scope and approach, the majority on the top three to five findings with impact and fix, and a closing block for priorities and questions. Rehearse against a timer, and cut any slide that does not change a decision the client needs to make.
Losing track of time across phases, spending the majority of the engagement on external enumeration and arriving at the Active Directory phase with too little time to attempt domain compromise or write a usable report.
Enumeration is open-ended and rewarding, so it expands to fill available time. Candidates do not set checkpoints, and they underestimate how long reporting and the debrief take.
What to do instead
Set hard phase checkpoints at the start (for example, external complete by one third, internal foothold by one half, AD attempt by two thirds, report drafted before the final block) and honour them even if a thread is unfinished. Park loose ends in a backlog with a one-line note so they can be picked up if time allows.
Failing to preserve evidence and command output as it is produced, then reconstructing findings from memory at report time and being unable to substantiate a claim the client challenges in the debrief.
Candidates work in a terminal and assume scrollback or shell history is enough. They do not anticipate that a finding will need an exact command, timestamp, and output to be defensible.
What to do instead
Adopt a logging habit from minute one: timestamped command logs, saved raw output files per host, and screenshots of key states, all stored in a single evidence directory with a naming convention. Reference evidence IDs directly in the report so any claim can be traced to its artifact during the debrief.