Lab 02 Passive Reconnaissance & OSINT

Mission Overview

Welcome to Lab 02 — Passive Reconnaissance & OSINT.

In Lab 01, you built a controlled ethical hacking environment and established the most important rule of professional security testing:

Know your scope before you test anything.

Now we begin the first operational phase of a penetration test: reconnaissance.

Before scanners, vulnerability assessments, or active enumeration begin, a penetration tester needs to understand the target’s externally visible footprint.

In this lab, you will learn how to collect and analyze publicly available information about an authorized training organization or domain without intentionally probing its infrastructure.

Mission Goal: Build an External Attack Surface Profile using passive OSINT techniques while documenting sources, confidence levels, security relevance, and potential investigation paths.

Mission Information

Item	Details
Difficulty	Beginner
Estimated Time	60–90 minutes
Primary Skill	Passive Reconnaissance
Secondary Skill	OSINT Analysis
Environment	Browser + Kali/Linux
Testing Type	Passive
Primary Outcome	External Attack Surface Profile
Evidence Required	Notes + screenshots + OSINT inventory
Safety Level	Authorized / Public Information Only

Learning Objectives

By completing this lab, you will be able to:

• explain passive reconnaissance

• distinguish passive from active reconnaissance

• define an OSINT collection objective

• investigate authorized domains

• identify publicly visible organizational information

• understand domain-registration information

• examine DNS information from passive sources

• identify possible subdomains from historical/public datasets

• investigate certificate-transparency information

• identify publicly exposed technologies

• examine historical website information

• search public code and documentation safely

• identify possible information leakage

• classify OSINT findings

• build an External Attack Surface Profile

• document evidence professionally

• determine what should be validated during later authorized testing

What Is Reconnaissance?

Reconnaissance is the process of collecting information about a target before deeper security testing.

Conceptually:

Target
   ↓
Information Collection
   ↓
Infrastructure Understanding
   ↓
Attack Surface
   ↓
Potential Investigation Paths

Good reconnaissance reduces guesswork.

Instead of blindly testing systems, you begin understanding:

• what the organization exposes

• which technologies may exist

• which domains may belong to it

• what services employees use

• what information is publicly available

• where security exposure may exist

Passive vs Active Reconnaissance

Understanding this distinction is essential.

Passive Reconnaissance

Information is obtained primarily from existing public or third-party sources rather than intentionally connecting to and probing target services.

Examples include:

• search engines

• public websites

• certificate-transparency datasets

• domain-registration information

• public DNS datasets

• archived websites

• public documentation

• public source-code repositories

• public job advertisements

Conceptually:

Researcher
     ↓
Public / Third-Party Sources
     ↓
Information About Target

Active Reconnaissance

The tester intentionally interacts with target infrastructure.

Examples include:

• host discovery

• port scanning

• direct service enumeration

• application crawling

• vulnerability scanning

Tester
   ↓
Target Infrastructure
   ↓
Response

Active reconnaissance comes later in this lab series.

Part 1 — Define Your Scope

Before collecting anything, define your target.

For Academy practice, use one of the following:

• a fictional organization supplied with the lab

• a domain you own

• a dedicated training environment

• another target for which you have explicit authorization

Create:

Lab-02-Scope.md

Record:

Organization:

Authorized Domain:

Assessment Purpose:

Start Date:

Authorized Information Sources:

Excluded Systems:

Notes:

Do not expand the assessment merely because you discover another organization, supplier, employee account, cloud service, or domain.

Discovery does not automatically create authorization.

Part 2 — Define the Intelligence Questions

Professional reconnaissance should answer questions rather than collect random data.

For this mission, investigate:

1. What domains are associated with the organization?

2. What subdomains may exist?

3. What public infrastructure information exists?

4. Which technologies appear to be used?

5. What cloud or SaaS platforms appear relevant?

6. What public documentation exists?

7. What historical information is available?

8. Is potentially sensitive information publicly exposed?

9. Which findings should be validated later?

10. What does the external attack surface appear to contain?

These become your intelligence requirements.

Part 3 — Create Your OSINT Workspace

Inside your lab documentation structure, create:

Ethical-Hacking-Labs/
└── Lab-02/
    ├── Notes/
    ├── Evidence/
    │   ├── Domains/
    │   ├── DNS/
    │   ├── Certificates/
    │   ├── Technologies/
    │   └── Historical/
    ├── Screenshots/
    ├── Findings/
    └── Report/

