Companies migrate to cloud thinking "the provider handles security". They don't. The shared responsibility model means you're responsible for your configurations. And cloud misconfigurations are more common than ever.
Shared Responsibility Model
Understanding responsibilities is key:
- Provider: Physical security, infrastructure, hypervisor
- You: Data, applications, IAM, configurations, encryption
AWS/Azure/GCP gives you secure infrastructure. What you do with it is your responsibility.
IAM (Identity and Access Management) Attacks
IAM is the most common vector for full cloud environment compromise.
Overly Permissive Policies
- Wildcard policies: "Action": "*", "Resource": "*" - access to everything
- AdministratorAccess: On most accounts that don't need it
- PassRole abuse: Creating new roles with higher privileges
Privilege Escalation Techniques
- iam:CreateAccessKey: Creating keys for other users
- iam:CreateLoginProfile: Setting password for IAM user
- iam:UpdateLoginProfile: Changing another user's password
- iam:AttachUserPolicy: Attaching policies to other users
- sts:AssumeRole: Assuming role with higher permissions
- lambda:CreateFunction + iam:PassRole: Lambda with admin role
- ec2:RunInstances + iam:PassRole: EC2 with instance profile
IAM Analysis Tools
- Cloudsplaining: AWS IAM Security Assessment
- PACU: AWS Exploitation Framework
- ScoutSuite: Multi-cloud security auditing
- Prowler: AWS security best practices assessment
Metadata Service Attacks
Every cloud VM has access to metadata service at 169.254.169.254. SSRF vulnerability = cloud credentials.
AWS Instance Metadata Service (IMDS)
- IMDSv1: GET http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]
- IMDSv2: Requires token - but still vulnerable if application makes multiple HTTP requests
Azure Instance Metadata Service
- Endpoint: http://169.254.169.254/metadata/identity/oauth2/token
- Header: Metadata: true
GCP Metadata Server
- Endpoint: http://metadata.google.internal/computeMetadata/v1/
- Header: Metadata-Flavor: Google
Exploitation
- Find SSRF vulnerability in application
- Request to metadata endpoint
- Obtain temporary credentials (access key, secret key, token)
- Use credentials outside the environment (no logging on instance)
S3/Blob Storage Exposure
Publicly accessible buckets with sensitive data are still a common problem.
Types of Exposure
- Public bucket: Anyone can read/write
- Public objects: Bucket isn't public, but individual objects are
- Misconfigured ACL: Authenticated users (all AWS users) have access
- Bucket policy: Principal: "*" with s3:GetObject permission
What I Find in Public Buckets
- Database backups
- Source code
- Log files with credentials
- Configuration files
- User data (GDPR violation)
Protection
- S3 Block Public Access at account level
- Bucket policies instead of ACLs
- Encryption at rest and in transit
- Access logging enabled
- Versioning for recovery
Kubernetes Security
Kubernetes in cloud brings additional attack vectors.
Common Problems
- Privileged containers: Access to host system
- hostPID/hostNetwork: Sharing namespace with host
- Mounted service accounts: Access to Kubernetes API
- RBAC misconfigurations: Overly permissive service accounts
- Secrets in ConfigMaps: Unencrypted secrets
Kubernetes Privilege Escalation
- Pod escape: From container to host
- Service account token: Access to API server
- RBAC abuse: Creating privileged pods
- etcd access: Direct access to cluster data
Serverless Security (Lambda, Functions)
Serverless doesn't mean vulnerability-free.
Attack Vectors
- Event injection: Manipulating event payload
- Excessive permissions: Lambda with admin rights
- Environment variables: Secrets in env vars (visible in console)
- Cold start secrets: Credentials in /tmp during cold start
- Dependency vulnerabilities: Vulnerable libraries
Multi-cloud and Hybrid Attacks
Companies with multiple cloud providers or hybrid environments have additional challenges.
- Cross-cloud credential sharing: AWS keys in Azure VM
- VPN/Direct Connect: Bridging to on-premise network
- Azure AD Connect: Sync with AD = path to on-prem DC
- Inconsistent policies: Different security policies between environments
My Approach to Cloud Penetration Testing
- Reconnaissance: Discovering cloud resources (subdomains, S3 buckets, Azure blobs)
- IAM analysis: Mapping users, roles, policies, potential privilege escalation paths
- Network assessment: Security groups, NACLs, VPC peering, transit gateways
- Service configuration: S3, RDS, Lambda, API Gateway, EKS/AKS/GKE
- Data exposure: Publicly accessible data, encryption, backup policies
- Logging & monitoring: CloudTrail, CloudWatch, GuardDuty configuration