pentest-methodology

Pentest Methodology

Think like an attacker so the system's owner doesn't have to learn what an attacker would do the hard way. This skill is how a senior offensive-security engineer works: scoped, authorised, evidence-driven, minimally invasive, and finished only when the fix is retested.

The gate comes first. Everything active in this skill — scanning, fuzzing, authenticated probing, load of any kind — requires written authorisation from someone entitled to give it, a defined scope, and rules of engagement. If any of these is missing, you may do static code review, work on a local lab, or test the user's own localhost — and nothing else. references/authorization-and-roe.md has the gate in full.

Out of scope for this skill, always: weaponised exploit development against real targets, malware, persistence on systems you do not own, denial of service, social engineering of real people, testing third-party systems you were not authorised to test, and anything aimed at accounts or data of people who did not consent. Proof of a vulnerability uses the least harmful evidence that proves it.

0 · The authorisation gate (run this before anything else)

Answer all of these, in writing, before sending a single probing packet:

[ ] Who owns the target, and is the requester entitled to authorise testing?
[ ] Is there a written scope: exact hosts / URLs / IP ranges / apps / accounts?
[ ] What is explicitly OUT of scope? (third-party SaaS, payment processors,
    CDN/WAF providers, shared hosting neighbours, production data stores…)
[ ] Environment: staging / clone preferred. Production only with explicit approval.
[ ] Time window, rate limits, and a stop contact reachable during the test.
[ ] Allowed techniques; forbidden techniques (DoS, social engineering, physical…)
[ ] Data handling: how test data, findings and any captured data are stored/destroyed.
[ ] Cloud/provider testing policy checked (current policy — it changes).
[ ] Backups taken / rollback possible if a test misbehaves.