Lab 03 — Reconnaissance and Attack Surface Mapping

Welcome to:

Lab 03 — Reconnaissance and Attack Surface Mapping

In Lab 02, you converted a Bug Bounty program policy into:

Structured Scope

Exclusions

Testing Restrictions

Target Priorities

Initial Hypotheses

Research Plan

Now you are ready to answer the next question:

What Actually Exists
Inside the
Authorized Scope?

Your mission in this lab is to transform:

Authorized Scope

into:

Validated

Classified

Prioritized

Attack Surface

You will work through:

Domain Discovery
      ↓
Subdomain Discovery
      ↓
DNS Validation
      ↓
HTTP Validation
      ↓
Application Classification
      ↓
Technology Mapping
      ↓
API Discovery
      ↓
JavaScript Analysis
      ↓
Cloud Signal Analysis
      ↓
Third-Party Separation
      ↓
Attack Surface Mapping
      ↓
Prioritization

Mission Information

Your Role

You are operating as a:

Bug Bounty Hunter

Security Researcher

continuing research against the fictional:

NovaCloud Security Research Program

From the previous lab, the primary authorized scope includes:

www.novacloud.test

app.novacloud.test

api.novacloud.test

*.labs.novacloud.test

NovaCloud Android Application

NovaCloud iOS Application

Your task is to discover and organize the attack surface without performing vulnerability exploitation.

Mission Objective

By the end of this lab, you should be able to answer:

Which Hosts Exist?

Which Hosts Resolve?

Which Hosts Serve HTTP?

Which Applications Exist?

Which APIs Exist?

Which Technologies Are Used?

Which Assets Look Cloud-Connected?

Which Services Are Third Party?

Which Targets Deserve
Deeper Testing?

Lab Objectives

By completing this lab, you will learn how to:

perform scope-aware reconnaissance.
distinguish passive and active reconnaissance.
collect candidate subdomains.
normalize discovered assets.
detect duplicate assets.
validate DNS records.
understand A, AAAA and CNAME records.
identify wildcard DNS.
validate HTTP and HTTPS services.
record status codes and redirects.
capture page titles.
classify applications.
identify authentication portals.
identify administrative interfaces.
identify APIs.
inspect JavaScript for endpoint references.
identify GraphQL and REST routes.
recognize cloud-service signals.
separate organizational assets from third parties.
identify potentially legacy assets.
create an attack-surface inventory.
cluster related applications.
prioritize targets.
convert reconnaissance findings into security hypotheses.

Prerequisites

You should have completed:

Lab 01
Build Your Professional
Bug Bounty Research Environment

Lab 02
Bug Bounty Program
Scope Analysis and
Target Prioritization

You should also understand:

DNS

HTTP

Subdomains

APIs

JavaScript

Basic Command Line

Bug Bounty Scope

Lab Deliverables

By the end of this lab, create:

01 Recon_Plan.md

02 Subdomain_Inventory.csv

03 DNS_Inventory.csv

04 HTTP_Assets.csv

05 Technology_Inventory.csv

06 JavaScript_Inventory.csv

07 API_Candidates.csv

08 Cloud_Asset_Register.csv

09 Third_Party_Register.csv

10 Attack_Surface_Map.md

11 Asset_Prioritization.csv

12 Recon_Hypotheses.csv

13 Recon_Summary.md

Part 1 — Review Scope Before Recon

Before running any reconnaissance, reopen:

Scope_Register.csv

Exclusion_Register.csv

Testing_Restrictions.md

Confirm:

Authorized Domains

Wildcard Rules

Excluded Assets

Third-Party Restrictions

Automation Limits

For NovaCloud:

Maximum Automated Rate:
10 Requests per Second

Your recon workflow must remain within that limit.

Part 2 — Create the Recon Plan

Create:

01 Recon_Plan.md

Use:

# Reconnaissance Plan

## Program

NovaCloud Security Research Program

## Objective

Discover, validate and classify
the authorized attack surface.

