Lesson 02 — Initial Access & Cloud Reconnaissance

Welcome

Every successful Cloud Red Team engagement begins with understanding the target environment.

Before testing privilege escalation, lateral movement, persistence, or detection capabilities, the Red Team must first identify the organization’s externally visible cloud footprint and determine where a realistic adversary may attempt to gain initial access.

Cloud reconnaissance is not simply scanning IP addresses.

Modern enterprises operate across:

AWS accounts
Microsoft Azure subscriptions
Google Cloud projects
Kubernetes clusters
Container registries
Serverless applications
SaaS platforms
CI/CD systems
Identity providers
Public APIs
Storage services
Custom domains

Many of these resources may not be visible through a traditional network assessment.

A professional Cloud Red Team must therefore combine business context, public information, cloud architecture knowledge, identity analysis, approved technical validation, and disciplined evidence collection to map the external attack surface.

This lesson introduces the reconnaissance and controlled initial-access phase using the GoHackersCloud Enterprise Cloud Red Team Operations Framework.

Authorization requirement: Perform reconnaissance and initial-access validation only against assets explicitly listed in the approved Rules of Engagement. Do not interact with third-party services, real user accounts, customer data, or production systems unless written authorization specifically permits it.

Learning Objectives

After completing this lesson, you will be able to:

Explain the purpose of cloud reconnaissance.
Differentiate passive and active reconnaissance.
Build an enterprise cloud attack-surface inventory.
Identify public cloud services and exposed resources.
Review cloud-related DNS and certificate information.
Identify identity and authentication entry points.
Assess public APIs and serverless endpoints.
Review exposed storage and registry surfaces.
Identify CI/CD and software supply-chain entry points.
Design safe initial-access scenarios.
Apply operational decision gates.
Document reconnaissance findings and evidence.
Map findings to realistic attack paths.

Business Scenario

CloudNova Technologies is conducting an authorized Cloud Red Team engagement for MedSecure Global.

The engagement objective is to determine whether a realistic attacker could move from the organization’s public-facing cloud footprint to a controlled test identity and then reach an approved synthetic data asset.

The Rules of Engagement permit:

Passive public-information review
DNS and certificate analysis
Review of approved public APIs
Authentication portal discovery
Limited testing of dedicated Red Team accounts
Safe validation of approved cloud endpoints
Synthetic credential and event scenarios

The Rules of Engagement prohibit:

Accessing real employee accounts
Password spraying
Denial-of-service testing
Accessing production customer information
Interacting with unapproved third parties
Exploiting production applications
Creating persistence outside the dedicated lab environment

Your first task is to map the organization’s cloud attack surface and prepare controlled initial-access scenarios for approval.

What Is Cloud Reconnaissance?

Cloud reconnaissance is the process of discovering, identifying, classifying, and documenting cloud-related assets, identities, services, trust relationships, and external entry points.

Its purpose is to answer questions such as:

Which cloud providers does the organization use?
Which applications are publicly accessible?
Which identity providers protect those applications?
Which APIs accept external requests?
Which storage services are publicly reachable?
Which container registries are visible?
Which serverless functions expose public endpoints?
Which development or CI/CD systems are Internet-facing?
Which assets appear to belong to production, development, or testing?
Which entry points are most relevant to the agreed threat model?

Reconnaissance vs Initial Access

Reconnaissance and initial access are related but distinct phases.

Reconnaissance

Reconnaissance identifies potential attack-surface elements.

Examples:

Public domains
API endpoints
Authentication portals
Cloud service hostnames
Public storage endpoints
Exposed development systems

Initial Access

Initial access validates whether an approved entry point can provide a controlled foothold.

Examples:

Using a dedicated test account
Invoking an approved test API
Accessing a deliberately exposed lab service
Validating a controlled identity misconfiguration
Using synthetic credentials supplied for the exercise

The Red Team should never move from reconnaissance to initial access automatically.

A formal decision gate must confirm that:

The asset is in scope.
The activity is permitted.
The safety controls are ready.
Evidence requirements are defined.
Stop conditions are understood.

Reconnaissance Principles

Professional cloud reconnaissance should be:

Scope Driven

Only approved assets should be investigated.

Threat Informed

Activities should align with the threat model.

Low Impact

Reconnaissance should minimize operational risk.

Evidence Based

Every important observation should be documented.

Repeatable

Another consultant should be able to follow the methodology.

Business Relevant

The objective is to identify meaningful paths to approved business assets.

Passive vs Active Reconnaissance

Passive Reconnaissance

Passive reconnaissance gathers information without directly interacting with target systems in a way that generates meaningful load or changes.

Examples:

Public DNS records
Certificate transparency information
Public documentation
Public code repositories
Search engine results
Public cloud service references
Job advertisements
Technology documentation
Public mobile or web application metadata

Active Reconnaissance

Active reconnaissance directly interacts with approved target systems.

Examples:

Requesting approved web pages
Reviewing API responses
Validating authentication endpoints
Confirming service availability
Testing approved public cloud endpoints
Inspecting response headers

Active reconnaissance requires stronger scope validation because it may generate logs, alerts, or operational impact.

GoHackersCloud Cloud Reconnaissance Workflow

Confirm Scope

↓

Review Business Context

↓

Collect Known Domains

↓

Analyze DNS & Certificates

↓

Identify Cloud Providers

↓

Discover Public Applications

↓

Identify Identity Entry Points

↓

Review APIs & Serverless Endpoints

↓

Review Storage & Registries

↓

Review CI/CD Exposure

↓

Classify Assets

↓

Prioritize Entry Points

↓

Request Initial-Access Approval

↓

Validate Controlled Scenario

↓

Document Evidence

Phase 01 — Confirm Scope Before Reconnaissance

Objective

Ensure every reconnaissance activity is tied to an approved scope item.

Review

Approved domains
Approved subdomains
Approved IP ranges
Approved cloud accounts
Approved subscriptions
Approved projects
Approved APIs
Approved authentication systems
Approved testing windows
Third-party exclusions

Scope Validation Questions

Before reviewing an asset, confirm:

Does this asset belong to the customer?
Is ownership documented?
Is it explicitly in scope?
Is the region approved?
Is a third party involved?
Is active validation permitted?
Are there operational restrictions?
Is customer approval required before proceeding?

Scope Decision

Result	Action
Confirmed in scope	Continue
Likely customer-owned but not listed	Pause and request clarification
Third-party hosted	Do not test without explicit approval
Ownership uncertain	Document and exclude
Out of scope	Stop immediately

Phase 02 — Review Business Context

Objective

Understand which external services are likely to support important business operations.

Review

Public websites
Customer portals
Partner portals
Mobile applications
APIs
Healthcare applications
Payment platforms
Employee access portals
Development portals
Support systems

Business Classification

Classify assets as:

Customer Facing
Employee Facing
Partner Facing
Administrative
Development
Testing
Security Operations
Unknown

Business Context Register

Asset	Business Function	Criticality	Owner	Environment
Customer API	Patient services	High	Application Team	Production
Developer Portal	Internal development	Medium	DevOps	Development
Test Login Portal	Red Team exercise	Low	Security Team	Test

Phase 03 — Build the Domain Inventory

Objective

Identify customer-owned domains and subdomains relevant to the cloud footprint.

Review

Primary corporate domains
Product domains
Regional domains
API domains
Authentication domains
Development domains
Support domains
Cloud-hosted domains

Common Naming Indicators

Subdomain names may indicate:

api
auth
login
sso
dev
test
stage
admin
portal
storage
cdn
registry
monitor
vpn

Names alone do not prove vulnerability.

They help prioritize classification and ownership validation.

Domain Inventory

Domain	Purpose	Environment	Cloud Indicator	Status
api.example.com	Public API	Production	API Gateway	In Scope
dev.example.com	Development portal	Development	Azure	In Scope
vendor.example.com	Third-party service	Unknown	SaaS	Excluded

Phase 04 — Analyze DNS

DNS information can reveal how enterprise services are connected.

Review

A records
AAAA records
CNAME records
MX records
TXT records
NS records
SRV records
Domain-verification records
Cloud service aliases

Cloud Indicators

