GIAC GPEN Recon and Enumeration Checklist: A Repeatable Workflow You Can Print

Reconnaissance and enumeration are where a penetration test either becomes methodical or turns into guesswork. In the GPEN context, that difference matters. A repeatable workflow helps you gather the same core facts every time, avoid missing obvious attack paths, and keep your notes useful when you need to explain risk later. A printable checklist is not just a convenience. It reduces mental load, gives you a sequence to follow under time pressure, and makes it easier to validate findings before you move on. This article lays out a practical recon and enumeration workflow you can print, use during labs, and adapt for real assessments.

Why a repeatable recon and enumeration workflow matters

Good testers do not rely on memory alone. They follow a process. That process matters because recon and enumeration create the map for every next step. If your map is incomplete, your exploitation phase will be incomplete too.

A checklist helps in four practical ways:

• It keeps you consistent. You do not skip DNS checks on one target and forget SMB enumeration on another.
• It improves speed. A clear sequence reduces tool switching and second guessing.
• It improves note quality. You know what to record at each stage, not just what looks interesting in the moment.
• It helps with validation. You can compare what one method shows against another before treating a result as real.

This is especially useful if you are preparing for GPEN and working through practice material such as the GIAC GPEN practice test. The exam expects judgment, not random tool use. A checklist trains that judgment.

Start with scope, assumptions, and a note-taking template

Before touching a target, define what you are allowed to touch. Many recon mistakes are not technical. They are scope mistakes. If you scan the wrong IP range or test a third-party service in scope by accident, your process has already failed.

Your first checklist section should be administrative and simple:

• Target name: company, host, or lab identifier
• Scope: IP ranges, domains, subdomains, URLs, VPN ranges
• Out of scope items: third-party SaaS, social engineering, DoS, production restrictions
• Testing window: approved dates and times
• Source systems: what IP or VPN endpoint you are testing from

Then create a note-taking structure before you gather data. This sounds minor, but it saves time later. A useful note template usually includes:

• Asset: IP, hostname, URL
• Discovery source: OSINT, DNS, scan, service banner, web content
• Open ports and services: with versions when known
• Interesting findings: banners, titles, usernames, shares, error messages
• Validation status: unverified, partially verified, confirmed
• Priority: low, medium, high, with reason
• Next action: what to test next and why

If you print one thing, print this template with room to write under each host.

Phase 1: OSINT before active scanning

Start with passive collection when possible. The goal is to understand the target’s external footprint before you begin active probing. This gives context. It also helps you spot naming patterns and external services that active scans alone may miss.

Your OSINT checklist should include:

• Primary domains and known subdomains
• Public IP ranges and hosting providers
• Mail records such as MX and SPF
• Public-facing applications like VPN portals, OWA, webmail, admin panels
• Technology clues from headers, page titles, TLS certificates, and error pages
• Naming conventions for hosts, users, offices, or environments such as dev, test, prod

Why do this first? Because passive data can shape your scanning plan. If OSINT suggests a company uses Microsoft 365 heavily, your expectations for mail infrastructure change. If certificate data reveals subdomains that are not in DNS anymore, those names may still appear internally or on old infrastructure.

Record both facts and confidence. For example:

• Fact: portal.example.com has a certificate with names for vpn.example.com and sso.example.com
• Confidence: certificate evidence is strong, but service availability still needs active validation

This is better than writing “possible VPN and SSO” with no source attached.

Phase 2: Host discovery and basic scanning

Once scope is clear and you have passive context, move into active discovery. The purpose here is not to run every scan option you know. It is to answer three basic questions:

• What hosts are alive?
• What ports are open?
• What services are actually listening on those ports?

A printable checklist for this phase should prompt you to:

• Confirm reachability using allowed discovery methods
• Identify live hosts across the scoped range
• Run an initial TCP port scan
• Follow with targeted UDP checks where relevant
• Capture service banners and versions
• Record filtered versus closed ports
• Note network patterns such as repeated open ports across many hosts

