Project 01 — Enterprise AWS Penetration Testing Assessment

Welcome

Welcome to Project 01 — Enterprise AWS Penetration Testing Assessment.

This is your first complete project inside:

09 — Enterprise Cloud Pentesting Projects

You are no longer working through isolated AWS techniques.

You are now performing a structured cloud penetration testing engagement against an authorised CloudNova AWS training environment.

Your objective is to operate like a professional Cloud Penetration Tester.

You will move through:

Engagement Planning
      ↓
AWS Environment Discovery
      ↓
Identity Enumeration
      ↓
IAM Analysis
      ↓
Resource Discovery
      ↓
Network Assessment
      ↓
EC2 Assessment
      ↓
Storage Assessment
      ↓
Workload Identity Analysis
      ↓
Secrets Review
      ↓
Logging Review
      ↓
Privilege-Path Analysis
      ↓
Controlled Validation
      ↓
Evidence Collection
      ↓
Risk Analysis
      ↓
Reporting
      ↓
Remediation
      ↓
Retesting

The purpose of this project is not to find the largest number of issues.

The purpose is to answer:

Can a low-privileged identity or compromised workload move through AWS permissions and trust relationships toward sensitive enterprise resources?

Mission Information

Project

Enterprise AWS Penetration Testing Assessment

Platform

CloudNova

Difficulty

Intermediate → Advanced

Estimated Time

4–6 hours

Primary Skills

• AWS reconnaissance

• IAM enumeration

• IAM policy analysis

• Role and trust analysis

• Effective permission analysis

• EC2 security

• Security Group review

• S3 security

• Workload identity review

• Secrets analysis

• Cloud logging

• Attack-path development

• Evidence collection

• Professional reporting

Mission Objective

You have been engaged by a fictional organisation to assess an AWS environment hosted in CloudNova.

The organisation suspects that:

• IAM permissions may be broader than necessary

• Workload roles may be overprivileged

• Cloud resources may have unnecessary exposure

• Storage permissions may be excessive

• Trust policies may enable unintended privilege paths

• Security logging may not provide sufficient visibility

Your objective is to determine whether these weaknesses can be combined into meaningful attack paths.

Engagement Scenario

The fictional organisation operates an AWS application environment resembling:

                         Internet
                            │
                            ↓
                  Application Load Balancer
                            │
                            ↓
                          WEB01
                            │
                            ↓
                          APP01
                            │
                    ┌───────┴───────┐
                    ↓               ↓
                  S3 Data        Database
                    ↑
                    │
              ApplicationRole
                    ↑
                    │
                  APP01

The environment also contains administrative and automation identities.

A simplified identity model may resemble:

AWS Account
│
├── Human Identities
│   ├── lab-developer
│   ├── lab-operator
│   └── lab-admin
│
├── Workload Identities
│   ├── WebRole
│   ├── ApplicationRole
│   └── AutomationRole
│
└── Resources
    ├── EC2
    ├── S3
    ├── Secrets
    ├── Lambda
    └── Logging

The exact CloudNova environment may differ.

Your job is to discover it.

Starting Position

You begin with an authorised low-privileged CloudNova AWS identity.

Example:

Identity:
lab-developer

Environment:
CloudNova AWS Training Account

Privilege:
Limited

Objective:
Determine whether available permissions or workload relationships
create a path toward sensitive cloud resources.

Rules of Engagement

Before doing anything, confirm that all testing remains within the supplied CloudNova AWS account.

Allowed:

AWS identity enumeration

Resource enumeration

IAM policy review

Role and trust analysis

Security Group review

S3 permission review

EC2 configuration review

Workload identity analysis

Secrets permission review

Logging review

Controlled permission validation

Evidence collection

Not allowed unless specifically stated by the lab:

Denial of Service

Deleting resources

Stopping production-like workloads unnecessarily

Destroying data

Disabling logging

Changing IAM beyond lab requirements

Accessing accounts outside CloudNova scope

Testing third-party infrastructure

Downloading large quantities of data

Golden Rule

Use:

Minimum Necessary Validation

If permissions, configuration, and safe evidence already prove a security path, do not perform unnecessary destructive actions.

Project Success Criteria

By the end of this project, you should be able to produce:

AWS Architecture Diagram

AWS Asset Inventory

IAM Identity Inventory

IAM Permission Matrix

Trust Relationship Map

EC2 Assessment

Network Exposure Matrix

S3 Assessment

Workload Identity Analysis

Secrets Review

Logging Review

Attack Path Register

Evidence Register

Findings Register

Enterprise AWS Pentest Report

