Map the exposed attack surface. Identify in-scope assets, reachable services, and application entry points before selecting a test.
The house & safe / Chapter 01
Inspect the house from outside
Check the doors, windows, and ventilation openings. Which entry points exist, and which answer when checked?
Technical meaning: Map approved hosts, ports, services, and application entry points. An open port is an available service, not automatically a vulnerability.
Confirm domains, addresses, exclusions, and test windows.
Separate passive discovery from active probing.
Record service versions as leads; a banner alone does not prove a vulnerability.
Phase deliverable
An asset inventory with ports, services, URLs, and candidate weaknesses.
Document what you observed, the assumptions you tested, and what remains unverified.
Field method / Expanded guide
Work through the phase.
Port scanning: checking the openings
Open: an opening answers and a service is listening. Closed: the host responds, but no service is listening at that port. Filtered: a barrier or missing response prevents Nmap from deciding whether the port is open. Think of a guarded or obscured opening—not a confirmed locked door.
A service scan then asks what is behind the opening. A vulnerability test asks whether that particular entry can be misused. Those are three different questions.
This guide uses a five-phase teaching model. PTES separates additional stages, and NIST uses a different lifecycle. The topics below adapt those ideas to the workflow here; they are not a claim that every framework uses these five names.
1. Reconcile assets with the authorized scope
HOUSE LENS The property boundary defines what the homeowner has authorized you to inspect. A neighboring house is not included because it looks similar.
Discovery creates candidates; authorization determines which can be tested.
Begin with the engagement’s actual asset list. Resolve ambiguous ownership before scanning a newly discovered name. A DNS alias or a shared IP can lead to third-party infrastructure; it is not enough to recognize the customer’s brand.
Keep hostname, address, owner, discovery source, last-seen time, and scope status together.
Deduplicate by the service you are testing, while preserving different virtual hosts and application routes.
Flag unreachable and untested assets explicitly so the report does not imply full coverage.
2. Separate passive research from active discovery
HOUSE LENS Old house plans suggest where a doorway might be; an approved check establishes what exists now.
Archived information suggests targets; current observations verify them.
Public documentation, published repositories, and certificate records can suggest services and naming patterns. Treat old records as leads. Active discovery then checks the approved target directly; even ordinary HTTP and DNS requests can be observable.
Do not label DNS querying or browsing the target as fully passive.
Record whether an observation came from a third party or from your own connection.
Choose discovery methods based on the engagement, not on a fixed maximum list of tools.
3. Enumerate services and application entry points
HOUSE LENS Inspect every relevant door, window, and vent. Then learn what lies behind the opening rather than assuming that an open window means access to the safe.
The useful output is a testable hypothesis, not just an open-port list.
Map reachable services, then examine the relevant protocol. For a web application, walk important user journeys and note methods, parameters, role requirements, uploads, API calls, and state changes. Version strings help choose research directions but may be inaccurate or reflect a backported package.
Record both a URL and the action that reaches it; login state often changes the accessible surface.
Distinguish an unexpected response from a security boundary violation.
Avoid inferring the whole host configuration from a reverse proxy’s banner.
4. Prioritize and hand off to validation
HOUSE LENS Choose the entry point whose test would answer the homeowner’s objective, instead of checking every decorative crack.
Prioritize tests that could affect an agreed business objective.
Build a small hypothesis register: affected asset, proposed weakness, prerequisites, intended proof, and the reason it matters. For example, a document API accepting an object ID suggests an authorization test with two accounts; it does not establish an IDOR finding.
Select hypotheses using reachability, privilege required, business function, and likely impact.
Document missing access or test data that prevents meaningful validation.
Recon is ready to hand off when key entry points have owners and actionable test plans.
Tools / Practical reference
Commands, outputs, interpretation.
Use approved targets. These examples show representative behavior; output varies by environment. Angle-bracket values must be replaced. No command here guarantees a finding.
Resolve a candidate hostnameCommand / authorized lab
dig app.example.test A +noall +answer
Expected output / illustrative
app.example.test. 300 IN A 192.0.2.10
Interpretation: Requires the lab DNS configuration. A public resolver usually cannot resolve example.test. A record indicates resolution, not ownership or permission to scan.
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.x
80/tcp open http nginx
443/tcp open https nginx
Files: lab-services.nmap, lab-services.xml, lab-services.gnmap
Interpretation: --version-light reduces version-detection intensity; -oA creates three output formats. This is still active service probing. XML is better for structured processing than scraping terminal text.
Interpretation / Common mistakes
Candidate versus finding
Candidate versus finding
Mistaking a shared hosting IP for a uniquely owned customer server.
Treating an old certificate or DNS record as a currently reachable service.
Assuming one unauthenticated crawl covers every role and application state.
Evidence checklist for this phase
Target and test identity
Timestamp and relevant configuration
Exact command or sanitized request
Observed output and its interpretation
Limitations, changes made, and cleanup status
Sources / Further reading
Read the underlying guidance.
Original guidance consulted for methodology and tool behavior. Commands and outputs on this page are illustrative lab examples, not output captured from these sources.
Check the doors, windows, and ventilation openings. Which entry points exist, and which answer when checked? Map approved hosts, ports, services, and application entry points. An open port is an available service, not automatically a vulnerability.
