"Give me six hours to chop down a tree and I will spend the first four sharpening the axe."
— Attributed to Abraham Lincoln
Reconnaissance is the foundation upon which all other assessment activities build.
Time invested in thoroughly understanding the target environment pays dividends
throughout the engagement. Rushing into active testing without comprehensive
reconnaissance means missed attack vectors, incomplete coverage, and findings
that lack context.
Learning Outcomes
By the end of this week, you will be able to:
LO1: Configure a professional security assessment environment using
industry-standard tools
LO2: Conduct passive reconnaissance to gather intelligence without alerting the
target
LO3: Enumerate external attack surface components including domains, subdomains,
and exposed services
LO4: Document reconnaissance findings in a structured, actionable format
LO5: Differentiate between passive and active reconnaissance techniques and their
appropriate use
Introduction: Before You Strike
With your engagement charter signed and scope defined, you're authorized to begin
work. But "beginning" doesn't mean launching vulnerability scanners. Professional
assessments start with two parallel activities: preparing your tools and
understanding your target.
This week covers both: setting up an assessment environment that will serve you
throughout the engagement, and conducting reconnaissance to map NovaTech's
attack surface. By week's end, you'll have a functioning lab and a comprehensive
picture of what you're assessing.
This Week's Deliverables
Assessment Lab: Configured and documented testing environment
Attack Surface Map: Comprehensive documentation of NovaTech's external
footprint
1. Assessment Environment Architecture
A professional assessment environment isolates your testing activities, organizes
your tools, and ensures you can document and reproduce your work. The environment
you build now will be your workspace for the entire engagement.
For this capstone, we recommend a virtualized environment that you can run on
your local machine. This provides isolation, snapshotting, and portability.
Option A: Kali Linux Virtual Machine (Recommended)
Kali Linux is a Debian-based distribution designed for security assessment,
with hundreds of pre-installed tools. Running it as a VM provides isolation
from your host system.
System Requirements
Host machine: 8GB+ RAM (16GB recommended), 50GB+ free disk space
Virtualization: VirtualBox (free) or VMware Workstation Player (free)
Reconnaissance ("recon") is the systematic collection of information about a target.
It's the intelligence-gathering phase that informs all subsequent testing activities.
Professional assessments distinguish between passive and active reconnaissance based
on detection risk and authorization requirements.
Passive vs. Active Reconnaissance
┌─────────────────────────────────────────────────────────────────┐
│ RECONNAISSANCE SPECTRUM │
├─────────────────────────────────────────────────────────────────┤
│ │
│ PASSIVE ACTIVE │
│ ────────────────────────────────────────────────────────── │
│ No direct target │ │ Direct target │
│ interaction │ │ interaction │
│ │ │ │
│ • Public records │ │ • Port scanning │
│ • Search engines │ │ • Service probing │
│ • Social media │ │ • Directory brute-force │
│ • Job postings │ │ • Banner grabbing │
│ • DNS records │ │ • Vulnerability scanning │
│ • Certificate logs │ │ │
│ • Code repositories │ │ │
│ │ │ │
│ DETECTION RISK: None │ │ DETECTION RISK: High │
│ AUTHORIZATION: Minimal │ │ AUTHORIZATION: Required │
│ │ │ │
└─────────────────────────────────────────────────────────────────┘
Aspect
Passive Reconnaissance
Active Reconnaissance
Definition
Gathering information without directly interacting with target systems
Directly probing or interacting with target systems
Detection
Virtually undetectable by target
May trigger IDS/IPS, appear in logs
Authorization
Generally doesn't require explicit authorization for public information
Requires explicit authorization before conducting
Timing
Can begin before engagement formally starts
Only after engagement charter is signed
Data Sources
Public records, third-party services, cached data
Direct responses from target systems
Authorization Boundary
Even "passive" reconnaissance has limits. Accessing a target's internal systems
through compromised credentials found in a data breach, for example, is NOT
passive reconnaissance—it's unauthorized access. Passive means using publicly
available information and services, not "any method that avoids detection."
3. Passive Reconnaissance Techniques
Passive reconnaissance leverages publicly available information to build
understanding of the target without any direct interaction. For NovaTech,
we'll gather intelligence from multiple sources.
3.1 WHOIS and Domain Information
WHOIS records reveal domain registration details including registrant information,
nameservers, and registration dates. While privacy protection has reduced the
information available, WHOIS still provides valuable context.
# Query WHOIS for primary domain
whois novatech-solutions.com
# Key information to extract:
# - Registrar (may indicate company size/sophistication)
# - Name servers (identify DNS providers)
# - Creation date (company age)
# - Registrant organization (verify correct target)
# - Admin/Tech contacts (if not privacy-protected)
Simulated NovaTech WHOIS Output
Domain Name: NOVATECH-SOLUTIONS.COM
Registry Domain ID: 2345678901_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.cloudflare.com
Registrar URL: https://www.cloudflare.com
Updated Date: 2024-03-15T12:00:00Z
Creation Date: 2018-06-22T08:30:00Z
Registrar Registration Expiration Date: 2026-06-22T08:30:00Z
Registrar: Cloudflare, Inc.
Registrant Organization: NovaTech Solutions, Inc.
Registrant State/Province: Texas
Registrant Country: US
Name Server: NS1.CLOUDFLARE.COM
Name Server: NS2.CLOUDFLARE.COM
Analysis: Domain registered in 2018 (matches company founding),
using Cloudflare for DNS (indicates some security awareness), Texas-based
(consistent with Austin HQ). Cloudflare may indicate CDN/DDoS protection.
3.2 DNS Enumeration
DNS records reveal infrastructure details: mail servers, subdomains, service
providers, and sometimes internal naming conventions.
# Query all DNS record types
dig novatech-solutions.com ANY
# Specific record types
dig novatech-solutions.com A # IPv4 addresses
dig novatech-solutions.com AAAA # IPv6 addresses
dig novatech-solutions.com MX # Mail servers
dig novatech-solutions.com TXT # Text records (SPF, DKIM, verification)
dig novatech-solutions.com NS # Name servers
dig novatech-solutions.com CNAME # Aliases
# Attempt zone transfer (usually blocked, but try)
dig axfr novatech-solutions.com @ns1.cloudflare.com
Simulated DNS Records
;; ANSWER SECTION:
novatech-solutions.com. 300 IN A 104.21.45.123
novatech-solutions.com. 300 IN A 172.67.182.45
novatech-solutions.com. 300 IN MX 10 aspmx.l.google.com.
novatech-solutions.com. 300 IN MX 20 alt1.aspmx.l.google.com.
novatech-solutions.com. 300 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
novatech-solutions.com. 300 IN TXT "google-site-verification=abc123..."
novatech-solutions.com. 300 IN TXT "atlassian-domain-verification=xyz789..."
Analysis: Multiple A records suggest load balancing or CDN.
Google MX records confirm Google Workspace (from client brief). SPF includes
SendGrid (email marketing/transactional email). Verification TXT records
confirm Google and Atlassian (Jira/Confluence) usage.
3.3 Subdomain Enumeration
Subdomains often reveal internal applications, development environments, APIs,
and forgotten services. Multiple techniques combine for comprehensive coverage.
Analysis: Several interesting findings: dev and
staging suggest non-production environments that may have weaker
controls. jenkins and grafana indicate CI/CD and
monitoring infrastructure that could be high-value targets. api
confirms API endpoints for testing. vpn indicates remote access
infrastructure.
3.4 Certificate Transparency
Certificate Transparency (CT) logs record all publicly issued TLS certificates.
This reveals subdomains, including those the organization may not want publicly known.
# Query crt.sh for all certificates
# Web interface: https://crt.sh/?q=novatech-solutions.com
# Command line query
curl -s "https://crt.sh/?q=%25.novatech-solutions.com" | \
grep -oP '(?<=
Search engines index publicly accessible content. Specialized queries can reveal
sensitive information that shouldn't be public.
# Site-specific searches
site:novatech-solutions.com
# Find specific file types
site:novatech-solutions.com filetype:pdf
site:novatech-solutions.com filetype:xlsx
site:novatech-solutions.com filetype:docx
site:novatech-solutions.com filetype:sql
site:novatech-solutions.com filetype:log
# Look for exposed directories
site:novatech-solutions.com intitle:"index of"
# Find login pages
site:novatech-solutions.com inurl:login
site:novatech-solutions.com inurl:admin
site:novatech-solutions.com inurl:portal
# Look for error messages
site:novatech-solutions.com "error" OR "warning" OR "exception"
# Search for configuration exposure
site:novatech-solutions.com "password" OR "pwd" OR "credentials"
# AWS-specific searches
site:novatech-solutions.com "s3.amazonaws.com"
site:novatech-solutions.com "amazonaws.com"
Ethical Consideration
Google dorking reveals publicly indexed information—you're not accessing
anything unauthorized. However, be mindful that some indexed content may
be unintentionally public. Document findings without downloading sensitive
files; instead, report the exposure.
3.6 GitHub and Code Repository Search
Developers sometimes commit sensitive information to public repositories. Search
GitHub for organization names, domain names, and potential credential exposures.
# GitHub search queries (use github.com search or gh CLI)
# Organization and domain references
"novatech-solutions.com"
"novatech" password
"novatech" api_key
"novatech" secret
# AWS-specific leaks
"novatech" AKIA # AWS access key ID prefix
"novatech" aws_secret
# Common credential patterns
"novatech-solutions.com" password
filename:.env novatech
filename:config novatech password
# Look for the organization's own repositories
org:novatech-solutions
Automated Tools
Tools like trufflehog, gitleaks, and gitrob
automate credential scanning across repositories. For passive recon, focus on
public repositories only.
3.7 Job Postings and Social Media
Job postings reveal technology stack, organizational structure, and sometimes
security maturity. LinkedIn provides employee information and organizational insights.
Team Structure: Security team size, reporting structure
Growth Areas: What they're hiring for indicates strategic priorities
Employee Count: LinkedIn shows company size and growth
Key Personnel: Security team members, IT leadership, executives
Simulated Job Posting Findings
Senior DevOps Engineer - NovaTech Solutions
Requirements:
- 5+ years experience with AWS (EC2, EKS, RDS, Lambda)
- Strong Kubernetes and Docker experience
- Terraform for infrastructure as code
- Experience with Jenkins CI/CD pipelines
- Familiarity with Datadog or similar monitoring
- Python and Bash scripting
Analysis: Confirms AWS as primary cloud, Kubernetes workloads,
Jenkins for CI/CD (matches subdomain finding), Datadog for monitoring (new intel).
Infrastructure-as-code suggests mature practices but also potential for
misconfiguration drift.
3.8 Shodan and Censys
Internet scanning services like Shodan and Censys continuously scan the internet
and index exposed services. Query these for target IP ranges to discover exposed
services without conducting your own scans.
# Shodan queries (requires free account for full results)
# Web: https://www.shodan.io/
# Search by organization name
org:"NovaTech Solutions"
# Search by domain
hostname:novatech-solutions.com
# Search by SSL certificate
ssl.cert.subject.cn:novatech-solutions.com
# Censys queries (requires free account)
# Web: https://search.censys.io/
# Search by domain
services.tls.certificates.leaf_data.subject.common_name: novatech-solutions.com
Analysis: OpenVPN server version may have known vulnerabilities.
Jenkins exposed on 8080 is a high-value target. Grafana version 9.3.2 should
be checked against CVE databases. All three services warrant inclusion in
active testing scope.
4. Active Reconnaissance Techniques
With the engagement charter signed, you're authorized to interact directly with
NovaTech's systems. Active reconnaissance confirms passive findings and discovers
details only visible through direct interaction.
Authorization Reminder
Active reconnaissance requires explicit authorization. Ensure your engagement
charter is signed and your testing window has begun before conducting any
active reconnaissance. All active techniques will generate logs and may
trigger security alerts.
4.1 DNS Zone Enumeration
While zone transfers are typically blocked, active DNS probing can reveal
additional records and verify passive findings.
# Attempt zone transfer (document if it works—significant finding)
dig axfr novatech-solutions.com @ns1.cloudflare.com
# DNS brute-forcing with wordlist
# Note: This generates queries to target DNS servers
dnsrecon -d novatech-solutions.com -t brt -D /usr/share/wordlists/subdomains.txt
# Verify discovered subdomains resolve
while read subdomain; do
host "$subdomain" && echo "$subdomain resolves"
done < all-subdomains.txt
4.2 Port Scanning
Port scanning identifies running services on target systems. Different scan
types balance speed, accuracy, and detection risk.
Nmap scan report for jenkins.novatech-solutions.com (54.85.xxx.xxx)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu
80/tcp open http nginx 1.18.0
443/tcp open ssl/http nginx 1.18.0
8080/tcp open http Jetty 9.4.z
|_http-title: Dashboard [Jenkins]
|_http-server-header: Jetty(9.4.43.v20210629)
Nmap scan report for vpn.novatech-solutions.com (52.23.xxx.xxx)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.4p1
443/tcp open ssl/http OpenVPN Access Server
943/tcp open http OpenVPN Access Server admin portal
4.3 Service Enumeration
Once ports are identified, deeper enumeration reveals service configurations,
versions, and potential vulnerabilities.
# Web server enumeration
whatweb https://app.novatech-solutions.com
nikto -h https://app.novatech-solutions.com -o nikto-app.txt
# SSL/TLS analysis
sslscan https://app.novatech-solutions.com
testssl.sh https://app.novatech-solutions.com
# HTTP methods and headers
curl -I https://app.novatech-solutions.com
curl -X OPTIONS https://app.novatech-solutions.com -i
# Directory enumeration (careful with rate limiting)
gobuster dir -u https://app.novatech-solutions.com \
-w /usr/share/wordlists/dirb/common.txt \
-t 10 -o gobuster-app.txt
# Technology fingerprinting
wappalyzer https://app.novatech-solutions.com # Browser extension
# Or use builtwith.com for passive fingerprinting
4.4 Web Application Reconnaissance
For WorkflowPro (app.workflowpro.io), gather application-specific intelligence:
# Crawl application to discover endpoints
# Using Burp Suite (configure browser proxy first):
# 1. Set browser proxy to 127.0.0.1:8080
# 2. Browse application manually
# 3. Review Site Map in Burp
# Automated crawling with gospider
gospider -s https://app.workflowpro.io -d 2 -o crawl-output
# JavaScript file analysis (reveals API endpoints)
# Download and analyze JS files referenced in HTML
curl https://app.workflowpro.io | grep -oP 'src="[^"]+\.js"'
# Review each JS file for API endpoints, hardcoded values
# API endpoint discovery
# Check for common paths
curl https://app.workflowpro.io/api/
curl https://app.workflowpro.io/api/v1/
curl https://app.workflowpro.io/graphql
curl https://app.workflowpro.io/swagger.json
curl https://app.workflowpro.io/api-docs
API Documentation Discovery
Check for exposed API documentation:
/swagger.json, /swagger-ui/, /swagger/
/api-docs, /api/docs
/openapi.json, /openapi.yaml
/graphql (introspection query)
/redoc, /docs
5. Documenting the Attack Surface
Reconnaissance generates substantial data. Professional documentation transforms
raw findings into actionable intelligence. Your attack surface map becomes a
reference document for the entire engagement.
Record when each piece of information was gathered. Infrastructure
changes during engagements; timestamps establish what was true when.
Source Attribution
Document how you discovered each item. "Subdomain found via CT logs"
differs from "Subdomain found via DNS brute-force." Sources affect
confidence levels.
Verification Status
Mark whether findings are verified (actively confirmed) or unverified
(from passive sources only). Passive findings should be verified before
exploitation attempts.
Testing Priority
Flag high-value targets for priority testing: internet-facing admin
panels, outdated software versions, services with known vulnerabilities.
Sample Attack Surface Entry
## Subdomain: jenkins.novatech-solutions.com
### Basic Information
- IP Address: 54.85.xxx.xxx
- First Discovered: 2025-01-15 via CT logs (passive)
- Verified: 2025-01-16 via nmap scan (active)
- Cloud Provider: AWS (us-east-1 based on IP range)
### Services
| Port | Service | Version | Notes |
|------|---------|---------|-------|
| 22 | SSH | OpenSSH 8.2p1 Ubuntu | Standard config |
| 80 | HTTP | nginx 1.18.0 | Redirects to 443 |
| 443 | HTTPS | nginx 1.18.0 | Valid cert, expires 2025-08 |
| 8080 | HTTP | Jetty 9.4.43 | Jenkins dashboard |
### Technology Stack
- Operating System: Ubuntu (inferred from SSH banner)
- Web Server: nginx 1.18.0 (reverse proxy)
- Application: Jenkins (version TBD)
- Java Runtime: Jetty 9.4.43
### Security Observations
- Jenkins accessible without VPN (external exposure)
- No apparent IP restriction
- Login page publicly accessible
- Version disclosure in HTTP headers
### Testing Priority: HIGH
- CI/CD systems are high-value targets
- May contain credentials, code, deployment access
- Check for CVEs affecting Jenkins version
- Test for default credentials, authentication bypass
### Screenshots
- [jenkins-login-page.png](./screenshots/jenkins-login-page.png)
### Raw Data Files
- [nmap-jenkins.xml](./nmap/jenkins-scan.xml)
- [nikto-jenkins.txt](./web-scans/nikto-jenkins.txt)
6. NovaTech Attack Surface Summary
Based on reconnaissance conducted for this capstone scenario, here's a summary
of NovaTech's attack surface. Your lab will involve creating this documentation
yourself through actual reconnaissance exercises.
Test your understanding of reconnaissance concepts and techniques:
Question 1
During passive reconnaissance, you discover what appears to be a NovaTech
employee's credentials in a public GitHub repository. The credentials appear
to be for their internal Jenkins system. What should you do?
Reveal Answer
Do NOT test the credentials. Document the finding (repository URL, commit
hash, date discovered) and immediately notify Marcus Webb through the
critical finding process. Exposed credentials in public repositories are
a significant finding regardless of whether they're still valid. Testing
them could be seen as unauthorized access if they provide access beyond
your scope, and you would destroy the ability to determine if attackers
have already used them. Let the client revoke and investigate while you
document the exposure.
Question 2
You're conducting subdomain enumeration and discover
dev-internal.novatech-solutions.com.
It resolves to a private IP address (10.x.x.x). Is this useful information?
Reveal Answer
Yes, this is valuable intelligence even though you can't reach it directly.
It reveals: (1) internal naming conventions that might apply to other resources;
(2) the existence of development infrastructure; (3) potential DNS configuration
issues (internal DNS records shouldn't typically be publicly resolvable).
Document this for the internal network assessment phase when you have VPN
access. It may also indicate split-horizon DNS, which could have security
implications.
Question 3
Your nmap scan of NovaTech's external IPs completes and shows all ports filtered
for several IP addresses. Does this mean there's nothing to test?
Reveal Answer
No, "filtered" typically indicates a firewall is blocking your probes, not
that nothing is running. This is actually expected for well-configured
infrastructure. Next steps: (1) Verify you're scanning during authorized
windows; (2) Try different scan types (-sA for ACK scan, -sN/-sF/-sX for
null/FIN/Xmas); (3) Focus on hosts/ports you know are accessible (from
passive recon); (4) Check if your source IP needs whitelisting; (5) The
services identified through passive recon (HTTPS on app.workflowpro.io)
are still in scope even if port scans are blocked.
Question 4
Explain why Certificate Transparency logs are valuable for reconnaissance
even when the target uses wildcard certificates.
Reveal Answer
CT logs record all issued certificates, not just the domains they cover.
Even with a wildcard (*.novatech-solutions.com), you gain: (1) Historical
certificates showing what specific subdomains were previously issued certs
for (before they switched to wildcard); (2) Non-wildcard certs for specific
services that needed their own certificate; (3) Certificate authority
preferences (Let's Encrypt vs. commercial CAs indicates security investment);
(4) Timing of certificate issuance (recent certs may indicate new services);
(5) Alternative domain names in SAN fields that might not be obvious.
Question 5
You're documenting NovaTech's attack surface and need to prioritize testing targets.
Rank these three discoveries from highest to lowest priority and explain why:
(A) Corporate blog running WordPress, (B) Jenkins server accessible from internet,
(C) Staging environment of WorkflowPro application.
Reveal Answer
1. Jenkins (B) — Highest: CI/CD systems typically have access to
source code, deployment credentials, and production infrastructure. A compromised
Jenkins often leads to supply chain attacks or direct production access. External
exposure is unexpected and concerning.
2. Staging Environment (C) — High: Staging environments often
mirror production but with weaker security controls, test data that may include
production copies, and developer shortcuts. Vulnerabilities found here likely
exist in production.
3. WordPress Blog (A) — Medium: While WordPress has frequent
vulnerabilities, a corporate blog is typically isolated from core infrastructure
and doesn't contain sensitive data. Unless it's on the same infrastructure as
critical systems, compromise impact is limited to reputation.
Question 6
What's the difference between running nmap -sV and checking Shodan
for the same target? When would you use each?
Reveal Answer
Shodan: Queries pre-collected data from Shodan's internet-wide
scans. Passive from your perspective (no packets to target). Data may be
hours/days/weeks old. Useful before engagement starts, for understanding
what's historically been exposed, and for targets you can't directly reach.
nmap -sV: Active scan sending probes directly to target.
Current, real-time data. More accurate version detection through active
probing. Generates logs on target. Requires authorization.
When to use each: Use Shodan during passive recon before
engagement authorization, for quick overview, or to see historical exposure.
Use nmap once authorized for accurate, current service enumeration. Compare
both to identify changes (services that were exposed but are now closed,
or new exposures not yet in Shodan).
Lab: Build Your Attack Surface Map
Objective
Configure your assessment environment and conduct comprehensive reconnaissance
against practice targets, producing a professional attack surface map document.
Deliverables
Configured Lab Environment: Documented with screenshots showing tool
verification
Attack Surface Map: Comprehensive documentation of reconnaissance findings
Time Estimate
4-5 hours
Important: Practice Targets
Since NovaTech is fictional, you'll practice reconnaissance techniques against
authorized targets. Use the following for hands-on practice:
01-recon/ — Directory containing all raw reconnaissance data
🎯 Hands-On Capstone Activities
Build your reconnaissance toolkit and conduct professional OSINT for the capstone engagement.
🔍 TryHackMe: Reconnaissance Mastery
What you'll do: Complete advanced OSINT and recon labs—passive information gathering, subdomain enumeration, service discovery.
Why it matters: Reconnaissance determines the attack surface—thorough recon enables better targeting.
Time estimate: 3-4 hours
What you'll do: Build professional pentesting environment—Kali Linux, Burp Suite Pro (community), reconnaissance tools, documentation system.
Why it matters: Proper tooling is essential for efficient, professional security assessments.
Time estimate: 2-3 hours
What you'll do: Conduct and document reconnaissance for your capstone target—create professional findings report with discovered assets.
Why it matters: This becomes part of your final capstone deliverable—portfolio-ready documentation.
Time estimate: 3-4 hours
Reflect on the relationship between thoroughness and efficiency in reconnaissance.
Consider: How do you decide when you've gathered "enough" information to move
forward? What are the risks of insufficient reconnaissance versus the cost of
spending too much time in this phase? How did passive reconnaissance findings
shape your approach to active reconnaissance?
Connect your reflection to the broader engagement context. How does the quality
of your reconnaissance affect subsequent phases of the assessment? What would
you do differently in future engagements based on this experience?