Lesson 01 — AWS Offensive Security Foundations
Learning Objectives
Section titled “Learning Objectives”By the end of this lesson, you will be able to:
- Understand AWS offensive security concepts.
- Explain how attackers target AWS environments.
- Understand the AWS Shared Responsibility Model from a penetration tester’s perspective.
- Identify common AWS attack surfaces.
- Understand the AWS attack lifecycle.
- Learn the methodology used during enterprise AWS penetration testing engagements.
Introduction
Section titled “Introduction”AWS is the world’s most widely adopted cloud platform and hosts millions of applications ranging from startups to governments and Fortune 500 companies.
Because organizations increasingly rely on AWS, attackers have shifted their focus from traditional data centres to cloud infrastructure.
Unlike traditional penetration testing, AWS penetration testing focuses on:
- Identity
- Cloud APIs
- Misconfigurations
- Cloud networking
- Storage
- Containers
- Serverless services
- Infrastructure as Code
As an AWS Cloud Penetration Tester, your objective is to identify security weaknesses before attackers do.
Why AWS Offensive Security Matters
Section titled “Why AWS Offensive Security Matters”Modern attacks rarely begin with operating system vulnerabilities.
Instead, attackers commonly exploit:
- Weak IAM permissions
- Exposed access keys
- Public Amazon S3 buckets
- Overly permissive Security Groups
- Misconfigured VPCs
- Vulnerable EC2 instances
- Exposed Lambda functions
- Weak Kubernetes configurations
- CI/CD pipeline weaknesses
Understanding these attack vectors is essential for securing AWS environments.
Enterprise Scenario
Section titled “Enterprise Scenario”You have joined CloudNova Technologies as a Cloud Penetration Tester.
A global financial organization has requested an AWS security assessment before migrating its production workloads.
Your responsibilities include:
- Reviewing AWS architecture
- Enumerating cloud resources
- Assessing IAM security
- Identifying attack paths
- Validating cloud security controls
- Producing executive security reports
This module follows the same workflow used by enterprise cloud security consultants.
AWS Shared Responsibility Model
Section titled “AWS Shared Responsibility Model”AWS secures the cloud infrastructure, while customers are responsible for securing what they deploy in the cloud.
AWS Responsibilities
Physical Security↓
Data Centres↓
Networking Infrastructure↓
Hypervisor↓
Managed Services
----------------------------------------
Customer Responsibilities
IAM
↓
Applications
↓
Operating Systems
↓
Cloud Configurations
↓
Security Groups
↓
Amazon S3
↓
Amazon EC2
↓
Amazon EKS
↓
Customer DataAttacker’s Perspective
Section titled “Attacker’s Perspective”Attackers generally do not attack AWS itself.
Instead, they target customer-controlled resources.
Common targets include:
- IAM Users
- IAM Roles
- Access Keys
- EC2 Instances
- Lambda Functions
- Amazon S3
- Kubernetes
- Cloud APIs
- CI/CD Pipelines
Most successful AWS compromises originate from customer misconfigurations rather than vulnerabilities within AWS.
Common AWS Attack Surface
Section titled “Common AWS Attack Surface”Internet
↓
CloudFront
↓
Application Load Balancer
↓
Amazon EC2
↓
Amazon EKS
↓
Lambda
↓
IAM
↓
Amazon S3
↓
Amazon RDS
↓
Customer DataEvery layer should be assessed during a penetration test.
AWS Penetration Testing Methodology
Section titled “AWS Penetration Testing Methodology”Professional AWS penetration testing follows a structured methodology.
Preparation
↓
Reconnaissance
↓
Enumeration
↓
Identity Assessment
↓
Infrastructure Assessment
↓
Storage Assessment
↓
Networking Assessment
↓
Container Assessment
↓
Attack Path Analysis
↓
Reporting
↓
Remediation ValidationSkipping stages often leads to incomplete assessments.
AWS Services Frequently Assessed
Section titled “AWS Services Frequently Assessed”Identity
Section titled “Identity”- AWS IAM
- IAM Identity Center
- STS
Compute
Section titled “Compute”- Amazon EC2
- Auto Scaling
- AMIs
Storage
Section titled “Storage”- Amazon S3
- Amazon EBS
- Amazon EFS
Networking
Section titled “Networking”- Amazon VPC
- Security Groups
- Network ACLs
- Route Tables
- Internet Gateways
- VPC Endpoints
Containers
Section titled “Containers”- Amazon EKS
- Amazon ECS
- ECR
Serverless
Section titled “Serverless”- AWS Lambda
- API Gateway
Monitoring
Section titled “Monitoring”- AWS CloudTrail
- Amazon CloudWatch
- AWS Config
- Amazon GuardDuty
- AWS Security Hub
Typical AWS Attack Workflow
Section titled “Typical AWS Attack Workflow”Reconnaissance
↓
Identity Discovery
↓
IAM Enumeration
↓
Permission Analysis
↓
Privilege Escalation
↓
Storage Discovery
↓
Compute Enumeration
↓
Container Discovery
↓
Data Access
↓
Persistence
↓
ReportingThis workflow reflects how professional attackers and penetration testers evaluate AWS environments.
Common AWS Security Weaknesses
Section titled “Common AWS Security Weaknesses”Examples include:
- Administrator accounts without MFA
- Long-lived access keys
- Wildcard IAM policies
- Public Amazon S3 buckets
- EC2 instances with public SSH access
- IMDSv1 enabled
- Overly permissive Security Groups
- Weak VPC segmentation
- Hardcoded AWS credentials
- Misconfigured EKS clusters
- Secrets stored in plaintext
- CloudTrail disabled
These weaknesses often combine into larger attack paths.
Enterprise Attack Path Example
Section titled “Enterprise Attack Path Example”Developer Access Key
↓
IAM User
↓
AssumeRole
↓
Administrator Role
↓
Amazon EC2
↓
Amazon S3
↓
Sensitive Customer DataA single misconfigured identity can lead to complete AWS account compromise.
AWS Penetration Testing Rules
Section titled “AWS Penetration Testing Rules”Professional testers should always:
- Obtain written authorization.
- Stay within the agreed scope.
- Validate findings without causing disruption.
- Collect evidence.
- Document every significant activity.
- Protect customer data.
- Report findings responsibly.
Ethical and legal compliance is fundamental.
Tools Used During AWS Assessments
Section titled “Tools Used During AWS Assessments”AWS Native
Section titled “AWS Native”- AWS CLI
- IAM Access Analyzer
- AWS Config
- CloudTrail
Open Source
Section titled “Open Source”- ScoutSuite
- PMapper
- Pacu
- Trivy
- Checkov
- kube-bench
- kube-hunter
General
Section titled “General”- jq
- curl
- Git
- Terraform
- Docker
- kubectl
Enterprise Engagement Lifecycle
Section titled “Enterprise Engagement Lifecycle”Kick-off Meeting
↓
Architecture Review
↓
Cloud Enumeration
↓
Security Assessment
↓
Attack Path Analysis
↓
Risk Assessment
↓
Executive Report
↓
Remediation
↓
RetestingThis lifecycle mirrors the process followed by enterprise consulting firms.
Best Practices
Section titled “Best Practices”- Review cloud architecture before testing.
- Focus on IAM before infrastructure.
- Assess attack paths rather than isolated vulnerabilities.
- Validate findings with evidence.
- Prioritize business impact.
- Follow least privilege principles.
- Produce clear executive and technical reports.
Common Mistakes
Section titled “Common Mistakes”Avoid:
- Starting without authorization.
- Ignoring IAM security.
- Assessing services in isolation.
- Focusing only on EC2.
- Ignoring logging and monitoring.
- Testing outside the approved scope.
- Reporting vulnerabilities without remediation guidance.
Knowledge Check
Section titled “Knowledge Check”1. What is the primary objective of AWS offensive security?
Section titled “1. What is the primary objective of AWS offensive security?”Answer: To identify and validate security weaknesses within customer-controlled AWS resources before they can be exploited by attackers.
2. Who is responsible for securing IAM users and roles?
Section titled “2. Who is responsible for securing IAM users and roles?”Answer: The customer. Under the AWS Shared Responsibility Model, customers are responsible for securing identities, permissions and cloud configurations.
3. Which AWS service is the most common attack target?
Section titled “3. Which AWS service is the most common attack target?”Answer: AWS Identity and Access Management (IAM), because identities and permissions control access to cloud resources.
4. Why are attack paths more valuable than isolated findings?
Section titled “4. Why are attack paths more valuable than isolated findings?”Answer: Attack paths demonstrate how multiple weaknesses can be chained together to compromise high-value assets, providing a clearer picture of business risk.
5. Why should CloudTrail and AWS Config be reviewed during an assessment?
Section titled “5. Why should CloudTrail and AWS Config be reviewed during an assessment?”Answer: They provide visibility into AWS activity and configuration changes, helping assess monitoring capabilities and supporting incident detection and forensic investigations.
Key Takeaways
Section titled “Key Takeaways”- AWS offensive security focuses on customer-controlled resources rather than AWS-managed infrastructure.
- Identity security is the foundation of AWS security and should be assessed first.
- Professional AWS penetration testing follows a structured methodology from reconnaissance through reporting.
- Attack-path analysis provides greater business value than isolated vulnerability identification.
- Understanding AWS architecture, services and shared responsibility is essential before performing hands-on assessments.
What’s Next?
Section titled “What’s Next?”In the next lesson, you will dive into AWS IAM Exploitation, learning how attackers abuse IAM users, roles, policies and trust relationships, and how penetration testers identify privilege escalation opportunities during enterprise AWS security assessments.
➡️ Next Lesson: Lesson 02 — IAM Exploitation