Create an investigation journal:

Lab-02-Investigation-Journal.md

Use:

# Lab 02 — Passive Reconnaissance & OSINT

## Target

## Scope

## Intelligence Questions

## Sources Used

## Observations

## Potential Assets

## Technologies

## Potential Exposure

## Evidence

## Confidence

## Items Requiring Validation

## Lessons Learned

Part 4 — Establish a Known Baseline

Start with information you already know from the authorized scope.

Record:

Item	Value
Organization
Primary Domain
Known Website
Known Subdomains
Known Technology
Assessment Date

This becomes your baseline.

Everything discovered afterward should be distinguished from information that was already known.

Part 5 — Search Engine Reconnaissance

Search engines can reveal a surprising amount of information that organizations intentionally or unintentionally expose.

Start with simple searches for the authorized organization and domain.

Look for:

• official website pages

• documentation

• support portals

• public files

• developer documentation

• login portals

• historical references

• technical information

Do not interact with accounts or attempt authentication.

Your objective is discovery and documentation.

Part 6 — Use Focused Search Queries

Search operators can help narrow public results.

For an authorized training domain, conceptually:

site:example.test

You might also investigate whether indexed public documents exist:

site:example.test filetype:pdf

or:

site:example.test filetype:docx

The objective is to identify publicly indexed material.

Do not use discovered information to access resources outside your authorization.

Part 7 — Document Search Findings

Create a table:

Source	Observation	Security Relevance	Confidence
Search Engine	Public documentation	Technology information	High
Search Engine	Login page reference	Possible external service	Medium
Public PDF	Product information	Infrastructure context	Medium

Use confidence ratings such as:

High — strongly supported.

Medium — plausible but requires validation.

Low — weak or ambiguous evidence.

This prevents assumptions from becoming “facts.”

Part 8 — Domain Registration Research

Domain-registration information can provide useful contextual information.

Depending on the domain and privacy controls, you may find:

• registrar

• registration dates

• expiration dates

• nameservers

• domain status

• DNSSEC information

Modern privacy protections often hide registrant details.

That is normal.

Do not treat unavailable personal information as something you need to circumvent.

Part 9 — Understand WHOIS and RDAP

Traditional domain research frequently uses WHOIS.

Modern registration information can also be provided through RDAP — Registration Data Access Protocol.

The important learning objective is not memorizing the service.

Understand what domain-registration records can tell you.

Record:

Domain:

Registrar:

Created:

Expires:

Nameservers:

DNSSEC:

Other Relevant Information:

Source:

Date Observed:

Part 10 — Investigate Nameservers

Nameservers can provide clues about how DNS is hosted.

For example, they may suggest the organization uses:

• a cloud provider

• DNS hosting

• CDN services

• security services

Conceptually:

Domain
   ↓
Nameserver
   ↓
DNS Provider
   ↓
Infrastructure Context

Do not immediately conclude that the DNS provider hosts the organization’s application infrastructure.

That is a hypothesis requiring validation.

Part 11 — Passive DNS Research

Public and historical DNS information may reveal relationships between:

• domains

• subdomains

• IP addresses

• mail infrastructure

• hosting providers

Build a DNS inventory:

Record / Observation	Value	Source	Confidence
Domain
Nameserver
Mail Provider
Possible Subdomain
Historical Address

Historical information may no longer reflect the current environment.

Always record when the information was observed.

Part 12 — Subdomain Discovery

Organizations often use subdomains for different services.

Conceptual examples:

www.example.test

portal.example.test

support.example.test

docs.example.test

api.example.test

A subdomain may reveal:

• application purpose

• development environments

• APIs

• authentication portals

• support systems

• cloud services

For this passive lab, rely on publicly indexed and historical sources rather than direct enumeration of target infrastructure.

Part 13 — Certificate Transparency

Certificate Transparency records provide visibility into publicly issued TLS certificates.

These records can sometimes reveal hostnames associated with a domain.

Conceptually:

Organization
      ↓
Domain
      ↓
TLS Certificates
      ↓
Certificate Transparency
      ↓
Possible Hostnames

Record any relevant findings.

Example:

Hostname	Source	First/Last Seen	Confidence
portal.example.test	Certificate data	—	High
api.example.test	Certificate data	—	Medium

Remember:

A hostname appearing in historical certificate data does not prove that the service currently exists.

