The previous lesson ended with a question neither the scanner in 05-01 nor the detection in 05-02 answers: would it really hold up? A scanner checks versions and a detection observes what happens, but neither tries to chain three small weaknesses together — a missing header, a rate limit that does not exist and a predictable identifier — into a real compromise. That is what an attacker does, and that is what a penetration test simulates. This lesson teaches you to commission one, scope it, understand it and get value from it, with a defensive focus: you will see what was found in Nimbus's environment and, above all, how each thing was fixed.

⚠️ Legal warning — this is the most delicate lesson in the course

Running intrusion techniques against someone else's system without written authorisation is a crime, not a prank. In Spain:

• Art. 197 bis of the Spanish Criminal Code: accessing, or enabling access to, all or part of an information system by circumventing its security measures, or intercepting non-public transmissions, is punishable with a prison sentence. You do not need to cause damage or copy anything: accessing is enough.
• Art. 264 and following: damaging, deleting, altering or rendering inaccessible someone else's data or systems, with aggravated penalties if critical infrastructure or a large number of systems are affected.
• Art. 197 ter: producing, supplying or possessing tools designed to commit those offences is also punishable when they are intended for that purpose.

Practical consequences: "I just wanted to try it out" is not a defence, the absence of damage does not remove the offence, an intrusive nmap against a third party may already constitute an attempt, and the authorisation must be written, prior, signed by someone with the capacity to grant it and current on the date of the test. In the cloud you also need the provider's authorisation on top of the client's.

That is why this lesson contains no exploits, no payloads and no exploitation commands. It describes the phases conceptually, shows the equivalent defensive verification and develops in detail how what was found is fixed. The complete ethical and legal framework — including responsible disclosure and the reasoning behind these rules — is developed in 06-06. (Note: the specific criminal classification depends on the case; whenever in any doubt, seek prior legal validation.)

1. What a pentest is and what it is not
2. Modes: black-box, grey-box and white-box
3. Scope and rules of engagement
4. The methodological phases
5. What happens in each phase, and its defensive equivalent
6. Walkthrough of an authorised test against Nimbus's environment
7. The pentest report
8. What happens afterwards: remediation and retest
9. Responsible disclosure and bug bounty as a continuous alternative
10. How to commission a pentest as a small company
11. Where to practise legally

A pentest is an authorised test in which a professional tries to compromise a system using the same techniques as a real attacker, with a declared objective and a report as the product. Its value does not lie in finding loose vulnerabilities — that is what 05-01 is for — but in demonstrating impact by chaining them together.

For Nimbus today, a red team would be throwing money away. It measures detection and response capability, and in 05-02 we have only just built the first twelve detections: you commission one once they have been running for a year. What is appropriate is an annual pentest of the application and the infrastructure, which is where the product and the risk live.

And one distinction worth being clear about: a pentest does not prove that a system is secure. It proves that, within a bounded period and a bounded scope, a specific person found these things. A report with no findings usually means the scope was narrow or the time was short, not that the system is impregnable.

Grey-box gives the most value per euro, and in a multi-tenant SaaS the difference is enormous. The reason is direct: at Nimbus, the main risk is not a stranger getting in, it is a legitimate customer seeing another's data — the IDOR from 01-04 is exactly that. A black-box pentest would never have found it, because testing for it requires being inside with two accounts from two different tenants. Paying for somebody to spend three days discovering what an nmap gives you in ten minutes is a poor use of the budget.

Recommendation for Nimbus: grey-box with two test accounts from two different fictitious clinics plus a support-role account, and read access to the API documentation.

The rules of engagement are the document that turns an intrusion into a professional service. Without them, the test is legally fragile for both parties and operationally dangerous.

Five clauses deserve emphasis. Point 3 protects the auditor as much as the client: Nimbus cannot authorise testing against the payment gateway because it is not its own, and doing so would be exactly the offence in the opening warning. The cloud provider's authorisation (point 1) is mandatory and many people forget it: the provider has a testing policy and skipping it can get the account suspended. Point 5 is what stops an audit becoming a breach: if preproduction holds real data — remember A-22, "classification to be reviewed" — downloading it creates the very incident you wanted to prevent. Point 6c exists because it happens: sometimes the auditor finds that somebody is already inside, and at that point the test stops and the plan from 04-05 is activated. And point 8 is what separates a useful service from a posthumous report: if on day 2 somebody finds a way to read every clinic's data, you do not wait two weeks.

The recognised methodologies — PTES, OSSTMM and, for web applications, the OWASP Web Security Testing Guide (WSTG) — agree on the structure. The WSTG is also a public, free checklist: if you commission an application pentest, asking for WSTG coverage is the simplest way to compare offers.