DNS may reference:

Amazon CloudFront
Amazon API Gateway
Azure App Service
Azure Front Door
Google Cloud Load Balancing
Cloud Run
SaaS identity providers
Container registries
Content delivery networks

Assessment Questions

Does the hostname resolve to a known cloud service?
Is the service customer controlled?
Is the endpoint still active?
Is the hostname associated with production?
Does the record reveal a development environment?
Is the service protected by a gateway or CDN?
Is ownership confirmed?

Evidence

Capture:

DNS record
Timestamp
Source
Resolution result
Ownership status
Cloud provider indicator

Phase 05 — Review Certificate Information

TLS certificates can reveal additional approved hostnames.

Review

Subject Alternative Names
Certificate issuer
Validity period
Wildcard domains
Historical certificates
Cloud-managed certificates

Assessment Questions

Are additional subdomains visible?
Are obsolete names present?
Are development names exposed?
Does the certificate identify a cloud platform?
Are expired or unexpected certificates in use?

Certificate data should be treated as an asset-discovery signal, not proof that every hostname is currently active or in scope.

Phase 06 — Identify Cloud Provider Footprints

AWS Indicators

Examples may include:

amazonaws.com
CloudFront
API Gateway
Elastic Load Balancing
Amazon S3
Amazon Cognito
Amazon ECR
Amplify

Microsoft Azure Indicators

Examples may include:

azurewebsites.net
cloudapp.azure.com
Azure Front Door
Azure API Management
Microsoft Entra ID
Azure Storage
Azure Container Registry

Google Cloud Indicators

Examples may include:

run.app
cloudfunctions.net
appspot.com
Google API Gateway
Cloud Storage
Artifact Registry
Identity-Aware Proxy

Cloud Footprint Register

Asset	Provider	Service	Environment	Confidence
Public API	AWS	API Gateway	Production	High
Function endpoint	Google Cloud	Cloud Functions	Test	Medium
Internal portal	Azure	App Service	Development	High

Phase 07 — Discover Public Applications

Objective

Identify Internet-accessible applications connected to the approved cloud scope.

Review

Web portals
Administrative interfaces
API documentation
Mobile backends
Cloud dashboards
Support applications
Development tools

Review Areas

Authentication requirement
Public accessibility
Response headers
Cloud provider references
API documentation
Error messages
Environment indicators
Security headers
Redirect behaviour

Safety Controls

Do not brute force.
Do not bypass authentication.
Do not submit destructive requests.
Do not create unauthorized accounts.
Do not upload files unless the scenario permits it.
Do not test production transaction workflows.

Phase 08 — Identify Authentication Entry Points

Identity is the primary security perimeter in cloud environments.

Common Entry Points

Microsoft Entra ID
AWS IAM Identity Center
Amazon Cognito
Google Cloud Identity
Okta
Ping Identity
Auth0
Custom OAuth portals
SAML portals
Partner identity portals

Review

Identity provider
Authentication protocol
MFA usage
Federation
Tenant or domain information
Test-account availability
Conditional Access
Login branding
Session controls

Important Restriction

Do not perform:

Password spraying
Credential stuffing
MFA fatigue
Real-user phishing
Account-lockout testing

unless these activities are specifically authorized in writing and supported by dedicated safety controls.

Identity Entry-Point Register

Portal	Identity Provider	User Type	Test Account	Status
Employee SSO	Microsoft Entra ID	Employee	Dedicated test user	Approved
Customer Login	Amazon Cognito	Customer	Synthetic account	Approved
Vendor Portal	Third-party IdP	Partner	None	Excluded

Phase 09 — Review Public APIs

Modern cloud environments expose large numbers of APIs.

Review

API Gateway endpoints
Azure API Management
Google API Gateway
GraphQL endpoints
REST APIs
Webhooks
Serverless function URLs

Assessment Areas

Authentication
Authorization
Rate limiting
Input validation
Error handling
API versioning
Public documentation
Logging
Web Application Firewall integration

Safe Validation

Use:

Read-only requests
Synthetic data
Approved API keys
Dedicated test accounts
Low request volumes
Documented test cases

Avoid:

High-volume automation
Real transaction submission
Data modification
Destructive API methods
Access to real customer records

Phase 10 — Review Serverless Endpoints

Serverless applications may expose endpoints directly.

AWS

Review:

Lambda Function URLs
API Gateway
Application Load Balancer integrations
Event-driven triggers

Azure

Review:

HTTP-triggered Functions
Azure API Management
Logic Apps
Event Grid

Google Cloud

Review:

HTTP Cloud Functions
Cloud Run
Eventarc
API Gateway

Assessment Questions

Is authentication required?
Is authorization enforced?
Are function permissions excessive?
Is the endpoint intended to be public?
Are event sources validated?
Are logs enabled?
Is synthetic testing supported?

Phase 11 — Review Public Storage Surfaces

Cloud storage is frequently connected to public applications.

Storage Services

Amazon S3
Azure Blob Storage
Google Cloud Storage

Review

Public endpoint presence
Expected business use
Authentication requirements
Read access
Write access
Directory or object listing
Signed URL usage
CDN integration

Safety Controls

Do not:

Download real sensitive data.
Upload files.
Modify objects.
Delete objects.
Attempt bulk listing.

Use synthetic test objects whenever validation is required.

Storage Observation

Storage Asset	Publicly Reachable	Auth Required	Data Type	Action
Static website bucket	Yes	No	Public assets	Document
Test evidence container	Yes	Test token	Synthetic	Approved validation
Production archive	Unknown	Unknown	Sensitive	Stop and escalate

Phase 12 — Review Container Registries

Container registries may expose metadata about enterprise applications.

Common Registries

Amazon ECR
Azure Container Registry
Google Artifact Registry
GitHub Container Registry
GitLab Container Registry
Docker Hub
Harbor

Review

Public vs private access
Repository naming
Image tags
Metadata exposure
Organization ownership
Authentication requirements
Development vs production usage

Do not pull private images or attempt authentication without explicit authorization.

Phase 13 — Review Public Code and CI/CD Indicators

Public repositories may reveal cloud architecture or development practices.

Review

Organization-owned repositories
Documentation
Workflow files
Infrastructure templates
Dependency files
Cloud-service references
Deployment scripts
Container definitions
Issue trackers

Sensitive Information Indicators

Look for references to:

Cloud account identifiers
Subscription names
Project names
Resource names
API endpoints
Identity providers
Secret-management services

Do not collect or use exposed credentials outside an explicitly approved controlled scenario.

CI/CD Entry Points

Common platforms include:

GitHub Actions
GitLab CI/CD
Azure DevOps
Jenkins
CircleCI
Bitbucket Pipelines

Assess only customer-owned systems that are explicitly in scope.

Phase 14 — Review Public Cloud Metadata Exposure

Applications may unintentionally reveal cloud metadata through:

Error messages
Diagnostic pages
Response headers
Build information
Health endpoints
Public documentation
Application configuration

Review Questions

Does the response reveal an account or project name?
Does it expose a region?
Does it identify a cloud service?
Does it disclose an internal hostname?
Does it reveal a runtime or framework version?
Does it reveal an identity provider?

Record only the minimum information required for the assessment.

Phase 15 — Classify the Attack Surface

Every discovered asset should be classified.

Classification Fields

Asset name
Business purpose
Environment
Cloud provider
Service type
Internet exposure
Authentication model
Data sensitivity
Ownership
Scope status
Risk relevance

Asset Classification Table

Asset	Provider	Service	Exposure	Identity	Priority
Customer API	AWS	API Gateway	Public	Cognito	High
Dev Function	Azure	Function App	Public	Function key	Medium
Test Registry	GCP	Artifact Registry	Restricted	IAM	Low

Phase 16 — Identify Candidate Initial-Access Paths

Initial-access candidates should be selected from approved, realistic, and controlled entry points.

Candidate Scoring

Factor	Question
Scope	Is it explicitly approved?
Realism	Does it match the threat model?
Safety	Can it be validated without business impact?
Evidence	Can the result be clearly documented?
Detection	Can Blue Team visibility be evaluated?
Reversibility	Can changes be safely rolled back?

