Key Takeaways
- Cloud breaches are almost always IAM, not zero-day. Over-privileged roles, public S3 buckets, exposed access keys, and metadata-API abuse are the recurring patterns.
- AWS, Azure and GCP each have a distinct attack model. Tooling and findings differ. A unified report that does not separate them is doing the customer a disservice.
- Metadata APIs (IMDSv1 on AWS, Azure Instance Metadata, GCP metadata server) are the single most-exploited cloud primitive when SSRF is present in the application layer.
- Serverless (Lambda, Functions, Cloud Run) shifts risk from compute to triggers and IAM. The runtime is short-lived, the blast radius is the role policy.
- Provider rules of engagement apply. AWS pentest is generally allowed without prior notice, Azure requires explicit acknowledgement for some activities, GCP similar. We document the legal boundary at the start of every engagement.
Why Cloud Pentest Is a Distinct Discipline
A traditional network pentest tests packets between hosts. A cloud pentest tests packets, plus identities, plus configuration, plus event triggers, plus serverless invocations, plus container orchestrators, plus storage policies, plus encryption keys. The attack surface expanded by an order of magnitude and the primary attack vector shifted from network to identity.
Almost every major Indian cloud breach in 2024 and 2025 followed a recognisable pattern: an over-privileged IAM role on a workload, an SSRF or RCE in the application allowed the attacker to query the metadata API for temporary credentials, those credentials had wildcard permissions on S3 or Cosmos or Cloud Storage, customer data was exfiltrated. Every Codesecure cloud pentest starts from this attack chain and works outward.
Methodology: External, Internal, Configuration Review
Our cloud pentest runs in three streams in parallel. External pentest tests the internet-facing footprint of the cloud estate (load balancers, API gateways, CloudFront and Azure Front Door distributions, GCP global LBs). Internal pentest assumes access to one workload (an EC2, an Azure VM, a GKE pod) and walks the identity-graph from there. Configuration review uses read-only API access (AWS SecurityAudit, Azure Reader plus Security Reader, GCP Viewer) plus tools like Prowler, ScoutSuite and Cloudsploit to enumerate misconfigurations across the entire account or subscription.
Every finding is mapped to the cloud-native security standard for that provider: AWS Well-Architected Security Pillar, Azure Security Benchmark v3, and GCP CIS Benchmarks. Customers get a report their auditor and their cloud engineering team can both read.
Need a Pentest Engagement?
Codesecure runs manual, OSCP-led VAPT for Indian businesses across web, API, mobile, network, cloud, AD, IoT, wireless and thick client. ISO/IEC 27001:2022 certified delivery with named consultants and a free retest within 90 days.
See Pentest Services →AWS Pentest Specifics
AWS workloads typically expose risk through IAM, S3, EC2 metadata, Lambda, ECS or EKS containers, and IAM federation.
IAM Abuse
We enumerate roles, users, policies, and the implicit permission graph with Pacu, Prowler, and IAM Vulnerable. Path-finding tools like CloudPEASS, principalmapper and aws-escalate identify privilege-escalation paths (iam:CreateAccessKey on another user, iam:PassRole into a higher-privileged role, sts:AssumeRole with weak condition checks, lambda:UpdateFunctionCode on a function attached to a more-privileged role). A typical AWS pentest surfaces 5 to 15 escalation paths in mid-size Indian SaaS estates.
S3 and Storage
Public-read buckets are still found in roughly 1 in 4 engagements despite Block Public Access defaults. More commonly, buckets are private but accessed through over-permissive IAM (s3:GetObject on Resource '*'). We test for bucket policy bypass, cross-account ACL drift, and pre-signed URL handling. CSV exports of bucket inventories accompany every report.
EC2 Metadata and Lambda
IMDSv1 is still enabled on many older workloads despite IMDSv2 being available since 2019. Any SSRF in an EC2-hosted application is one curl away from temporary IAM credentials. Lambda functions inherit IAM through their execution role; we walk the trigger graph (S3 PutObject, SQS message, EventBridge schedule) to identify functions that an untrusted input can invoke against an over-privileged role.
Azure Pentest Specifics
Azure is identity-first. Entra ID (Azure AD) controls almost everything, and the relationship between Entra ID roles, Azure RBAC roles, and resource-specific permissions creates a layered model where a low-Entra-role user can hold high-Azure-RBAC permissions on a subscription.
Our Azure methodology uses AzureHound for graph collection, ROADrecon for unauthenticated and authenticated Entra enumeration, MicroBurst PowerShell modules for service-specific abuse, and Stormspotter for visualisation. Common high-impact findings: subscriptions with Owner role granted to dev groups, storage accounts with anonymous blob containers, Key Vault access policies allowing keys list and get to broad groups, Managed Identities assigned beyond least privilege, and Conditional Access policies that exclude legacy authentication endpoints. App Service and Function Apps frequently expose deployment slots, FTP credentials and kudu consoles that bypass the production WAF.
GCP Pentest Specifics
GCP IAM is hierarchical: organisation, folder, project, resource. Inherited permissions cascade unless explicitly broken, which creates surprising exposure. Service accounts and their keys remain the dominant credential surface; default Compute Engine service account has Editor-on-project in many older projects, which is effectively domain admin for GCP.
Our methodology uses GCPBucketBrute for public storage discovery, Hayat and Forseti for configuration review, gcp_enum and gcp_misc for service-account abuse, and the official Cloud Asset Inventory for ground truth. Cloud Functions and Cloud Run inherit service-account permissions in the same way Lambda does; we walk the trigger graph end to end. Notably, GCP metadata server requires the Metadata-Flavor: Google header by default, which mitigates several SSRF patterns that hit AWS IMDSv1.
Stuck on Scope or Compliance Pressure?
Whether you need pentest for SOC 2, ISO 27001, RBI, a customer questionnaire or pure proactive testing, our VAPT lead is available for a 30-minute free scoping call. No obligation, no slideware.
Talk to a Pentest Lead →Containers, Kubernetes and Serverless
Cloud-native workloads concentrate risk in orchestrators. EKS, AKS and GKE clusters carry their own RBAC and admission-controller risk, separate from the underlying cloud IAM. Where the customer runs Kubernetes, we run a dedicated Kubernetes pass (see our separate Kubernetes pentest guide) alongside the cloud engagement.
Serverless shifts the conversation. Lambda, Functions and Cloud Run have no persistent OS layer to harden. Risk concentrates in the IAM role attached to the function, the triggers that can fire the function, and the dependencies bundled into the deployment package. Static analysis of the deployment package (npm, pip, go modules) for known-vulnerable libraries complements the runtime testing.
Provider Rules of Engagement and Legal Boundary
AWS allows penetration testing of customer-owned resources without prior approval for most services, with explicit exclusions (no DNS zone walking on Route 53, no DoS, no testing of AWS-managed services like RDS internals). Azure requires customers to follow the Microsoft Cloud Penetration Testing Rules of Engagement and to acknowledge them. GCP allows pentest on customer-owned resources without notice, with similar exclusions on managed services and DoS. We document the chosen provider's rules in the engagement letter so the legal team has a clean record.
Throughout every engagement we run only against the customer's accounts, never against other tenants, and never use techniques that risk the shared cloud platform itself.
Reporting, Re-Test and Compliance Mapping
Every cloud report includes: an attack-path diagram per provider, prioritised findings with CVSS v3.1 and provider-native severity, IAM exposure summary (over-permissive roles, dormant access keys, service principal sprawl), storage exposure summary (public, semi-public, cross-account), and a remediation roadmap segmented by quick wins (under 1 day), tactical (1 to 4 weeks) and structural (1 to 3 months).
Mapping covers ISO/IEC 27001:2022 Annex A, ISO 27017 cloud controls, SOC 2 CC6 and CC7, CIS Cloud Benchmarks (AWS / Azure / GCP), and where relevant the RBI cloud computing framework for regulated Indian banks. Free re-test within 90 days is standard.
Frequently Asked Questions
Do we need to notify AWS, Azure or GCP before you pentest?
AWS and GCP allow testing of customer-owned resources without notice. Azure requires acknowledgement of the Microsoft Cloud Penetration Testing Rules of Engagement. Codesecure handles the documentation as part of the engagement kickoff. We never run DoS-class techniques or test the provider's own services.
Can you test our cloud without giving you admin access?
Yes. Most engagements use read-only API access (AWS SecurityAudit, Azure Reader plus Security Reader, GCP Viewer) for configuration review plus a low-privilege user for the assumed-compromise track. We avoid administrative credentials where possible.
How does cloud pentest differ from cloud configuration audit?
An audit confirms whether each Annex A or CIS control is configured. A pentest demonstrates the actual attack path through the configuration. Most enterprise clients run an audit annually and a pentest annually; the pentest narrows the audit to the gaps that matter.
Do you test our applications running in the cloud as well?
Yes, where in scope. We bundle web, API and mobile pentest of the cloud-hosted applications with the cloud configuration testing, so the report walks the full chain from application input to cloud data exposure. Many SSRF-to-metadata-to-S3 findings only surface this way.
What does cloud pentest cost in India?
A single-cloud engagement (one of AWS, Azure or GCP) for a mid-size SaaS or enterprise runs INR 4 to 10 lakh depending on account count and resource footprint. Multi-cloud and complex hybrid setups run higher. Codesecure provides fixed-price proposals after scoping.
Do you provide cloud pentest evidence for SOC 2 and ISO 27001 audits?
Yes. Our cloud reports are written to satisfy SOC 2 Trust Services Criteria evidence requirements, ISO 27001 Annex A control evidence, and customer security questionnaire responses. Most clients submit our report directly to their auditor.
Test Your Cloud The Way Attackers Will
Codesecure delivers cloud pentest across AWS, Azure and GCP for Indian SaaS, fintech and enterprise clients. ISO/IEC 27001:2022 certified delivery, named OSCP consultants, provider-rules-of-engagement compliant, free retest within 90 days.