Phase 01 — Prepare Your Project Workspace

Create:

Project 01 - Enterprise AWS Pentest/
│
├── 01 Engagement
├── 02 Architecture
├── 03 Reconnaissance
├── 04 IAM
├── 05 Compute
├── 06 Network
├── 07 Storage
├── 08 Workload Identity
├── 09 Secrets
├── 10 Logging
├── 11 Attack Paths
├── 12 Evidence
├── 13 Findings
├── 14 Report
└── 15 Retest

Inside 01 Engagement, create:

Scope.md

Rules-of-Engagement.md

Objectives.md

Testing-Notes.md

Phase 02 — Record the Engagement Scope

Create:

Scope

Cloud Provider:
AWS

Environment:
CloudNova

Account:
<ACCOUNT-ID>

Regions:
<AUTHORISED-REGIONS>

Starting Identity:
<IDENTITY>

In Scope:
IAM
EC2
S3
Networking
Secrets
Lambda
Logging
Approved Resources

Out of Scope:
Other AWS accounts
Third-party systems
DoS
Destructive operations
Unapproved resources

Phase 03 — Confirm Your AWS Identity

Your first technical question should always be:

Who am I?

In the authorised CloudNova terminal:

aws sts get-caller-identity

Record:

Account

UserId

ARN

Example:

Account:
111122223333

ARN:
arn:aws:iam::111122223333:user/lab-developer

Save:

Evidence ID:
AWS-EV-001

Why This Matters

All subsequent actions occur within a security context.

Your attack path starts from:

Current Identity

Without understanding the starting identity, permission analysis has no meaning.

Phase 04 — Confirm AWS CLI Context

Review:

aws configure list

and:

aws configure get region

If appropriate for the lab:

aws ec2 describe-regions --query 'Regions[].RegionName' --output table

Record only regions relevant to the authorised scope.

Phase 05 — Create an Initial Identity Record

Create:

Field	Value
Identity	lab-developer
Type	IAM User / Role
Account	<Account ID>
Authentication	CloudNova session
MFA	Lab dependent
Known Privilege	Limited
Effective Privilege	Unknown

The important field is:

Effective Privilege:
Unknown

Your job is to determine it.

Phase 06 — Discover the Environment

Now begin building the AWS asset inventory.

Do not start by attempting privilege escalation.

Start by answering:

What exists in this account?

Phase 07 — EC2 Inventory

Use:

aws ec2 describe-instances

A more focused output:

aws ec2 describe-instances \
  --query 'Reservations[].Instances[].{InstanceId:InstanceId,PrivateIP:PrivateIpAddress,PublicIP:PublicIpAddress,State:State.Name,IamProfile:IamInstanceProfile.Arn}' \
  --output table

Record:

• Instance ID

• Private IP

• Public IP

• State

• Attached IAM instance profile

• Tags

• Security Groups

EC2 Asset Table

Create:

Instance	Public IP	Private IP	IAM Role	Security Group	Purpose
WEB01	Yes	10.0.1.10	WebRole	sg-web	Web
APP01	No	10.0.2.10	ApplicationRole	sg-app	Application

Do not assume purpose solely from names.

Validate with tags and architecture.

Phase 08 — Discover S3 Buckets

Use:

aws s3api list-buckets

or:

aws s3 ls

Create:

Bucket	Purpose	Public?	Encryption	Versioning	Logging
app-data-lab	Application data	Unknown	Unknown	Unknown	Unknown
backup-lab	Backup	Unknown	Unknown	Unknown	Unknown

Your initial inventory should contain unknowns.

Do not fill gaps with assumptions.

Phase 09 — Discover Lambda Functions

Use:

aws lambda list-functions

Record:

Function Name

Runtime

Execution Role

Description

Environment Configuration

Do not expose secrets unnecessarily in your notes.

Phase 10 — Discover IAM Users

If authorised permissions allow:

aws iam list-users

Record:

Identity	Type	Purpose	Review
lab-developer	User	Development	Yes
automation-user	User	Automation	Yes

Phase 11 — Discover IAM Roles

Use:

aws iam list-roles

Focus on:

Role Name

Role ARN

Trust Relationship

Purpose

Linked Workload

Create:

Role	Trusted Entity	Used By	Privilege
WebRole	EC2	WEB01	Unknown
ApplicationRole	EC2	APP01	Unknown
AutomationRole	Service / Identity	Automation	Unknown

Phase 12 — Build the First Architecture Diagram

At this point create an initial diagram.

Example:

AWS Training Account
│
├── IAM
│   ├── lab-developer
│   ├── WebRole
│   └── ApplicationRole
│
├── EC2
│   ├── WEB01
│   └── APP01
│
├── S3
│   ├── app-data-lab
│   └── backup-lab
│
├── Lambda
│   └── processor-lab
│
└── Logging
    └── CloudTrail

This diagram will change as you learn more.

Phase 13 — Assess the Current Identity

Now investigate what the starting identity can do.

If permitted, identify attached policies.

For an IAM user:

aws iam list-attached-user-policies --user-name lab-developer

and:

aws iam list-user-policies --user-name lab-developer

For a role, use the equivalent role-policy commands.

Phase 14 — Review Inline Policies

Example:

aws iam get-user-policy \
  --user-name lab-developer \
  --policy-name <POLICY-NAME>

Read the policy carefully.

Do not simply look for:

"Action": "*"

Analyse:

Effect

Action

Resource

Condition

IAM Policy Model

Always read permissions as:

Identity
   ↓
Effect
   ↓
Action
   ↓
Resource
   ↓
Condition

Phase 15 — Managed Policies

If a managed policy is attached:

aws iam get-policy --policy-arn <POLICY-ARN>

Identify the default version.

Then:

aws iam get-policy-version \
  --policy-arn <POLICY-ARN> \
  --version-id <VERSION>

Document the effective permissions.

Phase 16 — Build a Permission Matrix

Create:

Identity	Action	Resource	Condition	Risk Question
lab-developer	Lambda modification	Function A	—	Which role does function use?
lab-developer	Read EC2	*	—	Recon only
lab-developer	Read S3 metadata	Selected	—	Data exposure?

The fifth column is critical.

Do not ask only:

What permission exists?

Ask:

What security capability does this permission create?

Phase 17 — Permission Classification

Classify permissions into:

Read

Write

Resource Creation

Resource Modification

Identity Modification

Policy Modification

Credential Management

Role Assumption

Secret Access

Logging Modification

Permissions involving identity or resource modification deserve particular attention.

Phase 18 — Identify Potential Privilege-Changing Permissions

Look for permissions that may allow an identity to influence something operating with greater privilege.

Examples of important concepts include:

Modify Workload

Pass Role

Assume Role

Attach Policy

Modify Policy

Create Credential

Read Secret

Create Resource With Role

Do not assume that any single permission automatically produces privilege escalation.

Analyse combinations.

Phase 19 — Role Trust Policies

For a role:

aws iam get-role --role-name ApplicationRole

Review:

"AssumeRolePolicyDocument"

Ask:

Who Can Assume This Role?

Why?

Under Which Conditions?

Is Trust Broader Than Required?

Is Cross-Account Trust Present?

Phase 20 — Build the Trust Map

Example:

EC2
 ↓
ApplicationRole

Lambda
 ↓
ProcessorRole

lab-developer
 ↓
Can Modify
 ↓
Lambda

Now relationships become interesting.

Phase 21 — Understand Indirect Privilege

Suppose you observe:

lab-developer
      ↓
Can Modify
      ↓
processor-lab

and:

processor-lab
      ↓
Runs As
      ↓
ApplicationRole

and:

ApplicationRole
      ↓
Can Access
      ↓
Sensitive Resource

Potential attack path:

lab-developer
      ↓
Function Control
      ↓
ApplicationRole
      ↓
Sensitive Resource

This is a hypothesis until validated.

Phase 22 — Create the Hypothesis Register

ID	Hypothesis	Evidence	Status
H-001	Developer may indirectly use ApplicationRole	Function permissions + role	Investigate
H-002	ApplicationRole may access sensitive S3	IAM policy	Investigate
H-003	Storage may be public	Bucket config	Investigate

This prevents assumptions from becoming findings.

Phase 23 — Assess Security Groups

Use:

aws ec2 describe-security-groups

Create:

SG	Source	Port	Target	Expected?
sg-web	Internet	443	WEB01	Yes
sg-app	sg-web	8080	APP01	Yes
sg-db	0.0.0.0/0	3306	DB	No / Investigate

Do not report a rule until you understand the target resource and intent.

Phase 24 — Identify Public Exposure

For each internet-facing resource ask:

Why Is It Public?

Which Ports?

Who Requires Access?

Is Authentication Present?

Could Access Be Restricted?

Is the Exposure Intentional?

Phase 25 — Evaluate Administrative Exposure

Pay particular attention to exposure of:

SSH

RDP

Database Services

Kubernetes Management

Administrative Web Interfaces

Broad internet reachability may increase attack surface.

Phase 26 — Review EC2 IAM Profiles

