Penetration Testing

Ethical Hacking and Security Assessments#

Penetration testing is the practice of simulating a real attack against a system you are authorised to test, so that exploitable weaknesses are found and fixed before a genuine attacker finds them. It is deliberately more than an automated scan: a scanner reports isolated findings, while a pentester thinks like an adversary, chains minor issues into a serious one, and demonstrates real business impact.

Authorization Comes First#

Everything in this lesson is legal only inside explicit, written permission. A professional engagement starts with paperwork, not tools:

• Scope: the exact hostnames, IP ranges, applications and accounts that are in scope, and everything that is out of scope.
• Rules of engagement: which techniques are allowed (no denial-of-service unless approved, no touching other tenants' data, no social engineering unless contracted), the testing window, and rate limits.
• Emergency contacts and a "stop" procedure if something breaks or real user data is exposed.
• Handling of any data discovered during the test.

Without that authorization, probing a system you do not own is a crime in most jurisdictions regardless of intent. To practise on your own, use deliberately vulnerable targets whose owners authorise attacks: OWASP Juice Shop, DVWA, PortSwigger's Web Security Academy, HackTheBox, and TryHackMe. Never point these techniques at a live third-party site.

The Phases of an Engagement#

1. Reconnaissance. Map the attack surface, ideally without touching the target much. Enumerate subdomains, find exposed services and APIs, gather open-source intelligence (OSINT) from public sources, and fingerprint the technology stack. The more you learn here, the more targeted everything after is.

2. Scanning and enumeration. Now actively probe. Discover open ports and running services, identify versions, and look for hidden paths (admin panels, backups, .git directories). This is where a scanner earns its keep, turning a list of hosts into a list of concrete things to test.

# Discover open ports and service versions on a host you own/are authorised to test
nmap -sV -sC -p- 10.10.10.5

# Enumerate hidden paths against your own lab app
ffuf -u https://lab.local/FUZZ -w wordlist.txt -mc 200,301,403

-sV fingerprints service versions, -sC runs default safe scripts, and -p- covers all 65535 ports. ffuf (or gobuster) brute-forces paths from a wordlist and shows which return interesting status codes.

3. Exploitation. Turn a weakness into proven access: bypass authentication, exploit an injection to read data, abuse a file upload, or use a known CVE in an outdated component. The goal is not to cause damage but to demonstrate that access is possible, captured as evidence.

4. Post-exploitation and privilege escalation. A first foothold is usually a low-privilege account. The tester then tries to escalate (to admin or root), move laterally to other systems, and assess how far a real attacker could reach. On an authorised engagement, persistence mechanisms are documented, and removed at the end.

5. Reporting. The deliverable. Every finding is written up so a developer can reproduce and fix it, and so a manager can prioritise it (see below). The exploit is the raw material; the report is the product.

Methodologies and Standards#

You do not have to invent the process each time. Established methodologies give a repeatable structure and make coverage defensible:

• PTES (Penetration Testing Execution Standard): the seven phases from pre-engagement interactions through reporting, roughly the arc described above.
• OWASP Web Security Testing Guide (WSTG): a detailed checklist of what to test in a web app (authentication, session management, input handling, business logic, and more). It is the closest thing to a canonical "did I check everything" list for web engagements.
• OWASP Testing for the API and Mobile guides extend the same idea to those surfaces.
• MITRE ATT&CK: a catalogue of real adversary tactics and techniques, useful for red teams to plan realistic scenarios and for defenders to map coverage.

Following a named standard also helps the client trust the result: "tested against WSTG" communicates scope far better than a bare list of tools that happened to be run.

The Toolchain#

Most of these ship in Kali Linux or Parrot OS:

Tools accelerate the grunt work; they do not replace judgement. The findings that matter most (authorization gaps, business logic flaws, chained exploits) are the ones no scanner recognises, because they require understanding what the application is for.

Black, White, and Grey Box#

• Black box: no prior knowledge, simulating an external attacker. Realistic, but time is spent on discovery that a real adversary might also spend.
• White box: full source code, architecture and credentials. The most thorough and efficient for finding deep logic flaws, because nothing is hidden.
• Grey box: the middle ground, typically standard user credentials, ideal for testing what an authenticated user can abuse.

Related but distinct: a vulnerability scan is automated and broad; a penetration test is manual and deep; a red team engagement is a goal-oriented, stealthy, multi-vector simulation of a real threat actor over weeks, testing detection and response as much as the systems.

What Makes a Finding Useful#

A finding nobody can reproduce or prioritise is wasted work. Each report entry should contain:

• The affected asset and exactly where the issue is (URL, parameter, request).
• Reproduction steps, usually including the raw request and response, so a developer can see it themselves.
• A severity rating, commonly a CVSS score or a High/Medium/Low band, so triage is consistent.
• Business impact in plain language: "an unauthenticated attacker can read every customer's personal data" lands very differently from "IDOR on /api/users."
• A concrete remediation, ideally the specific code or configuration change.

The skill that separates a good pentester is translating "this endpoint reflects input" into "here is the exposure and here is the fix," which is why testers keep meticulous notes and screenshots throughout.

A useful habit is to write findings in a fixed template so nothing is forgotten and severity is applied consistently:

Title:       IDOR on GET /api/orders/{id} exposes other users' orders
Severity:    High (CVSS 7.5)
Asset:       https://app.example/api/orders/1942
Steps:       1. Log in as user A. 2. Note own order id. 3. Change the id in
             the request to 1942 (user B's). 4. Full order returned, 200 OK.
Impact:      Any authenticated user can read every order, including PII and
             partial payment data, by incrementing the id.
Fix:         Scope the query to the authenticated user; return 404 on a
             non-owned id. Add an authorization test across roles in CI.

The value of a template is not bureaucracy; it forces the tester to state impact and remediation for every issue, which is exactly what a busy engineering team needs to act.

Testing Is Continuous, Not Annual#

A pentest is a snapshot; the code changes the next day. Mature teams shift left and bake security testing into the development pipeline:

• SAST (static analysis) scans source for risky patterns on every commit.
• DAST exercises the running app for issues that only appear at runtime.
• Dependency and container scanning flags components with known CVEs (supply chain security).
• Secret scanning catches credentials committed to the repository.

Scheduled manual pentests (before major releases, and periodically) then focus human effort on the logic and authorization flaws automation cannot see. Feed every confirmed finding back into a tracker, fix it, and add a regression test so it cannot silently return. Pair the offensive view here with defensive lessons on firewalls and incident response to see both halves of the picture.