Phase 17 — Design the Initial-Access Scenario

Scenario Template

Field	Description
Scenario ID	Unique identifier
Entry Point	Approved initial-access asset
Threat Behaviour	Adversary behaviour being emulated
Preconditions	Required test setup
Test Identity	Dedicated account
Success Condition	Controlled foothold established
Safety Control	Restrictions
Evidence	Required records
Detection Goal	Expected alert
Stop Condition	Immediate stop trigger

Example Scenario

Field	Value
Scenario ID	IA-01
Entry Point	Approved test API
Threat Behaviour	Unauthorized access simulation
Preconditions	Synthetic API key
Test Identity	Red Team test identity
Success Condition	Test function invoked
Safety Control	No production data
Evidence	API log and function invocation
Detection Goal	SIEM alert
Stop Condition	Unexpected production access

Phase 18 — Initial-Access Decision Gate

Before validating any scenario, confirm:

Authorization

Entry point is explicitly in scope
Method is permitted
Test account is approved
Testing window is active

Safety

Synthetic data is available
No real-user account is involved
Rollback procedure exists
Stop conditions are documented

Detection

Required logs are enabled
Expected alert is defined
Control team is ready
Evidence owner is assigned

Decision

Result	Action
All controls confirmed	Proceed
Scope uncertain	Pause
Logging unavailable	Delay or document limitation
Production risk exists	Do not proceed
Synthetic data unavailable	Redesign scenario

Phase 19 — Perform Controlled Initial-Access Validation

Initial access should be validated using the minimum action required.

Principles

Use dedicated test accounts.
Use synthetic credentials.
Avoid persistent changes.
Avoid production data.
Minimize requests.
Stop after proving the objective.
Preserve evidence.
Validate detection.

Controlled Validation Workflow

Confirm Decision Gate

↓

Begin Activity Log

↓

Perform Minimum Approved Action

↓

Confirm Expected Result

↓

Check Defensive Telemetry

↓

Capture Evidence

↓

Revoke or Close Access

↓

Document Outcome

↓

Proceed Only After Approval

Phase 20 — Validate Logging and Detection

Initial-access activity should produce observable telemetry.

Expected Telemetry

Authentication event
API request
Function invocation
Cloud audit event
Identity event
Storage-access event
WAF event
SIEM alert
SOC ticket

Detection Validation Table

Activity	Expected Log	Expected Detection	Actual Result
Test login	Identity log	Unusual login alert	Detected / Not Detected
Test API invocation	API log	Unauthorized access alert	Detected / Not Detected
Function execution	Function log	Unexpected invocation alert	Detected / Not Detected

Phase 21 — Document Reconnaissance Findings

Every observation should be documented with context.

Finding Template

Finding ID
Title
Asset
Description
Evidence
Business relevance
Attack-path relevance
Risk rating
Recommendation
Remediation owner

Phase 22 — Build the Attack-Surface Map

A visual attack-surface map helps connect assets and identities.

Corporate Domain

├── Customer Portal
│   ├── API Gateway
│   ├── Identity Provider
│   └── Serverless Function
│
├── Developer Portal
│   ├── CI/CD Platform
│   └── Container Registry
│
├── Public Storage
│   └── Static Assets
│
└── Test Authentication Portal
    └── Dedicated Red Team Identity

The attack-surface map should identify:

Public entry points
Identity boundaries
Cloud providers
Trust relationships
High-value targets
Out-of-scope boundaries

Phase 23 — Prioritize Reconnaissance Results

Not every exposed asset requires immediate testing.

Priority Factors

Business criticality
Public exposure
Authentication strength
Identity privileges
Data sensitivity
Threat relevance
Detection opportunity
Safety of validation

Priority Matrix

Priority	Description
Critical	Approved entry point directly connected to high-value assets
High	Realistic path to privileged identity or sensitive system
Medium	Useful supporting path requiring additional conditions
Low	Limited business impact
Informational	Visibility or governance observation

Phase 24 — Prepare the Reconnaissance Report

Executive Summary

Include:

Scope
External attack-surface size
Major exposure categories
Initial-access outcome
Detection outcome
Top business risks
Immediate recommendations