Part 14 — Build the Domain Map

Begin connecting your findings.

                   example.test
                        │
        ┌───────────────┼────────────────┐
        │               │                │
        ▼               ▼                ▼
       www            portal            docs
        │               │                │
        ▼               ▼                ▼
    Website        Authentication    Documentation

At this stage these relationships may still be hypotheses.

Mark them accordingly.

Part 15 — Technology Identification

Public information may reveal technologies used by an organization.

Examples might include:

• web frameworks

• CMS platforms

• analytics services

• CDNs

• cloud platforms

• identity providers

• programming languages

• development tools

Possible sources include:

• public documentation

• technology-detection services

• job advertisements

• developer documentation

• public code repositories

• archived websites

Create:

Technology	Evidence	Source	Confidence
Cloud Platform	Job advertisement	Public job listing	Medium
Framework	Public documentation	Documentation site	High
Identity Provider	Login documentation	Public support page	Medium

Part 16 — Why Technology Information Matters

Suppose public research indicates:

Cloud Platform

Web Framework

Identity Provider

Container Platform

That information can help a penetration tester understand the likely attack surface.

But avoid making the mistake:

“Organization uses Technology X, therefore Vulnerability Y exists.”

Technology identification is not vulnerability confirmation.

The correct workflow is:

Technology → Potential Exposure → Later Validation

Part 17 — Public Job Advertisements

Job descriptions can reveal useful architectural information.

For example, a public job advertisement might mention experience with:

AWS

Azure

Kubernetes

Terraform

Active Directory

Microsoft 365

SIEM

EDR

This may suggest technologies used within the environment.

However:

A technology appearing in a job advertisement does not prove it is currently deployed.

Record it as intelligence with an appropriate confidence level.

Part 18 — Public Documentation

Organizations sometimes publish:

• technical documentation

• API documentation

• integration guides

• support documentation

• architecture diagrams

• configuration guides

• migration documents

These documents can provide significant security context.

When reviewing them, ask:

• What technologies are mentioned?

• Are internal naming conventions visible?

• Are service names disclosed?

• Are environment names visible?

• Are architecture details exposed?

• Is the information still current?

Do not attempt to access restricted documents.

Part 19 — Metadata Awareness

Publicly available documents may contain metadata.

Metadata can sometimes reveal:

• document author

• software used

• creation dates

• modification dates

• organization information

For this lab, the objective is simply to understand:

Public files can reveal information beyond their visible content.

Only analyze files intentionally made public and within your authorized research scope.

Part 20 — Historical Website Research

Archived websites can reveal information that no longer appears on the current site.

Potential findings include:

• old applications

• previous domains

• retired products

• historical documentation

• older technology references

• previous organizational structures

Conceptually:

Current Website
      +
Historical Website
      =
Better Attack-Surface Context

But old information must be treated carefully.

Record:

Observation:

Approximate Date:

Historical Source:

Current Status:

Security Relevance:

Requires Validation:

Part 21 — Public Source-Code Repositories

Organizations and developers may intentionally publish source code.

Public repositories can reveal:

• application names

• programming languages

• dependencies

• configuration examples

• deployment patterns

• documentation

• infrastructure templates

For this lab, restrict yourself to publicly available repositories associated with your authorized training target.

Do not attempt to access private repositories or bypass access controls.

Part 22 — Secret Exposure Awareness

One important security risk is accidentally publishing sensitive information.

Examples may include:

• credentials

• API keys

• tokens

• private configuration

• internal hostnames

• connection information

If you encounter what appears to be a real exposed secret during an authorized assessment:

Do not attempt to use it simply to determine whether it works.

Record the exposure according to the Rules of Engagement and follow the agreed escalation procedure.

Part 23 — Public Cloud Exposure Awareness

OSINT may reveal references to:

• cloud storage

• cloud applications

• CDN endpoints

• hosted services

• identity platforms

At this stage, document the relationship.

Do not attempt to bypass permissions or access non-public data.

Think:

Public Reference
      ↓
Potential Cloud Asset
      ↓
Document
      ↓
Validate Later If Authorized

Part 24 — Email Pattern Awareness

Public organizational pages may reveal corporate email-address formats.

Conceptually:

firstname.lastname@example.test

Understanding naming conventions can help defenders assess identity exposure.

For this lab, record only the general pattern when relevant.

