The fastest way to lose a day during reconnaissance is to collect everything before deciding what matters. A small scan gives us a hypothesis, a boundary, and a next action.
Start with an inventory
Before opening a terminal, write down what is known:
| Question | Example answer |
|---|---|
| What is in scope? | portal.example.test |
| What is the goal? | Find unexpected public services |
| What is the time limit? | 30 minutes |
| What is out of scope? | Brute force and destructive checks |
This simple table prevents a common failure mode: mistaking activity for progress.
A three-pass workflow
Pass one: identify
Look for the smallest set of facts that can change your next decision:
- DNS names and ownership;
- exposed ports and service banners;
- robots files and obvious application paths;
- certificate names and expiration dates.
Pass two: compare
Compare the result with the expected architecture. A development hostname on a production certificate is not automatically a vulnerability, but it is a useful lead.
Pass three: document
Capture commands, timestamps, and assumptions:
scan --target portal.example.test --ports 80,443 --output notes.txtThe exact command is less important than making the result reproducible.
A scan is valuable when it reduces uncertainty, not when it produces the most lines of output.
What to keep
Keep findings that answer one of these questions:
- Does this expand the known attack surface?
- Does this contradict the expected deployment?
- Does this suggest a safe next test?
Everything else can wait in a scratch file.