Advanced Penetration Testing
Practice evidence-led reconnaissance, attack-path thinking, and clear reporting through a compact investigation.
Start here
Course introduction
This is not an exploit memorization course. It is a short investigation about how experienced testers control risk, build a hypothesis from evidence, and communicate what they can actually prove.
Each exercise uses mock evidence created for this page. Nothing here touches an external target.
By the end of this course, you can
- Define a safe testing scope and choose the smallest useful proof.
- Separate observed evidence from assumptions during reconnaissance.
- Trace privilege boundaries across requests, workers, and data stores.
- Retest a fix and write a finding another reviewer can reproduce.
Learn, then practice
Course lessons
Work through these 5 lessons in order. Each lesson introduces one concept, then gives you a practical activity or lab to apply it.
Scope comes before tools
Not startedA professional test begins by defining what may be touched, when it may be tested, and what must remain available.
A clever technique used outside scope is still a failed test. Write down the allowed hosts, accounts, test window, and stop conditions before collecting evidence.
Good scope also tells you what success looks like. A read-only proof may be enough to demonstrate impact. There is rarely a reason to collect real user data or leave persistence behind.
In scope: staging.example.test
Allowed: authenticated web testing
Stop if: service errors rise or real customer data appears
Proof: minimum evidence needed to reproduce the issue
A stop condition is useful only when it is written before the test begins.
Course challenge
Choose the safe proof
You can show that an account can read another user's invoice. Which proof stays inside the rules of engagement?
Reconnaissance builds a hypothesis
Not startedUseful reconnaissance connects small observations instead of collecting every possible hostname and header.
Start with passive signals: page source, response headers, script names, public documentation, and certificate names. Each observation should lead to a question you can test safely.
A staging label, for example, is not automatically a vulnerability. It is a clue that may explain a different authentication flow, an older build, or a forgotten host.
Before moving on, separate what you observed from what you inferred. Reports become unreliable when those two are mixed together.
Course challenge
Follow the quiet signal
Start the investigation, open the browser console, and find the mock environment named in the course clue. Enter only the environment name.
Report the chain, not the drama
Not startedA strong finding explains the path from attacker-controlled input to measurable impact.
Record the precondition, exact action, observed result, and smallest safe reproduction. Then explain the broken trust boundary and give a fix that addresses the cause.
Severity should follow evidence. If a finding needs an administrator account and affects only that same account, say so. Clear limitations make the confirmed impact more credible.
Preconditions → Request → Missing control → Observed result → Impact
Screenshots support a finding, but they do not replace reproducible steps.
Course challenge
Name the missing control
Read the mock exchange. Enter the control the server failed to enforce.
GET /api/invoices/1842
Cookie: session=user-27
HTTP/1.1 200 OK
{ "owner": "user-91", "total": 240 }
Trace the privilege boundary
Not startedThe useful question is not only what an account can do, but what stronger component it can cause to act.
Modern applications hand work to queues, functions, and background workers. A low-privilege request may become high-impact when the next component runs with broader access.
Draw the path one hop at a time. Record the caller, the action it controls, the component that receives it, and the identity used at the final resource.
Course challenge
Find the stronger identity
Follow the mock path and enter the identity that finally reads the customer export.
support-user
└─ starts: report-preview
└─ runs as: export-worker
└─ reads: customer-export
Retest the boundary
Not startedA closed ticket is not evidence that the vulnerable path is gone.
Keep the original request and expected safe result. After the fix, repeat that same request with the same low-privilege account and confirm that access is denied.
Then test a nearby allowed case. A fix that blocks every invoice request may hide the vulnerability by breaking the feature instead of repairing authorization.
Course challenge
Build a useful retest
Put the retest actions in an order that proves the boundary was fixed without hiding a regression.
Select the steps in the order they should happen.
Continue learning
Up next: Cloud Security Essentials
Trace identity, public exposure, and audit evidence through an approachable cloud incident scenario.