## In-Scope Assets

- www.novacloud.test
- app.novacloud.test
- api.novacloud.test
- *.labs.novacloud.test

## Exclusions

- support.novacloud.test
- status.novacloud.test
- careers.novacloud.test
- third-party analytics
- third-party payment providers
- customer-controlled integrations

## Recon Phases

1. Candidate asset collection
2. Normalization
3. DNS validation
4. HTTP validation
5. Technology classification
6. JavaScript analysis
7. API mapping
8. Cloud signal analysis
9. Third-party separation
10. Prioritization

## Safety Controls

- scope filter required
- maximum 10 requests per second
- low concurrency
- no exploitation
- no password attacks
- no customer data access

## Expected Deliverables

- subdomain inventory
- DNS inventory
- HTTP inventory
- application map
- API candidates
- cloud assets
- target priorities

Part 3 — Understand Passive Reconnaissance

Passive reconnaissance uses information already available without aggressively interacting with the target.

Potential sources include:

Certificate Data

Public DNS

Historical URLs

Public Documentation

Application References

The objective is:

Candidate
Asset Collection

not validation yet.

Part 4 — Understand Active Reconnaissance

Active reconnaissance interacts directly with authorized systems.

Examples:

DNS Resolution

HTTP Requests

Title Collection

Header Inspection

Active recon should occur only:

After Scope Validation

Part 5 — Start with Known Assets

Your known starting assets are:

www.novacloud.test

app.novacloud.test

api.novacloud.test

Add them immediately to:

02 Subdomain_Inventory.csv

Use:

Hostname	Source	Scope	Status	Notes

Example:

Part 6 — Discover Candidate Lab Subdomains

The wildcard:

*.labs.novacloud.test

may contain training hosts.

In the lab environment, assume your discovery process identifies:

auth.labs.novacloud.test

files.labs.novacloud.test

legacy.labs.novacloud.test

api-v1.labs.novacloud.test

graphql.labs.novacloud.test

admin.labs.novacloud.test

static.labs.novacloud.test

Record them as:

Candidate

until validated.

Part 7 — Candidate Does Not Mean Live

Your inventory may now look like:

Candidate Asset
      ↓
Needs Validation

Do not assume:

Discovered
      =
Live

Part 8 — Normalize Hostnames

Normalize:

AUTH.LABS.NOVACLOUD.TEST

auth.labs.novacloud.test.

https://auth.labs.novacloud.test/

into the hostname:

auth.labs.novacloud.test

Normalization improves:

Deduplication

Comparison

Inventory Quality

Part 9 — Deduplicate Assets

If the same host appears from:

Certificate Source

Historical Source

Application JavaScript

store:

One Asset

but preserve:

Multiple Sources

Example:

Hostname	Sources
api.novacloud.test	Scope; JavaScript; Historical

Part 10 — Preserve Provenance

Do not record only:

api-v1.labs.novacloud.test

Record:

Source:
Historical API reference

This helps determine:

Confidence

Age

Research Relevance

Part 11 — DNS Validation

Now validate candidate hostnames through DNS.

For each host record:

A Record

AAAA Record

CNAME

Resolution Status

Create:

03 DNS_Inventory.csv

with:

Hostname	A/AAAA	CNAME	Status	Notes

Part 12 — Example DNS Results

Assume:

app.novacloud.test
      ↓
192.0.2.20

api.novacloud.test
      ↓
192.0.2.30

files.labs.novacloud.test
      ↓
storage.novacloud-cloud.test

legacy.labs.novacloud.test
      ↓
192.0.2.40

Record them.

Part 13 — Understand A Records

An A record maps:

Hostname
      ↓
IPv4 Address

It helps identify:

Where
the Host Resolves

but not necessarily:

Who Owns
the Entire IP Range

Part 14 — Understand CNAME Records

A CNAME may reveal relationships such as:

files.labs.novacloud.test
      ↓
cloud-storage-service.test