Two warnings about the diagram. The first: phase 4 is not the objective, it is the proof. Exploiting serves to show that the vulnerability is real and to measure its impact; a professional auditor exploits just enough to document it and then stops. The second: phase 7 is the one almost everybody skips, and without it you do not know whether you paid for a homework list nobody did.

On the tools named, with the precision this lesson's approach demands: nmap and testssl.sh are for reconnaissance and verification and you use them yourself daily; ZAP and Burp are intercepting proxies that let you see and modify the requests your own browser sends — their legitimate use is against your own application; ffuf and gobuster try lists of paths and files against your own server to discover what was published by accident; hydra tries credentials, and it has only one admissible use here: checking against your own test accounts that lockout after failed attempts and rate limiting work, which is a defensive verification; and Metasploit is a framework packaging exploitation modules for known vulnerabilities, whose use stays within the authorised scope and never in this material.

An observation that saves money: almost everything a pentest finds that is genuinely valuable in a SaaS is manual and about business logic. The IDOR, the password recovery flow that allows user enumeration, the reports endpoint that ignores the role. No tool automates that, and that is why you pay for hours of a person with judgement.

Marta commissions five days of grey-box testing against preproduction, with the rules from §3. These are the five findings and their fixes.

The WHERE tenant_id was applied to the bookings and customers endpoints, but the reports module was written later and queries through an aggregate view that nobody reviewed. With the Alfa clinic's account, changing an identifier in the request returned the Beta clinic's billing totals.

The underlying fix is not the line that changed: it is that the customer identifier stops being an input parameter across the whole API. In addition, RLS was enabled on the aggregate view, which already protected the base tables but not the view (03-07). Generalising this pattern to the whole application is developed in 05-05.

The auditor confirmed that 4,000 authentication attempts could be sent in five minutes with no lockout and no slowdown: the door left open to the credential stuffing of 02-02.

And in the application, lockout per account as well as per IP, because password spraying uses a different IP for each attempt: after 10 failures against the same account in 15 minutes, a second factor is required or an exponential delay applied. Both feed detection D-01 from 05-02.

Content-Security-Policy was missing from the SPA, which turned any XSS into a complete session theft. It was deployed in report mode first so as not to break the application:

After reviewing the reports and adjusting two legitimate origins, it was switched to Content-Security-Policy in blocking mode. The full set of headers and the reasoning for each is in 05-05.

Reconnaissance found pruebas-2019.nimbusreservas.example, served by a host that accepted TLS 1.0 and RC4 suites, and pointing at an IP that was no longer under Nimbus's control: a candidate for subdomain takeover (05-04).

Fix: delete the DNS record — do not patch a host that has to disappear, as we already concluded in 05-01 — and add a quarterly review of the DNS zone to the inventory.

A queue administration panel, deployed "temporarily" eight months ago, answered at /flower with admin/admin and with no authentication on the proxy. From there you could see the identifiers and e-mail addresses of the jobs in flight.

Access now goes through an SSH tunnel via the bastion host. This finding is the most instructive of the five: it is not a software vulnerability, it has no CVE, no scanner from 05-01 would have flagged it as critical and it had been exposed for eight months. It is the same pattern as the python -m http.server: the temporary thing that stays.

The report is the product. An auditor who delivers a tool dump with 80 unprioritised pages of output has not done the job, and that is the most reliable signal not to use that supplier again.

The elements that make it actionable are the same as in 05-01, with two additions specific to a pentest: step-by-step reproduction — without it the developer cannot confirm the fix — and the retest verification criterion, which sets out in advance what will count as fixed.

The classic mistake is filing the report away. The correct cycle is short and has owners:

1. Handover meeting with the auditor, Marta, Lucía and Iván. Each finding is discussed until the team understands it; a report that is e-mailed over and never explained loses half its value.
2. A remediation plan with an owner and a date, using the deadline policy from 05-01: criticals in 7 days, highs in 30. Each finding becomes an issue with an acceptance criterion.
3. Update of the risk register from 04-01. The residual IDOR is not a loose finding: it modifies risk R-04 (data leakage between customers), whose residual was calculated assuming control C-05 was implemented. It was half implemented, which is 04-03's lesson about implemented versus effective.
4. Retest, included in the original contract and not as a separate service. It is a short exercise — usually one or two days — that only checks the findings that were fixed and produces an annex with the final status. Without a retest, the pentest measures the past.
5. Structural lessons. If two IDORs turned up, the problem is not two lines: it is that authorisation is decided in each route. The structural fix — the common dependency — prevents the third one.

An annual pentest is a snapshot; external researchers are looking all year round. For an SME there are three steps, and the first is free and mandatory:

A management warning: a bug bounty without the capacity to respond is worse than not having one. If 40 reports arrive and nobody triages them within 48 hours, the community publishes it and the reputation (A-20) suffers more than it would from the original flaw. The ethics of disclosure, reasonable deadlines and the conflict between researcher and company are developed in 06-06.

What to ask for in the request for quotation, and it is five concrete things: a declared methodology (PTES or WSTG), the profile and named certifications of whoever will run it (not of the company), the actual person-days dedicated — the variable that determines quality — a retest included, and an anonymised sample report, which is the best predictor of what you will receive.

Indicative price in Spain for an SME: 4,000-8,000 € for a web application with an API, grey-box, 5 person-days with a report and a retest; 8,000-15,000 € if cloud infrastructure and a mobile application are added. A reasonable cadence: annual, plus an additional test when there are major architectural changes (a new module with sensitive data, a change of identity provider, an infrastructure migration). With 18,000 €/year, Nimbus can afford an annual application pentest if it accepts that this is the largest single outlay in the budget, and the decision is defensible: A-04 is the product.

Three warning signs when comparing offers: a fixed price without knowing the scope, an "automated pentest" (that is a scan under another name and another price), and a refusal to hand over a sample report.

Practising exploitation is necessary in order to understand the defence, and there is only one place to do it: environments designed for it.

The rule, with no nuance: if the system is not yours and you have no written authorisation, it is not a lab. Your former employer's website is not one, nor is a supplier's that "will surely be grateful", nor a relative's. The labs in the table exist precisely so that there is never an excuse. And in a professional setting, that practice is also done on an isolated network, with snapshots and with no connection to the corporate network.

• Commissioning a pentest without written authorisation or rules of engagement. It exposes both parties legally and leaves no framework for what happens if something goes down.
• Choosing black-box for "realism". In a multi-tenant SaaS you pay for reconnaissance instead of depth, and the main risk — leakage between customers — goes untested.
• Testing against production unnecessarily. If preproduction is equivalent, you test there; and if it is not, fixing that difference is more urgent than the pentest.
• Not excluding third parties. You cannot authorise testing against the payment gateway or the consultancy: they are not yours.
• Contracting without a retest. Without verification, the report describes a system that no longer exists and nobody knows whether it was fixed.
• Treating findings as loose issues. Two IDORs are not two bugs: they are a design pattern in the authorisation.
• Tip: hand the auditor the results from 05-01. If you have already fixed what a scanner finds, their five days go on what no tool sees. It is the most direct way to multiply the value of what you are paying for.
• Tip: publish your security.txt today. It costs half an hour, it is free and it determines whether the next flaw somebody finds reaches your inbox or somewhere else.
• Tip: warn your own on-call rota. With the detections from 05-02 live, a pentest will generate alerts. Them firing and being handled is, in fact, a free proof that detection works: record it as a verification.

A supplier sends this scope summary. Identify at least six problems and rewrite the affected clauses.

In September Nimbus launches a teleconsultation module with video and clinical notes. Marta has 9,000 € for offensive security this year and asks what to commission.

1. Pentest, red team, audit or bug bounty? Justify it.
2. The specific mode and scope, including which accounts and what is excluded.
3. How to allocate the 9,000 € and what is done with whatever is left.

During the test, the auditor discovers that the password recovery flow answers "E-mail address not registered" when the address does not exist and "We have sent you a link" when it does, allowing an attacker to enumerate which e-mail addresses are customers of each clinic. In a SaaS used by physiotherapy clinics, knowing that an address is a customer is already sensitive information.

1. Write up the finding record in the format from §7, assigning a severity with judgement.
2. Write the fix in python, explaining why it works.
3. State how it would be verified in the retest and which detection from 05-02 would cover it.

Exercise 1

Exercise 2

(1) A pentest, without a doubt. A red team is ruled out because it measures detection and response, and the detections from 05-02 are months old, not years: it would measure a predictable failure at a very high price. A compliance audit answers a different question and will be dealt with in 06-04. A bug bounty demands a response capability Nimbus does not yet have. And the timing is right: a module with video and clinical notes is health data, it is a new surface and it is exactly when testing is worthwhile, before the launch and not after.

(2) Mode and scope. Grey-box, with two accounts from different clinics, a patient account and a support account, plus the documentation for the API and the video flow. Scope: the complete teleconsultation module (room creation, room access control, clinical notes, attachments and their field-level encryption from 03-07) plus the API endpoints it touches, in preproduction. Excluded: production, the video provider, the payment gateway, transactional e-mail and all social engineering. OWASP WSTG and API Top 10 coverage is requested (05-05), with two explicit questions for the auditor: can a patient get into somebody else's room? and can one clinic see another's notes?

