The penetration-testing lifecycle: attacking with permission

A penetration test is a simulated attack, carried out with permission, to find weaknesses before real attackers do. NIST defines it as security testing in which evaluators mimic real-world attacks to identify ways to circumvent the security features of an application, system or network. The techniques can look identical to a criminal’s. The difference is everything around them: authorization, scope, rules, and a report written to help the defenders.

Phase 0: authorization and rules of engagement

Before any technical work, the tester and the client agree in writing on the scope (which systems, addresses and applications are in, which are out), the time window, the techniques allowed (is phishing staff allowed? physical entry?), who to call if something breaks, and how sensitive data found during the test will be handled. This document is what makes the test legal and what protects both sides. NIST’s technical guide to security testing (SP 800-115) treats planning and rules of engagement as a formal phase, not a formality.

Phase 1: planning

The team decides what the test is trying to answer. “Can an outsider reach customer data?” leads to a different test from “What can a malicious employee do?” The type of test matters too: black-box (the tester starts with no inside knowledge, like an outside attacker), white-box (full documentation and access, to find as much as possible) or grey-box, somewhere in between.

Phase 2: reconnaissance

Reconnaissance gathers information about the target, first passively (public sources, without touching the target’s systems) and then actively. MITRE ATT&CK lists reconnaissance as the first tactic in an attacker’s playbook, which is exactly why defenders care about it: what a tester can learn here, a criminal can learn too. The next lesson covers open-source intelligence in detail.

Phase 3: scanning and enumeration

The tester maps what is reachable: which hosts respond, which services and versions they run, and which of those have known vulnerabilities. Vulnerability databases and severity scores such as CVSS help decide what is worth attention. Scanning is noisy by nature, which is why a good SOC should notice it; if the client’s monitoring does not see the test, that is itself a finding.

Phase 4: exploitation

Exploitation means actually using a weakness to gain access, within the agreed limits, to prove that the risk is real rather than theoretical. Professionals choose the least disruptive way to demonstrate impact, stop when they reach the agreed objective, and never keep data they do not need. Post-exploitation (what an attacker would do next, such as escalating privileges) is covered in the last lesson of this course.

Phase 5: reporting

The report is the real product. A useful one has two parts: an executive summary that explains business risk in plain language, and a technical section with each finding, its severity, evidence, and clear steps to fix it. The best reports also note what worked well and what the defenders detected, because a test that only lists failures misses half the lesson. A retest after fixes confirms the gaps are really closed.

Penetration test, red team, bug bounty

All four are legitimate only inside a clear agreement. That shared foundation, permission first, is what the security profession is built on.