Pentesting Methodology
A controlled end-to-end workflow for scoping, discovery, validation, evidence, reporting, and retesting.
On this page · 5 sections
Authorization & rules of engagement
A strong assessment starts with boundaries that an operator can apply without interpretation. Translate the contract into a working scope sheet and keep it visible throughout the engagement.
- Confirmed legal owner for every domain, CIDR, tenant, and application.
- Approved source IPs, accounts, tools, timing, and maximum request rate.
- Excluded systems and prohibited actions, including denial-of-service and destructive changes.
- Named stop contact, emergency phrase, communication channel, and evidence-transfer method.
- Retention and deletion date for screenshots, logs, tokens, and customer data.
ENGAGEMENT:
IN SCOPE:
OUT OF SCOPE:
WINDOW / TIMEZONE:
SOURCE IPS:
TEST IDENTITIES:
RATE LIMIT:
PROHIBITED ACTIONS:
STOP CONTACT / PHRASE:
EVIDENCE RULES:External and internal workflow
External tests begin with ownership-aware asset discovery. Internal tests begin with an approved network location and identity context. If an external engagement reaches an internal boundary, re-scope and restart discovery from that new trust zone.
| Phase | External focus | Internal focus |
|---|---|---|
| Context | Organizations, domains, ASN, cloud edges | Network segment, identity, trust zone |
| Discovery | Passive-first asset inventory | Hosts, services, directory and management planes |
| Validation | Internet exposure and application controls | Segmentation, identity and host configuration |
| Evidence | Public asset ownership and request pairs | Host, account, event and control context |
- 01
Normalize every discovered asset with source, timestamp, ownership confidence, and scope status.
- 02
Validate live services at the agreed rate before deeper testing.
- 03
Create a hypothesis for each control being tested and define the minimum proof.
- 04
Record expected versus observed behavior and stop after reproducibility is established.
Asset and service discovery
Discovery should reduce uncertainty rather than produce the largest possible scan. Start passive, de-duplicate aggressively, then validate only the approved set.
dig +short A example.com
dig +short AAAA example.com
curl -sS -D - -o /dev/null https://example.com/- Capture redirect chains, certificate names, headers, and technology indicators.
- Separate CDN addresses from organization-owned ranges.
- Record service name and protocol confidence rather than trusting port numbers alone.
- Re-run discovery when credentials or a new trust zone legitimately expands visibility.
Vulnerability validation & controlled exploitation
A scanner result is a lead, not a finding. Reproduce the broken security expectation manually, using synthetic records or designated test accounts wherever possible.
- 01
State the expected control and preconditions.
- 02
Capture a clean baseline request or command.
- 03
Change one variable and observe the security decision.
- 04
Confirm repeatability without accessing unrelated data.
- 05
Preserve sanitized evidence and document cleanup.
Evidence, reporting & retest
TITLE:
AFFECTED ASSET / CONTROL:
PRECONDITIONS:
STEPS TO REPRODUCE:
OBSERVED RESULT:
EXPECTED RESULT:
IMPACT:
SANITIZED EVIDENCE:
ROOT-CAUSE REMEDIATION:
VERIFICATION TEST:- Tie severity to a realistic path and affected boundary.
- Include timestamps, account role, request IDs, tool versions, and exact scope.
- Recommend root-cause remediation and a regression test.
- Retest both the original path and nearby variants.
- Confirm evidence deletion at the agreed date.