Avoid building unnecessary lists of individual employees or collecting personal information that is not required for the assessment.

Part 25 — Social Media and People OSINT

People can form part of an organization’s public attack surface, but this area requires restraint.

Public profiles may reveal:

• job roles

• technologies

• departments

• public projects

• organizational changes

For Academy labs, focus on organizational security relevance, not personal profiling.

Avoid collecting unnecessary:

• personal addresses

• private contact information

• family information

• personal photographs

• unrelated personal activity

Professional OSINT should be purpose-limited.

Part 26 — Identify External Services

During reconnaissance, you may discover third-party services associated with the organization.

Examples include:

Email Provider

Cloud Provider

CDN

Identity Provider

Support Platform

Source-Code Platform

Analytics Service

Create a relationship map:

                    Organization
                         │
       ┌─────────────────┼──────────────────┐
       │                 │                  │
       ▼                 ▼                  ▼
     Email             Cloud             Identity
       │                 │                  │
       ▼                 ▼                  ▼
   Provider A        Provider B         Provider C

Remember:

A third-party provider used by the target does not automatically become part of your authorized penetration-testing scope.

Part 27 — Identify Potential Attack-Surface Categories

Organize your findings into categories.

Domains

Primary domains
Related domains
Historical domains

Applications

Public website
Portal
API
Documentation

Identity

Authentication portal
Identity provider
Email pattern

Infrastructure

DNS
Hosting
Cloud
CDN

Technology

Frameworks
CMS
Cloud platform
Development tools

Information Exposure

Public documents
Metadata
Historical content
Public repositories

This becomes your External Attack Surface Profile.

Part 28 — Create an OSINT Findings Register

Use a structured table:

ID	Finding	Source	Confidence	Security Relevance	Validation
OSINT-01	Possible portal	Certificate data	Medium	External application	Required
OSINT-02	Cloud technology reference	Job listing	Medium	Architecture context	Required
OSINT-03	Public documentation	Search results	High	Technical disclosure	Review
OSINT-04	Historical hostname	Archive	Low	Possible legacy asset	Required

This is far more useful than hundreds of unorganized screenshots.

Part 29 — Correlate Findings

Now connect information from different sources.

Suppose you discover:

Certificate Data
      ↓
portal.example.test

Public Documentation
      ↓
Portal User Guide

Technology Source
      ↓
Identity Provider

Historical Website
      ↓
Previous Portal Reference

These independent sources strengthen your confidence that an external portal exists or existed.

This is OSINT correlation.

Part 30 — Separate Facts from Assumptions

Use three categories.

Confirmed

Strong evidence supports the observation.

Example:

Official documentation explicitly references the service.

Probable

Multiple pieces of evidence suggest it.

Example:

Certificate data and archived documentation reference the same hostname.

Possible

Only weak evidence exists.

Example:

An old job advertisement mentions a technology.

Never present possible as confirmed.

Part 31 — Build the External Attack Surface Map

Your final map might resemble:

                       Organization
                            │
           ┌────────────────┼─────────────────┐
           │                │                 │
           ▼                ▼                 ▼
        Domains          Identity           Cloud
           │                │                 │
     ┌─────┼─────┐          ▼                 ▼
     │     │     │       Login/SaaS       Provider
     ▼     ▼     ▼
    WWW  Portal  API
     │     │     │
     ▼     ▼     ▼
    Web   Auth   Application

This map becomes input for later active reconnaissance.

Part 32 — Prioritize What Matters

Not every OSINT finding deserves further investigation.

Classify findings as:

High Priority

Could directly influence the security assessment.

Medium Priority

Useful context requiring validation.

Low Priority

Interesting but unlikely to materially affect the assessment.

Ask:

Does this information help me understand an asset, identity, technology, trust relationship, or security exposure?

If not, it may simply be noise.

Part 33 — Create Validation Questions

For each important finding, define what should be validated later.

Example:

Finding:
Possible external portal.

Evidence:
Certificate Transparency + public documentation.

Validation Question:
Is the hostname currently part of the authorized environment?

Validation Phase:
Active Reconnaissance.

This creates a professional transition from:

Passive Reconnaissance → Active Reconnaissance

Part 34 — Evidence Requirements

Capture evidence for:

Evidence 01

Defined assessment scope.

Evidence 02

Primary-domain research.

Evidence 03

Domain-registration information.

Evidence 04

Passive DNS information.