The “why” matters here. A host with 80, 443, and 22 open tells a different story than a host with 135, 139, 445, and 3389 open. You are building a role hypothesis. Is this likely a web server, a workstation, a domain-connected Windows host, or an admin jump box? That hypothesis helps you prioritize enumeration.

Make room in your checklist for simple classifications:

• Likely web server
• Likely Windows host
• Likely Linux host
• Likely network appliance
• Likely authentication or directory service

Do not treat version detection as perfect. Banners lie. Proxies interfere. Reverse proxies often hide the real application stack. Mark version details as confirmed only when more than one clue supports them.

Phase 3: Service enumeration prompts by protocol

Once you know what is open, switch from broad scanning to service-specific questions. This is where many people become too tool-focused. A better habit is to ask the same questions for each service type and use tools only to answer them.

Below is a practical printable prompt list.

HTTP and HTTPS

• What is the page title, server header, and application fingerprint?
• Are there redirects to other hostnames or applications?
• What directories, login portals, APIs, or admin paths are exposed?
• Are default pages, debug messages, or stack traces visible?
• What methods are accepted?
• Does TLS reveal certificate names, weak configuration, or internal naming?
• Are there signs of virtual hosting that require hostname-based requests?

Why these prompts? Because web services often reveal more structure than the banner does. A redirect to intranet.example.local or a certificate containing old hostnames can give you new enumeration paths even without exploitation.

DNS

• What records exist for the target domain?
• Is zone transfer allowed?
• Do reverse lookups reveal naming patterns?
• Are internal names exposed through misconfiguration?
• Do MX, TXT, SPF, or DMARC records reveal vendors or infrastructure choices?

DNS is often overlooked because it feels basic. It should not be. It connects names, systems, and services. That context can reshape the whole test.

SMB and NetBIOS

• Can you identify hostname, domain, and OS details?
• Are null sessions or anonymous access possible?
• What shares are available?
• What permissions exist on accessible shares?
• Are there useful file names, scripts, backups, or configuration files?

On Windows-heavy environments, SMB enumeration can quickly tell you whether you are dealing with a workstation, server, or domain-connected asset. Share names alone can point to backup locations, software deployment folders, or user data.

LDAP and directory services

• Does anonymous bind work?
• Can you identify naming contexts and directory structure?
• Are user, group, or computer objects exposed?
• Does the service reveal domain naming and trust clues?

Directory services are high-value because they describe the environment itself. Even limited exposure can provide usernames, group names, and domain structure.

SSH

• What version and key details are exposed?
• Does the banner reveal vendor or device type?
• Are there clues about legacy configuration or weak policy?

FTP, TFTP, and file transfer services

• Is anonymous access allowed?
• What files or directories are exposed?
• Are upload permissions present?
• Do visible files reveal credentials, configs, or backups?

SMTP and mail services

• What banner and server software are visible?
• Can valid users be identified through allowed methods?
• Do headers or TLS details expose internal names or vendors?

RDP, VNC, and remote access

• Can you identify hostnames, domains, or certificate names?
• Are there NLA or authentication clues?
• Does the service suggest an admin-facing system worth prioritizing?

Databases

• What database type and version are present?
• Is anonymous or weakly authenticated access possible?
• Does the banner expose hostnames, schema names, or internal app references?

For each service, your checklist should force you to write two things: what you observed and why it matters. Example:

• Observed: SMB share named “DeployScripts” readable anonymously
• Why it matters: deployment scripts often store credentials, host lists, or software paths useful for lateral movement

Build notes that support decisions, not just raw output

A common mistake is saving scan output and calling that documentation. Raw output is evidence, not analysis. Your notes should help you decide what to test next.

A better host entry looks like this:

• Host: 10.10.10.25 / filesrv01
• Role hypothesis: Windows file server in corp domain
• Key ports: 445, 3389
• Evidence: SMB naming, domain string, RDP certificate hostname
• Interesting findings: readable share with installer packages and login scripts
• Validation: hostname confirmed by SMB and RDP certificate
• Priority: High, because accessible files may expose credentials or network paths
• Next step: review scripts and configs, check for stored secrets, map referenced hosts

This format turns data into action. It also makes reporting easier later because you can trace each conclusion to evidence.

Validate before you escalate effort

Enumeration often produces false positives, weak clues, or stale information. Validation keeps you from wasting time. It also keeps your final report credible.

Your printable checklist should include these validation steps:

• Confirm hostnames with more than one source such as DNS, banners, certificates, or SMB
• Confirm versions with more than one clue instead of trusting one banner
• Confirm access levels by testing read versus write permissions separately
• Confirm whether a finding is current not just cached, redirected, or stale
• Recheck high-value services manually if automated output looks unusual

For example, a scanner may label a service as Apache on Linux, but the response could be coming through a load balancer in front of a Windows application. If you prioritize based on the wrong stack, you will test the wrong things.

Validation is also how you avoid duplicate findings. If five subdomains all point to one application, record that relationship. Do not treat them as five separate issues unless the exposure really differs.

Prioritize findings based on access, impact, and follow-on value

Not every open service deserves the same time. Prioritization is what turns a checklist into a workflow.

Use three practical filters:

• Access: Can you interact with it now, with current permissions?
• Impact: If this leads somewhere, how serious could the result be?
• Follow-on value: Will this likely reveal credentials, internal hosts, usernames, or trust relationships?

Examples help:

• High priority: anonymous SMB share containing scripts, because it may reveal passwords and network paths
• High priority: external login portal with detailed error messages and known technology stack, because it could expose authentication weaknesses
• Medium priority: SSH banner on a hardened host with no other clues, because the attack surface is narrow without credentials
• Low priority: generic HTTPS page with no unique content and no alternate paths, until other evidence raises its value

This is the real point of enumeration. You are not collecting trivia. You are identifying the few observations most likely to produce valid, explainable security findings.

A printable GIAC GPEN recon and enumeration checklist

Below is a clean version you can print and use.

• 1. Scope and setup
  • Record target name, IP ranges, domains, URLs
  • Record out-of-scope items and restrictions
  • Prepare note template for each host
• 2. Passive recon
  • Collect domains, subdomains, IP ownership clues
  • Review DNS and mail-related records
  • Identify public-facing apps and certificate names
  • Record naming patterns and technology clues
• 3. Host discovery
  • Identify live hosts within scope
  • Record reachability limitations
• 4. Port and service discovery
  • Run initial TCP scan
  • Run targeted UDP checks as needed
  • Capture banners, versions, and filtered ports
  • Classify likely host role
• 5. Service enumeration
  • HTTP/HTTPS: titles, headers, paths, methods, certs, virtual hosts
  • DNS: records, transfers, reverse lookups, naming clues
  • SMB: shares, anonymous access, permissions, useful files
  • LDAP: binds, contexts, users, groups, domain structure
  • SSH/FTP/SMTP/RDP/DB: banner, access, host clues, weak exposure
• 6. Notes and evidence
  • For each host, record observed facts
  • Write why each fact matters
  • Set validation status and next action
• 7. Validation
  • Confirm names and versions with multiple sources
  • Verify access levels manually where needed
  • Remove stale or duplicate conclusions
• 8. Prioritization
  • Rank by access, impact, and follow-on value
  • Focus next effort on findings most likely to produce evidence-backed results

Final takeaway

The best recon and enumeration workflow is the one you can repeat without thinking too hard about the sequence. That is why a printable checklist works. It gives you structure when the environment is messy, keeps your notes aligned with your actions, and makes validation a normal step instead of an afterthought. For GPEN study, that habit improves both speed and accuracy. For real-world testing, it improves the quality of your findings. If your enumeration notes clearly show what you observed, why it matters, and what you confirmed, you are already working like a disciplined tester rather than someone just running tools.