When the next major Indian enterprise breach makes headlines, the post-mortem will almost certainly reveal the same culprit: not a sophisticated nation-state zero-day, not an undisclosed vulnerability in a critical library — but a misconfigured cloud resource that sat exposed for months, ignored by quarterly VAPT cycles and annual compliance audits.

According to IBM's Cost of a Data Breach Report, the average Indian enterprise cloud breach now costs ₹17.6 crore — and 78% of critical findings across cloud environments are misconfigurations, not exploitation of software vulnerabilities. The attack surface is not your code. It is your configuration.

This is not a theoretical risk. From publicly exposed S3 buckets containing KYC documents at fintech firms to unrestricted security groups in RBI-regulated banks, Indian cloud environments carry misconfigurations that attackers are actively scanning for — right now, at machine speed. And the tooling gap between traditional VAPT and real cloud attack surfaces is costing enterprises dearly.

78%
Of critical cloud findings are misconfigurations, not zero-days (IBM)
₹17.6Cr
Average Indian enterprise cloud breach cost (IBM, 2025)
65%
Of Indian enterprises cannot detect malicious packages in their cloud supply chain

The 5 Most Common Cloud Misconfigurations in Indian Enterprises

Across cloud assessments and red team engagements, the same categories of misconfigurations surface repeatedly — regardless of whether organisations run on AWS, Azure, or GCP.

1. Public S3 / Azure Blob Exposure. Object storage buckets configured for public access — or made public by developers during testing and never locked down. In India's fintech and healthcare sectors, we routinely find KYC documents, Aadhaar-linked records, and financial statements sitting in publicly readable buckets. A single misconfigured bucket in a 200-bucket environment is enough for a complete breach. Risk rating: Critical, Passive Discovery.

2. IAM Over-Privilege and Wildcard Permissions. Developers are provisioned with *:* policies for convenience that never gets revoked. Service accounts inherit human-user permissions. Lambda functions carry roles that can list all S3 buckets, read Secrets Manager values, and enumerate EC2 instances. A compromised Lambda becomes a keys-to-the-kingdom scenario instantly. Risk rating: Critical, Privilege Escalation Path.

3. Instance Metadata Service (IMDS) Abuse. EC2 and Azure VMs expose instance metadata at a well-known internal IP. Without IMDSv2 enforcement, a server-side request forgery (SSRF) vulnerability anywhere in your application lets an attacker steal IAM credentials directly from the metadata endpoint — no authentication required. This is one of the most commonly exploited cloud-specific attack chains. Risk rating: High, SSRF Chain to Credential Theft.

4. Unrestricted Security Groups and NACLs. Security groups allowing inbound 0.0.0.0/0 on ports 22 (SSH), 3389 (RDP), 5432 (PostgreSQL), or 27017 (MongoDB) are disturbingly common in Indian enterprise cloud environments. Often created for temporary debugging access, these rules persist for years. Attackers run automated scans across all AWS and Azure IP ranges daily. Risk rating: High, Direct Network Exposure.

5. Container Escape and Kubernetes RBAC Failures. Containers running as root, privileged pods without seccomp profiles, exposed Kubernetes dashboards without authentication, and overpermissioned service accounts that can create pods — these create container escape paths. An attacker who compromises a single pod can pivot to the host node and laterally across the cluster. RBAC configurations in managed Kubernetes (EKS, AKS, GKE) are almost always under-hardened. Risk rating: Critical, Lateral Movement and Node Compromise.

Why Traditional VAPT Misses Cloud Misconfigurations

Standard VAPT was designed for a different era — the era of on-premise servers, firewalled data centers, and fixed network perimeters. Cloud environments invalidate almost every assumption that traditional VAPT is built on.

A traditional VAPT engagement typically involves an external scanner, a few authenticated web application tests, and a network scan. What it does not test: IAM policy logic, cross-account trust relationships, service control policy (SCP) inheritance, bucket policies and ACL conflicts, metadata service reachability, or the behaviour of Lambda function execution roles. These are the vectors attackers actually use.

