Pentest Methodology & Recon · beginner · ~12 min
**What you will learn** - Explain why signed authorization is the single thing that separates a penetration tester from a criminal, and identify what a valid authorization contains. - Read a **scope** definition and decide correctly whether a given host, URL, or account is in bounds or out of bounds. - Interpret **Rules of Engagement (RoE)**: allowed techniques, forbidden techniques, testing windows, data-handling rules, and points of contact. - Recognise **stop conditions** and know exactly what to do when you find something outside scope or trigger one. - Build a reusable **pre-engagement authorization checklist** you can apply before any lab or authorized test. - Set up a **local, isolated lab** so you can practise technique without ever needing real-world authorization.
Security objective. The asset this lesson protects is everyone's legal and physical safety during a test — the client's production systems, uninvolved third parties, and you. The threat is unauthorized or out-of-scope testing, which can break systems, expose data, and turn skilled work into a crime. What you will learn to detect and prevent is scope creep (touching something you were never authorized to touch) and RoE violations (using a forbidden technique or testing outside the agreed window).
This is the first lesson on the Pentest Methodology track, so it has no prerequisites — it is the prerequisite for everything else. Every recon, scanning, and exploitation technique you learn later is worthless, and illegal, without the paperwork this lesson describes. Later lessons such as The phases of an engagement (methodology-phases) assume you already have a signed authorization and a defined scope in hand before phase one begins.
In plain terms: a penetration test is authorized simulated attack. Remove the word "authorized" and you are left with "attack." The authorization document, the scope, and the rules of engagement are the contract that makes the whole activity legitimate. In this lesson you will learn to read and reason about those documents, and to set up a private lab where the question of authorization never even arises because you own everything in it.
In real, authorized work, the pre-engagement paperwork is not bureaucracy you rush through — it is the thing that keeps you employed and out of court.
A memorable framing: the authorization letter is sometimes called the "get out of jail" letter. If you cannot produce it on demand, you should not be testing.
Each concept below is taught on its own: what it is, how it works, when it applies, and a pitfall to avoid.
Definition. A signed document from someone who owns or legally controls the target systems, granting you explicit permission to test named assets during a named period.
How it works. It names the tester (you or your company), the client, the specific assets, the time window, and the signatory's authority to grant access. It is signed by both sides before any packet is sent.
When / when not. Required for every engagement, always, before any activity — including passive recon that touches the target. Not needed for a lab you fully own (you are the owner).
Pitfall. Verbal permission, a Slack message, or "the manager said it was fine" is not authorization. The signatory must actually have authority to grant it — a random employee cannot authorize testing of systems they do not control.
Definition. The exact list of assets that are in bounds: IP ranges, domains, URLs, applications, and accounts. Everything not listed is out of scope and off-limits.
How it works. Scope is usually written as an allow-list. If an asset is not explicitly listed, treat it as forbidden — even if it is owned by the same client and even if it is trivially reachable.
When / when not. In scope: test it, within the RoE. Out of scope or ambiguous: do not touch it; note it and ask.
Pitfall. Reachable does not mean in scope. A vulnerable server you can see from an in-scope host is still off-limits until someone with authority adds it in writing.
Definition. The document that says how you may test: permitted techniques, forbidden techniques, data-handling rules, testing hours, and contacts.
How it works. Typical clauses: no denial-of-service; no social engineering unless explicitly agreed; no changes to production data; how to store and encrypt any data you collect; who your point of contact is; and how to report a critical finding immediately rather than waiting for the final report.
When / when not. The RoE governs every action. If a technique is not clearly permitted and could cause harm, treat it as forbidden until confirmed.
Pitfall. Assuming "it's a pentest, so anything goes." A forbidden technique used "just to confirm" a finding is still a violation.
Definition. The start and end dates plus allowed hours for testing.
How it works. Some tests must run off-peak to avoid disrupting real users; others are limited to business hours so staff can respond. Testing before the window opens or after it closes is unauthorized testing.
Pitfall. Leaving a long-running scan going past the end of the window. When the window closes, you stop.
Definition. Predefined triggers that require you to halt immediately and contact the client — for example, evidence of a prior real breach, accidental impact on a production service, or discovery of highly sensitive data.
How it works. You stop, preserve evidence, and call the emergency contact rather than pressing on.
Pitfall. "I'll just finish this one thing first." Stop means stop.
Definition. The professional habit of continuously checking every action against the scope and RoE before you take it.
Pitfall. Momentum. Deep in an engagement it is easy to follow a thread out of bounds. Discipline is what keeps you in bounds under pressure.
THREAT MODEL: an authorized penetration test
ASSET PROTECTED: legal safety + system integrity of client,
third parties, and the tester
+-----------------------------------------------------------+
| AUTHORIZED SCOPE (allow-list) |
| [ app.example-lab.internal ] [ 10.0.5.0/24 ] |
| [ test accounts: pentest01 ] |
| |
| Tester acts here, within RoE, within time window |
+-----------------------------------------------------------+
^ |
| signed authorization | forbidden to cross
| (entry point / trust boundary) v
=========================================================== <-- TRUST
OUT OF SCOPE (everything else, even if reachable): BOUNDARY
- other client servers not listed
- shared-hosting neighbours / upstream providers
- real user data, production DBs
- any third-party system
Crossing the boundary = scope creep = ethical + legal breach
Knowledge check.
This is a methodology lesson, so the "syntax" is the structure of the paperwork and a couple of safe shell commands for standing up an isolated lab. Nothing here touches a remote system.
The shape of a pre-engagement package:
1. Authorization letter -> WHO may test WHAT, WHEN, signed by an owner
2. Scope (allow-list) -> exact IPs / domains / apps / accounts in bounds
3. Rules of Engagement -> allowed vs forbidden techniques, data handling
4. Time window -> start/end dates + permitted hours
5. Contacts + stop rules -> who to call, when to halt immediately
A lab-safe way to confirm you are working only against yourself (loopback), annotated:
# Show your loopback interface — 127.0.0.1 is YOUR machine, nobody else's.
ip addr show lo # Linux; on macOS use: ifconfig lo0
# A local-only web server for practice, bound to loopback so it is
# NOT reachable from the network. The 127.0.0.1: prefix is the key part.
python3 -m http.server 8000 --bind 127.0.0.1
The important detail is --bind 127.0.0.1: it keeps the practice server on your own machine, so there is no third party to authorize and nothing to leak onto a network.
The one thing that separates a penetration tester from a criminal is written authorization.
Every technique in this course is worthless — and illegal — without it.
Suppose an interesting server appears that is not in scope.
You do not touch it. You note it and ask.
"It was reachable" is never a defence. Scope creep crosses both an ethical and a legal line.
Testing an unauthorized system is a crime in essentially every jurisdiction, no matter how skilled the work.
The labs in this course are local toys and loopback fixtures by design. That lets you practise technique without ever needing — or risking — real-world authorization.
Because there is no exploit to write here, the "code" is a decision procedure plus a lab setup. It follows the same insecure -> secure -> verify shape: an unsafe way to decide whether to test, a disciplined replacement, and checks that prove the disciplined rule rejects bad actions and accepts good ones.
This is an example of insecure reasoning — the mental shortcut that gets testers in trouble. It is written as pseudo-code to make the flaw obvious.
# INSECURE DECISION LOGIC (do NOT follow)
function should_i_test(target):
if i_can_reach(target): # <-- the fatal flaw
return "go ahead"
else:
return "skip"
The insecure assumption is reachable == authorized. Reachability is a network fact; authorization is a legal one. They are unrelated.
# secure_decision.py -- a lab helper that encodes scope discipline.
# It decides whether an action is permitted. It does NOT attack anything.
SCOPE = {
"app.example-lab.internal", # in-bounds host (a placeholder lab name)
"10.0.5.0/24", # in-bounds network (placeholder)
}
ALLOWED_TECHNIQUES = {"port-scan", "web-crawl", "auth-test"}
FORBIDDEN_TECHNIQUES = {"denial-of-service", "social-engineering"}
def is_in_scope(target: str) -> bool:
# Allow-list logic: unknown target -> NOT in scope.
return target in SCOPE
def decide(target: str, technique: str, have_signed_auth: bool):
if not have_signed_auth:
return "HALT: no signed authorization on file"
if not is_in_scope(target):
return f"HALT: {target} is OUT OF SCOPE - note it and ask the client"
if technique in FORBIDDEN_TECHNIQUES:
return f"HALT: {technique} is forbidden by the RoE"
if technique not in ALLOWED_TECHNIQUES:
return f"HALT: {technique} not explicitly allowed - confirm first"
return "PROCEED: authorized, in scope, technique allowed"
if __name__ == "__main__":
print(decide("app.example-lab.internal", "port-scan", True))
print(decide("unknown.example.com", "port-scan", True))
print(decide("app.example-lab.internal", "denial-of-service", True))
print(decide("app.example-lab.internal", "port-scan", False))
Expected output when you run python3 secure_decision.py:
PROCEED: authorized, in scope, technique allowed
HALT: unknown.example.com is OUT OF SCOPE - note it and ask the client
HALT: denial-of-service is forbidden by the RoE
HALT: no signed authorization on file
The first line shows a good action (in scope, allowed technique, authorization present) is accepted. The next three show bad actions — out-of-scope target, forbidden technique, missing authorization — are each rejected with a clear reason. That is exactly the behaviour scope discipline should produce.
This file only prints decisions; it never connects to anything. You can run it safely on any machine you own.
A walkthrough of secure_decision.py.
SCOPE = {...} — the allow-list. Only these exact entries are in bounds. Anything else is out of scope by default, which is the safe default.ALLOWED_TECHNIQUES / FORBIDDEN_TECHNIQUES — the RoE encoded as two sets. Note that a technique in neither set is still treated as not-allowed by the final check, so silence means "confirm first," not "go ahead."is_in_scope(target) — returns True only for an exact match in SCOPE. Using an allow-list (not a block-list) means a target you forgot to consider is refused rather than permitted.decide(...) — runs the checks in priority order:Trace of the four calls in __main__:
| target | technique | auth? | which check trips | result |
|---|---|---|---|---|
| app.example-lab.internal | port-scan | yes | none | PROCEED |
| unknown.example.com | port-scan | yes | scope (step 2) | HALT out of scope |
| app.example-lab.internal | denial-of-service | yes | forbidden (step 3) | HALT forbidden |
| app.example-lab.internal | port-scan | no | auth (step 1) | HALT no auth |
The key lesson is the order: authorization is checked before anything else, because without it nothing downstream matters.
Real mistakes, each shown as WRONG -> WHY -> CORRECTED -> how to recognise/prevent.
1. Treating reachable as authorized.
2. Accepting verbal or informal permission.
3. Using a forbidden technique "just to confirm."
4. Testing outside the time window.
5. Assuming an automated scanner or a decoded token proves security.
"Debugging" a rules-of-engagement problem means catching a scope or authorization error before it becomes an incident.
Common problems and how to work through them.
Questions to ask when something feels wrong.
If you cannot answer 1–3 with a confident yes, the correct move is to pause and confirm, not to proceed.
Security & safety: detection and logging for engagement conduct.
On an authorized engagement you keep an activity log so that both you and the client can reconstruct exactly what you did. This protects you if a system fails for unrelated reasons, and it is the raw material for the final report.
What to log for every testing action:
What to NEVER store in your notes or logs:
Which events signal abuse or trouble (yours or someone else's):
How false positives arise. The client's own monitoring will often flag your authorized scans as attacks — that is expected. To avoid a fire drill, the RoE should include a de-confliction step: your source IPs and testing window are shared with the client's SOC in advance, so they can distinguish your authorized traffic from a genuine attacker. A benign scan flagged by an IDS is a false positive; the fix is coordination, not stopping.
A concrete authorized use case. A retailer hires a security firm to test a single web application before launch. Before any traffic is sent, the firm and the retailer sign an authorization letter, agree a scope of exactly two hostnames and one test-account, and set an RoE that forbids denial-of-service and any access to real customer records, with testing limited to weeknights 20:00–02:00. The firm shares its source IPs with the retailer's monitoring team so scans are not mistaken for a real attack. The tester keeps a timestamped activity log, reports one critical finding immediately per the RoE, and delivers a full report at the end of the window. Every action is justifiable from the paperwork.
Professional best-practice habits.
Beginner vs advanced.
| Beginner | Advanced | |
|---|---|---|
| Scope | Practise only on labs you own | Negotiate and clarify scope with a client, handle multi-party de-confliction |
| Authorization | Understand what a signed letter contains | Review and flag gaps in third-party / cloud-provider authorization requirements |
| RoE | Follow a given RoE strictly | Help draft RoE, define stop conditions and reporting SLAs |
| Logging | Keep a simple timestamped log | Maintain evidence chains suitable for legal review |
All tasks are lab-only and end with a defensive conclusion. Practise on systems you own or explicitly control.
Authorization checklist (use before any lab or test):
Beginner 1 — Read a scope.
app.lab.internal and 10.0.5.0/24, classify five candidate targets as in-scope or out-of-scope.Beginner 2 — Stand up an isolated lab.
python3 -m http.server 8000 --bind 127.0.0.1 and confirm it is reachable only from your own machine.http://127.0.0.1:8000.--bind 127.0.0.1 flag is the whole point.Intermediate 1 — Extend the decision tool.
time window check to secure_decision.py so an action outside allowed hours returns HALT.Intermediate 2 — Design an activity-log line.
127.0.0.1.Challenge — Draft a mini rules-of-engagement.
API_KEY=<development-placeholder>.Main concepts. A penetration test is an authorized simulated attack; remove authorization and it is just an attack. Three documents make the work legitimate: a signed authorization letter (who may test what, when), a scope allow-list (exactly which assets are in bounds), and Rules of Engagement (allowed vs forbidden techniques, data handling, time window, contacts, stop conditions).
Key rules to remember.
Common mistakes. Treating reachability as permission; accepting verbal-only approval; using a forbidden technique "just to confirm"; running scans past the window; and claiming a scanner pass or a decoded JWT proves security (it does not — nothing is ever "completely secure").
Detection and logging. Keep a timestamped, correlated activity log of every action and decision; never log passwords, tokens, keys, full PANs, or unneeded PII; de-conflict your scan traffic with the client's monitoring so authorized tests are not mistaken for real attacks.
What to carry forward. Practise offensive technique only on labs you own (localhost, loopback, containers), where you are the owner and the authorization question never arises. This discipline is the foundation the next lesson, The phases of an engagement, builds on.