This may indicate:

Cloud Storage

CDN

SaaS Platform

but does not automatically authorize testing of the destination service.

Part 15 — Identify Wildcard DNS

Generate a clearly nonexistent training hostname such as:

random-8f3d2.labs.novacloud.test

Check whether it resolves.

If:

random-8f3d2.labs.novacloud.test

random-99ac7.labs.novacloud.test

both resolve identically, record:

Possible Wildcard DNS

Part 16 — Why Wildcard Detection Matters

Without wildcard detection you might believe:

Every Random Name
Is a Real Subdomain

leading to:

False Assets

Duplicate Work

Recon Noise

Part 17 — Mark Resolution Status

Use:

Resolved

Unresolved

Wildcard

Unknown

Do not delete unresolved hosts immediately.

Historical context may still matter later.

Part 18 — HTTP Validation

For each resolved authorized host, determine:

HTTP?

HTTPS?

Redirect?

Authentication?

Application?

Create:

04 HTTP_Assets.csv

with:

URL	Status	Title	Redirect	Type	Notes

Part 19 — Example HTTP Results

Assume:

URL	Status	Title
www.novacloud.test	200	NovaCloud
app.novacloud.test	200	NovaCloud Workspace
api.novacloud.test	401	NovaCloud API
auth.labs.novacloud.test	200	NovaCloud Identity
admin.labs.novacloud.test	403	Administration
legacy.labs.novacloud.test	200	NovaCloud Legacy Portal
static.labs.novacloud.test	200	Static Assets

Part 20 — Do Not Ignore 401

A response such as:

401 Unauthorized

may identify:

Protected API

Authentication Gateway

Management Interface

It may still be high-value attack surface.

Part 21 — Do Not Ignore 403

Likewise:

403 Forbidden

may reveal:

Restricted
Administrative
Surface

Do not attempt access-control bypasses in this recon lab.

Simply record the asset.

Part 22 — Capture Redirects

Example:

login.novacloud.test
      ↓
302
      ↓
auth.labs.novacloud.test

Record:

Original Host

Final Destination

Relationship

Part 23 — Page Title Analysis

Titles help classify hosts.

Examples:

NovaCloud Workspace
      ↓
Main Application

NovaCloud Identity
      ↓
Authentication

Administration
      ↓
Admin

API Documentation
      ↓
Developer/API Surface

Part 24 — Classify HTTP Assets

Use:

Main Application

Authentication

API

Admin

Files

Static

Developer

Legacy

Unknown

Part 25 — Identify High-Value Application Types

High-interest application types may include:

Authentication

API

Administration

File Management

Developer Portal

Legacy Application

because they often expose:

Security Boundaries

Part 26 — Technology Fingerprinting

Next, determine useful technology context.

Possible signals include:

HTTP Headers

HTML

JavaScript

Cookies

DNS CNAMEs

Error Pages

Part 27 — Create Technology Inventory

Create:

05 Technology_Inventory.csv

with:

Asset	Technology	Evidence	Confidence	Notes

Example:

Part 28 — Do Not Treat Technology as Vulnerability

Finding:

React

Nginx

Node.js

CloudFront

does not prove:

Vulnerability

Technology provides:

Context

for later hypothesis development.

Part 29 — Record Confidence

Use:

High

Medium

Low

Example:

Technology:
Cloud CDN

Evidence:
CNAME

Confidence:
High

Part 30 — Identify Authentication Surface

From recon you may discover:

auth.labs.novacloud.test

Record features such as:

Login

MFA

Password Reset

SSO

if visible through normal navigation.

Do not test them yet.

Part 31 — Authentication Surface Register

Add observations such as:

Asset:
auth.labs.novacloud.test

Function:
Identity

Features:
Login
Password Reset

Priority:
High

Part 32 — Identify API Surface

Look for:

api.novacloud.test

/api/

graphql

developer documentation

Record each candidate.

Part 33 — Create API Candidate Register