Evidence 05

Certificate-transparency findings.

Evidence 06

Technology observations.

Evidence 07

Historical information.

Evidence 08

Public documentation or repository observations, if applicable.

Evidence 09

OSINT findings register.

Evidence 10

Final External Attack Surface Map.

For every screenshot, record:

Evidence ID:

Source:

Date:

Observation:

Security Relevance:

Part 35 — Mission Challenge

Without performing active scanning, produce answers for:

Primary Domain:

Related Domains:

Potential Subdomains:

DNS Provider:

Mail Provider:

Potential Cloud Provider:

Identity Provider:

Observed Technologies:

Public Documentation:

Historical Assets:

Potential External Applications:

Potential Information Exposure:

Highest-Priority Finding:

Items Requiring Active Validation:

Do not guess.

Use:

Confirmed

Probable

Possible

Unknown

when appropriate.

Part 36 — Mission Deliverables

Complete:

• Scope document

• Intelligence requirements

• Investigation journal

• Domain inventory

• DNS observations

• Certificate observations

• Subdomain candidates

• Technology inventory

• Historical research

• Public-documentation review

• Third-party service map

• OSINT findings register

• External Attack Surface Map

• Validation questions

• Final reconnaissance report

Lab Report Template

# Lab 02 — Passive Reconnaissance & OSINT

## Executive Summary

## Mission Objective

## Scope

## Methodology

## Intelligence Requirements

## Sources Used

## Domain Intelligence

## DNS Intelligence

## Certificate Intelligence

## Potential Subdomains

## Technology Intelligence

## Public Documentation

## Historical Information

## External Services

## Information Exposure

## OSINT Findings

## External Attack Surface

## Confidence Assessment

## Items Requiring Validation

## Security Recommendations

## Lessons Learned

## Conclusion

Knowledge Check

Question 1 — What is passive reconnaissance?

Passive reconnaissance collects information primarily through existing public or third-party sources without intentionally probing target infrastructure.

Question 2 — Why is OSINT useful during penetration testing?

It helps testers understand the target’s external footprint, technologies, assets, relationships, and potential areas requiring later validation.

Question 3 — Does a hostname in Certificate Transparency prove that the service currently exists?

No.

It demonstrates certificate-related historical or current evidence associated with that hostname, but its current operational status still requires validation.

Question 4 — Why assign confidence levels?

Because reconnaissance information can be incomplete, historical, misleading, or incorrect.

Confidence ratings prevent assumptions from being presented as facts.

Question 5 — If you discover a third-party SaaS platform, can you test it?

Not automatically.

Its relationship with the authorized target does not necessarily place the third-party service within the penetration-testing scope.

Question 6 — Why should exposed credentials or tokens not simply be tested?

Attempting to use them could exceed the authorized assessment scope and affect real systems or data. Follow the Rules of Engagement and escalation procedure.

Question 7 — What is the final objective of passive reconnaissance?

Not simply collecting information.

The goal is to produce a structured understanding of the external attack surface and the questions that should be validated next.

Skills Achieved

After completing this lab, you should understand:

• passive reconnaissance

• OSINT methodology

• intelligence requirements

• domain intelligence

• registration data

• passive DNS concepts

• certificate transparency

• passive subdomain discovery

• technology intelligence

• historical research

• public-document analysis

• information-exposure awareness

• third-party relationships

• confidence classification

• OSINT correlation

• attack-surface mapping

• evidence management

• reconnaissance reporting

Professional Takeaway

Passive reconnaissance is not about collecting the largest possible amount of information.

A professional tester turns public information into security intelligence.

The workflow is:

Scope → Question → Collect → Verify → Correlate → Classify → Map → Prioritize → Document

The important transition is from:

“I found some information about the target.”

to:

“I identified information that changes how I understand the target’s external attack surface, and I can explain how confident I am in that conclusion.”

What’s Next?

➡️ Lab 03 — Host Discovery & Network Mapping

In Lab 02, you built hypotheses from passive information.

In the next lab, we move into active reconnaissance inside the isolated GoHackersCloud lab environment.

You will begin identifying which authorized systems are actually reachable and construct a network asset map.

The methodology becomes:

Scope → Network → Discover → Verify → Inventory → Map → Document

By the end of Lab 03, you should be able to answer:

“What systems exist within my authorized assessment network, which ones are reachable, and how is the environment structured?”