Consider the gap: VAPT will flag an outdated Apache version on your EC2 instance. But it will not tell you that the instance role attached to that server can read your entire production Secrets Manager vault, list all RDS snapshots, or assume roles in your partner accounts. The CVE is a distraction. The misconfiguration is the breach.

Cloud environments are also ephemeral. Infrastructure-as-code pipelines spin up and tear down resources daily. A VAPT done in March does not reflect your attack surface in August. The only way to stay current is continuous, automated cloud security testing — not point-in-time assessments.

Your cloud provider secures the infrastructure. You are responsible for everything you put in it — and most enterprises still have not fully internalized what that means.

What Cloud Red Teaming Actually Tests

Cloud red teaming is not a scanner run against your IP range. It is an adversarial simulation of a threat actor who has initial access to your environment — perhaps through a compromised developer credential, a phishing email, or a vulnerable web application — and is attempting to escalate privileges, move laterally, and exfiltrate data while evading detection controls.

A complete cloud red team engagement covers: IAM privilege escalation chains — mapping every path from a low-privilege identity to AdministratorAccess, including role chaining, policy boundary bypasses, and cross-account trust exploitation; data exfiltration path analysis — simulating the path from initial compromise to sensitive data exfiltration, including S3 enumeration, RDS snapshot access, and Secrets Manager harvesting; SSRF to IMDS credential theft — testing whether application-layer SSRF vulnerabilities can steal instance credentials from the metadata endpoint; container and Kubernetes escape testing — attempting breakout from container isolation to the underlying host and from a single pod to cluster-wide control via RBAC misconfigurations; detection and response validation — running real attack techniques and measuring whether your SIEM, CloudTrail alerts, and SOC detect and respond within acceptable windows; and supply chain attack surface evaluation — assessing third-party integrations, Lambda dependency trees, container image registries, and CI/CD pipeline access for injection points.

The RBI and CERT-In cloud audit requirements. CERT-In's 2022 directives brought real enforcement teeth to cloud security requirements that previously existed only on paper. RBI mandates cloud service risk assessment and annual third-party audit of cloud controls for all regulated entities. CERT-In requires mandatory reporting of cloud-related security incidents within 6 hours of detection. Penetration testing of cloud environments at least annually, with board-level reporting, is required for banks, insurance firms, large NBFCs, and designated market infrastructure. Enterprises that cannot demonstrate active cloud security testing with documented findings and remediation timelines are now exposed to regulatory action, not just breach risk.

How Arxiis Maps Your Full Cloud Attack Surface

Arxiis is autonomous AI red teaming built for the scale and complexity of modern Indian enterprise cloud environments. Unlike traditional VAPT tools that scan for CVEs, Arxiis reasons about your cloud configuration the way an attacker would — mapping privilege escalation paths, identifying data exfiltration routes, and testing detection controls — all without requiring manual rule configuration or signature updates.

The Arxiis cloud assessment operates in five stages. First, identity graph construction: Arxiis ingests your IAM policies, role trust relationships, and service control policies to build a complete identity graph revealing every privilege escalation path, running in minutes across accounts with thousands of IAM entities. Second, autonomous attack path simulation: the AI red team agent chains misconfigurations together the way a real attacker would, combining SSRF vulnerabilities with IMDSv1 exposure, overpermissioned instance roles, and public S3 buckets into complete kill chains with impact scoring at each stage. Third, continuous drift detection: cloud configurations change daily, and Arxiis monitors your environment continuously, alerting on new misconfigurations as they are introduced. Fourth, RBI and CERT-In audit-ready reporting: every finding is mapped to regulatory control requirements, with remediation guidance that DevSecOps teams can action directly. Fifth, detection and response stress testing: Arxiis runs real attack techniques against your cloud environment, measuring detection latency, alert fidelity, and incident response effectiveness.

The average Indian enterprise has 3–7 cloud accounts, 2–4 cloud providers, and dozens of service integrations. The attack surface is not a list — it is a graph.

Arxiis maps it completely, automatically, and continuously — so your security team is always operating on current intelligence, not a stale audit report.

Close your security gaps — continuously.