Recon and enumeration are where a CREST CPSA-style assessment is usually won or lost. Not because they are flashy, but because they shape everything that follows. If you miss a subdomain, trust bad DNS data, skip a service banner, or fail to write down what you tested, the rest of the engagement becomes guesswork. A printable checklist fixes that. It gives you a repeatable path from passive discovery to active validation, helps you stay methodical under time pressure, and creates notes you can actually use later. This article lays out a practical workflow you can print and follow, with clear prompts for what to check, how to record it, and how to decide what matters first.
Why a checklist matters in CREST CPSA-style work
A checklist does not replace skill. It supports it. In a CPSA scenario, you are expected to think like a tester, not a script runner. That means you need a structure that helps you notice relationships between assets, spot weak assumptions, and verify findings before you move on.
The reason checklists work is simple. Human memory is unreliable when tasks repeat. During recon, you may look at ten hosts that seem similar. Without a checklist, you can forget to test name resolution on one, skip TLS inspection on another, or fail to compare open services across hosts. A checklist reduces that drift.
It also helps with scope control. In many assessments, the challenge is not finding something. It is finding the right thing, inside scope, with enough evidence to justify the next step. A good workflow keeps you from spending twenty minutes on noise while missing a high-value service that should have been investigated first.
If you are preparing for practice work, structured repetition matters even more. Using the same order each time trains your eye. You begin to see patterns faster. If you want extra preparation material, you can pair this checklist with a CREST CPSA practice test so your note-taking and technical flow improve together.
The core workflow: from OSINT to active enumeration
The safest and most useful flow is to move from passive collection to low-noise validation, then to targeted active enumeration. That order matters because each stage improves the next one.
Stage 1: Define the target clearly
- Record the scope exactly as given. Write the domain names, IP ranges, exclusions, and test constraints.
- Note the objective. Are you mapping the attack surface, looking for weak exposure, or proving a path?
- Record time limits and access assumptions. For example, unauthenticated internet-only testing is very different from internal authenticated enumeration.
This matters because every later finding must tie back to scope. If you discover an asset but cannot show why it belongs to the target, it may waste time or create reporting problems.
Stage 2: Passive OSINT collection
- Identify root domains and likely subdomain patterns. Look for naming conventions such as vpn, mail, dev, test, api, auth, or legacy.
- Review public DNS records. Note A, AAAA, MX, NS, TXT, SPF, DKIM, and DMARC where relevant.
- Check certificate transparency data. This often exposes hostnames that are not obvious from DNS alone.
- Review public-facing technologies. Search headers, job posts, documentation, cached screenshots, and exposed branding for clues about platforms in use.
- Note third-party dependencies. CDN use, cloud hosting, identity providers, and outsourced services all affect what you test and how you interpret results.
The goal here is not to collect trivia. It is to build hypotheses. If you see MX records, there may be mail services. If certificate data shows admin and sso subdomains, identity and management interfaces may exist. If TXT records reveal cloud validation tokens, you may infer hosted services or migration history.
Stage 3: Passive-to-active validation
- Resolve discovered hostnames. Separate live records from stale ones.
- Map hostnames to IPs and shared infrastructure. Multiple names on one IP can reveal a reverse proxy or virtual hosting setup.
- Check whether services are actually reachable. A hostname in a certificate does not mean the service is live.
This step prevents a common mistake: treating every discovered name as equally important. Some are parked, old, or delegated to third parties. Validation tells you where to spend effort.
Stage 4: Initial scanning
- Perform host discovery where allowed. Note responsive systems and those that appear filtered.
- Scan for open TCP ports. Use sensible timing. Record exact ports, not just “web” or “mail.”
- Follow with version detection and banner grabs. The service behind a port is more important than the port number itself.
- Where relevant, assess UDP selectively. Focus on services that matter, such as DNS, SNMP, NTP, or VPN-related ports.
Initial scanning gives you the exposed surface. But the real value comes from interpreting it. An open 443 on a host named dev-api means something different from the same port on a host named mail.
What to record for each host
Good enumeration notes are structured, not free-form. You want a record that lets you answer three questions quickly: what is this host, what does it expose, and what should I test next?
A useful host entry should include:
- Identifier: hostname, IP address, and any aliases
- Source: where you found it, such as DNS, certificate data, scan result, or application content
- Reachability: live, filtered, redirects, resolves but no service
- Open ports and services: exact port, protocol, detected service, version if known
- Fingerprint clues: server headers, page title, TLS subject names, framework hints, favicon match, login forms
- Authentication state: public, login required, SSO redirect, client certificate prompt, VPN-only indicators
- Interesting observations: default pages, exposed docs, error messages, verbose banners, directory listing, weak TLS, unusual methods
- Next actions: targeted checks you plan to run
- Priority: low, medium, high, based on exposure and likely impact
This note structure matters because raw scan output gets noisy fast. A clean host summary lets you compare systems and notice outliers. For example, if seven web servers look hardened and one still exposes an old Tomcat manager page, that one deserves immediate attention.
Service enumeration prompts you can print and follow
The easiest way to make enumeration repeatable is to use prompts per service. These prompts are not there to force identical tests on every host. They are there to trigger the right questions.
Web services: HTTP and HTTPS
- What is the page title, redirect behavior, and default landing page?
- Are there multiple virtual hosts on the same IP?
- What do response headers reveal about the stack?
- Is TLS configured sensibly, and does the certificate expose extra hostnames?
- Are common paths present, such as admin, api, login, docs, swagger, backup, test, old, or upload?
- Does robots.txt, sitemap.xml, or JavaScript reveal hidden routes or internal names?
- Are there signs of a framework, CMS, reverse proxy, or WAF?
- Do error messages leak file paths, software versions, or backend details?
- Are dangerous HTTP methods enabled?
- Is authentication local, federated, or mixed?
Why these prompts? Because web services hide complexity. The port tells you almost nothing. The behavior around redirects, headers, JavaScript, and certificates often gives you a better map of the app than a simple banner ever will.
DNS
- Which records exist for the domain and subdomains?
- Are zone transfers allowed?
- Do TXT records reveal infrastructure, mail policy, or verification tokens?
- Do NS records suggest internal naming patterns or split-horizon DNS?
- Are there stale records that point to decommissioned infrastructure?
DNS is often treated as a quick lookup, but it is really an asset map. It can reveal old systems, cloud migrations, and external providers that explain what you are seeing elsewhere.
SMTP and mail-related services
- What banner and software hints are exposed?
- Do supported verbs reveal unnecessary functionality?
- Is relay behavior restricted?
- Do TLS settings align with the target’s mail posture?
- Can usernames or internal naming conventions be inferred safely from responses?
Mail services are useful even when they are not vulnerable. They often disclose hostnames, internal domains, anti-spam products, or identity patterns that help later testing.
SMB, NetBIOS, and Windows services
- What is the host naming format and domain or workgroup information?
- Is SMB signing required?
- Are shares visible, even if access is restricted?
- Do banners or protocol responses indicate OS version or patch age?
- Are remote management services exposed, such as WinRM or RDP?
These checks help you judge whether the host is likely an endpoint, server, or management system. That influences risk and next steps.
SSH
- What version and software family are exposed?
- What host keys are presented?
- Do banners or algorithms suggest age or non-default configuration?
- Does the hostname or key reuse suggest shared provisioning?
SSH can tell you a lot about build consistency. Reused keys, old versions, or strange banners are not proof of compromise, but they are strong signs to look closer.
SNMP
- Is the service reachable at all?
- Are default or weak community strings accepted where testing rules allow?
- What device information can be enumerated?
- Does the response reveal network layout, interface names, or management details?
SNMP matters because it can turn one exposed UDP service into a detailed inventory of hardware and topology.
Databases and application backends
- Is the service intended to be internet-facing?
- What version and flavor are exposed?
- Is authentication required immediately, or is metadata disclosed first?
- Do banners, certificates, or service names reveal environment role, such as prod or dev?
An exposed database is often high priority, not only because of direct risk, but because it usually points to poor network segmentation or a rushed deployment.
How to validate findings before you trust them
Enumeration produces false positives. A checklist should include validation steps so you do not build conclusions on shaky data.
- Confirm with two signals where possible. If a scanner says Apache, compare that with headers, error pages, or TLS clues.
- Recheck unusual results manually. If one host appears to expose an old service while peers do not, verify it by direct interaction.
- Distinguish redirects from content. A login page on one host may just be a central SSO redirect.
- Treat stale DNS carefully. A record that resolves may still point to retired or unrelated infrastructure.
- Note uncertainty explicitly. “Likely nginx reverse proxy” is better than writing “nginx” as a fact without enough evidence.
This discipline matters in exams and real work. Good testers do not just collect output. They interpret it carefully and state confidence levels. That makes your later reporting stronger and your testing decisions smarter.
Prioritization: what to investigate first
Once you have a list of hosts and services, the next job is triage. Not every finding deserves equal time. A practical checklist should force a priority decision after initial enumeration.
Use these factors:
- Exposure: Is it public, reachable, and unauthenticated?
- Sensitivity: Does it appear to be admin, identity, mail, VPN, management, or data storage?
- Weakness signals: Old versions, default pages, verbose errors, weak TLS, exposed docs, test environments
- Business value clues: Payroll, customer portal, SSO, finance, remote access
- Path potential: Could this service lead to credentials, internal names, or wider access?
A simple way to score is:
- High priority: internet-facing admin portals, VPNs, exposed databases, legacy web apps, identity services, storage systems
- Medium priority: standard websites with custom functionality, mail gateways, remote management interfaces with controls in place
- Low priority: static brochure sites, heavily filtered hosts, assets with no meaningful interaction
The reason to prioritize this way is that impact usually comes from combinations: exposed service plus weak control plus business importance. A forgotten test portal with weak auth often matters more than a polished marketing site on the same network.
A printable checklist structure you can actually use
If you want this workflow on paper, keep it compact enough to scan quickly. One page for the global flow. One repeated block for host notes. That is usually enough.
Global flow checklist
- Confirm scope, exclusions, and objective
- List root domains and IP ranges
- Collect passive DNS and certificate hostname data
- Record likely subdomains and environment naming patterns
- Resolve hostnames and remove stale entries
- Map live hosts to IPs and shared infrastructure
- Run initial port discovery
- Perform service and version detection
- Group hosts by role: web, mail, identity, admin, remote access, storage, management
- Apply service-specific prompts
- Validate unusual or high-risk results manually
- Assign priority and next action for each host
- Mark evidence captured and notes complete
Per-host note block
- Hostname / IP:
- Source of discovery:
- Status: live / filtered / redirect / unknown
- Ports and services:
- Version or banner clues:
- TLS / cert names:
- Auth type:
- Interesting content or errors:
- Related hosts or shared IP:
- Likely role:
- Confidence level:
- Priority:
- Next steps:
This layout works because it mirrors how your decisions happen in practice. First you identify. Then you verify. Then you classify. Then you choose where to go deeper.
Common mistakes this workflow helps prevent
- Jumping into deep testing too early. If you attack one app before mapping related hosts, you may miss a weaker sibling service.
- Trusting scanner labels without checking. Service fingerprints can be wrong behind proxies and load balancers.
- Ignoring naming patterns. Hosts like old-vpn, dev-admin, or backup-api are often more revealing than their polished production counterparts.
- Keeping messy notes. Poor notes lead to repeated work and weak reporting.
- Failing to rank findings. Time spent on low-value services can cost you meaningful results elsewhere.
These are small process failures, but they have large effects. A repeatable checklist reduces them because it forces consistency, even when the target is unfamiliar.
Final thought
The best recon workflow is not the longest one. It is the one you can repeat accurately under pressure. For CREST CPSA-style preparation, that means a checklist that moves in a clear order: define scope, collect OSINT, validate what is live, enumerate by service, record evidence properly, and prioritize based on exposure and value. If you print that workflow and use the same note structure every time, your assessments become sharper and faster. More importantly, your findings become easier to trust, explain, and act on.
