Recon and enumeration are where most penetration tests either become efficient or go sideways. If you miss a host, an exposed service, or a naming pattern early on, the rest of the test is built on weak ground. For CompTIA PenTest+, this matters for two reasons. First, the exam expects you to understand a logical workflow, not just random tools. Second, real-world testers need a process they can repeat under time pressure. A printable checklist helps because it reduces mistakes, keeps notes consistent, and makes it easier to validate what you found before you move to exploitation. This guide walks through a practical OSINT-to-scanning workflow, gives service enumeration prompts, and shows how to record and prioritize findings in a way you can actually use.
Why a repeatable recon and enumeration workflow matters
A lot of beginners treat recon as “run a few scans and see what comes back.” That approach creates noise, misses context, and wastes time. A repeatable workflow fixes that.
It helps you:
- Cover the basics every time. You are less likely to skip DNS, certificate data, or version detection.
- Stay inside scope. A checklist reminds you what targets, domains, and IP ranges are approved.
- Write usable notes. Findings are only useful if you can trace them back to a host, port, and evidence source.
- Prioritize better. Enumeration should reveal what is likely exploitable, not just what is open.
- Defend your conclusions. On the exam and in real engagements, you need to explain why you believe a service is vulnerable or relevant.
Think of recon and enumeration as a funnel. You start broad with public information, narrow into exposed infrastructure, and then go deeper into the most promising systems and services.
Step 1: Confirm scope before touching anything
Before OSINT, before scanning, before even opening your notes, confirm scope. This sounds obvious, but it is one of the easiest places to make a serious mistake.
Your checklist should start with:
- Client name and engagement ID
- Authorized domains
- Authorized IP ranges
- Cloud assets included or excluded
- Third-party services included or excluded
- Allowed test window
- Rules of engagement
- Points of contact and escalation path
This matters because recon often uncovers shared infrastructure. For example, a subdomain may point to a SaaS provider or CDN. If that provider is out of scope, testing it directly can create legal and operational problems.
Step 2: Start with OSINT to build context
OSINT is not just “look up the company on the internet.” The goal is to build a target map before active scanning begins. That gives you better scan inputs and helps you recognize what looks normal versus unusual.
Your OSINT checklist should include:
- Primary domains and known subdomains
- WHOIS and registration details
- DNS records such as A, AAAA, MX, TXT, NS, and CNAME
- Certificate transparency data to identify additional hostnames
- Email formats like [email protected]
- Public IP ranges and ASN data
- Technology fingerprints from public-facing sites
- Employee naming patterns if relevant to phishing or password testing scenarios
- Public documents and metadata that may reveal usernames, paths, software versions, or internal hostnames
- Job postings that hint at the tech stack, such as specific firewall vendors or cloud platforms
The “why” is simple. OSINT often gives you target expansion and attack surface clues without sending a single packet to the target. For example, a certificate entry might reveal vpn.company.com, owa.company.com, and dev-api.company.com. Those names tell you what to scan first and what kinds of services may be behind them.
At this stage, record every discovered asset with a source. If you found a hostname in a certificate log, note that. If a subdomain came from DNS zone data, note that too. Source tracking helps later when you validate findings.
Step 3: Organize targets before scanning
Do not jump from a raw list of domains into full scans. Clean the list first.
Group targets into categories such as:
- External web applications
- Remote access services like VPN, RDP gateways, SSH, Citrix
- Email infrastructure
- Development or staging systems
- Cloud-hosted assets
- Known third-party or shared platforms
Then resolve hostnames to IPs and remove duplicates. If multiple hostnames point to one IP, keep both pieces of information. Virtual hosting matters. One IP may serve several different applications depending on the host header.
This step saves time because your scans become cleaner and your results become easier to interpret.
Step 4: Run host discovery and port scanning in phases
Active scanning should also follow a sequence. Start broad, then go deep.
A practical scanning checklist looks like this:
- Host discovery: Identify which systems are alive.
- Port discovery: Find open TCP and relevant UDP ports.
- Service detection: Identify what is running on each open port.
- Version detection: Collect product and version clues.
- Scripted checks: Use safe enumeration scripts where allowed.
- Targeted follow-up: Enumerate the most relevant services manually.
Why phases matter: if you try deep enumeration too early, you spend time on hosts that may not matter. If you stop after a basic port scan, you miss the details needed to assess risk.
As you scan, record:
- IP address
- Hostname
- Open port and protocol
- Service banner or fingerprint
- Version guess confidence
- Response notes such as redirects, authentication prompts, or TLS details
For PenTest+, it is useful to understand that “enumeration” means extracting more detail from a known service. Port 445 being open is discovery. Learning the host name, domain/workgroup, SMB signing status, accessible shares, and supported protocol versions is enumeration.
Step 5: Use service-based enumeration prompts
Once you know what is open, switch from generic scanning to service-based questions. This is where many good findings come from. Instead of asking “what ports are open?” ask “what can this service tell me, and how could that matter?”
Here is a printable-style prompt list you can reuse.
For HTTP/HTTPS:
- What server headers, titles, redirects, and technologies are exposed?
- Are there default pages, admin panels, API endpoints, or documentation paths?
- What HTTP methods are allowed?
- Is directory listing enabled?
- Are there login portals, password reset flows, or exposed debug interfaces?
- What does the TLS certificate reveal about hostnames and organization details?
- Are there differences between the root page, robots rules, and error responses?
Why it matters: Web services often reveal hidden applications, frameworks, and environment names. A redirect to staging.company.local or a JavaScript file that references /api/v1/admin can reshape your whole test plan.
For DNS:
- Which record types are available?
- Is zone transfer possible?
- Do TXT records expose email security settings, cloud verification tokens, or internal naming clues?
- Are there subdomains that suggest development, backup, or legacy systems?
Why it matters: DNS is often the fastest route to infrastructure mapping. A single zone transfer misconfiguration can reveal the internal structure of public-facing assets.
For SMB/NetBIOS:
- What is the host name and domain/workgroup?
- Is SMB signing required?
- Which shares are visible?
- Can guest or anonymous access read anything useful?
- What protocol versions are supported?
Why it matters: SMB enumeration can expose sensitive shares, weak signing settings, or old protocol support. Those are often high-value findings.
For SSH:
- What version is advertised?
- What key exchange, ciphers, and host keys are supported?
- Are there naming clues in the banner or key comments?
Why it matters: SSH usually leaks less than SMB or HTTP, but weak crypto support and clear host naming can still help with prioritization.
For SMTP:
- What banner is returned?
- Which commands are supported?
- Is user enumeration possible through server responses?
- Do headers or relay behavior reveal mail flow details?
Why it matters: Email systems are often identity-adjacent. Even small clues can support credential attacks in approved scenarios.
For LDAP:
- Does anonymous bind work?
- What naming contexts are exposed?
- Are domain details, users, groups, or policies visible?
Why it matters: LDAP misconfigurations can reveal the shape of an entire directory environment.
For RDP, VPN, and remote access gateways:
- What product is in use?
- Is multi-factor authentication visible or implied?
- Are there version clues or branding indicators?
- Do login errors reveal valid usernames or policy details?
Why it matters: Remote access services are high-value entry points. Even if exploitation is not possible, they deserve priority because they sit at the perimeter.
Step 6: Keep notes in a structure you can search later
Bad notes are one of the biggest causes of weak reporting. A finding without evidence, timestamps, or affected assets is hard to trust.
A simple note-taking structure works well:
- Asset ID: Hostname and IP
- Service: Port, protocol, and identified product
- Evidence: Banner, screenshot reference, response text, or scan result
- Observation: What you saw in plain English
- Security relevance: Why this matters
- Validation status: Unverified, partially verified, verified
- Priority: Low, medium, high, or your chosen risk scale
- Next action: Follow-up enumeration, vuln check, or no action
Example:
- Asset ID: files.company.com / 203.0.113.20
- Service: 445/TCP SMB
- Evidence: Share listing shows anonymous read access to “Public”
- Observation: Anonymous users can access a shared directory
- Security relevance: Could expose internal documents or usernames
- Validation status: Verified
- Priority: High
- Next action: Review accessible files for sensitive data in scope
This format forces you to connect technical output to business impact. That is useful for the exam and essential in real work.
Step 7: Validate findings before you escalate them
Enumeration often produces false positives, partial truths, and misleading banners. Validation is the step that turns raw data into credible findings.
Your validation checklist should ask:
- Did I confirm this with more than one method?
- Is the service actually what the scanner says it is?
- Did I test the correct virtual host or hostname?
- Could this be a reverse proxy, load balancer, or WAF masking the origin?
- Is the banner stale or intentionally misleading?
- Did I capture enough evidence to reproduce the result?
For example, a scanner may label a web server as Apache based on a header, but the real application may sit behind a proxy. Or a service banner may claim an older version even though the product is patched. If you report version-based risk without validation, your report becomes weaker.
Step 8: Prioritize what deserves deeper testing
Not every open port matters equally. Prioritization helps you spend time where it is most likely to produce meaningful results.
In general, prioritize:
- Internet-facing login portals
- Administrative interfaces
- Services with anonymous or weak access controls
- Legacy protocols and old versions
- Services tied to identity such as LDAP, SMTP, VPN, SSO, OWA
- Systems labeled dev, test, backup, old, or legacy
- Anything exposing sensitive data directly
The reason is simple: these systems either control access, expose data, or are more likely to have weak configuration. A printer management page with no auth might be interesting. A VPN portal with policy leakage is usually more important.
Step 9: Turn the workflow into a printable checklist
If you want a checklist you can print and use during labs or review sessions, keep it compact. A good one-page format looks like this:
- Scope confirmed
- Domains, IPs, exclusions recorded
- OSINT completed: DNS, certs, public docs, tech clues
- Targets grouped and deduplicated
- Host discovery completed
- Port scan completed
- Service/version detection completed
- HTTP/HTTPS enumerated
- DNS enumerated
- SMB enumerated
- SMTP enumerated
- LDAP enumerated
- Remote access services enumerated
- Notes captured with evidence
- Findings validated
- High-value targets prioritized
- Next-step actions assigned
Print it. Use it during labs. Use it during practice exams. Over time, the order becomes natural.
How this helps with CompTIA PenTest+ study
PenTest+ is not just about memorizing tools. It tests whether you understand process, evidence, scope, and decision-making. A checklist gives you a structure for all four.
If you are practicing for the exam, use this workflow while working through scenarios and sample questions. It helps you recognize where a question sits in the engagement lifecycle. If you want extra exam prep, you can review targeted questions here: CompTIA PenTest+ practice test.
The key idea is simple: recon and enumeration should be methodical. Start with context. Move into scanning in phases. Ask service-specific questions. Record evidence clearly. Validate before you assume. Then prioritize what matters most. That is the repeatable workflow worth printing, and it is the one most likely to make your testing cleaner, faster, and more accurate.
