PTES

Per PTES Exploitation phase: leverage vulnerabilities. Requirements include (a) execute exploits within scope + rules of engagement + (b) maintain stealth + minimise impact + (c) document exploitation including evidence + screenshots + (d) capture credentials + tokens + sensitive data per scope + (e) maintain chain of custody + (f) prepare for post-exploitation.

• PTES Phase 5 evidence

• scope + threat modeling + reporting partial

Per PTES Intelligence Gathering phase: collect information about target. Requirements include (a) conduct passive OSINT including domains + employees + technology + (b) conduct active reconnaissance including DNS + WHOIS + service enumeration + (c) social media + LinkedIn + GitHub investigation + (d) identify entry points + attack surface + (e) document findings + (f) maintain chain of custody for evidence.

• PTES Phase 2 evidence

• scope + threat modeling + reporting partial

Exploitation must be planned to maximise evidence value while minimising risk to production systems, including consideration of payload selection, timing, and rollback.

• Exploit plan with risk assessment
• Payload selection rationale
• Rollback procedure
• Production sensitivity check

• Public exploits used without code review
• No rollback for destructive payloads
• Tests run during peak business hours

Where in scope, the tester must consider AV, EDR, IDS, and similar controls and use evasion techniques that mirror realistic threat actor tradecraft while leaving sufficient logs for blue team replay.

• Evasion technique catalogue
• Detection bypass evidence
• Blue team replay handoff package
• Tool obfuscation notes

• Off the shelf payloads without obfuscation
• No replay handoff
• Excessive stealth defeats learning value

Where commodity exploitation fails, the tester should develop or adapt custom exploits where the engagement profile supports it, documenting the development process and impact carefully.

• Exploit source or harness
• Test environment evidence
• Approval to deploy in target
• Code review by second tester

• Custom exploit not peer reviewed
• Deployed without test environment validation
• Reuse without rebuild for current target

Open source intelligence collection must enumerate public information about the target organisation, infrastructure, personnel, and technology stack without direct interaction with target assets.

• OSINT findings notebook
• Domain and subdomain inventory
• Public document metadata analysis
• Social media exposure summary

• Reliance on a single OSINT tool
• Missing certificate transparency review
• Employee enumeration not validated

Active reconnaissance including port scans, service identification, and banner grabbing must enumerate live hosts and exposed services within the agreed scope.

• Nmap or equivalent scan output
• Service version inventory
• Identified host operating systems
• Scan timing and rate evidence

• Scans too noisy and trigger denial of service
• Incomplete UDP coverage
• Out of scope hosts touched

Where social engineering is in scope, intelligence on personnel structure, communication patterns, and pretext context must be gathered ethically and within agreed limits.

• Pretext design document
• Personnel mapping
• Approved targets list
• Ethical limits acknowledgement

• Targeting of executives without consent
• Personal email of staff used without authorisation
• Pretext that misrepresents law enforcement

After initial access, the tester must enumerate the compromised environment to identify pivot routes, sensitive data, and additional vulnerabilities reachable from the new vantage point.

• Network map from inside view
• Credentials extracted with sanitised logs
• Pivot pathway diagram
• Identified sensitive data stores

• No internal enumeration once initial foothold gained
• Credentials extracted but not stored securely
• Pivoting tested but pathways not documented

Where persistence is in scope, the tester must install controlled persistence to assess detection capability, with all artefacts inventoried for removal at engagement end.

• Persistence inventory
• Cleanup procedure
• Client notification of remaining artefacts
• Detection metric tracking

• Persistence left behind after engagement
• No detection capability measured
• Persistence outside scope of authorisation

The tester must demonstrate impact in business terms by safely simulating data exfiltration of test or low sensitivity records, never extracting genuinely sensitive customer data unless explicitly authorised.

• Synthetic data used for exfil
• Authorised exfil records
• Channel evidence (DNS, HTTPS, etc.)
• Business impact narrative

• Exfiltration of real customer records without authorisation
• No business impact framing in report
• Channel coverage limited to one technique

All testing artefacts including accounts, files, persistence, and modifications must be removed at engagement end, with a written attestation of cleanup provided to the client.

• Cleanup checklist signed
• Client attestation letter
• Removal logs
• Outstanding artefacts list (if any)

• Local accounts left active
• Files left in temp directories
• No written attestation provided

The penetration tester and client must define explicit scope boundaries including target IP ranges, domains, applications, physical sites, and business units that are included or excluded from testing.

• Signed scope document
• Asset inventory under test
• Exclusion list
• Network and application diagrams

• Scope defined only verbally
• Third party cloud assets not authorised by hosting provider
• Drift from agreed scope during execution

Rules of engagement document permitted techniques, off limits actions, timing windows, escalation contacts, and conditions under which testing must pause or stop to protect business operations.

• Rules of engagement document
• Authorisation letter (get out of jail card)
• Emergency contact tree
• Testing window calendar

• No written authorisation carried by tester
• Stop conditions not specified
• Out of hours testing without contact tree

Test objectives, success criteria, and threat scenarios must be agreed in advance so findings and the final report can be assessed against business risk rather than raw vulnerability counts.

