The penetration testing method: permission, scope and the report
Lesson 1 of 3
1The penetration testing method: permission, scope and the report
The big pictureCompanies pay people to break in, because it is better to find the flaw yourself before the attacker does. But the difference between a tester and an attacker is not the tools, which are the same; it is permission and purpose: the tester works with permission, stops at the edge of scope, reports a critical risk at once, and aims for the company to fix things, not to prove how clever they are.
What the picture shows: No phase starts before the one before it, you never leave the scope, and every step is logged with its time because the report needs proof for every claim.
Map of this part
The concepts in order, click any one to jump to it:
Two ways into the same idea
Picture a bank hiring you to test whether its vault can be reached. Before anything, you sign a contract: which branch, which days, what you may do (open the door? touch the money?), and who to call if you see a real burglar. Then you walk around, observe, try the doors, and write down everything you did. The result is not taking the money but a report: "the back door opens this way, and this is the fix".
Rules of engagement (RoE): the exact scope by address and domain, what is out of scope, the time window, banned methods (denial of service, social engineering unless named), emergency contacts, and data handling. Kinds: black box (no information), grey box (an ordinary user account), and white box (code and design). Methods: PTES, NIST SP 800-115, and the OWASP WSTG for the web. Phases: passive then active reconnaissance, port and service scanning (Nmap), vulnerability analysis, verification through safe exploitation, post-exploitation as far as scope allows, then the report. CVSS 4.0 (FIRST, November 2023) scores 0 to 10: low 0.1–3.9, medium 4–6.9, high 7–8.9, critical 9–10. Priority = severity combined with how much the asset matters and how easy the exploit is. The report: executive summary, method, findings (description, evidence, impact, fix), then a retest after the fix.
Before You Start
🐧Linux for defenders
You work in the terminal with confidence.
🌐Web application security
You know the OWASP Top 10.
The Core Idea
1Permission before anything
The signed paper is what makes your work a test and not a crime. It protects both sides: the company knows what will happen, and you know your limits. Read the scope letter by letter: if app.company.sa is in scope, mail.company.sa is not, even if you spot an obvious flaw.
| RoE item | Example |
|---|---|
| Scope | app.company.sa and 10.20.0.0/24 only |
| Out of scope | Email, third-party cloud systems, staff devices |
| Window | Sunday to Thursday, 8 pm to 6 am |
| Not allowed | Denial of service, deleting or changing data, phishing |
| Emergency | The security manager, their phone, and when to call: any critical risk or sign of a real attacker |
| Data | No real data is copied; a screenshot proving access is enough |
2The phases
Each phase feeds the next. Press one to see what happens in it, and the defender's side of it.
The phases of a penetration test
A grey-box test of an internal web app, with an ordinary staff account. Everything below stays inside the written scope.
The idea: a test is an organised process; each phase produces information for the next and evidence for the report. And the defender learns from each phase what they should have seen.
1 · Recon
You gather what is public: subdomains from public TLS certificates, the technologies used, staff names and their email format. Defender: review what your certificates and pages reveal.
2 · Scanning
You scan open ports and service versions with Nmap, in scope only. Defender: a scan this size should show in your firewall and IDS; if it did not, that is a finding in itself.
3 · Analysis
You match versions to known flaws and test the logic by hand (permissions, sessions). Scanners make claims; you verify them. Defender: version inventory and patching.
4 · Verification
You prove the flaw with the least impact: reading one record that is not yours proves an IDOR, with no table download. Defender: did anyone see the abnormal access?
5 · Report
For each flaw: description, evidence, business impact, CVSS score and the suggested fix. Plus a one-page executive summary. Then a retest after the fix. Defender: a fix plan with dates and owners.
3Severity and priority: CVSS 4.0 and beyond
CVSS gives a flaw a technical score from 0 to 10. But real priority needs more: a "high" on an isolated test server is less urgent than a "medium" on the payroll system open to the internet. Rank findings by score together with how much the asset matters and whether a public exploit exists (the CISA KEV list of actually exploited flaws is an excellent reference).
The VPN rose to the top despite a lower score than the SQL injection, because it is being exploited in the wild. That is what a manager needs to decide where to start.
def band(score):
return "critical" if score >= 9 else "high" if score >= 7 else "medium" if score >= 4 else "low" if score > 0 else "none"
findings = [ # title, CVSS 4.0 base score, asset weight 1-3, exploited in the wild?
("SQL injection in /reports search", 9.3, 3, False),
("IDOR: any user reads any payslip", 7.1, 3, False),
("Outdated VPN appliance (in CISA KEV)", 8.7, 3, True),
("Verbose error pages show stack traces", 5.3, 1, False),
("Old TLS 1.0 on the test server", 3.7, 1, False),
]
def priority(f):
_, score, weight, kev = f
return score * weight + (10 if kev else 0)
for title, score, weight, kev in sorted(findings, key=priority, reverse=True):
print(f"{score:>4} {band(score):<8} asset x{weight} {'KEV ' if kev else ' '}{title}")4The report: the real product
The client does not see your work; they see your report. Write the executive summary for a manager who does not know the technology: the most serious finding, what it means for the business, and what to do first. Write the findings for the developer: clear steps to reproduce, evidence (a request and response or a screenshot), and a practical fix. And keep secrets out of the report: no real passwords and no customer data.
FINDING 2 · IDOR: any user can read any payslip CVSS 4.0: 7.1 (High)
Asset : payroll.company.sa (in scope, production)
What : /api/payslips/{id} returns the payslip for any id without checking it belongs to the caller.
Evidence : logged in as test user A (id 1042), GET /api/payslips/1043 returned user B's payslip
(screenshot 4, name and salary masked). Only one record was viewed.
Impact : every employee's salary is readable by every other employee: privacy breach (PDPL), trust.
Fix : check ownership on the server for every object (payslip.owner == session.user), deny by
default, and add a test that user A gets 403 for user B's id.
Retest : 2026-11-20, confirm 403 for foreign ids.Worked example
The task: during an authorised test of app.company.sa, you notice the same server hosts admin.company.sa with a login page whose default password is obvious. admin is not in scope. What do you do?
The answer: Do not try to log in. Out of scope means out of permission, however easy it looks. Note what you saw without interacting (the name and that it shares the address), call the contact named in the rules of engagement, and offer to widen the scope in writing if they wish. In the report add an "out of scope, not tested" note with a recommendation to review it. That protects the client and you.
Myth vs Reality
| Myth | Reality |
|---|---|
| A pen tester is a hacker who tries everything. | A professional with a contract, a scope and a method, who stops at the boundaries and produces a report. |
| An automatic scanner is enough. | Scanners find the known and make false claims. Logic and permission flaws need a thinking human. |
| My intentions are good, so testing a site without permission is fine. | The law looks at permission, not intention. Even reporting a flaw goes through official disclosure programmes. |
Where you meet it at work
🏦A mandatory annual test
Banks and government bodies require periodic tests in their controls.
🐞Bug bounty programmes
A published scope and clear rules for anyone who wants to test and report legally.
🧑💻The development team
A clear report turns into fix tasks and automatic tests.
Test your understanding
What turns a break-in attempt from a crime into a test?
Without written permission access is unlawful whatever the intention.
A flaw scores CVSS 7.5. What is its band?
7.0 to 8.9 is high; 9 and above is critical.
You find a critical risk open to the internet during the test. When do you report it?
The rules of engagement set a channel for critical risk, because a real attacker may find it before the report.
A test where you are given an ordinary user account. What kind is it?
Black has no information; white has the code and design.
Why might an 8.7 flaw come before a 9.3 one in priority?
Priority = severity + asset importance + real-world exploitation.
Quick review cards
Check Your Understanding
What do you do if you find traces of a real attacker during the test?
Stop and call the emergency contact at once, because it has become an incident, not a test.
Why prove a flaw with the least possible impact?
Because the goal is proof, not harm: one record is enough, and downloading data hurts the client and usually breaks the rules.
Who is the executive summary for, and who are the findings for?
The summary is for management in terms of impact and decisions; the findings are for developers with steps, evidence and fixes.
Resources for this lesson
Grouped by type. Start with the official docs for precision, or an article or video for the explanation.
Done with this lesson?
Sign in to save your progress.