Create:

07 API_Candidates.csv

with:

Host	Endpoint	Type	Source	Auth	Status

Part 34 — Example API Candidates

Assume application traffic reveals:

/api/v2/profile

/api/v2/projects

/api/v2/files

/api/v2/invitations

/graphql

Record them.

Part 35 — API Candidate Is Not a Vulnerability

At this stage:

Endpoint Discovered
      ↓
Map It

Do not automatically:

Modify IDs

Call Admin Actions

Exploit Parameters

That comes in later testing labs.

Part 36 — Identify API Versions

Suppose you discover:

/api/v1/

and

/api/v2/

This is useful because:

Legacy Version

vs

Current Version

may later warrant comparison.

Part 37 — Record API Relationships

Example:

app.novacloud.test
      ↓
uses
api.novacloud.test

and:

mobile application
      ↓
uses
api.novacloud.test

These relationships matter later.

Part 38 — JavaScript Reconnaissance

Modern web applications often expose important architecture through JavaScript.

Collect application JavaScript files from:

Authorized
Applications

Create:

06 JavaScript_Inventory.csv

with:

Application	Script	Hash	First Seen	Notes

Part 39 — Why JavaScript Matters

JavaScript may contain references to:

API Endpoints

Feature Flags

Cloud Storage

WebSocket URLs

GraphQL

Internal Route Names

Part 40 — Example JavaScript Findings

Assume you find references to:

/api/v2/files

/api/v2/share

/graphql

/ws/notifications

/files/presign

/admin/export

Record each as:

Candidate
Endpoint

Part 41 — Hidden Does Not Mean Vulnerable

A string such as:

/admin/export

inside JavaScript does not mean:

Normal Users
Can Access It

It simply creates a later authorization hypothesis.

Part 42 — JavaScript Hashing

Record a hash for major scripts.

Example:

app.js
      ↓
HASH-A

Later:

HASH-B

means:

Application
Changed

This will support future change-based hunting.

Part 43 — Identify WebSocket Surface

Suppose JavaScript references:

wss://api.novacloud.test/ws/notifications

Record:

WebSocket Endpoint

and its likely purpose:

Notifications

No security testing is required yet.

Part 44 — Identify GraphQL

Suppose:

graphql.labs.novacloud.test

or:

/graphql

is found.

Record:

GraphQL API

for later testing.

Part 45 — Cloud Signal Analysis

Cloud-related indicators may appear through:

DNS CNAME

JavaScript

Storage URLs

API Responses

Headers

Part 46 — Create Cloud Asset Register

Create:

08 Cloud_Asset_Register.csv

with:

Asset	Provider/Type	Signal	Scope	Notes

Part 47 — Example Cloud Signals

Assume you observe:

files.novacloud.test
      ↓
Object Storage

assets.novacloud.test
      ↓
CDN

functions.labs.novacloud.test
      ↓
Serverless

Record the relationship.

Part 48 — Do Not Expand Cloud Scope Automatically

If:

files.novacloud.test

points to:

storage.provider.test

do not automatically test:

storage.provider.test

as a separate target.

First classify:

Target-Controlled Alias

Third-Party Service

Unknown

Part 49 — Identify Signed URL Functionality

Suppose application JavaScript references:

/files/presign

This creates a future hypothesis around:

File Authorization

Signed URLs

Object Ownership

But do not test it yet.

Part 50 — Identify Third-Party Services

Modern applications commonly load:

Analytics

Support

Payments

Authentication

Monitoring

CDN

Create:

09 Third_Party_Register.csv

with:

Service	Domain	Purpose	Scope	Action

Part 51 — Example Third-Party Classification

Service	Purpose	Scope	Action
analytics.vendor.test	Analytics	Out of Scope	Exclude
payment.vendor.test	Payments	Out of Scope	Exclude
support.vendor.test	Support	Out of Scope	Exclude

Part 52 — Why Third-Party Separation Matters

Without separation, recon tools may:

Follow Links

Collect URLs

Send Requests

to systems outside authorization.

Your workflow should prevent this.

Part 53 — Identify Legacy Assets

The discovered:

legacy.labs.novacloud.test

may be particularly interesting because it represents:

Older Application

Record:

Legacy

as a classification.

Do not assume:

Legacy
      =
Vulnerable

Part 54 — Legacy Security Questions

Later hypotheses may include:

Does Legacy API
Use Different
Authorization?

Does It Support
Older Authentication?

Does It Expose
Removed Features?

Part 55 — Identify Administrative Surface

The host:

admin.labs.novacloud.test

returns:

Record:

Admin Interface

Restricted

High Security Relevance

Do not attempt bypasses during recon.

Part 56 — Identify File Surface

The product’s core business includes:

Cloud File Storage

Therefore assets and endpoints involving:

files

upload

download

share

presign

deserve increased priority.

Part 57 — Business Context Meets Recon

Recon alone tells you:

files.labs.novacloud.test

Business context tells you:

Private File Storage
      =
High-Value
Security Boundary

Part 58 — Build Asset Relationships

Create relationships such as:

app.novacloud.test
      ↓ uses
api.novacloud.test

app.novacloud.test
      ↓ redirects authentication to
auth.labs.novacloud.test

api.novacloud.test
      ↓ serves
file workflows

files.labs.novacloud.test
      ↓ maps to
cloud storage

Part 59 — Create Attack Surface Map

Create:

10 Attack_Surface_Map.md

Example:

NovaCloud
│
├── Public Web
│   └── www.novacloud.test
│
├── Main Application
│   └── app.novacloud.test
│       ├── Authentication
│       ├── Projects
│       ├── Files
│       ├── Sharing
│       └── Organizations
│
├── APIs
│   ├── api.novacloud.test
│   ├── /api/v1/
│   ├── /api/v2/
│   └── /graphql
│
├── Identity
│   └── auth.labs.novacloud.test
│
├── Administrative
│   └── admin.labs.novacloud.test
│
├── Legacy
│   └── legacy.labs.novacloud.test
│
├── File Infrastructure
│   └── files.labs.novacloud.test
│
└── Third Parties
    ├── Analytics
    ├── Payments
    └── Support

Part 60 — Create Asset Clusters

Group related assets.

Identity Cluster

auth.labs.novacloud.test

login functionality

password reset

Application Cluster

app.novacloud.test

api.novacloud.test

File Cluster

files.labs.novacloud.test

/files/presign

/api/v2/files

Legacy Cluster

legacy.labs.novacloud.test

/api/v1/

Part 61 — Why Clustering Matters

Clustering helps identify:

Shared Trust

Shared Authentication

Shared Objects

Shared Business Logic

and reduces random testing.

Part 62 — Prioritize Assets

Create:

11 Asset_Prioritization.csv

with:

Asset	Function	Auth	Sensitive Data	Complexity	Priority
app.novacloud.test	Main app	High	High	High	P1
api.novacloud.test	API	High	High	High	P1
auth.labs.novacloud.test	Identity	High	High	Medium	P1
files.labs.novacloud.test	Files	High	High	Medium	P1
legacy.labs.novacloud.test	Legacy	Medium	Medium	High	P2
graphql.labs.novacloud.test	API	High	High	High	P2
admin.labs.novacloud.test	Admin	High	High	High	P2
www.novacloud.test	Marketing	Low	Low	Low	P3

Part 63 — Why Identity Is P1

Authentication controls:

Who Becomes
Which User

Weaknesses here may affect:

Account Security

Session Security

Recovery

Part 64 — Why Files Are P1

NovaCloud’s core function is:

Private
File Storage

Potential boundaries include:

User A
      ↓
User B

Tenant A
      ↓
Tenant B

Private
      ↓
Shared

Part 65 — Why API Is P1

The API likely controls:

Objects

Roles

Files

Projects

Sharing