(3) Allocation. ~6,500 € on 5 person-days of grey-box testing with a report and a retest included; ~1,000 € held back for a short second round if criticals appear that require a redesign; and ~1,500 € unspent until after the report. Whatever is left is not spent on more offensive work: it is spent on fixing. The industry's most expensive mistake is consuming the budget on finding and having nothing left to fix with. On top of that, free: publish the security.txt and run 05-01 against the module before the auditor arrives, so that their days go on the business logic.

Exercise 3

(1) Record:

The severity of Medium and not Low is the important judgement: the base CVSS treats it as a minor information leak, but the environmental group from 05-01 raises it because of the business context. That is precisely what a scanner cannot calculate.

(2) Fix:

It works because it removes all three channels through which the difference leaks: the message, the status code and the timing. The third is the one people forget: without the timing levelling, sending a real e-mail takes 300 ms longer and the attacker measures that difference precisely. The same reasoning applies to account registration and to changing an e-mail address, which are the other two places where this flaw reappears.

(3) Verification and detection. In the retest, 200 requests are sent alternating valid and invalid addresses and the body, the code and the distribution of times are compared: if the mean latency of the valid ones differs consistently, the finding is still open. The detection that covers it is a variant of D-01: more than 20 requests to /auth/recuperar from one IP in 5 minutes, or more than 100 distinct addresses tried in an hour, with severity S3 and automatic blocking through fail2ban — one of the actions 05-02 classified as safe to automate because they are reversible.

You now know what a pentest is and is not: an authorised test that demonstrates impact by chaining weaknesses, distinct from a scan (known surface), an audit (conformity) and a red team (detection capability), with its duration, its indicative cost and the criterion for choosing each one — and with the conclusion that for Nimbus today a red team would be throwing money away. You know that a pentest does not prove that a system is secure, and that a report with no findings almost always means a narrow scope or a short time. You know the three modes and why grey-box gives the most value per euro in a multi-tenant SaaS: the main risk is not a stranger getting in, but a legitimate customer seeing another's data, and that can only be tested from inside with two accounts.

You take away the template for a scope agreement and rules of engagement with its critical clauses: excluded assets — you cannot authorise testing against third parties — the cloud provider's authorisation, the window and the intensity, the prohibition on downloading real data, the stop condition for a pre-existing compromise, a 24/7 emergency contact and real-time notice of critical findings. You know the methodological phases of PTES/OSSTMM/WSTG and what happens in each, always with its defensive equivalent: enumerate your own subdomains, run testssl.sh, fix what a scanner sees before the auditor arrives and measure your segmentation yourself. And you know what saves money: what is genuinely valuable in a SaaS is manual and about business logic.

You have walked through a real authorised test against preproduction with its five findings and their fixes: the residual IDOR in reports, resolved by making tenant_id stop being an input parameter across the whole API; the missing rate limit, with limit_req in Nginx and per-account lockout for password spraying; the missing CSP, deployed in Report-Only first; the forgotten subdomain with obsolete TLS, which is deleted rather than patched; and the default credential on the queue panel, the most instructive finding because it has no CVE, no scanner would have prioritised it and it is the same pattern as the http.server: the temporary thing that stays. You know what the report must contain, how a finding is written up with step-by-step reproduction and a retest criterion, and why delivering a tool dump is the signal to change supplier. You know what happens afterwards: handover meeting, a plan with owners and deadlines, updating risk R-04 in the register from 04-01, a retest included in the contract and a structural fix instead of a one-off patch. And you know how to frame responsible disclosure — publish your security.txt today, it costs half an hour — and the bug bounty as a later step that should not be opened without a response capability, with the complete ethical and legal treatment waiting for you in 06-06. Finally, you know how to commission one: what to ask for, what OSCP and CREST attest, how much it costs, how often to do it and in which labs — Juice Shop, DVWA, TryHackMe, HackTheBox — exploitation is practised, which are the only place to practise it.

Notice how many of the five findings were, at bottom, network and exposure problems: a panel published on the host's external interface, a subdomain pointing at somebody else's IP, a service reachable from where it should not be. And remember what has been outstanding since 05-01: PostgreSQL listening on 0.0.0.0:5432, SSH open to the whole Internet and the consultancy with permanent access. In Network Security (05-04) we draw Nimbus's network as it stands, redesign it into zones, close those three holes with security groups and a bastion host, set up remote access with WireGuard, fix the guest wifi and the DNS, and — most importantly — check with connectivity tests that the segmentation really works, because an untested design is just a pretty drawing.