Cloud Vulnerabilities

Shared Responsibility Model

Cloud Provider:
  ├── Physical security (data center)
  ├── Hypervisor / host OS
  ├── Managed service infrastructure
  └── Network infrastructure

Customer:
  ├── IAM (who can access what)
  ├── Data classification & encryption
  ├── Application security
  ├── Network controls (security groups, NACLs)
  └── OS / runtime patching (IaaS)

If you misconfigure any customer responsibility → YOUR problem

Misconfigured Storage

S3 Bucket Misconfiguration (AWS)

- Public read/write on bucket containing sensitive data
- Overly permissive bucket policy
- ACL set to "public" unintentionally

Real incidents:
- Capital One breach (2019): misconfigured WAF + SSRF → S3 exfiltration
- Many data leaks via "list bucket" permissions on S3

Checks:
aws s3api get-bucket-acl --bucket <bucket-name>
aws s3api get-bucket-policy --bucket <bucket-name>

Mitigations:
- Block Public Access settings (BPA) — enable at account level
- S3 bucket versioning + MFA delete
- CloudTrail logging on S3

IAM Misconfigurations

Common mistakes:
- Root account used for day-to-day operations
- Access keys embedded in code / committed to GitHub
- Overly broad policies (Action: "*", Resource: "*")
- Unused accounts with high privileges
- No MFA on privileged accounts

Principle of Least Privilege:
- Attach only needed permissions
- Use IAM roles (not users) for service-to-service
- Use SCP (Service Control Policies) in AWS Organizations
- Regular access reviews (IAM Access Analyzer)

Leaked Credentials

Common sources:
- AWS keys committed to GitHub → scraped by bots within seconds
- .env files exposed in web root
- CI/CD pipeline logs containing secrets
- Docker images with hardcoded credentials

Prevention:
- git-secrets, truffleHog, GitGuardian (pre-commit scanning)
- AWS Secrets Manager / HashiCorp Vault for secret storage
- Short-lived credentials (STS AssumeRole / OIDC)
- Rotate keys immediately on exposure; audit CloudTrail for use

Cloud Metadata Service Attacks

Cloud instances expose metadata via a link-local address.

# AWS IMDSv1 (vulnerable to SSRF)
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Returns temporary access keys for the instance role
# Attacker via SSRF can steal these and act as the instance

Mitigations:
- Require IMDSv2 (session-oriented, SSRF-resistant)
aws ec2 modify-instance-metadata-options \
  --instance-id i-xxx \
  --http-tokens required

Container / Kubernetes Misconfigurations

Risks:
- Exposed Kubernetes API server (port 6443) without auth
- Pods running as root
- No network policies → flat cluster network
- Secrets stored as base64 in ConfigMaps (not encrypted)
- RBAC misconfiguration: wildcard permissions

kubectl checks:
kubectl auth can-i --list --as=system:anonymous
kubectl get roles,rolebindings -n kube-system

Mitigations:
- Enable RBAC + audit logging
- Use OPA Gatekeeper / Kyverno for policy enforcement
- Encrypt etcd secrets at rest
- Run pods as non-root (securityContext.runAsNonRoot: true)

Serverless Vulnerabilities

AWS Lambda / GCP Cloud Functions / Azure Functions:

Risks:
- Event injection: malicious input via untrusted event sources
- Overly permissive execution roles
- Insecure dependencies in function packages
- Function timeout abuse (cost amplification)

Mitigations:
- Input validation on all event data
- Least privilege IAM role per function
- Dependency scanning (npm audit, Safety)
- Concurrency limits + dead letter queues

Cloud Attack Techniques

Cloud Security Monitoring

# AWS CloudTrail — key event types to alert on
- ConsoleLogin from unusual IP
- CreateUser, AttachUserPolicy, CreateAccessKey
- PutBucketPolicy, PutBucketAcl (storage changes)
- RunInstances in unexpected regions
- DescribeInstances by unknown principal

# GuardDuty findings (automated threat detection)
- UnauthorizedAccess:IAMUser/MaliciousIPCaller
- Recon:EC2/PortProbeUnprotectedPort
- CryptoCurrency:EC2/BitcoinTool