CyberFortify cloud penetration testing exploits IAM trust paths, federation flaws, container escapes and SSRF→STS chains across AWS, Azure and GCP - producing a report engineering can ship from and auditors will accept for SOC 2, ISO 27001 and PCI DSS.
// 01 What is cloud penetration testing?
Cloud penetration testing is the manual offensive assessment of an AWS account, Azure subscription or GCP project - including the IAM systems binding them and the workloads running on top.
It is not a CSPM scan and not a checklist audit. It demonstrates attacker impact by exploiting the gaps and trust relationships posture tools cannot reason about.
The modern cloud perimeter is identity. CyberFortify engagements typically begin from an assumed-breach position - a low-privilege role or leaked credential - and chain forward to whatever the IAM graph allows: cross-account roles, federated trust, exposed metadata, runaway service principals.
// 02 AWS, Azure & GCP - what changes between providers
The same exploitation primitives appear in all three clouds, but the surface differs. CyberFortify scopes per-provider, with a senior tester who specialises in the platform leading each.
AWS pen testing
Account · Org · Control Tower · STSAzure pen testing
Tenant · Subscription · Mgmt GroupGCP pen testing
Org · Folder · Project hierarchy// 03 Cloud kill chain
Real cloud breaches follow a recognisable shape. CyberFortify exercises the full chain - not just the entry point - because realistic impact is established by reaching the data, not by demonstrating the foothold.
Identity pivot
STS AssumeRole, managed-identity token, GH Actions OIDC, service-account key.
Privilege escalation
iam:PassRole, actAs, role-assignment write, attribute-based-access misuse.
Lateral movement
Cross-account roles, peered VPCs, container escape, K8s service-account token theft.
Data access
S3 / GCS / Blob exfil, RDS snapshot, KMS decrypt, BigQuery / Cosmos read.
Persistence & cover
Backdoor IAM user, Lambda layer plant, CloudTrail / Activity Log gap, GuardDuty muting.
// 04 Container, Kubernetes & serverless scope
Managed Kubernetes (EKS, AKS, GKE), container platforms and serverless functions are tested as first-class cloud surfaces - not as out-of-scope appendages. The unit of compromise has shifted from "host" to "workload identity."
RBAC & service accounts
Cluster role and role-binding review, default-namespace SA token reachability, service-account-token automount audit, impersonation chains.
Pod-spec abuse
Privileged: true, hostPID / hostNetwork / hostPath, capabilities, securityContext bypass, hostPath escapes to node-IAM.
Workload identity
EKS IRSA, GKE Workload Identity, AKS Pod Identity / Workload Identity - pod→cloud token theft pathways.
Supply chain & admission
Image signing (cosign / Notary), admission controllers (OPA / Kyverno / Gatekeeper), registry trust, base-image CVE pressure.
Serverless
Lambda / Cloud Functions / Azure Functions environment variable exfil, function-URL / HTTP trigger abuse, layer poisoning, cold-start side channels.
IaC & CI/CD
Terraform / Bicep / CloudFormation drift, GitHub Actions OIDC role over-trust, self-hosted runner abuse, build-time secret leakage.
// 05 Common cloud pen test findings
Recurring real-engagement findings, mapped to MITRE ATT&CK for Cloud techniques. Treat as a self-audit checklist before scoping.
iam:PassRole → admin role
Identity with the ability to launch a workload (EC2, Lambda, ECS task) under a high-privilege role becomes account-admin within minutes. Most common AWS privesc path.
T1078.004 / T1098.001SSRF → IMDS → STS
Application-layer SSRF reaches the EC2 metadata endpoint, harvests instance role credentials, pivots to AWS APIs. IMDSv1 still enabled on production fleet.
T1552.005 / T1078.004GitHub Actions OIDC over-trust
Cloud trust policy accepts any branch / any repo from the org, allowing a fork or low-trust repo to assume a production role.
T1078.004 / T1199Public S3 / GCS / Blob with PII
Storage container readable to anonymous internet, indexed by buckets-search engines. Data classification policy not enforced via guardrail.
T1530K8s service-account token automount
Pod compromise yields a service-account token reachable from the application container. Token grants list / get on cluster-wide secrets.
T1552.007Conditional Access bypass via legacy auth
Entra ID Conditional Access enforces MFA for modern auth but legacy protocols remain enabled, allowing username + password from any geography.
T1078.004 / T1556.006// 06 Pen test vs CSPM, scanner & audit
Different tools verify different properties. Cloud pen testing is complementary to CSPM, vulnerability scanning and configuration audit - it is not a replacement for any of them, and none of them are a replacement for it.
// 07 Cloud pen testing methodology
CyberFortify's seven-phase engagement, tuned for cloud. Default posture is assumed-breach: a low-privilege role or read-only credential, the way real intrusions actually start.
Pre-engagement
Provider notification where required, scope account list, workload inventory, blast-radius boundaries.
Provider compliantReconnaissance
Account / org enumeration, IAM graph extraction, exposed-resource discovery, federation map.
Read-only firstVulnerability identification
Manual analysis primary; Pacu, ScoutSuite, Prowler, kube-hunter, Peirates as targeted aids.
Manual primaryExploitation & lateral movement
Bounded, documented chains - IAM escalation, SSRF→STS, container escape, federation abuse.
ControlledReporting
CIS Benchmark cross-reference, ATT&CK technique IDs, CVSS v3.1, fix-by-priority.
Audit-readyFree remediation retest
Updated attestation issued after engineering closes findings.
Included// 08 Standards & compliance mapping
| Standard | Reference | What our test covers |
|---|---|---|
| MITRE ATT&CK for Cloud | IaaS, SaaS, M365, Containers matrices | Adversary technique mapping per finding |
| SOC 2 | CC6.1, CC6.6, CC7.1 | Logical access, boundary protection, detection |
| ISO/IEC 27001:2022 | A.5.23, A.8.20, A.8.21 | Cloud services, network & segregation |
| PCI DSS v4.0 | Req 1, 11.4, 6.4.3 + cloud guidance | Cardholder environments hosted in cloud |
| NIST CSF 2.0 | ID.AM, PR.AC, DE.CM | Asset, identity, continuous monitoring |
| CIS Benchmarks | AWS / Azure / GCP / Kubernetes | Configuration hardening cross-reference |
// 09 Frequently asked questions
How is cloud pen testing different from a CSPM tool?
A CSPM tool emits a list of policy violations. Cloud penetration testing exploits the violations, validates real attacker impact, and chains misconfigurations into attack paths a posture tool cannot reason about - for example, a low-severity SSRF combined with an over-permissive instance role becoming full account takeover.
Do you need provider authorisation to test?
CyberFortify follows each provider's current penetration-testing policy. AWS, Azure and GCP are largely permissive for customer-owned resources without prior notification, with documented exceptions for shared infrastructure. Provider-specific compliance is documented during scoping.
Do you test Kubernetes / EKS / AKS / GKE?
Yes by default. RBAC, service-account boundaries, pod-spec abuse, supply-chain (signed images, admission controllers), network policies and cluster-scoped resources are all in scope. Container-escape testing is performed where cluster topology permits.
Is identity federation in scope?
Yes. SAML / OIDC, GitHub Actions OIDC role chains, third-party SaaS-to-cloud OAuth scopes and cross-account assume-role chains are all tested. Identity is the modern cloud perimeter and where most successful attacks pivot.
Do you test the application running on the cloud as well?
On request. Most cloud engagements pair with a web application pen test or API security assessment, since cloud and application risk frequently chain.
How long does a cloud pen test take?
Seven to fourteen business days of active testing depending on account count, services in scope and Kubernetes depth. Total elapsed time including scoping, reporting and the free remediation retest typically spans four to six weeks.