and represents the primary:

Server-Side
Authorization Layer

Part 66 — Why Legacy Is P2

Legacy systems may contain:

Older Architecture

Old API Versions

Different Controls

but the main application remains the highest-value starting point.

Part 67 — Prioritize Features

Inside the main app, rank:

Feature	Priority
Authentication	P1
Files	P1
Sharing	P1
Organizations	P1
Projects	P1
Billing	P2
Search	P2
Static content	P3

Part 68 — Convert Recon into Hypotheses

Now turn observations into:

Security Questions

Create:

12 Recon_Hypotheses.csv

Part 69 — Hypothesis 1

Observation:

/files/presign

Hypothesis:

A user may be able
to request a signed URL
for another user's file
if object ownership is not
validated server-side.

Priority:

High

Part 70 — Hypothesis 2

Observation:

/api/v1/
and
/api/v2/

Hypothesis:

Authorization controls
may differ between
legacy API v1
and current API v2.

Part 71 — Hypothesis 3

Observation:

admin.labs.novacloud.test

Hypothesis:

Administrative API
functions may rely on
frontend visibility
rather than server-side
role enforcement.

Part 72 — Hypothesis 4

Observation:

/graphql

Hypothesis:

GraphQL object or field
authorization may expose
data not available through
the normal interface.

Part 73 — Hypothesis 5

Observation:

auth.labs.novacloud.test

Hypothesis:

Authentication state
or password recovery
may contain weaker controls
than the primary login flow.

Part 74 — Hypothesis 6

Observation:

files + share endpoints

Hypothesis:

Revoked file-sharing links
may remain usable after
access is removed.

Part 75 — Hypothesis 7

Observation:

WebSocket notifications

Hypothesis:

Users may be able to
subscribe to notification
channels belonging to
another account or tenant.

Part 76 — Hypothesis 8

Observation:

legacy.labs.novacloud.test

Hypothesis:

Legacy workflows may expose
features no longer visible
in the current application.

Part 77 — Hypothesis Quality

Avoid:

Test GraphQL

Prefer:

A standard user may
be able to query fields
belonging to another user
if object authorization
is not enforced at the
resolver layer.

Part 78 — Create the Initial Research Queue

Your highest-priority follow-up queue may be:

1. Main application mapping

2. API object mapping

3. Authentication flow mapping

4. File workflow mapping

5. Sharing workflow mapping

6. Organization and tenant mapping

7. Legacy API comparison

8. GraphQL mapping

Part 79 — Recon Does Not End Here

Reconnaissance should continue as you use the application.

You may discover new assets through:

Authenticated Features

API Responses

JavaScript Changes

Mobile Application

Cloud Integrations

Part 80 — Record First Seen

For every asset record:

First Seen

Later this enables:

Change-Based Recon

Part 81 — Record Last Seen

Also maintain:

Last Seen

so you can identify:

Removed Assets

Inactive Assets

Changed Infrastructure

Part 82 — Create Recon Summary

Create:

13 Recon_Summary.md

Use:

# Reconnaissance Summary

## Program

NovaCloud Security Research Program

## Recon Objective

Identify and classify the
authorized external attack surface.

## Key Assets Identified

### P1

- app.novacloud.test
- api.novacloud.test
- auth.labs.novacloud.test
- files.labs.novacloud.test

### P2

- legacy.labs.novacloud.test
- graphql.labs.novacloud.test
- admin.labs.novacloud.test

### P3

- www.novacloud.test
- static.labs.novacloud.test

## Key Attack Surfaces

- authentication
- APIs
- private files
- sharing
- organizations
- GraphQL
- legacy APIs
- administrative functions

## Cloud Signals

- file storage service
- CDN/static infrastructure

## Third Parties

- analytics
- payment provider
- support provider

These services are excluded
from active testing.

## Highest-Priority Research Questions

1. Is object authorization enforced
   for files and projects?

2. Are tenant boundaries enforced?

