PJPT common mistakes
PJPT · Understand the traps and how to avoid them.
Starting active scanning (Nmap SYN scans, directory brute forcing) against in-scope hosts before confirming the signed scope and rules of engagement are on hand, then having to reconstruct what was authorized later.
Candidates treat the practical lab as a race against the clock and jump straight to tooling, assuming the engagement letter is a formality rather than the document that defines allowed targets, time windows, and prohibited techniques.
What to do instead
Before the first packet, read the engagement document and write down the exact IP ranges, domains, and excluded hosts; keep that list visible and check every scan command against it. If a scope detail is missing or ambiguous, note it as an assumption in your notes rather than guessing silently.
Using only a single default Nmap top-1000 TCP scan as the reconnaissance output and moving on, missing non-standard high ports, UDP services, and hostnames leaked in DNS or certificate data.
Default tool output feels authoritative and complete, and candidates underestimate how often exam targets place services on unusual ports or expose information through DNS zone data, reverse lookups, and TLS certificate subject fields.
What to do instead
Layer the enumeration: full TCP port sweep, targeted UDP on common services, service/version detection with scripts, then passive-style gathering from DNS (zone transfer attempts, PTR sweeps, certificate transparency lookups) and HTTP headers. Record every discovered hostname and port in a single asset list you keep updating.
Treating SMB, LDAP, and RPC enumeration as separate one-off commands instead of correlating users, groups, shares, and password policy into an attack plan.
Each tool (enum4linux, ldapsearch, rpcclient, CrackMapExec) produces a wall of text, and candidates copy output into notes without normalizing usernames, identifying privileged groups, or checking lockout thresholds before password attacks.
What to do instead
Build a small structured table of users, groups, group memberships, shares, and policy values. Explicitly check the account lockout threshold and observation window before any spraying, and use the enumerated user list as spray input only after confirming the policy permits it.
Firing a password spray or brute force at domain accounts without first reading the lockout policy, locking out valid accounts and burning the engagement.
Spraying is fast and satisfying, and candidates assume a low number of attempts per account is always safe without verifying the threshold or the reset counter.
What to do instead
Query the domain password policy (e.g., via LDAP or net accounts) and record the threshold and lockout duration. Keep attempts per account well below the threshold per window, space rounds out, and stop the moment a lockout is observed. Prefer single-password-across-many-users spraying over per-user guessing.
Stopping at initial low-privilege code execution and reporting 'shell obtained' rather than escalating, harvesting credentials, and demonstrating lateral movement toward the stated objective.
Getting a first shell feels like success, and candidates are unsure how to proceed from a service account to domain compromise, so they declare victory prematurely.
What to do instead
After foothold, enumerate local privileges, tokens, stored credentials, and misconfigurations (unquoted service paths, weak service ACLs, SeImpersonate, credential files). Then map the path to the objective: local admin, credential reuse, lateral movement, and privilege escalation to Domain Admin or the agreed target, documenting each hop.
Running Kerberoasting or AS-REP roasting and submitting the hashes to an offline cracker without first checking whether the recovered plaintext is even needed, then failing to test the cracked credentials against other systems.
The technique is memorable and candidates treat hash capture as the end goal, forgetting that the value is in reuse across the estate and in demonstrating impact.
What to do instead
After cracking, immediately test recovered credentials against SMB, WinRM, LDAP, and other hosts to find reuse and privilege. Where cracking fails, document the exposure (weak service account, RC4-enabled SPN) as a finding with its risk, and record which accounts were tested and where.
Testing a web application only through the browser UI and missing the API endpoints, parameters, and roles exposed in JavaScript, source maps, and hidden form fields.
The visible application is the obvious surface, and candidates underuse proxy history review and content discovery, so they never see the endpoints the front end calls behind the scenes.
What to do instead
Proxy all traffic, review the site map for API routes and parameters, fetch and read JavaScript bundles for endpoint strings and keys, run content discovery against discovered directories, and test each endpoint with multiple roles and HTTP methods. Log every request/response pair that supports a finding.
Reporting a vulnerability from a single anomalous response without reproducing it or capturing the exact request, so the finding cannot be verified or replicated.
Time pressure and excitement push candidates to note 'SQL injection found' from one error page, without confirming exploitability, impact, or a clean reproduction path.
What to do instead
For every candidate finding, reproduce it at least twice, save the raw request and response, and state the concrete impact (data read, auth bypass, command execution). If it cannot be reproduced deterministically, downgrade it to an observation or needs-review item rather than a confirmed finding.
Capturing a wireless handshake or PMKID and then reporting 'WPA2 cracked' without verifying the recovered passphrase actually authenticates to the access point.
The cracker prints a key and candidates assume success, skipping the validation step that proves the key works and that the finding is real.
What to do instead
After recovery, reconnect to the target SSID with the recovered passphrase and confirm association and DHCP. Record the capture file, the cracking method, time taken, and the successful reconnection as evidence; if the key does not authenticate, treat the capture as inconclusive.
Writing the report as a chronological tool log ('ran Nmap, then ran Hydra') instead of findings with evidence, risk rating, business impact, and remediation, and omitting the legal/scope section.
Candidates document what they did rather than what it means, and leave report writing to the final minutes, so the deliverable reads as a diary and lacks the scope, authorization, and methodology sections a client expects.
What to do instead
Draft the report skeleton early (scope and authorization, methodology, findings with evidence and risk, remediation, appendix of raw output). Write each finding in a fixed template: title, affected asset, description, reproduction steps, evidence, impact, severity, remediation. Reserve the last portion of exam time for polishing and cross-checking every claim against saved evidence.