Cloud penetration testing in 2026 is no longer a niche specialism — it’s a baseline expectation for senior pentesters working with any Indian enterprise that runs more than a handful of EC2 instances or App Service plans. The skill stack is genuinely different from traditional network or web pentesting: you’re attacking IAM mis-configurations, metadata services, managed-service integration boundaries, and SaaS-style identity flows rather than missing patches and weak passwords. This guide breaks down the AWS, Azure, and GCP attack surfaces that actually matter on a 2026 engagement, the tooling for each, and the methodology that converts a one-off finding into a full cloud compromise.
TL;DR — what’s different about cloud pentests
| Traditional pentest | Cloud pentest |
|---|---|
| Network-perimeter focus | IAM and identity-perimeter focus |
| Missing patches, weak passwords | Mis-scoped policies, overprivileged service principals |
| Lateral movement via SMB, WinRM | Lateral movement via role assumption, federation, managed identity |
| Persistence via scheduled tasks, services | Persistence via IAM users, OAuth apps, function URLs, key pairs |
| Tools: Nmap, Metasploit, Impacket, BloodHound | Tools: Pacu, ScoutSuite, Prowler, CloudFox, ROADtools, GCPBucketBrute |
| Rules of engagement: physical / network scope | Rules of engagement: subscription/account scope, cloud provider AUP |
| Skill bridge: CEH, OSCP+, network fundamentals | Skill bridge: Solutions Architect Associate + classic pentest skills + IAM literacy |
The most important conceptual shift: cloud pentesting is mostly IAM exploitation. If you understand identity primitives — principals, roles, federation, conditional access, scoped credentials — you can find production-grade findings in environments where the network perimeter is well-defended. If you don’t, you’ll spend your engagement port-scanning storage buckets and reporting low-severity informationals.
AWS pentesting — the methodology that works in 2026
AWS engagements break into four phases: enumeration, access expansion, lateral movement, and persistence / impact. Each has its own toolset.
Phase 1 — enumeration
Given a foothold (a leaked AccessKeyId/SecretKey pair from a public S3 bucket, a compromised CI/CD pipeline, an SSRF on an EC2 instance hitting the metadata service), the first step is mapping what the credential can actually do. Pacu’s iam__enum_permissions and CloudFox’s aws inventory give a rapid baseline of effective permissions. The standard Pacu modules to run on every engagement: iam__enum_users_roles_policies_groups, iam__bruteforce_permissions, s3__bucket_finder, ec2__enum, lambda__enum, secretsmanager__enum.
Phase 2 — access expansion
The high-frequency findings: (1) IAM users with iam:CreateAccessKey on themselves (account takeover), (2) Lambda functions with environment-variable secrets, (3) S3 buckets allowing s3:GetObject publicly with sensitive content (backups, customer PII, .env files committed by mistake), (4) RDS snapshots set to public, (5) AMIs with embedded SSH keys, (6) Secrets Manager / Parameter Store entries with overly broad read access. CloudFox’s aws permissions and aws role-trusts outputs guide you to the highest-leverage targets.
Phase 3 — lateral movement
Role assumption is the primary lateral mechanism. iam:PassRole + service permissions (Lambda, ECS Fargate, EC2 InstanceProfile) lets you escalate from a low-privilege user to a much higher-privileged service role by creating a resource and consuming its identity. Cross-account roles with weak trust policies (often left from prior auditor / consulting access) are the second pivot — Pacu’s iam__privesc_scan identifies the chain candidates.
Phase 4 — persistence and impact
Stealthy persistence options on AWS: additional access keys on existing IAM users, Lambda function URLs left enabled, S3 bucket policies adding the attacker as principal, CloudFormation StackSets in a backdoor account, federated SAML IdP additions on the IAM Identity Center. Detection-evasion technique: route all attacker traffic through an account region the customer doesn’t operate in — CloudTrail is per-region and many customers monitor only their primary region.
Azure pentesting — federated identity is the centre of gravity
Azure’s attack surface differs from AWS because of the tight integration between Entra ID (formerly Azure AD), the management plane (subscriptions, resource groups, RBAC), and the data plane (storage accounts, key vaults, function apps). A compromised user with the right roles can pivot across both planes in ways that don’t have an AWS equivalent.
The Entra ID attack surface
Identity is the perimeter. The most common Azure findings: (1) Conditional Access policies that exclude legacy authentication endpoints, allowing brute force or password spray against device-code OAuth flows, (2) Service principals with delegated Graph permissions like Application.ReadWrite.All or RoleManagement.ReadWrite.Directory — these allow tenant takeover in a single API call, (3) Guest users (B2B collaboration) with elevated rights on production subscriptions, (4) Multi-factor authentication unenforced on break-glass accounts.
ROADtools (specifically roadrecon) is the standard enumeration tool — pulls the entire Entra ID directory via Graph API into a local SQLite database, then runs analytical queries on roles, permissions, group memberships, conditional access. Microburst, AzureHound, and PowerZure cover the management-plane side.
Management plane to data plane pivots
Common chain on Azure: subscription Contributor role → create function app → set managed identity → use that managed identity to access Key Vault → exfiltrate stored secrets. Or: subscription Reader → list storage account keys via Microsoft.Storage/storageAccounts/listKeys/action if accidentally granted → access blob containers with sensitive data without further detection. The Stormspotter, Powerzure, and AzureHound BloodHound integrations help map these chains.
Hybrid AD / Azure AD pivots
Enterprises with hybrid identity (on-prem AD synced to Entra ID via AD Connect) introduce a sync-account attack surface. The AD Connect sync account has DCSync rights on on-prem AD and limited rights on Entra ID — compromise it, dump on-prem AD hashes via DCSync, then use those credentials in Entra ID where MFA isn’t enforced. Hybrid identity is one of the highest-impact findings in BFSI engagements where both clouds operate.
GCP pentesting — IAM and service-account inheritance
GCP’s IAM model differs from AWS in a critical way: roles are inherited down the resource hierarchy (Organization → Folder → Project → Resource). A binding at the Organization level applies to every project beneath it. This makes scoped findings rarer and broader-impact findings more common.
The high-value GCP findings: (1) Service accounts with iam.serviceAccountTokenCreator on themselves or other accounts (allows token-based privilege escalation), (2) Service accounts with broad project-level roles like roles/owner bound at the project level when only a single resource needed access, (3) Cloud Storage buckets with allUsers or allAuthenticatedUsers readers — almost identical to S3 public buckets but discovered with different tooling, (4) Cloud Functions with HTTP triggers and weak IAM bindings, (5) Compute Engine instances with overly-permissive default service accounts.
Tooling: GCPBucketBrute for storage enumeration, ScoutSuite multi-cloud, Prowler GCP module, GCP-IAM-Privilege-Escalation (rhino-security-labs) for the privesc paths. The CloudFox GCP module is newer than its AWS counterpart but stabilising rapidly.
Multi-cloud and SaaS — the underrated attack surface in 2026
Indian enterprises increasingly run multi-cloud (AWS for compute, Azure for identity, GCP for analytics, plus a handful of critical SaaS like Workday, Salesforce, ServiceNow). The attack surface between these planes — federated identity, OAuth integrations, secret-sharing via secret managers replicated across providers — is where 2026’s highest-impact findings sit.
Specific patterns to test for: (1) OAuth applications with delegated permissions across multiple providers (Slack-to-Workday integrations with broad scopes), (2) Secrets shared between AWS Secrets Manager and Azure Key Vault via replication scripts that store the cross-account credentials in plaintext, (3) Workload identity federation mis-configurations where AWS roles trust GCP service accounts without conditions, (4) GitHub Actions OIDC tokens granting access to cloud roles where the trust policy doesn’t constrain the repository or branch.
Rules of engagement — what you must agree before a single API call
Cloud pentests require explicit written authorization that goes beyond the customer agreeing — they need to comply with the cloud provider’s Acceptable Use Policy. AWS, Azure, and GCP all permit penetration testing of customer-owned resources without prior notification (AWS dropped the prior-notification requirement in 2019), but: denial-of-service testing remains prohibited, intentional disruption of shared infrastructure is prohibited, and testing of provider-managed services (RDS engine internals, App Service host OS, GCP load balancer infrastructure) is out of scope.
Always document in your statement of work: (1) explicit list of accounts, subscriptions, projects in scope, (2) prohibition on DoS / DDoS / brute-force-at-scale, (3) data-handling agreement for any extracted credentials or PII discovered, (4) commitment to rotate exposed credentials within twenty-four hours of discovery, (5) acknowledgment that the customer’s cloud-provider AUP applies to the engagement.
How Macksofy Trainings helps
Macksofy Trainings runs cloud-security bootcamps that pair traditional offensive-security depth (OSCP+ / OSWE-level enumeration and exploitation skills) with cloud-specific IAM exploitation labs across AWS, Azure, and GCP. Our cohorts cover the Pacu / CloudFox / ROADtools / Prowler tooling stack end-to-end with hands-on lab time in our internal multi-cloud range.
For the broader pentest skill stack that pairs with cloud specialism, see our OSCP+ 2026 update and CRTP vs CRTE vs OSEP guides. Programs are delivered from our Mumbai and Hyderabad classrooms plus full-time online cohorts. Get in touch via the contact form for the next cloud-security cohort date.
Frequently asked questions
Do I need to be a Solutions Architect before pentesting cloud?
Strongly recommended for AWS and Azure — the architecture knowledge accelerates exploitation thinking. The AWS Solutions Architect Associate, Azure Administrator Associate, or Google Cloud Engineer certs each take six-to-twelve weeks of part-time study and pay off heavily once you start the offensive side. GCP-focused pentesters often pair with the Google Professional Cloud Architect cert.
Can I pentest AWS without telling AWS first?
Yes, with caveats. Since 2019 AWS allows customer-side pentesting of in-scope services without prior notification. However, denial-of-service testing, simulated phishing of AWS personnel, and physical security testing remain prohibited. Always confirm the customer’s scope is within AWS’s allowed-services list before testing.
What’s the salary trajectory for cloud pentesters in India?
Mid-level cloud pentester (OSCP+ plus AWS Solutions Architect + two-to-three years of cloud engagement experience): ₹18-30 lakh CTC. Senior cloud-security consultants with red-team plus cloud specialism (OSCP+ + OSEP + CCSP or equivalent + four-to-six years): ₹35-55 lakh. Principal cloud security architects in BFSI / GCC: ₹65 lakh-1.2 crore.
Is CCSP necessary for cloud pentesting?
CCSP (Certified Cloud Security Professional from ISC²) is a governance-oriented certification — strong on architecture, audit, and compliance, light on offensive techniques. Useful for senior consultant roles where you’ll write cloud-security strategy alongside pentest work, but the hands-on side is better served by Pacu/CloudFox lab time and provider-specific architecture certs.
Which cloud should I learn first for pentesting?
AWS still has the largest enterprise footprint in India (~55% of cloud workloads), so AWS-first gives the broadest engagement market. Azure is critical for any consultant working with Microsoft-shop enterprises (large pockets of BFSI, MNC captives). GCP is the smallest but growing fastest in Indian startups and the analytics/data side of large enterprises. Plan for proficiency across all three over 24 months.
Are cloud pentest findings really worth more than network pentest findings?
Often yes. A misconfigured IAM policy that allows account takeover frequently scores Critical (CVSS 9.0+) where a missing patch on an internal Windows host scores Medium. Cloud findings also tend to compound — one cross-account role compromise opens the entire connected estate. The high impact justifies the steeper learning curve.
References
- AWS — Customer Support Policy for Penetration Testing
- Microsoft Azure — Penetration testing guidance
- Google Cloud — Cloud penetration testing rules
- Pacu — AWS exploitation framework (Rhino Security Labs)
- CloudFox — multi-cloud offensive enumeration (Bishop Fox)
- ROADtools — Azure AD / Entra ID enumeration
- Prowler — multi-cloud security assessment
- MITRE ATT&CK — Cloud Matrix