3. Are signed file URLs generated
   only after authorization?

4. Are legacy and current API
   authorization controls consistent?

5. Are administrative functions
   protected server-side?

6. Does authentication state remain
   secure across login, reset and logout?

## Next Research Phase

Application and API mapping.

Part 83 — Common Recon Mistake: Collect Everything

Avoid:

Millions of URLs

Thousands of Screenshots

Huge Raw Output

without:

Classification

Context

Priority

Part 84 — Common Recon Mistake: Ignore Scope During Discovery

Discovery may reveal:

vendor.test

Do not continue testing because:

The Target
Uses It

Part 85 — Common Recon Mistake: Assume Subdomain Names

A host named:

internal.labs.novacloud.test

does not prove:

Internal Network

It is simply a name.

Validate actual behavior.

Part 86 — Common Recon Mistake: Ignore 401 and 403

Protected services can be:

Very Important
Attack Surface

even though recon cannot access them directly.

Part 87 — Common Recon Mistake: Technology Hunting

Do not spend hours determining exact software versions if it does not help answer:

What Should
I Test?

Part 88 — Common Recon Mistake: Scan Entire IP Range

If:

app.novacloud.test

resolves into a cloud-provider IP, do not scan:

Entire Provider Range

Part 89 — Common Recon Mistake: Treat API Discovery as Exploitation

Finding:

/api/admin/export

means:

Create Hypothesis

not:

Execute
Immediately

Part 90 — Common Recon Mistake: Ignore Business Context

A host called:

files.novacloud.test

is particularly important because NovaCloud’s business includes:

Private
Cloud File Storage

Recon should connect:

Technical Asset
      +
Business Function

Part 91 — Common Recon Mistake: No Relationship Mapping

Do not store assets as disconnected lines.

Instead map:

Application
      ↓
API
      ↓
Identity
      ↓
File Service
      ↓
Cloud Storage

Part 92 — Recon Quality Checklist

Before finishing the lab, confirm:

Scope Checked

Candidates Normalized

Duplicates Removed

DNS Validated

Wildcard DNS Considered

HTTP Validated

Redirects Recorded

Titles Recorded

Technologies Classified

APIs Identified

JavaScript Reviewed

Cloud Signals Recorded

Third Parties Separated

Assets Prioritized

Hypotheses Created

Part 93 — Lab Success Criteria

You have successfully completed this lab when you can explain:

What Exists

What Resolves

What Is Live

What Each Asset Does

How Assets Relate

Which Assets Are Third Party

Which Assets Are High Priority

What Security Questions
Should Be Tested Next

Portfolio Deliverables

Keep:

01 Recon_Plan.md

02 Subdomain_Inventory.csv

03 DNS_Inventory.csv

04 HTTP_Assets.csv

05 Technology_Inventory.csv

06 JavaScript_Inventory.csv

07 API_Candidates.csv

08 Cloud_Asset_Register.csv

09 Third_Party_Register.csv

10 Attack_Surface_Map.md

11 Asset_Prioritization.csv

12 Recon_Hypotheses.csv

13 Recon_Summary.md

Portfolio Structure

Lab 03 — Reconnaissance and Attack Surface Mapping
│
├── Recon Plan
├── Subdomain Inventory
├── DNS Inventory
├── HTTP Asset Register
├── Technology Inventory
├── JavaScript Inventory
├── API Candidates
├── Cloud Asset Register
├── Third-Party Register
├── Attack Surface Map
├── Asset Prioritization
├── Recon Hypotheses
└── Recon Summary

Knowledge Check