Technical Report

Include:

Methodology
Asset inventory
DNS findings
Cloud footprint
Identity entry points
API inventory
Storage inventory
Registry inventory
Initial-access scenarios
Evidence
Detection results
Recommendations

Common Enterprise Findings

Cloud reconnaissance frequently identifies:

Forgotten development environments
Public APIs without strong authentication
Excessive information disclosure
Public serverless endpoints
Unprotected test portals
Public storage configuration
Weak identity-provider configuration
Exposed container registries
Public CI/CD services
Missing detection for initial-access activity
Poor asset ownership records
Incomplete cloud inventory

Consultant Best Practices

Professional Cloud Red Team Operators should:

Confirm scope before every active action.
Prefer passive reconnaissance first.
Treat ownership uncertainty as a stop condition.
Use dedicated test identities.
Use synthetic data.
Minimize interaction with production systems.
Do not test third-party services without approval.
Record timestamps in UTC.
Document confidence levels.
Validate detection alongside technical access.
Stop after proving the objective.
Remove temporary access after testing.
Explain how each finding supports a realistic attack path.

Key Takeaways

Cloud reconnaissance extends beyond traditional IP and port discovery.
Identity providers, APIs, storage, serverless functions, registries, and CI/CD platforms are major cloud entry points.
Passive and active reconnaissance require different safety controls.
Asset ownership and scope must be validated before interaction.
Initial access should use controlled scenarios, test identities, and synthetic data.
A formal decision gate is required before moving from reconnaissance to access validation.
Detection validation is part of the initial-access phase.
Findings should be connected to business objectives and attack paths.

Lesson Summary

In this lesson, you learned how authorized Cloud Red Teams discover and classify enterprise cloud attack surfaces.

You reviewed domains, DNS, certificates, public applications, authentication systems, APIs, serverless endpoints, storage services, registries, code repositories, and CI/CD platforms.

You also learned how to design controlled initial-access scenarios, apply decision gates, validate monitoring, preserve evidence, and document findings using the GoHackersCloud Enterprise Cloud Red Team Operations Framework.

The result of this phase should be a clear, evidence-driven attack-surface map and a set of approved initial-access paths that can support the next stage of the Red Team engagement.

Knowledge Check

What is the difference between passive and active reconnaissance?
Why must asset ownership be confirmed before testing?
Which cloud services commonly expose public entry points?
Why are identity providers important during cloud reconnaissance?
What controls should be confirmed before validating initial access?
Why should synthetic credentials and data be used?
What telemetry should an initial-access scenario generate?
When should an operator stop reconnaissance activity?
How should discovered third-party services be handled?
Why should reconnaissance findings be mapped to attack paths?

Practical Assignment

Create an Enterprise Cloud Reconnaissance Plan for a fictional multi-cloud organization.

Your plan must include:

Approved scope
Domain inventory
DNS review plan
Certificate review plan
Cloud-provider identification process
Public application inventory
Identity entry-point inventory
API inventory
Serverless endpoint inventory
Storage and registry inventory
CI/CD exposure review
Asset-classification model
Initial-access candidate matrix
Initial-access decision gate
Evidence requirements
Detection-validation plan
Stop conditions
Reporting structure

Assignment Deliverables

Submit:

Cloud Reconnaissance Plan
External Attack-Surface Inventory
Cloud Provider Footprint Map
Identity Entry-Point Register
API and Serverless Endpoint Register
Storage and Registry Register
Initial-Access Scenario Plan
Decision-Gate Checklist
Evidence Register
Detection Validation Table
Executive Reconnaissance Summary

What’s Next?

➡️ Lesson 03 — Cloud Identity Attacks & Privilege Escalation

In the next lesson, you will learn how authorized Cloud Red Teams assess cloud identities, permissions, trust relationships, temporary credentials, Managed Identities, Service Accounts, role assumption, and privilege-escalation paths across AWS, Microsoft Azure, and Google Cloud.

You will build identity attack-path maps, identify excessive permissions, validate controlled privilege paths, apply decision gates, and measure whether identity-based activity is prevented or detected by enterprise security controls.