Pentest Notes

Cloud — Pentest Notes

A working checklist for cloud tests across AWS, Azure and Google Cloud, in roughly the order a test runs: scope it, find the tenant, work out who can do what, then look at the data and what gets logged. It grows with every post in the Cloud Journey. Everything below is lab and authorised-only, and where a technique has its own write-up it's linked.

0/9 done

01Scoping & recon

Translate cloud service names across AWS, Azure and Google Cloud before you scope

# VMs: EC2 = Virtual Machines = Compute Engine
# Object storage: S3 = Blob Storage = Cloud Storage
# Functions: Lambda = Azure Functions = Cloud Run functions
# Kubernetes: EKS = AKS = GKE   |   CDN: CloudFront = Front Door = Cloud CDN

Look for: Every service the client names mapped to its job, so nothing gets missed: PaaS (Elastic Beanstalk / App Service / App Engine), containers (ECS, Fargate / Container Apps / Cloud Run), file shares (EFS / Azure Files / Filestore), data warehouse (Redshift / Fabric, Synapse / BigQuery).

Gotcha: Common mistake: old names in reports. Use Entra ID (was Azure AD, 2023), Google Workspace (was G Suite, 2020), Cloud Run functions (was Cloud Functions, 2024).

#scoping#service-names#aws#azure#gcp → related write-up

Split Azure from Microsoft 365, and Google Cloud from Workspace, in the scope

# Azure / Google Cloud: config, IAM, networks, workloads
# M365 / Workspace: user access, sharing, email, tenant config

Look for: Separate scope lines for the infrastructure platform and the office suite, with the shared identity noted on both (one Entra ID tenant for Azure and M365, one Cloud Identity for Google Cloud and Workspace).

Gotcha: "We use Microsoft" can mean Azure, M365 or both. They need different access, tools and time. Ask before you price it.

#scoping#azure#m365#workspace → related write-up

Tell if a client uses Microsoft 365 or Google Workspace from MX records

dig +short MX example.com

Look for: <tenant>.mail.protection.outlook.com = Microsoft 365 (so an Entra ID tenant exists). smtp.google.com or aspmx.l.google.com = Google Workspace (so Cloud Identity exists).

Gotcha: A mail filter (Mimecast, Proofpoint) in front hides the real suite. Check SPF (dig +short TXT example.com) for include:spf.protection.outlook.com or include:_spf.google.com.

#recon#dns#m365#workspace → related write-up

Find a Microsoft Entra tenant ID from a company domain

curl -s https://login.microsoftonline.com/example.com/v2.0/.well-known/openid-configuration | jq -r .issuer

Look for: https://login.microsoftonline.com/<tenant-guid>/v2.0. The GUID is the tenant ID. No login needed.

Gotcha: An error means the domain isn't registered to any Entra tenant. Try the client's other domains.

#recon#entra-id#tenant#azure → related write-up

Check whether a Microsoft domain uses managed or federated sign-in

curl -s "https://login.microsoftonline.com/getuserrealm.srf?login=user@example.com&xml=1"

Look for: <NameSpaceType>Managed</NameSpaceType> = Entra ID checks passwords. Federated = sign-in goes to the client's own provider (ADFS, Okta), which then becomes part of the attack surface.

Gotcha: Quote the URL, or the shell treats & as a background operator and drops xml=1.

#recon#entra-id#federation#azure → related write-up

02Identity & access

Check whether a Microsoft 365 user can reach Azure in the same tenant

az login --allow-no-subscriptions
az account list -o table
az ad user list --query "length(@)"

Look for: Any subscription in az account list (an Azure role on an office user), and a user count from az ad user list, which means the account can read the whole directory.

Gotcha: Without --allow-no-subscriptions, az login can stop with an error for users with no Azure access, which looks like a dead end when the directory is still readable.

#identity#entra-id#m365#azure → related write-up

Check whether a Google Workspace admin can control the Google Cloud organisation

gcloud organizations list
gcloud organizations get-iam-policy ORG_ID

Look for: The organisation ID, and who holds roles/resourcemanager.organizationAdmin. A Workspace super admin can grant that role, which covers every project in the organisation.

Gotcha: Google advises keeping super admins out of day-to-day Google Cloud admin. Super admins used as daily cloud admins is a finding.

#identity#workspace#gcp#super-admin → related write-up

03Storage & data

List object storage in AWS, Azure and Google Cloud

aws s3 ls
az storage account list -o table
gcloud storage buckets list

Look for: Buckets (S3, Cloud Storage) and storage accounts (Azure) your identity can see. Note names that hint at backups, logs or exports.

Gotcha: An empty list means your identity can't list, not that there's no storage. Confirm which AWS accounts, Azure subscriptions and GCP projects are in scope.

#storage#s3#blob#cloud-storage → related write-up

04Logging & detection

Lock down shared cloud identity and spot cross-side recon

# Entra ID: default user permissions -> allowedToReadOtherUsers = false
# Watch: CloudTrail ListBuckets, Entra sign-ins to 'Microsoft Azure CLI' by office users, GCP GetIamPolicy on the organisation

Look for: Ordinary users unable to read the whole directory, Azure roles reviewed every quarter, separate admin accounts, two or three super admins on hardware keys. Alerts when an office user first signs in to the Azure CLI.

Gotcha: Audit logs are where the client sees your checks too. Agree test windows and source IPs up front.

#defence#detection#entra-id#audit-logs → related write-up

Nothing matches that filter. Clear the search, or tell me what to add.