What is the purpose of reconnaissance?
Why must scope be reviewed before recon begins?
What is passive reconnaissance?
What is active reconnaissance?
What is a candidate asset?
Why should assets be normalized?
Why is deduplication important?
What is data provenance?
What is DNS validation?
What is an A record?
What is a CNAME?
What is wildcard DNS?
Why should unresolved assets sometimes be retained?
What is HTTP validation?
Why should 401 responses not be ignored?
Why should 403 responses not be ignored?
Why are redirects useful?
What can page titles reveal?
What is technology fingerprinting?
Why is technology not automatically a vulnerability?
Why is confidence useful when identifying technology?
Why are authentication systems high-value attack surfaces?
How can APIs be discovered?
Why should API versions be recorded?
What can JavaScript reveal?
Why should JavaScript files be hashed?
What is a WebSocket?
What is GraphQL?
What are cloud signals?
Why should cloud-provider infrastructure not automatically be tested?
What is a third-party asset?
Why are third-party services separated from the attack surface?
Why can legacy systems be interesting?
Why does legacy not automatically mean vulnerable?
Why are file services important in NovaCloud?
What is asset relationship mapping?
What is an attack-surface map?
What is application clustering?
Why is asset prioritization important?
Why is research priority different from vulnerability severity?
Why is business context useful during recon?
What is a reconnaissance hypothesis?
Why should recon create hypotheses?
Why should first-seen timestamps be recorded?
Why should last-seen timestamps be recorded?
Why should huge recon datasets be avoided?
Why should IP ranges not be scanned blindly?
Why should endpoint discovery remain separate from exploitation?
What should a recon summary contain?
What defines successful attack-surface mapping?

Key Takeaways

Reconnaissance is not:

Find
Maximum Number
of Assets

It is:

Discover
      ↓
Validate
      ↓
Understand
      ↓
Classify
      ↓
Prioritize

Remember:

Discovered
      ≠
Live

Live
      ≠
Interesting

Interesting
      ≠
Vulnerable

Cloud Hosted
      ≠
Cloud Vulnerability

Related Service
      ≠
Authorized Target

Hidden Endpoint
      ≠
Authorization Failure

A professional reconnaissance workflow produces:

Scope
      ↓
Assets
      ↓
DNS
      ↓
HTTP
      ↓
Technology
      ↓
Applications
      ↓
APIs
      ↓
Cloud
      ↓
Relationships
      ↓
Priority
      ↓
Hypotheses

The objective is:

Attack Surface
Intelligence

not:

Recon Noise

Career Connection

Reconnaissance and attack-surface mapping are important for:

Bug Bounty Hunters

Security Researchers

Penetration Testers

Red Teamers

Application Security Engineers

Attack Surface Management Analysts

During an interview, you should be able to explain:

I begin reconnaissance
with the authorized scope
rather than with discovery tools.

Candidate assets are collected,
normalized, deduplicated and
validated through DNS before
I interact with them over HTTP.

For live assets, I capture
application type, redirects,
technology context and business
function.

I then map APIs, JavaScript
references, cloud relationships
and third-party dependencies.

Rather than treating every asset
equally, I cluster related systems
and prioritize them according to
authentication, sensitive data,
security boundaries and business
importance.

The output of reconnaissance is
not a vulnerability list.

It is a validated attack-surface
map and a prioritized set of
security hypotheses for deeper
manual testing.

What’s Next?

➡️ Next: Lab 04 — Web Application Mapping and Security Boundary Analysis

You now have:

Validated Assets

HTTP Applications

API Candidates

Technology Context

Cloud Signals

Third-Party Boundaries

Research Priorities

The next step is to move inside the highest-priority application and understand:

How It Actually Works

In the next lab, you will map:

Registration

Login

Sessions

User Roles

Application Features

Objects

Files

Projects

Sharing

Organizations

Business Workflows

HTTP Requests

API Calls

Security Boundaries

You will build:

Application Map

User Journey

Feature Inventory

Object Register

Role Matrix

Request Register

Security Boundary Map

Authorization Matrix

Initial Testing Hypotheses

You will move from:

I Know
What Assets Exist

to:

I Understand

How the Application Works

Who Can Do What

Which Objects Exist

and

Where Security Controls
Must Be Enforced

➡️ Next: Lab 04 — Web Application Mapping and Security Boundary Analysis