PenTest+ common mistakes
PenTest+ · Understand the traps and how to avoid them.
Treats the statement of work, the rules of engagement, and the master service agreement as interchangeable, and picks whichever one 'sounds like' it authorizes the activity in the scenario.
The documents share vocabulary and in most real engagements one person handles all of them, so candidates never build a clean mental map of which artifact governs which question.
What to do instead
Write a one-line definition for each and drill it: SOW = deliverables, cost, timeline; ROE = what/when/how you may test, plus emergency contacts, stop conditions, and excluded techniques; MSA = standing legal/liability terms; NDA = confidentiality; test plan = your technical methodology. For any scenario question, first ask 'is this a scope/permission question or a deliverable question?'
Continues testing after hitting a critical finding, evidence of a prior compromise, or an out-of-scope asset, instead of pausing and escalating per the engagement terms.
The instinct from hands-on lab work is to keep pressing for more access; exam scenarios reward restraint and documentation, not maximum exploitation.
What to do instead
Memorize the escalation triggers as a short list: critical/domain-wide impact, evidence of a real attacker already present, PII or regulated data exposure, accidental scope escape, and any safety-critical system. For each, the answer sequence is stop -> preserve evidence -> notify the named contact per ROE -> wait for written direction.
Labels direct DNS queries to the target's own authoritative name server, direct site browsing, or banner grabs as 'passive reconnaissance' because the tool used is a lookup utility rather than a scanner.
OSINT tooling blurs the line; candidates classify by tool category instead of by whether packets reach client-owned infrastructure.
What to do instead
Apply a single rule: if traffic reaches an asset the client owns or controls (including their authoritative DNS server), it is active. Passive means third-party caches only - certificate transparency logs, WHOIS registries, Wayback Machine, Shodan/Censys, and search-engine queries. Note that Google dorking is passive from the target's view because the query goes to Google.
Misreads DNS enumeration output - confuses PTR with CNAME, treats a TXT record as a host, or does not recognize what a successful AXFR actually hands over.
Record types are memorized as trivia rather than as answers to 'what does this tell me about the target?', so the candidate can name the type but cannot act on the result.
What to do instead
Drill record semantics with intent: A/AAAA = live host, CNAME = alias chain that reveals third-party hosting, MX = mail provider and phishing surface, TXT = SPF/DKIM/DMARC posture and verification tokens, PTR = reverse mapping and naming convention leakage, NS/SOA = zone authority and transfer targets. An AXFR yields the full zone, which is a finding in itself as well as a host list.
Reports a scanner's output as the final finding list, including every plugin hit, without manually reproducing or validating the issues.
Scanner dashboards present findings as facts, and reproducing each one is slow; candidates under time pressure skip confirmation and default to 'the tool said so'.
What to do instead
Adopt the standard workflow: scan -> triage -> manual verification with captured request/response evidence -> severity adjustment -> report. Only validated findings get rated. State explicitly that unverified scanner hits are informational at most, and note that over-reporting false positives damages credibility with the client more than missing a low-severity item.
Assigns a raw CVSS base score to a finding as if it were the client's risk, ignoring temporal and environmental metrics and business context.
Base scores are the only number most tools surface, so they become the default answer, and candidates never learn that the other metric groups exist.
What to do instead
Memorize the three groups and what moves each: base = intrinsic and unchanging; temporal = exploit maturity, remediation level, report confidence; environmental = confidentiality/integrity/availability requirements and modified attack vectors. In scenarios, ask what compensating controls or data sensitivity the client described before quoting a number, and treat risk rating as severity plus context.
Confuses attack mechanisms that look similar in a payload string - reflected vs stored vs DOM-based XSS, SSRF vs CSRF, or error-based vs blind SQL injection.
The categories are learned from payload examples rather than from the data-flow path each one exploits, so recognition collapses when the scenario is described in prose instead of code.
What to do instead
Build a mechanism-first table: for each class, record where the payload is stored, who executes it, and what the attacker gains. Reflected = payload in the request, echoed back; stored = persisted server-side, served to other users; DOM = never leaves the browser, sink is client-side JS. SSRF = server makes the request; CSRF = victim's browser makes an authenticated request. Then classify by tracing the flow in the scenario rather than matching keywords.
Selects a payload that cannot traverse the described network - bind shell through NAT/ingress filtering, or a staged loader where egress filtering blocks secondary connections - instead of choosing the transport the environment permits.
Candidates rehearse one successful payload per lab target and reuse it, treating shell type as a preference rather than as a function of the firewall and NAT rules stated in the scenario.
What to do instead
Before choosing, answer two questions from the scenario: which direction do connections succeed (outbound-only favors reverse shells, commonly over 443), and is a second connection possible (if not, choose stageless). Bind shells require inbound reachability to the target. Write the decision out as a short if/then rule so it becomes reflex.
Uses pivoting, lateral movement, and privilege escalation interchangeably, and cannot map SSH -L, -R, and -D to the topology they produce.
All three are 'moving around the network' in casual description, and the tunnel flags are memorized as syntax without a picture of where the listener ends up.
What to do instead
Separate the concepts: privilege escalation raises rights on the current host; lateral movement reaches a new host; pivoting uses a compromised host as a relay to reach a network you cannot otherwise route to. For SSH, anchor each flag to the listener location: -L listens on your side (local forward in), -R listens on the remote side (remote forward back to you), -D creates a SOCKS proxy on your side for tooling such as proxychains.
Blurs Kerberos and NTLM credential attacks - calls any hash-cracking exercise Kerberoasting, or assumes pass-the-hash works against a Kerberos-only service.
All of them are 'use stolen credentials to move', and the distinguishing preconditions (SPN present, preauthentication disabled, NTLM enabled) are the part candidates skip.
What to do instead
Anchor each attack to its precondition: Kerberoasting needs a service account with an SPN and any valid domain user to request the ticket; AS-REP roasting needs an account with Kerberos preauthentication disabled; pass-the-hash needs NTLM authentication to be permitted and uses the hash directly with no cracking; pass-the-ticket injects a TGT/TGS and works where NTLM is blocked. Ask 'what must be true about the target account or protocol?' before naming the technique.