• Objectives memo
• Threat scenarios list
• Success criteria sign off
• Mapping to business risk register

• Engagement framed as compliance checkbox
• No business risk linkage
• Vague objectives such as find vulnerabilities

The report must include an executive summary that communicates business risk in language accessible to non technical leadership, including overall posture and a small set of strategic recommendations.

• Executive summary section
• Risk heat map
• Strategic recommendation list
• Posture score with rationale

• Executive summary too technical
• No strategic recommendations
• Heat map without scoring methodology

The technical report must detail each finding with severity, evidence, reproduction steps, business impact, and remediation guidance, supporting both engineering and audit consumption.

• Finding table
• Reproduction steps
• Screenshots or logs
• Remediation guidance referencing standards
• Severity rationale

• Severity assigned without methodology
• No remediation guidance
• Findings lack reproduction evidence

The report should include a remediation roadmap prioritised by risk and effort, and a process for retesting fixed findings to verify closure.

• Prioritised roadmap
• Effort estimates
• Retest scope and timing
• Closure verification records

• No retest scope agreed
• Closure documented without verification
• Roadmap not tied to business calendar

Threat modeling must identify business assets, their value, and likely adversary motivations to focus testing on what matters to the client rather than what is easy to attack.

• Asset value inventory
• Crown jewels list
• Adversary capability profile
• Mapped threat scenarios

• No business asset analysis
• Threat model copied from prior client
• Crown jewels not validated with client

The model must identify likely threat agents (insiders, organised crime, nation state, hacktivist) and their capability and intent, calibrating test sophistication accordingly.

• Threat agent matrix
• Capability scoring
• Intent assessment
• Calibration of test tools to agent profile

• Single generic threat actor assumed
• Capability score lacks evidence
• Insider threat ignored

Capabilities such as tooling, technical knowledge, communication channels, and finances must be mapped to threat agents and reflected in the test plan.

• Tooling inventory
• Funding and time assumptions
• Communication patterns considered
• Test plan tied to capability map

• Plan ignores low capability but realistic threats
• Mismatch between plan and assigned tester skill
• No mapping to commodity malware ecosystem

Vulnerability analysis must combine automated scanning and manual validation to identify weaknesses, eliminate false positives, and confirm exploitability paths.

• Scanner output
• Manual validation notes
• False positive disposition log
• Vulnerability ranking rationale

• Reports based on raw scanner output
• No manual validation of high impact findings
• False positive rate not tracked

Both passive techniques such as traffic monitoring and active techniques such as fuzzing and probing must be used to expose flaws in design, configuration, and implementation.

• Traffic capture logs
• Fuzzing harness configuration
• Configuration review notes
• Source code review (where in scope)

• Reliance on scanners only
• No fuzzing of custom protocols
• Configuration review omitted

Identified vulnerabilities must be researched against public databases (CVE, vendor advisories) and proprietary findings documented with reproducible steps.

• CVE mapping table
• Proof of concept code or steps
• References to advisories
• Internal vulnerability ID assignment

• No CVE mapping
• Proprietary findings without repro steps
• Outdated advisory references

Per PTES Post Exploitation phase: assess impact. Requirements include (a) establish persistence appropriate to scope + (b) lateral movement + privilege escalation per scope + (c) identify business impact + sensitive data exposure + (d) document attack chain + (e) maintain operational security + (f) prepare for cleanup.

• PTES Phase 6 evidence

• scope + threat modeling + reporting partial

Per PTES Pre-Engagement Interactions phase: define engagement parameters. Requirements include (a) define scope including in-scope + out-of-scope assets + IP ranges + applications + cloud + APIs + (b) define rules of engagement including testing windows + escalation + emergency contacts + (c) obtain authorisation + sign-off + (d) define communication channels + reporting cadence + (e) determine threat model + objectives + (f) maintain documented engagement letter + scope.

• PTES Phase 1 evidence

• scope + threat modeling + reporting partial

Per PTES Reporting phase: deliver findings + cleanup. Requirements include (a) prepare executive summary + technical report + (b) classify findings by severity + likelihood + impact + (c) provide remediation guidance + verification approach + (d) clean up artifacts + persistence + restore systems + (e) maintain chain of custody for evidence + (f) integrate with client remediation tracking + verification testing.

• PTES Phase 7 evidence

• scope + threat modeling + reporting partial

Per PTES Threat Modeling phase: model threats. Requirements include (a) identify threat agents relevant to target including external + internal + nation-state + criminal + (b) model attack scenarios + paths + (c) determine motivations + capabilities + (d) align scenarios to engagement objectives + (e) document threat model + (f) integrate with vulnerability analysis + exploitation.

• PTES Phase 3 evidence

• scope + threat modeling + reporting partial

Per PTES Vulnerability Analysis phase: identify weaknesses. Requirements include (a) conduct vulnerability scanning + manual review + (b) validate findings + remove false positives + (c) prioritise by exploitability + impact + business context + (d) cross-reference threat intelligence + CVE + ATT&CK + (e) document validated vulnerabilities + (f) integrate with exploitation.

• PTES Phase 4 evidence

• scope + threat modeling + reporting partial