Chapter 5
Reconnaissance, OSINT and Attack-Surface Mapping
Diploma in Cybersecurity
Ethical Hacking & Penetration Testing
•
Diploma
Reconnaissance, OSINT and Attack-Surface Mapping
Introduction
Reconnaissance is the systematic collection and interpretation of information about a target before security testing begins. In ethical hacking, reconnaissance is not an invitation to explore any system of interest. It is an authorized activity conducted within a defined scope, time window, and rules of engagement. Its purpose is to reduce uncertainty, identify likely exposure paths, and help testers select safe and proportionate validation techniques.
A modern organization rarely has a single, easily defined perimeter. Its attack surface may include public websites, cloud services, remote-access gateways, application programming interfaces, mobile applications, email systems, third-party platforms, source-code repositories, employee identities, leaked metadata, and abandoned infrastructure. Reconnaissance therefore combines technical observation with organizational and contextual analysis.
This chapter develops a practical methodology for passive and active reconnaissance, open-source intelligence (OSINT), DNS analysis, metadata examination, search-engine research, repository review, threat intelligence, identity discovery, and attack-surface mapping. The emphasis is on authorized, low-risk, reproducible professional practice.
Learning Objectives
By the end of this chapter, students should be able to:
Distinguish passive reconnaissance, active reconnaissance, and intrusive testing.
Establish scope, authorization, safety controls, and evidence-handling requirements.
Use public records, DNS, search engines, metadata, repositories, and threat intelligence responsibly.
Identify external assets, technologies, identities, relationships, and exposure paths.
Build an attack-surface map that distinguishes evidence from inference.
Assess data quality, confidence, business relevance, and risk.
Communicate findings without exposing unnecessary sensitive information.
1. Reconnaissance as an Information Problem
Reconnaissance can be understood as an information-reduction process. At the beginning of an engagement, the tester may know only the organization’s name and a small number of approved domains. Through structured collection, the tester develops an evidence-based model of:
Assets: domains, subdomains, IP addresses, applications, cloud services, APIs, certificates, repositories, and devices.
Technologies: web servers, content-management systems, frameworks, identity providers, hosting platforms, and security controls.
Identities: staff names, job roles, email conventions, service accounts, public maintainers, and organizational affiliations.
Relationships: ownership, hosting, delegation, suppliers, subsidiaries, and shared infrastructure.
Exposure paths: routes by which an attacker might reach data, credentials, administrative functions, or trusted relationships.
The objective is not to collect the largest possible quantity of data. Unfiltered data creates noise, false positives, privacy risk, and wasted testing time. High-quality reconnaissance is relevant, current, attributable, and sufficiently corroborated.
Passive and Active Reconnaissance
Passive reconnaissance uses information obtained without directly interacting with the target’s systems in a way that is observable as a probing action. Examples include public web pages, certificate-transparency records, business registries, archived pages, public DNS records, search-engine indexes, published documents, and public repositories.
Active reconnaissance involves direct interaction with target-controlled infrastructure. Examples include DNS queries directed at authoritative servers, connection attempts to approved hosts, service discovery, banner collection, and controlled application requests. Active work may generate logs, alerts, or operational impact and therefore requires explicit authorization.
The boundary is contextual. A DNS query may be public and low risk, but repeated queries from a testing source can still be detected. Retrieving a public document is generally passive; submitting forms, testing credentials, crawling aggressively, or sending crafted requests is not passive reconnaissance.
Activity
Typical classification
Main concern
Reading a public web page
Passive
Accuracy and attribution
Reviewing certificate records
Passive
False associations
Querying DNS records
Low-impact active or passive, depending on method
Logging and scope
Connecting to an approved web host
Active
Operational impact
Port or service scanning
Active
Detection and disruption
Testing credentials
Intrusive validation
Account lockout and legal risk
Exploiting a vulnerability
Exploitation
Requires separate authorization
2. Authorization, Scope and Governance
A professional reconnaissance exercise begins with written authorization. The authorization should identify the client, testing team, dates, approved assets, prohibited systems, permitted techniques, emergency contacts, data-handling rules, and reporting requirements.
A useful scope statement distinguishes:
In-scope assets: exact domains, IP ranges, applications, subsidiaries, or cloud accounts.
Out-of-scope assets: third-party systems, shared hosting, production services, or personal accounts.
Permitted sources: public records, approved test accounts, customer-provided inventories, and authorized intelligence platforms.
Operational limits: request rates, scanning windows, maximum concurrency, and prohibited actions.
Evidence requirements: screenshots, URLs, timestamps, hashes, response metadata, and chain of custody.
Reconnaissance frequently reveals personal information. Data minimization is therefore essential: collect only what is necessary, protect it during storage and transmission, redact it in reports, and delete it according to the engagement agreement. Public availability does not automatically make collection ethically unrestricted.
A tester should maintain a stop condition. Examples include evidence that an asset belongs to a third party, signs of instability, exposure of sensitive personal data, a request from the client to pause, or uncertainty about whether a system is in scope.
3. A Reconnaissance Workflow
A repeatable workflow improves completeness and reduces uncontrolled activity.
Authorized reconnaissance workflow from scope to reporting
Figure: Authorized reconnaissance workflow from scope to reporting
Figure: A controlled reconnaissance workflow emphasizing authorization, validation, mapping, and iterative reporting.
Step 1: Establish Seed Information
Seeds are known facts from which investigation begins: official domains, brand names, registered business names, public IP ranges, approved subsidiaries, product names, and known cloud tenants. Record the source and date of every seed.
Step 2: Expand Carefully
Expansion may identify related domains, subdomains, certificates, providers, applications, repositories, and identities. Each new item is a candidate, not automatically an in-scope asset.
Step 3: Validate Ownership and Relevance
Ownership can be checked through registration information, DNS delegation, certificate details, organization-controlled pages, consistent branding, and client confirmation. A matching name or logo is not proof of ownership.
Step 4: Correlate and Map
Correlate observations across independent sources. For example, a subdomain, certificate, DNS record, and application response together provide stronger evidence than any one source alone.
Step 5: Report and Reassess
Report confirmed assets, uncertain associations, exposure paths, evidence quality, and recommended defensive actions. Reconnaissance is iterative: new evidence may identify forgotten assets or invalidate earlier assumptions.
4. OSINT Sources and Methods
Public Web and Search Engines
Search engines reveal indexed pages, documentation, error messages, cached titles, file types, and references to subdomains. Search operators can narrow results by domain, file type, phrase, or URL pattern. Ethical use requires respecting authorization and avoiding attempts to bypass access controls. Search results are not complete inventories: indexing is selective, stale, and affected by robots directives and personalization.
Public Registries and Business Records
Domain-registration data, corporate registries, procurement records, regulatory filings, and transparency reports may reveal legal names, subsidiaries, contact addresses, technology suppliers, or historical ownership. Privacy services and data-protection laws may limit available information. Treat registry data as a lead requiring corroboration.
DNS and Certificate Transparency
DNS translates names into records such as A or AAAA addresses, MX mail servers, NS authoritative servers, TXT policy records, and CNAME aliases. A DNS record can reveal service relationships, but it does not prove that a host is vulnerable.
Certificate-transparency logs record publicly issued certificates. They can expose previously unknown hostnames and development environments. Certificates may contain old names, wildcard names, or third-party services, so each result must be validated.
Important DNS observations include:
Delegation to authoritative name servers.
Mail-exchange providers and email-security controls.
SPF, DKIM, and DMARC-related TXT records.
Cloud-hosting aliases and content-delivery networks.
Inconsistent or stale records suggesting possible abandonment.
Metadata
Documents, images, presentations, and spreadsheets may contain author names, usernames, software versions, creation dates, internal paths, GPS coordinates, or revision history. Metadata is useful for identifying technology and organizational patterns, but it can also expose personal information. Collect a copy only where authorized, preserve the original, and avoid publishing sensitive values.
Public Repositories
Repositories may reveal application architecture, dependency files, deployment configurations, issue discussions, commit history, documentation, and organizational naming conventions. Public code does not imply permission to use exposed credentials. If a secret is discovered, do not authenticate with it; record minimal evidence, notify the designated contact, and follow the incident process.
A sound repository review considers:
Current and historical branches.
Configuration and environment templates.
Dependency manifests and lock files.
Build and deployment workflows.
Issue trackers and pull requests.
Ownership and maintainer identity.
Secret-scanning results provided by approved tools.
Threat Intelligence
Threat intelligence adds context about known malicious infrastructure, malware campaigns, vulnerability exploitation, and sector-specific threats. Useful sources include government advisories, vendor reports, incident databases, vulnerability catalogues, and information-sharing communities.
Intelligence must be assessed for source reliability, collection date, confidence, and relevance. A shared IP address appearing in a threat feed is not sufficient evidence that the organization is compromised. Threat data supports prioritization; it does not replace verification.
5. Identity and Technology Enumeration
Identity reconnaissance examines public organizational roles and naming patterns, not private lives. Sources may include staff directories, conference biographies, professional profiles, public commits, press releases, and support documentation. The goal is to understand organizational structure and potential account exposure, not to facilitate harassment, impersonation, or unauthorized access.
Technology enumeration identifies platforms and components through response headers, page structures, public documentation, certificate details, JavaScript libraries, error behavior, and repository files. Fingerprinting is probabilistic. A framework signature may be removed, spoofed, or shared by many products. Findings should therefore use confidence labels such as high, medium, or low.
A useful technology record contains:
Field
Example content
Asset
Public application hostname
Observation
Framework indicator in a response or document
Source
URL, record, or client-provided evidence
Date
Collection timestamp in UTC
Confidence
High, medium, or low
Security relevance
Patch priority, exposure, or dependency risk
Validation needed
Safe confirmation step
6. Attack-Surface Mapping
An attack-surface map is a structured representation of assets, trust relationships, technologies, identities, and possible exposure paths. It should distinguish at least three layers:
External assets: what can be reached or observed from outside.
Control and trust relationships: identity providers, suppliers, cloud accounts, DNS providers, repositories, and administrative dependencies.
Potential paths: sequences connecting an external observation to a sensitive function or resource.
A simple asset register might contain asset ID, hostname, IP address, owner, provider, service, environment, evidence source, last-seen date, confidence, and risk notes. Duplicate records should be merged carefully, preserving historical aliases.
Exposure Paths
An exposure path is a reasoned chain, not merely a list of findings. For example:
This path does not prove compromise. It identifies a route requiring control review. The path may be weakened by multifactor authentication, network restrictions, strong authorization, monitoring, or an inactive service.
Prioritization
A practical prioritization model considers exposure, business importance, confidence, and control strength. A qualitative model can classify an asset as:
Critical: externally reachable, business-critical, sensitive, and weakly controlled.
High: significant exposure or identity dependency with credible security concern.
Medium: relevant exposure requiring validation or remediation planning.
Low: informational, historical, or well-controlled asset.
Avoid presenting a subjective score as scientific precision. If a numerical scale is used, define it clearly and explain that it supports triage rather than proving probability of attack.
7. Evidence Quality and Analytical Reasoning
Reconnaissance produces observations, hypotheses, and conclusions. These must not be confused.
Observation: “A certificate issued in March contains the hostname portal.example.org.”
Inference: “The hostname may belong to the organization.”
Conclusion requiring validation: “The hostname is an active organization-managed portal.”
Evidence quality improves when sources are independent, recent, attributable, and technically consistent. Contradictions should be recorded rather than silently resolved. Dates matter because assets, providers, and staff roles change.
A professional notebook should record the query or source, timestamp, collector, result, interpretation, confidence, and next action. Screenshots alone are weak evidence if they lack URL, date, and context.
8. Illustrative Case Study: Northbridge Health Services
This is a fictional illustrative case.
Background
Northbridge Health Services authorized a two-week external assessment of its public web presence. The scope included northbridge.example, two named subsidiaries, and an approved cloud tenant. Patient portals, payment providers, and unrelated suppliers were explicitly out of scope.
Problem
The organization believed that its external surface consisted of one corporate website and a patient portal. Management wanted to know whether forgotten services, public documents, or supplier relationships created additional exposure.
Analysis
The team first recorded the approved domains and legal entity names. Passive collection identified several certificate names, an older documentation subdomain, public job advertisements mentioning a cloud platform, and a repository belonging to an organization with a matching name. The repository was not immediately treated as in scope because ownership was uncertain.
DNS review showed that the corporate site used a content-delivery provider, while email was hosted by a separate provider. Public documents contained author names and a software-generation path. A historical page referred to a retired support portal. A threat-intelligence feed listed an IP address once associated with a Northbridge hostname, but current DNS and certificate evidence indicated that the address was now used by a shared provider.
Approach and Solution
The team created an asset register with evidence and confidence fields. The documentation subdomain was validated through DNS delegation and client confirmation. The repository was reported as an unconfirmed association and sent to the client for ownership review; no credentials were tested. The retired support portal was checked only through approved, low-impact requests and was found to redirect to the current portal.
The exposure map identified three meaningful paths:
Public documentation → technology disclosure → patch-management review.
Public staff information → predictable email convention → identity-protection review.
Retired hostname → redirected portal → asset-inventory and certificate-lifecycle review.
Outcome
Northbridge confirmed that the documentation service was managed by a contractor and that the repository belonged to an unrelated community project. It removed unnecessary metadata from public documents, updated its external asset inventory, retired obsolete DNS aliases, and reviewed identity-provider protections. No exploitation was performed and no patient data was accessed.
Learning Points
The case demonstrates that reconnaissance is an evidence-management activity. Similar names are not proof of ownership, historical data can mislead, and a credible finding may be a governance weakness rather than a technical vulnerability. Passive-first collection reduced risk while still producing actionable improvements.
9. Challenges, Limitations and Contemporary Developments
Reconnaissance is limited by incomplete indexing, privacy protection, shared infrastructure, dynamic cloud allocation, domain changes, false positives, and deliberate concealment. Automated tools can rapidly produce large datasets but may duplicate assets, misclassify technologies, or overload systems if used carelessly.
Artificial intelligence can assist with entity resolution, document classification, deduplication, and summarization. However, AI-generated associations require human validation. Models may infer relationships from weak signals, reproduce confidential data, or obscure the source of a conclusion. A defensible workflow preserves raw evidence, records tool versions, restricts sensitive inputs, and requires analyst approval before reporting.
Contemporary attack surfaces increasingly include software-as-a-service platforms, serverless functions, APIs, mobile back ends, identity providers, software supply chains, exposed storage, and machine identities. Traditional domain lists are therefore insufficient. Organizations should combine external attack-surface management with asset ownership, cloud governance, certificate lifecycle management, repository protection, and continuous monitoring.
10. Professional Best Practices
Begin with written authorization and a precise scope.
Start passively and escalate only when explicitly permitted.
Use multiple independent sources before asserting ownership.
Record dates, sources, queries, and confidence levels.
Separate facts, inferences, and hypotheses.
Minimize collection of personal and sensitive information.
Do not use discovered credentials or bypass access controls.
Rate-limit active requests and define stop conditions.
Preserve evidence securely and redact reports.
Validate cloud, supplier, repository, and shared-hosting relationships.
Report uncertainty rather than converting it into false certainty.
Translate technical observations into business-relevant remediation.
Chapter Summary
Reconnaissance is the authorized process of reducing uncertainty about an organization’s external presence. Passive reconnaissance uses public and non-intrusive sources, while active reconnaissance directly interacts with approved infrastructure and requires stronger operational controls. OSINT sources include search engines, public records, DNS, certificate-transparency data, metadata, repositories, and threat-intelligence feeds.
Effective practitioners establish scope, collect seed information, expand carefully, validate ownership, correlate evidence, map assets and exposure paths, and report with confidence levels. Attack-surface mapping must include not only domains and IP addresses but also technologies, identities, cloud services, suppliers, repositories, trust relationships, and business importance. Ethical practice requires authorization, data minimization, privacy protection, safe handling of discovered secrets, and clear separation between observation and inference. Automation and AI can improve scale, but human validation remains essential.
Key Terms
Active reconnaissance: Direct interaction with authorized target infrastructure to collect information.
Asset: A system, service, identity, data store, domain, or dependency relevant to security.
Attack surface: The collection of externally reachable or exposed elements that could affect security.
Attack-surface map: A structured representation of assets, relationships, technologies, and possible exposure paths.
Certificate transparency: Public logging of issued digital certificates.
Confidence: An assessment of how strongly evidence supports an observation or conclusion.
DNS: The naming system that maps domain names to services and network addresses.
Exposure path: A reasoned chain connecting an external observation to a sensitive function or resource.
Fingerprinting: Inferring a technology or platform from observable characteristics.
Metadata: Information describing a file, object, or communication, such as author, date, or software.
OSINT: Open-source intelligence collected and analyzed from publicly available information.
Passive reconnaissance: Information collection that avoids direct probing of target infrastructure.
Repository: A managed store of source code, documentation, configuration, or development history.
Seed information: Initial trusted facts used to begin reconnaissance.
Scope: The authorized boundaries of an assessment.
Threat intelligence: Contextual information about threats, adversaries, vulnerabilities, and malicious infrastructure.
Validation: Checking whether an observation is current, relevant, and correctly attributed.
WHOIS or registration data: Public or restricted information concerning domain registration and delegation.
Review Questions
Short Answer Questions
What is the main difference between passive and active reconnaissance?
Why is a public repository not automatically proof of organizational ownership?
Name four sources that can contribute to an attack-surface map.
What is the difference between an observation and an inference?
Why should discovered credentials never be tested without explicit authorization?
Long Answer Questions
Explain a complete reconnaissance workflow from authorization through reporting.
Discuss how DNS and certificate-transparency data can reveal assets and also create false positives.
Explain how privacy, data minimization, and evidence handling apply to OSINT.
Describe the components of a useful attack-surface map for a modern cloud-connected organization.
Evaluate the benefits and limitations of using AI in reconnaissance and asset discovery.
Analytical / Application Questions
An analyst finds a subdomain in a certificate log, an IP address in a historical DNS record, and a matching organization name in a public repository. Explain how the analyst should determine ownership and confidence without performing intrusive testing.
A public document reveals employee names, software versions, and an internal file path. Analyze the security relevance, privacy risks, evidence requirements, and appropriate client recommendations.
Design a passive-first reconnaissance plan for an organization that has a corporate website, a cloud-hosted API, several subsidiaries, and third-party email services. Identify scope controls, sources, validation steps, and reporting outputs.
Multiple Choice Questions with Answers
Question 1
Which activity is best classified as passive reconnaissance?
A. Testing a password against a login portal
B. Reading a publicly available security policy
C. Running a high-rate service scan
D. Submitting crafted requests to an API
Correct Answer: B. Reading a publicly available security policy
Question 2
What is the primary purpose of certificate-transparency records in reconnaissance?
A. To prove that a host is vulnerable
B. To identify potentially related hostnames and certificates
C. To reveal private encryption keys
D. To bypass web-application authentication
Correct Answer: B. To identify potentially related hostnames and certificates
Question 3
Which statement about a public repository is correct?
A. All content may be used for unauthorized access
B. Repository ownership should be validated before treating it as an in-scope asset
C. Historical commits are never relevant
D. A matching organization name proves ownership
Correct Answer: B. Repository ownership should be validated before treating it as an in-scope asset
Question 4
Which item is most important in an authorization document?
A. The tester’s preferred programming language
B. The exact scope and permitted techniques
C. A list of unrelated public websites
D. The number of search-engine results expected
Correct Answer: B. The exact scope and permitted techniques
Question 5
What does an exposure path represent?
A. A guaranteed successful attack
B. A chain connecting an external observation to a sensitive function or resource
C. A list of software licenses
D. A cryptographic key hierarchy
Correct Answer: B. A chain connecting an external observation to a sensitive function or resource
Question 6
Which practice improves the quality of reconnaissance evidence?
A. Removing collection dates
B. Treating every inference as a confirmed fact
C. Recording sources, timestamps, and confidence
D. Using only one source for all conclusions
Correct Answer: C. Recording sources, timestamps, and confidence
Question 7
Why can threat-intelligence data produce false conclusions?
A. Threat feeds never contain dates
B. IP addresses and infrastructure may be shared, reused, or historical
C. Threat intelligence cannot contain technical information
D. All listed indicators are guaranteed to be malicious
Correct Answer: B. IP addresses and infrastructure may be shared, reused, or historical
Question 8
Which information may be exposed through document metadata?
A. Only the document’s visible title
B. Author names, software versions, or internal paths
C. The organization’s private encryption key by definition
D. A guaranteed active network port
Correct Answer: B. Author names, software versions, or internal paths
Question 9
What should an analyst do after discovering a possible secret in a public repository?
A. Use it immediately to confirm access
B. Publish the secret as proof
C. Record minimal evidence, avoid authentication, and notify the designated contact
D. Delete the repository without authorization
Correct Answer: C. Record minimal evidence, avoid authentication, and notify the designated contact
Question 10
Why should AI-generated asset associations be reviewed by a human analyst?
A. AI cannot process text
B. AI may infer relationships from weak signals or incorrect data
C. AI always removes evidence sources
D. AI prevents all duplicate records automatically
Correct Answer: B. AI may infer relationships from weak signals or incorrect data
Ethical Hacking & Penetration Testing
Chapter 5
of 15