For each EC2 instance:

aws ec2 describe-instances \
  --instance-ids <INSTANCE-ID> \
  --query 'Reservations[].Instances[].IamInstanceProfile'

Map:

Instance
   ↓
Instance Profile
   ↓
Role
   ↓
Policies
   ↓
Resources

Phase 27 — Workload Identity Analysis

For every workload identity ask:

What Workload Uses It?

Who Can Modify That Workload?

What Permissions Does the Role Have?

What Secrets Can It Access?

Which Resources Can It Modify?

Can It Assume Another Role?

This is one of the most important phases of the project.

Phase 28 — Build a Workload Identity Table

Workload	Role	Permission	Sensitive Resource	Who Controls Workload?
APP01	ApplicationRole	S3 Read	app-data-lab	App team
processor-lab	ProcessorRole	Secrets Read	app-secret	lab-developer?

The last column often reveals the attack path.

Phase 29 — Assess S3 Bucket Configuration

For each approved bucket review configuration such as:

aws s3api get-public-access-block --bucket <BUCKET>

aws s3api get-bucket-policy --bucket <BUCKET>

aws s3api get-bucket-acl --bucket <BUCKET>

aws s3api get-bucket-encryption --bucket <BUCKET>

aws s3api get-bucket-versioning --bucket <BUCKET>

Not every command will be permitted in every lab identity.

Record denied actions as part of your current security context.

Phase 30 — S3 Questions

For every bucket ask:

Who Can List?

Who Can Read?

Who Can Write?

Who Can Delete?

Is Public Access Possible?

Is Cross-Account Access Present?

Is Encryption Enabled?

Is Versioning Enabled?

Is Logging Enabled?

What Data Classification Applies?

Phase 31 — Minimum Data Access

If authorised validation shows that an identity can access a sensitive lab bucket:

Do not download everything.

Use:

Synthetic Marker

or inspect the minimum object needed to prove access.

Example:

OBJECTIVE-VALIDATION.txt

Phase 32 — S3 Finding Example

AWS-001 — Workload Identity Has Excessive Access to Sensitive Storage

Observation

The application workload role possesses read permissions to an S3 bucket outside its documented application requirement.

Attack Scenario

If an attacker compromises the application workload, the attacker could inherit the role’s effective permissions and access unrelated sensitive application data.

Root Cause

Excessive IAM permissions assigned to the workload identity.

Recommendation

Scope the role to the specific S3 resources required by the workload and regularly review machine-identity permissions.

Phase 33 — Review Secrets

If the environment contains AWS Secrets Manager and your identity has authorised enumeration permissions:

aws secretsmanager list-secrets

Record metadata only initially.

Do not retrieve secret values simply because you can.

Secret Assessment Questions

Who Can Discover Secrets?

Who Can Read Secret Values?

Who Can Modify Secrets?

Which Workloads Use Them?

Are Access Permissions Narrow?

Are Secrets Rotated?

Are Sensitive Actions Logged?

Phase 34 — Privilege Path Through Secrets

Example:

Low-Privilege Identity
       ↓
Read Secret
       ↓
Application Credential
       ↓
Higher-Value Service

Secret access often hides indirect privilege.

Phase 35 — Review Lambda Roles

For each function:

aws lambda get-function-configuration \
  --function-name <FUNCTION-NAME>

Record:

Runtime

Role

Environment Variable Names

VPC Configuration

Function Purpose

Do not copy sensitive environment-variable values into unrestricted notes.

Phase 36 — Lambda Control Analysis

Ask:

Who Can Modify the Function?

Who Can Invoke It?

Which Role Does It Use?

What Can the Role Access?

Does It Reach Internal Resources?

Does It Access Secrets?

A function can become an important privilege bridge.

Phase 37 — Example IAM Attack Hypothesis

Suppose CloudNova reveals:

lab-developer
      ↓
Can Update
      ↓
processor-lab

The function uses:

ProcessorRole

ProcessorRole can:

Read:
arn:aws:s3:::finance-lab/*

Potential path:

lab-developer
      ↓
Control Function
      ↓
ProcessorRole
      ↓
finance-lab

Do not jump directly into modifying the function.

First determine whether configuration evidence already proves the security relationship.

Phase 38 — Controlled Validation Decision

Use:

Do I Already Have Sufficient Evidence?
        ↓
Yes → Document and Stop

No
 ↓
Can I Validate Safely?
        ↓
Yes → Minimal Approved Test

No
 ↓
Escalate / Document Potential Risk

Phase 39 — Validate Only in CloudNova

If the lab explicitly requires controlled validation, use the exact lab-specific instructions supplied by CloudNova.

Do not perform destructive or unrelated privilege actions.

The goal is to prove:

Permission Relationship

not:

Maximum Possible Damage

Phase 40 — Review Role Assumption

Where permitted:

aws iam get-role --role-name <ROLE>

Examine trust.

If your current identity has authorised role-assumption capabilities, document:

Source Identity

Target Role

Trust Requirement

Conditions

Resulting Privilege

Phase 41 — Cross-Account Trust

If trust references another AWS account, confirm whether that account is in scope.

If not:

STOP

Do not follow the trust relationship outside the authorised environment.

Document it for client review.

Phase 42 — Assess Logging

Determine whether CloudTrail exists.

Where permitted:

aws cloudtrail describe-trails

and:

aws cloudtrail get-trail-status --name <TRAIL-NAME>

Ask:

Is CloudTrail Enabled?

Which Regions?

Where Are Logs Stored?

Is Log Integrity Protected?

Who Can Disable Logging?

Who Can Delete Logs?

Phase 43 — Logging Attack Surface

Security telemetry itself is a sensitive control.

Attack path:

Compromised Identity
       ↓
Modify Logging
       ↓
Reduced Visibility

If the current identity can modify logging, determine whether that capability is operationally necessary.

Do not disable logging during the lab unless specifically required by an isolated exercise.

Phase 44 — AWS Config and Security Monitoring

If present, document services such as:

AWS Config

GuardDuty

Security Hub

CloudWatch

CloudTrail

You are not trying to defeat them.

Ask:

Would the activities performed during this authorised assessment be visible to the security team?

Phase 45 — Build the AWS Attack Surface Map

Your map may now look like:

Internet
│
├── ALB
│    ↓
│   WEB01
│
├── Public API
│
└── Exposed Services

AWS Identity
│
├── lab-developer
├── ApplicationRole
└── ProcessorRole

Resources
│
├── EC2
├── Lambda
├── S3
├── Secrets
└── Logging

Phase 46 — Build the Identity Graph

Example:

lab-developer
     │
     ├── Read EC2
     │
     └── Modify processor-lab
                   │
                   ↓
              ProcessorRole
                   │
                   ├── Read Secret
                   │
                   └── Read finance-lab

This provides far more insight than a raw permission list.

Phase 47 — Identify Choke Points

Suppose:

Attack Path 01
      ↓
ProcessorRole

Attack Path 02
      ↓
ProcessorRole

Then:

ProcessorRole

may be a high-value remediation choke point.

Reducing its privilege could break multiple attack paths.

Phase 48 — Attack Path 01

Example:

lab-developer
      ↓
Function Modification
      ↓
ProcessorRole
      ↓
Sensitive S3

Document:

Initial Identity

Transition Permission

Target Workload

Workload Role

Role Permission

Sensitive Resource

Evidence

Phase 49 — Attack Path 02

Example:

Application Workload
       ↓
ApplicationRole
       ↓
Secrets Manager
       ↓
Database Credential
       ↓
Sensitive Database

Again, the secret is not the end.

Understand what the secret protects.

Phase 50 — Attack Path 03

Example:

Developer
    ↓
Broad IAM Permission
    ↓
Role Trust Modification
    ↓
Privileged Role
    ↓
Cloud Administration

Only report this as validated if the actual permission relationship supports it.

Phase 51 — Attack Path Register

Create:

Path ID	Start	Transition	Target	Status	Severity
AP-001	lab-developer	Function control	S3	Validated	High
AP-002	APP01	Workload role	Secret	Validated	High
AP-003	developer	IAM relationship	Admin role	Hypothesis	TBD

Do not assign final severity to unvalidated hypotheses.

Phase 52 — Evidence Standards

Every important claim should be supported by evidence.

Example:

AWS-EV-001
Starting identity

AWS-EV-002
Current IAM policy

AWS-EV-003
Lambda configuration

AWS-EV-004
ProcessorRole trust policy

AWS-EV-005
ProcessorRole permission

AWS-EV-006
S3 bucket configuration

AWS-EV-007
Controlled synthetic-object access

Phase 53 — Evidence Record

Use:

Evidence ID:
AWS-EV-005

Timestamp:
<DATE/TIME>

Resource:
ProcessorRole

Observation:
ProcessorRole has authorised read access to finance-lab.

Source:
IAM policy review.

Attack Path:
AP-001

Sensitive Data:
No real sensitive data collected.

Phase 54 — Findings Register

Create:

ID	Finding	Severity	Attack Path
AWS-001	Workload role has excessive S3 access	High	AP-001
AWS-002	Developer can control higher-privilege workload	High	AP-001
AWS-003	Administrative network exposure is overly broad	High	—
AWS-004	Cloud logging permissions are excessive	Medium/High	AP-002

Your actual CloudNova findings should determine the final register.

Phase 55 — Finding Example 01

AWS-001 — Developer Permissions Create an Indirect Path to a Higher-Privilege Workload Identity

Observation

The authorised development identity can modify a cloud workload operating under a role with privileges exceeding those assigned directly to the developer.

Attack Scenario

Compromise of the development identity could allow an attacker to influence the higher-privilege workload context and indirectly exercise permissions assigned to the workload role.

Impact

This may allow expansion from a development identity into sensitive AWS resources accessible to the workload.

Root Cause

Insufficient separation between workload-management permissions and workload IAM privilege.

Recommendation

Restrict modification rights to privileged workloads, minimise the workload role’s permissions, and implement separation of duties between application development and privileged cloud administration.

Phase 56 — Finding Example 02

AWS-002 — Application Role Has Unnecessary Access to Sensitive S3 Data

Observation

The application role possesses access to an S3 resource unrelated to its expected operational requirements.

Impact

If the application or its execution context is compromised, the role’s excessive permission could increase the blast radius of the incident.

Recommendation

Apply least privilege using resource-specific S3 permissions and periodically review workload-role access.

Phase 57 — Finding Example 03

AWS-003 — Administrative Service Is Accessible From Broad Network Sources

Observation

An administrative service is reachable from network sources broader than those required for legitimate administration.

Impact

Broad exposure increases the attack surface and may enable credential-based or vulnerability-based attacks against management infrastructure.

Recommendation

Restrict administrative access to approved management paths such as private connectivity, trusted administrative networks, or controlled access services.

Phase 58 — Finding Example 04

AWS-004 — Security Logging Configuration Can Be Modified by Non-Security Identity

Observation

An identity outside the dedicated security administration function possesses permissions capable of modifying security telemetry configuration.

Risk

Compromise of the identity could reduce the organisation’s ability to detect or investigate malicious cloud activity.

Recommendation

Restrict logging administration to dedicated security identities and monitor all changes to audit infrastructure.

Phase 59 — Risk Analysis

Do not prioritise based only on policy names.

Consider:

Exposure

Initial Privilege Required

Permission Combination

Critical Asset

Sensitive Data

Blast Radius

Business Impact

Existing Detection

Ease of Remediation

Phase 60 — Root Cause Analysis

Your findings may reveal themes such as:

Overprivileged Workload Identities

Weak Separation of Duties

Excessive Resource Exposure

Inconsistent IAM Governance

Weak Logging Governance

Look beyond individual findings.

Phase 61 — Identify Positive Controls

Record controls that worked.

Examples:

S3 Public Access Block Enabled
        ✓

CloudTrail Enabled
        ✓

Database Not Publicly Exposed
        ✓

Administrative MFA Enforced
        ✓

A professional assessment reports strengths as well as weaknesses.

Phase 62 — Remediation Prioritisation

Immediate

Break validated critical privilege paths

Remove unnecessary sensitive-resource access

Restrict broad administrative exposure

Rotate any intentionally exposed lab credentials if applicable

Short Term

Review workload IAM

Review developer permissions

Review trust policies

Strengthen network segmentation

Review machine identities

Strategic

IAM Governance

Permission Boundaries

Privileged Access Management

Machine Identity Governance

Cloud Security Monitoring

Continuous Attack-Path Analysis

Phase 63 — Build the Remediation Matrix

Finding	Immediate	Long-Term	Owner
AWS-001	Remove excessive workload access	IAM governance	Cloud Security
AWS-002	Restrict function control	Separation of duties	DevOps
AWS-003	Restrict network rule	Network baseline	Cloud Network
AWS-004	Restrict log permissions	Security account architecture	SOC/Cloud

Phase 64 — Retesting

After remediation, repeat only the necessary tests.

Example:

Before:

lab-developer
      ↓
Modify Workload
      ↓
Privileged Role
      ↓
Sensitive S3

After:

lab-developer
      ↓
Required Development Actions
      ✓

lab-developer
      ↓
Privileged Workload Control
      X

This demonstrates successful remediation.

Phase 65 — Retest Status

Use:

Resolved

Partially Resolved

Not Resolved

Risk Accepted

Do not mark an issue resolved simply because the policy text changed.

Verify the attack path.

Phase 66 — Final Architecture Diagram

Update your original diagram with the confirmed security relationships.

Example:

                         Internet
                            │
                            ↓
                           ALB
                            │
                            ↓
                          WEB01
                            │
                         WebRole
                            │
                            ↓
                          APP01
                            │
                    ApplicationRole
                     /             \
                    ↓               ↓
                 S3 Data          Secrets
                                    │
                                    ↓
                                  DB01


lab-developer
      │
      └──── Modify ────> processor-lab
                              │
                              ↓
                        ProcessorRole
                              │
                              ↓
                       Sensitive S3

Phase 67 — Final Attack Narrative

Your narrative should tell a story.

Example:

The assessment began with an authorised low-privileged development identity. IAM analysis identified that the identity could modify a serverless workload operating under a more privileged execution role. The workload role possessed access to a sensitive synthetic storage resource outside the developer’s direct permissions. This created an indirect privilege path in which compromise of the development identity could potentially expand into access to sensitive AWS data. The path resulted from the combination of excessive workload-management permission and overprivileged workload IAM.

That is stronger than:

Lambda is vulnerable.

Phase 68 — Enterprise AWS Report Structure

Create:

Enterprise AWS Penetration Testing Report

1. Executive Summary

2. Engagement Objectives

3. Scope

4. Rules of Engagement

5. AWS Environment Overview

6. Architecture

7. Methodology

8. Asset Inventory

9. Identity & IAM Assessment

10. Network Security Assessment

11. Compute Assessment

12. Storage Assessment

13. Workload Identity Assessment

14. Secrets Assessment

15. Logging & Monitoring Assessment

16. Attack Paths

17. Validated Findings

18. Positive Security Observations

19. Root Cause Themes

20. Remediation Roadmap

21. Retest Plan

22. Evidence Appendix

Phase 69 — Executive Summary Questions

Your executive summary should answer:

What Was Tested?

What Was the Main Risk?

Could Privilege Expand?

Which Business Assets Were Exposed?

Which Controls Worked?

Which Controls Failed?

What Should Be Fixed First?

Phase 70 — Technical Report Standard

Every finding should include:

Finding ID

Title

Severity

Affected Resources

Observation

Evidence

Attack Scenario

Impact

Root Cause

Recommendation

Retest Guidance

Phase 71 — Project Deliverables

Complete all of these:

Project 01 - Enterprise AWS Pentest/
│
├── 01 Engagement
│   ├── Scope.md
│   ├── Rules-of-Engagement.md
│   └── Objectives.md
│
├── 02 Architecture
│   ├── Initial-AWS-Architecture.md
│   └── Final-AWS-Architecture.md
│
├── 03 Reconnaissance
│   └── Asset-Inventory.md
│
├── 04 IAM
│   ├── Identity-Inventory.md
│   ├── Permission-Matrix.md
│   └── Trust-Map.md
│
├── 05 Compute
│   └── EC2-Assessment.md
│
├── 06 Network
│   └── Security-Group-Matrix.md
│
├── 07 Storage
│   └── S3-Assessment.md
│
├── 08 Workload Identity
│   └── Workload-Identity-Map.md
│
├── 09 Secrets
│   └── Secrets-Assessment.md
│
├── 10 Logging
│   └── Logging-Assessment.md
│
├── 11 Attack Paths
│   └── Attack-Path-Register.md
│
├── 12 Evidence
│   └── Evidence-Register.md
│
├── 13 Findings
│   └── Findings-Register.md
│
├── 14 Report
│   └── Enterprise-AWS-Pentest-Report.md
│
└── 15 Retest
    └── Retest-Report.md

Phase 72 — Student Submission Checklist

Before marking Project 01 complete:

ENGAGEMENT

[ ] Scope documented
[ ] Starting identity documented
[ ] ROE understood
[ ] Stop conditions understood

DISCOVERY

[ ] Account identified
[ ] Regions reviewed
[ ] EC2 inventoried
[ ] S3 inventoried
[ ] Lambda inventoried
[ ] IAM identities inventoried
[ ] IAM roles inventoried

IAM

[ ] Starting permissions analysed
[ ] Managed policies reviewed
[ ] Inline policies reviewed
[ ] Trust policies reviewed
[ ] Effective permissions mapped
[ ] Workload identities mapped
[ ] Potential privilege paths identified

NETWORK

[ ] Security Groups reviewed
[ ] Public exposure reviewed
[ ] Administrative exposure reviewed
[ ] Segmentation considered

COMPUTE

[ ] EC2 configurations reviewed
[ ] Instance profiles mapped
[ ] Workload roles reviewed

STORAGE

[ ] S3 permissions reviewed
[ ] Public-access controls reviewed
[ ] Encryption reviewed
[ ] Versioning reviewed
[ ] Sensitive synthetic data handled safely

SECRETS

[ ] Secret inventory reviewed where authorised
[ ] Secret access permissions analysed
[ ] No unnecessary secret values collected

LOGGING

[ ] CloudTrail reviewed
[ ] Logging permissions reviewed
[ ] Monitoring capability considered

ATTACK PATHS

[ ] Hypotheses documented
[ ] Hypotheses distinguished from findings
[ ] Validated attack paths documented
[ ] Minimum necessary proof followed
[ ] Choke points identified

REPORTING

[ ] Evidence register completed
[ ] Findings register completed
[ ] Positive controls documented
[ ] Root causes identified
[ ] Recommendations prioritised
[ ] Final report completed
[ ] Retest plan completed

Phase 73 — Skills You Should Demonstrate

After completing this project, you should be able to explain:

How do you start an AWS penetration test?

How do you establish your current AWS identity?

How do you inventory AWS resources?

How do you analyse IAM policies?

What is the difference between direct and indirect privilege?

Why are workload identities important?

How do role trust policies affect attack paths?

How do you assess S3 security?

How do you assess Security Groups?

Why should Secrets Manager access be reviewed?

Why is CloudTrail important?

How do you validate a privilege path without causing unnecessary impact?

How do you translate an IAM weakness into business risk?

Phase 74 — Interview Story

You should now be able to explain this project professionally.

Example:

In a CloudNova enterprise AWS lab, I started with a limited development identity and first established the AWS account and permission context. I created an asset and identity inventory covering IAM, EC2, S3, Lambda, networking, secrets, and logging. During IAM analysis, I identified a relationship where the developer could control a workload operating under a more privileged execution role. I mapped the role’s effective access to sensitive synthetic storage, validated only the minimum evidence required, documented the attack path, and recommended separation of duties and least-privilege workload IAM. I then defined a retest to confirm the path had been broken after remediation.

That demonstrates:

AWS Knowledge
      +
Cloud Pentest Methodology
      +
IAM Analysis
      +
Attack-Path Thinking
      +
Professional Reporting

Key Takeaways

Project 01 is about learning to assess AWS as a connected security system.

Remember:

Start with identity.

Understand the environment before testing deeper.

Inventory resources before forming conclusions.

IAM policy names do not tell you effective privilege.

Always analyse action, resource, effect, and condition together.

Trust policies are as important as permission policies.

Cloud privilege can be indirect.

Who controls the workload may matter as much as the workload’s permissions.

Workload identities must be treated as privileged security principals.

Public exposure is not automatically a vulnerability.

S3 risk depends on data, access, and business context.

Secrets can create hidden privilege paths.

Security logging is itself a high-value security control.

A hypothesis is not a finding.

Validate the minimum necessary evidence.

Do not perform destructive cloud actions simply to prove privilege.

Attack paths provide more context than isolated IAM findings.

Look for remediation choke points that break multiple attack paths.

Report controls that worked as well as controls that failed.

Retest the attack path, not merely the changed configuration.

Your AWS penetration testing methodology is:

Scope
  ↓
Establish Identity
  ↓
Inventory Environment
  ↓
Analyse IAM
  ↓
Map Trust
  ↓
Assess Network
  ↓
Assess Compute
  ↓
Assess Storage
  ↓
Assess Workload Identities
  ↓
Assess Secrets
  ↓
Assess Logging
  ↓
Build Hypotheses
  ↓
Develop Attack Paths
  ↓
Validate Safely
  ↓
Collect Evidence
  ↓
Assess Business Risk
  ↓
Recommend Controls
  ↓
Report
  ↓
Retest

What’s Next?

➡️ Project 02 — Enterprise Azure Identity & Cloud Penetration Test

In the next CloudNova project, you will move from AWS IAM into the Microsoft cloud identity model.

You will assess:

• Microsoft Entra ID

• Azure subscriptions

• Resource groups

• Azure RBAC

• Role assignments

• Managed identities

• Virtual machines

• Network Security Groups

• Storage

• Key Vault

• Application identities

• Enterprise identity relationships

• Privilege paths

• Logging and monitoring

The major shift will be:

AWS IAM
   ↓
Azure Enterprise Identity

You will move from asking:

Can AWS permissions and workload roles create an unintended privilege path?

to asking:

Can Microsoft Entra identities, Azure RBAC, managed identities, and resource control combine into a path toward privileged Azure resources?