Lesson 12 — AWS Lateral Movement
Learning Objectives
Section titled “Learning Objectives”By the end of this lesson, you will be able to:
- Understand lateral movement in AWS.
- Identify common cloud lateral movement techniques.
- Assess IAM trust relationships.
- Review cross-account access.
- Analyze movement between AWS services.
- Detect enterprise attack paths.
- Recommend controls to prevent lateral movement.
Introduction
Section titled “Introduction”Compromising a single AWS resource is rarely the attacker’s final objective.
Instead, attackers attempt to move laterally across the cloud environment to gain access to more valuable systems, identities and data.
Unlike traditional enterprise networks, lateral movement in AWS primarily occurs through:
- IAM Roles
- Temporary Credentials
- AWS STS
- Cross-Account Trust
- EC2 Instance Profiles
- Lambda Execution Roles
- Amazon EKS (IRSA)
- Secrets Manager
- AWS Organizations
Understanding these attack paths is essential for professional cloud penetration testing.
Enterprise Scenario
Section titled “Enterprise Scenario”CloudNova Technologies has completed an AWS security assessment for FinSecure Bank Ltd.
The assessment confirmed that an attacker compromised a developer EC2 instance.
Management now wants to know:
- Can the attacker reach production?
- Can workloads move across AWS accounts?
- Are IAM roles overly permissive?
- Can Kubernetes workloads access AWS resources?
Your objective is to determine whether lateral movement is possible within the AWS environment.
What is Lateral Movement?
Section titled “What is Lateral Movement?”Lateral movement is the process of moving from one compromised identity or resource to another in order to reach higher-value assets.
Example:
Developer EC2
↓
IAM Role
↓
Amazon S3
↓
Secrets Manager
↓
Production DatabaseThe attacker expands access without exploiting additional external vulnerabilities.
Enterprise Lateral Movement Lifecycle
Section titled “Enterprise Lateral Movement Lifecycle”Initial Access
↓
Credential Discovery
↓
Privilege Escalation
↓
Lateral Movement
↓
Resource Discovery
↓
Sensitive Data Access
↓
Persistence
↓
ImpactLateral movement often follows privilege escalation and precedes data theft.
Common AWS Lateral Movement Paths
Section titled “Common AWS Lateral Movement Paths”Attackers commonly pivot between:
- IAM Users
- IAM Roles
- AWS STS
- Amazon EC2
- Amazon S3
- AWS Lambda
- Amazon EKS
- Secrets Manager
- Systems Manager
- Cross-Account Roles
- AWS Organizations
IAM Role Pivoting
Section titled “IAM Role Pivoting”One of the most common techniques is abusing IAM roles.
Example:
Compromised IAM User
↓
sts:AssumeRole
↓
Administrator Role
↓
Production AccountReview:
- Trust relationships
- External principals
- Wildcard permissions
- Role chaining
EC2-Based Lateral Movement
Section titled “EC2-Based Lateral Movement”Attackers frequently pivot through EC2 instances.
Compromised EC2
↓
Instance Profile
↓
IAM Role
↓
AWS APIs
↓
Amazon S3
↓
Secrets ManagerReview:
- Instance profiles
- Attached IAM roles
- Metadata service configuration
- Security Groups
Lambda-Based Lateral Movement
Section titled “Lambda-Based Lateral Movement”A compromised Lambda function can access multiple AWS services.
Lambda Function
↓
Execution Role
↓
Amazon DynamoDB
↓
Secrets Manager
↓
Amazon RDSAssess:
- Execution role permissions
- Environment variables
- Function URLs
- Event sources
Kubernetes (IRSA) Lateral Movement
Section titled “Kubernetes (IRSA) Lateral Movement”Amazon EKS integrates with IAM through IAM Roles for Service Accounts (IRSA).
Compromised Pod
↓
Service Account
↓
IAM Role (IRSA)
↓
Amazon S3
↓
Secrets Manager
↓
Production ResourcesReview:
- Service Accounts
- IAM trust policies
- RBAC permissions
- Namespace isolation
Secrets Manager Pivoting
Section titled “Secrets Manager Pivoting”Secrets Manager often contains credentials that enable access to additional services.
Examples:
- Database credentials
- API keys
- SSH keys
- OAuth tokens
- Third-party cloud credentials
Review IAM permissions that allow:
secretsmanager:GetSecretValueCross-Account Lateral Movement
Section titled “Cross-Account Lateral Movement”Large enterprises commonly allow trusted access between AWS accounts.
Example:
Development Account
↓
AssumeRole
↓
Shared Services
↓
Production Account
↓
Administrator RoleReview:
- Trust policies
- External accounts
- SCP restrictions
- Least privilege
AWS Organizations
Section titled “AWS Organizations”Poor governance can enable organization-wide movement.
Management Account
↓
Shared Services
↓
Production
↓
Security Account
↓
Logging AccountReview:
- Organization Units (OUs)
- Service Control Policies (SCPs)
- Delegated administrators
- Cross-account roles
Systems Manager (SSM)
Section titled “Systems Manager (SSM)”AWS Systems Manager may provide access to multiple EC2 instances.
Review:
- Session Manager permissions
- Managed instances
- IAM roles
- Fleet Manager access
Unrestricted SSM access can significantly expand an attacker’s reach.
Amazon ECR
Section titled “Amazon ECR”Container images stored in Amazon ECR may contain:
- Embedded credentials
- Secrets
- Application configuration
- Vulnerable software
Review:
- Repository permissions
- Image scanning
- Public repositories
Network-Based Lateral Movement
Section titled “Network-Based Lateral Movement”Attackers also evaluate:
- VPC Peering
- Transit Gateway
- Shared VPCs
- Security Groups
- Network ACLs
Example:
Compromised EC2
↓
VPC Peering
↓
Production VPC
↓
Application ServerWeak segmentation increases the risk of lateral movement.
Enumeration Commands
Section titled “Enumeration Commands”List IAM roles
aws iam list-rolesRetrieve role details
aws iam get-role \--role-name ROLE_NAMEList EC2 instances
aws ec2 describe-instancesList Lambda functions
aws lambda list-functionsList Secrets
aws secretsmanager list-secretsList Kubernetes Service Accounts
kubectl get serviceaccounts -AList Role Bindings
kubectl get clusterrolebindingsList Organizations Accounts
aws organizations list-accountsEnterprise Attack Path
Section titled “Enterprise Attack Path”Developer Laptop
↓
Compromised EC2
↓
IAM Role
↓
Secrets Manager
↓
Production Database Credentials
↓
Amazon RDS
↓
Customer RecordsThis demonstrates how attackers chain multiple AWS services together to achieve their objectives.
Enterprise Assessment Workflow
Section titled “Enterprise Assessment Workflow”Review IAM
↓
Review EC2
↓
Review Lambda
↓
Review Kubernetes
↓
Review Secrets Manager
↓
Review Cross-Account Access
↓
Review AWS Organizations
↓
Identify Attack Paths
↓
Validate Lateral Movement
↓
Document FindingsDetecting Lateral Movement
Section titled “Detecting Lateral Movement”Security teams should monitor for:
- Unusual
sts:AssumeRoleactivity - Cross-account access
- IAM role changes
- Unexpected Secrets Manager access
- New Kubernetes Service Accounts
- Privileged Pod creation
- Unusual Systems Manager sessions
- Access to production from development environments
- New trust relationships
CloudTrail, GuardDuty and Security Hub should generate alerts for suspicious identity and access behavior.
Common Enterprise Findings
Section titled “Common Enterprise Findings”Examples include:
- Excessive
sts:AssumeRolepermissions - Shared IAM roles
- Weak IRSA configuration
- Public EC2 instances with privileged roles
- Secrets accessible to multiple applications
- Unrestricted Systems Manager access
- Missing Service Control Policies
- Flat Kubernetes RBAC model
- Weak network segmentation
- Excessive cross-account trust
Security Best Practices
Section titled “Security Best Practices”- Apply least-privilege IAM policies.
- Restrict
sts:AssumeRole. - Use dedicated IAM roles for workloads.
- Limit cross-account trust relationships.
- Enforce namespace isolation in Kubernetes.
- Secure Secrets Manager with resource policies.
- Segment VPCs using Network Policies and Security Groups.
- Enable CloudTrail organization-wide.
- Continuously review IAM trust relationships.
- Monitor abnormal identity behavior with GuardDuty.
Common Mistakes
Section titled “Common Mistakes”Avoid:
- Sharing administrator IAM roles.
- Allowing unrestricted role assumption.
- Granting workloads broad access to Secrets Manager.
- Ignoring Kubernetes RBAC reviews.
- Allowing unrestricted VPC peering.
- Sharing AWS accounts across environments.
- Failing to monitor cross-account activity.
Knowledge Check
Section titled “Knowledge Check”1. What is lateral movement in AWS?
Section titled “1. What is lateral movement in AWS?”Answer: Lateral movement is the process by which an attacker expands access from one compromised AWS resource or identity to additional services, accounts or workloads to reach higher-value assets.
2. Why is sts:AssumeRole frequently abused?
Section titled “2. Why is sts:AssumeRole frequently abused?”Answer: sts:AssumeRole allows temporary access to IAM roles. Weak trust relationships or excessive permissions can enable attackers to pivot into more privileged roles.
3. How can Kubernetes contribute to lateral movement?
Section titled “3. How can Kubernetes contribute to lateral movement?”Answer: Compromised Pods using Service Accounts with excessive IRSA permissions can access AWS resources such as Amazon S3, Secrets Manager or DynamoDB, allowing attackers to move beyond the cluster.
4. Why should cross-account trust relationships be reviewed?
Section titled “4. Why should cross-account trust relationships be reviewed?”Answer: Weak or overly permissive trust relationships can allow attackers to move between AWS accounts and compromise production environments from lower-trust accounts.
5. How can organizations reduce the risk of lateral movement?
Section titled “5. How can organizations reduce the risk of lateral movement?”Answer: By enforcing least privilege, restricting AssumeRole permissions, segmenting networks, protecting secrets, implementing strong RBAC and continuously monitoring identity activity.
Key Takeaways
Section titled “Key Takeaways”- Lateral movement is one of the most important phases of a cloud attack because it enables attackers to expand their access and reach high-value assets.
- IAM roles, temporary credentials and trust relationships are the primary mechanisms used for movement within AWS.
- Amazon EKS, Lambda, EC2 and Secrets Manager are common pivot points during enterprise cloud attacks.
- Strong identity governance, network segmentation and continuous monitoring significantly reduce lateral movement opportunities.
- Enterprise cloud penetration tests should always identify and validate potential lateral movement paths before concluding an assessment.
What’s Next?
Section titled “What’s Next?”In the next lesson, you will explore Lesson 13 — Enterprise AWS Attack Chains, where you will combine reconnaissance, privilege escalation, persistence and lateral movement into complete real-world attack chains that mirror advanced cloud threats and enterprise penetration testing engagements.
➡️ Next Lesson: Lesson 13 — Enterprise AWS Attack Chains