Penetration Tester

Penetration Tester

When to Use

• Plan or execute authorized penetration tests (cloud workload, wireless) spanning multiple domains under one ROE
• Coordinate dedicated network/AD/infra assessments → network-pentester
• Draft or validate rules of engagement, asset lists, and emergency stop procedures
• Perform reconnaissance and vulnerability identification with manual validation
• Develop proof-of-concept exploitation and document attack paths within agreed impact
• Execute in-scope post-exploitation (credential proof, lateral movement, objective demo) with cleanup
• Produce remediation-focused reports and retest critical/high findings

When NOT to Use

• Deep web application or API-only assessments (OWASP, proxy methodology, GraphQL) → web-pentester
• Dedicated internal/external network, AD, segmentation, wireless methodology → network-pentester
• Triage SIEM/EDR alerts or run SOC playbooks → soc-analyst
• Lead live incident command, war room, or stakeholder comms → incident-responder
• Acquire and analyze forensic disk/memory images → digital-forensics-analyst
• Disassembly, decompilation, patch diff, or malware RE lab work → reverse-engineer
• Jailbreak LLMs, prompt injection, or agent tool abuse → ai-redteam
• Campaign planning, purple team, detection validation at program level → red-team-specialist
• Implement cloud IAM, CSPM, landing zone guardrails → cloud-security-engineer
• Map audit controls or continuous compliance evidence → compliance-engineer
• Add CI/CD security gates or SBOM pipelines → devsecops

Related skills

Core Workflows

1. Scope and authorization

Do not test without written authorization.

1. Confirm signed SOW/ROE: assets, methods, windows, contacts 2. Define out-of-scope (third parties, prod PII, physical access, DoS unless approved) 3. Agree severity rubric and evidence handling 4. Establish emergency stop and escalation path 5. Prefer isolated lab or designated test tenants

See `references/scoping_rules_of_engagement.md` and `references/penetration_tester_scope.md`.

2. Reconnaissance and vulnerability identification

passive OSINT → asset inventory → service/version ID → auth surface mapping → validate findings

Document source, timestamp, tool, and raw output references. Validate scanner output manually.

See `references/recon_and_vulnerability_identification.md`.

3. Exploitation and post-exploitation (in scope only)

• Minimal PoC steps; redacted evidence
• Clear preconditions (role, network position, config)
• Stop at agreed impact; chain into attack paths when useful
• Post-exploitation only per ROE; remove persistence and test artifacts before closeout

See `references/exploitation_and_post_exploitation.md`.

4. Reporting, remediation, and retest

Per finding: title, severity, impact, reproduction, evidence, remediation, retest criteria. Deliver executive summary + technical appendix; schedule retest for critical/high.

See `references/reporting_and_remediation.md` and `references/retest_and_safe_practices.md`.

When to load references

Exploitation and post-exploitation

Table of contents

1. Exploitation principles 2. Proof-of-concept template 3. Attack-path chaining 4. Post-exploitation (in scope) 5. Cleanup 6. Out of scope behaviors

Exploitation principles

• Minimal impact — demonstrate the weakness; do not maximize damage
• In scope only — stop at agreed objective (e.g., single host proof, no domain-wide ransom simulation)
• No real harm — avoid deleting data, disrupting production, or exfiltrating unnecessary PII
• Document preconditions — role, network path, config, chained bugs
• Preserve evidence — redact tokens, passwords, and personal data in artifacts

If exploitation risks instability, coordinate with customer before proceeding.

Proof-of-concept template

Attack-path chaining

When useful, document chains:

Initial access → privilege escalation → objective (per ROE)

Example: phishing not in scope → do not include phishing. Web RCE in scope → document through agreed depth only.

Post-exploitation (in scope)

Perform only what ROE permits:

Do not install ransomware, crypto-miners, or long-term backdoors unless explicitly part of a scoped red-team exercise with cleanup plan.

Cleanup

Before engagement closeout:

• [ ] Remove shells, web shells, scheduled tasks, and test accounts created
• [ ] Revoke API keys or tokens issued for testing
• [ ] Confirm with customer that monitoring alerts from testing are understood
• [ ] Deliver list of artifacts left intentionally (if any) with removal date

Document cleanup in the final report appendix.

Out of scope behaviors

Unless explicit written approval:

• Denial of service or resource exhaustion attacks
• Testing third-party services without their authorization
• Social engineering of employees
• Physical intrusion
• Supply-chain attacks on unrelated vendors
• Modifying production data or encryption keys
• Sharing exploits or customer data outside the engagement team

When in doubt, stop and confirm in writing.

Penetration tester scope

Table of contents

1. Role boundary 2. Engagement types 3. Partnership model 4. What good looks like

Role boundary

Pentester validates exploitability and impact of weaknesses; it does not operate the SOC, command live incidents, or build production security controls.

Engagement types

Clarify black-box vs grey-box vs white-box and credentials provided in the SOW.

Partnership model

What good looks like

1. Written authorization on file before any active testing 2. Every reported issue is manually validated with reproducible steps 3. Evidence is redacted; no unnecessary real customer data exfiltration 4. Cleanup completed; test accounts and shells removed 5. Retest scheduled for critical/high; closed only with evidence

Reconnaissance and vulnerability identification

Table of contents

1. Recon phases 2. Asset tracking 3. Vulnerability identification 4. Validation rules 5. Documentation

Recon phases

Execute in order unless ROE restricts passive activity:

passive OSINT → DNS/certificate transparency → active discovery (if allowed) →
service/version fingerprint → auth surface mapping → prioritize targets

Asset tracking

Maintain a table:

Never expand scope silently—confirm new assets with the customer.

Vulnerability identification

Sources (use per ROE):

• Manual testing (Burp, browser, API client)
• Authenticated scanners (when approved)
• Configuration review (headers, TLS, cloud settings—read-only unless exploit scoped)
• Source review (if white-box)

Classify each candidate:

Map to CWE/CVE and MITRE ATT&CK where it aids remediation—not for checkbox reporting.

Validation rules

Do not report unvalidated scanner output.

1. Reproduce the issue manually or with a minimal script 2. Confirm impact matches severity rubric 3. Note preconditions (auth level, network position) 4. Check if compensating control blocks exploitation in production 5. Capture evidence (request/response, screenshot)—redact secrets

Filter common noise: version banners alone, self-signed TLS in lab, missing headers without exploit chain.

Documentation

For each validated finding (draft):

• Title (business-readable)
• Affected asset and parameter
• Steps to reproduce (numbered)
• Evidence reference (file hash or ticket ID)
• Preliminary severity (finalize in report)

Log tool, command, timestamp, and operator for auditability and retest.

Reporting and remediation

Table of contents

1. Report structure 2. Finding template 3. Executive summary 4. Remediation guidance 5. Handoff

Report structure

Deliverables (per SOW):

1. Executive summary — risk posture, top issues, business impact (non-technical audience) 2. Technical report — all findings with reproduction and evidence 3. Appendices — scope, ROE, tools, glossary, cleanup attestation 4. Retest plan — dates and criteria for critical/high (if included)

Use consistent finding IDs across report, ticket system, and retest.

Finding template

Executive summary

Include:

• Engagement type, dates, and scope summary
• Overall risk rating (qualitative)
• Count by severity
• Top 3–5 themes (e.g., broken access control, secrets in repos)
• Positive observations (defenses that worked)
• Recommended prioritization for remediation

Avoid jargon; link to technical section for detail.

Remediation guidance

Write remediation actionable for engineering:

Note compensating controls already present and what remains exploitable.

Handoff

Schedule readout; capture questions and scope for retest.

Retest and safe practices

Table of contents

1. Retest workflow 2. Retest criteria 3. Safe testing practices 4. Legal and ethical boundaries 5. Tool and data hygiene

Retest workflow

1. Customer notifies fixes deployed (environment, build, date) 2. Confirm same scope and credentials as original test (or updated list) 3. Re-run minimal reproduction steps per finding ID 4. Record outcome: Pass, Fail, Partial, Not applicable 5. Update report or issue retest letter; do not reopen closed SOW without amendment

Retest criteria

Define pass conditions when the finding is first reported:

Document partial fixes (e.g., patched one endpoint but not others) as Fail with notes.

Safe testing practices

• Rate-limit active scans and brute force per ROE
• Prefer non-production environments when they represent prod code paths
• Coordinate with SOC if production testing may trigger alerts
• Use dedicated test accounts; never spray passwords against real employee accounts without approval
• Redact secrets in logs, reports, and chat
• Encrypt evidence at rest; limit distribution to engagement team
• Time-box sessions; avoid overnight unmonitored destructive tests

Legal and ethical boundaries

• Operate only under valid authorization in relevant jurisdictions
• Respect computer fraud and contract terms; unauthorized testing is out of scope for this skill
• Do not use engagement access for personal benefit or unrelated research
• Report critical issues promptly per ROE (responsible disclosure timeline)
• Do not disclose customer vulnerabilities publicly without written permission

This skill is operational guidance, not legal advice—escalate legal questions to customer counsel.

Tool and data hygiene

• Keep tool versions and command logs for reproducibility
• Store evidence in customer-approved repository (ticket, vault, encrypted share)
• Delete local copies per data-retention clause when engagement ends
• Do not upload customer data to public paste sites or unapproved cloud drives
• Segregate customer A and customer B workspaces to prevent cross-contamination

When retest passes, archive workpapers with pass evidence linked to finding ID.

Scoping and rules of engagement

Table of contents

1. Authorization gate 2. Scope worksheet 3. ROE decisions 4. Emergency stop 5. Severity rubric

Authorization gate

Stop. Do not run active scans, exploitation, or credential attacks without:

• [ ] Signed contract, SOW, or letter of authorization naming tester and customer
• [ ] Named technical and business contacts (24/7 during test window if production)
• [ ] Explicit in-scope assets (IPs, hostnames, app URLs, API bases, cloud accounts)
• [ ] Explicit out-of-scope (third parties, other tenants, physical, employees unless approved)
• [ ] Agreed testing window, timezone, and notification channel
• [ ] Emergency stop procedure and escalation path documented

If authorization is unclear, ask the customer in writing—do not assume implied consent.

Scope worksheet

Maintain a living asset inventory during recon; add newly discovered hosts only after customer confirms they are in scope.

ROE decisions

Record compensating controls that block exploitation (WAF, MFA, segmentation)—they inform severity and remediation, not excuses to skip validation.

Emergency stop

1. Customer or tester invokes stop word or stop channel 2. Cease all active testing immediately 3. Preserve logs and notes; do not delete evidence 4. Notify all testers and customer contact 5. Document stop reason and resume criteria in writing before continuing

Severity rubric

Align with customer before testing. Typical mapping:

Score impact × likelihood using agreed definitions; avoid inflating scanner noise to Critical.