eJPT common mistakes
eJPT · Understand the traps and how to avoid them.
Running only the default top-1000-port scan and moving straight to exploitation, never scanning all 65,535 TCP ports or any UDP ports on a target.
Scanners like Nmap and most GUI tool profiles ship with a fast default port set, and the candidate is anxious to start attacking the first interesting service they see. Non-standard high ports (management consoles, alternate SSH, custom app ports) and UDP services (SNMP, TFTP, NFS-related) simply never appear in the results, so whole attack paths stay invisible.
What to do instead
Adopt a fixed scan sequence per host: (1) fast full-range SYN scan of 1-65535 with -p- and a high min-rate, (2) service/version detection (-sV) plus default scripts (-sC) against only the discovered open ports, (3) a targeted UDP scan of the top ~50 UDP ports. Only after step 3 do you start attacking.
Discovering a password, hash, SSH key, or flag and then continuing to hunt without writing it down, so it is lost or mis-transcribed when it is needed for the report or for reuse on another host.
Tunnel vision: once a shell is obtained the candidate focuses on 'what next' inside that host and assumes they will remember the credential. Terminal scrollback is later buried under hundreds of lines of output, and the exam environment may be reverted or sessions may drop.
What to do instead
Maintain a live notes file per host with sections for ports, services, credentials, hashes, flags/answers, and commands run. Paste raw output into it at the moment of discovery, and take a timestamped screenshot of the command and its output in the same action.
Treating each host as an isolated puzzle and never replaying credentials already obtained against every other host and service in scope.
Candidates mentally tag a credential to the box where it was found ('that's the web server password') and do not think of the estate as one network with shared accounts, reused local admin passwords, and common service accounts.
What to do instead
Keep a credential matrix (username / secret / source host) and, for every new credential, systematically try it against SSH, SMB, RDP, WinRM, FTP, databases, and every web login form on every in-scope host. Re-run this sweep each time a new credential or hash appears.
Scanning and attacking only from the initial attack host, concluding that the internal segment is unreachable, rather than routing traffic through a compromised host.
Proxychains and port-forwarding are usually configured once during study and then forgotten, and the failure mode looks like 'the host is down' rather than 'I have no route'. Timing out on a second network is often misread as an out-of-scope target.
What to do instead
When a host has two interfaces, immediately establish a pivot: SSH dynamic forwarding (-D 1080) with a proxychains config set to socks5, or a Metasploit route plus socks proxy. Then re-run the full scan sequence through the proxy, accepting that it will be slower and needs proxychains-friendly scanning options (TCP connect scans, no ICMP/ping).
Running an automated vulnerability scanner or exploit suggester against a web application and reporting its output as confirmed findings without manually reproducing any of them.
Scanner output is verbose and authoritative-looking, and manual verification of each item is slow. Black-box scanners also generate large numbers of false positives on custom applications, and they miss logic issues entirely (access control between users, parameter tampering, weak password reset, unrestricted file upload).
What to do instead
Use the scanner only to build a candidate list. For each candidate, reproduce it manually with curl or a proxy (Burp), capture the request/response pair as evidence, and discard anything you cannot reproduce. Then do a manual pass over every input point: authentication forms (default credentials, username enumeration), URL and body parameters, file uploads, and directory/file brute forcing.
Starting enumeration on the first host found without first extracting the exact in-scope host list and rules from the exam brief, resulting in time spent on out-of-scope machines and in-scope machines never being examined at all.
The brief is long, and the candidate skims it looking for the lab connection details. Scope is then inferred from whatever the first scan returns, which includes routers, appliances, and decoy hosts that are not part of the assessment.
What to do instead
Before touching a tool, write the scope (hostnames, IP ranges, any excluded addresses, permitted techniques) into the notes file and convert it into a checklist of every in-scope host and every question that must be answered. Tick hosts off as they are fully enumerated; do not finish until the list is complete.
Skipping protocol-level auditing of SMB, FTP, SNMP, NFS, and LDAP, treating those ports as 'not vulnerable' simply because a version banner came back.
These services look unglamorous next to a web app, and the candidate does not have a memorised command for each. Anonymous FTP, SMB null sessions and share enumeration, default SNMP community strings, and world-readable NFS exports yield credentials and file contents far more often than memory-corruption exploits.
What to do instead
Attach a fixed enumeration checklist to each service: SMB - share listing and null/guest session checks, user enumeration; FTP - anonymous login and write permission test; SNMP - walk with public/private community strings; NFS - export listing and mount attempt; LDAP - anonymous bind and attribute dump. Run the checklist every time the port appears.
Obtaining a shell and immediately moving on, without stabilising it, checking privilege level, or confirming which user context the process is running as.
The rush of a successful exploit makes the shell feel like the finish line. Unstable non-interactive shells then die mid-task (losing work), and running as an unprivileged service account is mistaken for running as root or SYSTEM, so local privilege escalation and credential harvesting are never attempted.
What to do instead
On every shell: run whoami/id, upgrade to a stable TTY (python3 pty spawn plus stty raw -echo, or a proper reverse shell), background it, and record the user and host in notes. Then always perform a local enumeration pass on that host before pivoting onward.
Spending the whole session on one stubborn host or one exploit path instead of timeboxing and moving to the next target.
Sunk-cost thinking: the candidate has invested an hour in a service and keeps assuming the next tweak will work. The exam is scored across many hosts and questions, so a single box is never worth the majority of the time.
What to do instead
Set a hard per-host timebox (e.g. 60-90 minutes for initial access). If it expires with no progress, record what was tried, move to the next in-scope host, and return later with fresh ideas. Keep a running 'parked' list so nothing is forgotten.
Leaving the written report and the exam answers to the final hours, producing answers that are unsupported by evidence or that do not match the exact wording of what was asked.
Candidates treat the report as paperwork that can be reconstructed from memory at the end, but by then command output is scattered across terminals and screenshots are unnamed.
What to do instead
Write the report incrementally: for each finding, immediately capture the affected host, the exact command or request, the raw output or screenshot, the impact, and the remediation. Answer each exam question verbatim in the notes at the moment it is solved, with a pointer to the evidence file.