Ethical Hacking
Recon Best Practices
Section II is nearly done. Ten lessons of reconnaissance and scanning — DNS, WHOIS, Google dorking, Nmap, service enumeration, vulnerability scanning, banner grabbing. This lesson ties it together into a workflow that holds up under real engagement conditions.
The mistakes that cost engagements
After running a recon phase, most people make one of two errors. Either they rush through it — ticking boxes rather than actually reading what the tools return — or they go so deep into one area that they run out of time for the rest. Both are avoidable. The first is a discipline problem. The second is a planning problem.
A tight recon workflow fixes both. It tells you what to do, in what order, for roughly how long — and when to move on even if a particular area feels like it might have more to give. Knowing when to stop digging in one place and move to the next is one of the less-discussed skills in pen testing, and it is genuinely important.
The recon workflow — phases in order
Every engagement is different but the underlying structure of a professional recon phase stays consistent. This is the order that works — each phase feeds into the next, and skipping one creates gaps that show up later.
Seven phases. The first two are passive and can run before the engagement formally opens. Phases three through seven are active and require an open testing window. If you have a two-week engagement, passive recon should already be complete before day one begins.
Documentation — the habit that separates professionals
Every command you run in a pen test should be logged. The timestamp, the exact command, the output, and a one-line note about what it revealed. This sounds tedious — it is not, once it becomes habit — and it matters for three very concrete reasons.
Reason 1 — You will need it for the report
Three days after running a scan, you will not remember whether a particular finding came from Nmap or OpenVAS or a manual banner grab. The log tells you. Without it, you either guess — which is unprofessional — or you re-run the command, which wastes time you do not have.
Reason 2 — Legal protection
If something goes wrong during an engagement — a service goes down, a client disputes what you tested — your logs are your evidence. Timestamped command history showing exactly what ran, when, and against which IP is the difference between a clean exit and a legal problem.
Reason 3 — Team coordination
On multi-person engagements, your logs let teammates pick up where you left off without duplicating work. A scan that was already run does not need to be run again. A finding that was already validated does not need re-validating. Good documentation multiplies team capacity.
Logging commands automatically during a session
The scenario: You are starting day two of a two-week engagement. Before running a single command, you set up a session log that will automatically capture everything you type — commands, outputs, and timestamps — into a structured file you can reference throughout the engagement and pull from when writing the report.
# Create an organised directory structure for the engagement
# Good folder structure means findings are easy to locate under time pressure
# mkdir -p creates all folders in the path at once, including parent directories
# Replace "clientname" with the actual client or engagement name
mkdir -p ~/engagements/clientname/{recon,scans,exploits,loot,report}
# Navigate into the engagement directory
cd ~/engagements/clientname
# Start a session log using the script command
# script captures everything printed to the terminal — commands and their output
# -t writes a timing file alongside the transcript (useful for replaying the session)
# The log file is named with today's date so multiple day logs do not overwrite each other
# tee -a appends to the log file rather than overwriting if you run this again today
script -t 2>recon/timing-$(date +%Y%m%d).log recon/session-$(date +%Y%m%d).log
# From this point every command and output is captured automatically
# When the session is done, type "exit" to stop the logging
# Also save Nmap output directly to files during scanning
# -oN saves human-readable output -oX saves XML for tool import
nmap -sS -p- -T4 -oN scans/nmap-syn-full.txt -oX scans/nmap-syn-full.xml 192.168.56.101Breaking it down:
Five folders — recon, scans, exploits, loot, report — mirror the phases of a pen test. Every file you create during the engagement goes into the appropriate folder. At report-writing time, everything you need is already organised. This sounds trivial until you are three days from deadline and searching for a specific Nmap output file.
The script command records everything that appears on your terminal into a text file — including commands you type and the output they produce. The date-stamped filename means running it on multiple days creates separate logs rather than overwriting. It is the simplest possible session logging tool and it requires nothing to install.
Saving Nmap output in both formats simultaneously costs nothing and gives you two useful files. The .txt file is readable by humans. The .xml file is importable into Metasploit with db_import — the same command covered in Lesson 18. Running both output flags on every scan is a habit that pays dividends during the exploitation phase.
Noise management — staying under the radar when it matters
Not every engagement is black box with the SOC unaware. But some are — and even on engagements where the security team knows testing is happening, good recon practice involves not generating unnecessary noise. Sloppy scanning habits that work fine in the lab become problems in production.
Three habits make a significant difference to scan visibility:
The recon mindset — what to carry into Section III
Section III is system and network attacks — exploitation. Everything from here uses what the recon phase produced. The quality of your recon determines the quality of your exploitation phase. A weak recon means guessing what to attack. A strong recon means walking in with a prioritised list and knowing which door to try first.
Three things to carry forward:
Never act on unvalidated scanner output
A scanner finding is a hypothesis. Manual validation is the experiment. Do not write "vulnerable" in a report until you have confirmed it is actually vulnerable — not just version-string-possibly-vulnerable.
Critical findings get escalated immediately
A confirmed unauthenticated RCE or an exposed database backup does not wait for the final report. Phone call to the engagement contact — not an email — the same day it is found.
Stay inside the scope
Every tool, every technique, every packet — directed only at what is explicitly authorised. When WHOIS reveals an IP block larger than what the client listed, you confirm scope before you scan. When a subdomain surfaces that was not in the original list, you confirm before you touch it. Always.
Teacher's Note: The best recon produces a target list short enough to fit on one page, with each entry annotated with the confirmed version, the specific CVE it is susceptible to, and whether that CVE has a public exploit available. When you can hand that page to your team lead and they can plan the exploitation phase from it — that is what good recon looks like.
Practice questions
Scenario:
Scenario:
Scenario:
Quiz
Scenario:
Scenario:
Scenario:
Up Next · Section III — Lesson 21
System Hacking — Overview
Section III begins. The recon phase is documented, the target list is ready, and the exploitation phase opens. Everything changes from here.