10 Cloud Misconfigurations Causing Data Breaches in Indian Firms

Why Misconfiguration Is India’s Biggest Cloud Security Problem

When Indian businesses suffer cloud-related data breaches, the post-incident investigation almost always arrives at the same uncomfortable conclusion: the breach was not the result of an advanced persistent threat, a nation-state actor, or an exploit that nobody could have anticipated. It was the result of a misconfiguration — a gap between how the cloud environment should have been set up and how it actually was.

This pattern is not unique to India, but it is particularly acute here. The combination of rapid cloud adoption timelines, a shortage of cloud security expertise in the talent market, intense pressure to ship products quickly, and the genuine complexity of modern cloud environments creates a perfect condition for misconfiguration to accumulate faster than it is remediated.

The consequences are not theoretical. Publicly accessible databases containing millions of customer records. Storage buckets with sensitive financial documents open to anyone with a browser. API keys embedded in public repositories giving attackers unrestricted access to production infrastructure. These incidents happen to Indian firms of every size and sector — and they happen regularly.

What makes this particularly frustrating from a security standpoint is that every misconfiguration on this list is entirely preventable. None requires exotic security expertise to fix. All of them are caught routinely by cloud security assessments conducted by firms like FactoSecure — before an attacker finds them.

This blog documents the ten cloud misconfigurations most frequently responsible for data breaches in Indian firms, what they look like in practice, why they happen, and what organisations should do about them.

Misconfiguration 1: Publicly Accessible Cloud Storage

The Finding

An S3 bucket, Azure Blob container, or Google Cloud Storage bucket configured to allow public read — or in some cases public read and write — access without authentication. Any person on the internet who knows or can guess the resource URL can access its contents directly from a browser.

What It Looks Like in Practice

A mid-sized Indian e-commerce company migrates its product image storage to S3 during a platform rebuild. The developer provisioning the bucket sets it to public access during the development phase for testing convenience — CDN integration is easier without dealing with signed URLs during initial setup. The migration goes live. The public access setting is never reverted. Six months later the bucket contains not just product images but customer invoice PDFs, order export CSVs with customer PII, and internal sales reports — all accessible publicly. An automated scanner operated by a criminal group indexes the bucket contents within weeks of the migration going live.

Why It Keeps Happening

Developer convenience during testing, forgotten temporary configurations, and the absence of automated enforcement that prevents public access settings from persisting into production. AWS introduced the S3 Block Public Access feature specifically to address this — but it must be explicitly enabled, and many Indian cloud environments were provisioned before it became the default.

What FactoSecure Finds

Storage misconfiguration is the single most common critical finding in FactoSecure’s cloud security assessments of Indian firms. In a significant proportion of assessments, at least one storage resource containing sensitive data is found to be publicly accessible. The contents range from test data with real customer records to production databases exported for analysis and never secured.

The Fix

Enable S3 Block Public Access at the account and organisation level. Implement AWS Config rules or Azure Policy assignments that automatically remediate any storage resource set to public access and generate immediate alerts. Audit all existing storage resources for access settings as an immediate priority. Use pre-signed URLs for any legitimate use case that requires temporary external access to specific objects.

Misconfiguration 2: Overpermissioned IAM Roles and Policies

The Finding

IAM roles attached to cloud workloads — EC2 instances, Lambda functions, ECS tasks, Azure virtual machines — with permissions significantly broader than the workload requires. The most dangerous variant is a workload role with AdministratorAccess or equivalent that was attached during development and never scoped down before production deployment.

What It Looks Like in Practice

A Bengaluru-based SaaS startup builds their backend on AWS Lambda. During rapid development, the developer attaches the AWS-managed AdministratorAccess policy to the Lambda execution role because it eliminates permission errors and keeps development moving. The application goes to production. The overpermissioned role goes with it. When an attacker exploits a server-side request forgery vulnerability in the Lambda function — a relatively common web application flaw — they can use the instance metadata service to retrieve the Lambda’s IAM credentials. With AdministratorAccess, those credentials give them complete control over the AWS account: the ability to read every S3 bucket, access every database, create new IAM users, and exfiltrate or destroy the entire environment.

Why It Keeps Happening

Development velocity pressure, the absence of IAM review as part of deployment checklists, and the genuine complexity of writing precise IAM policies for modern cloud applications. Writing a least-privilege IAM policy for a Lambda function that touches S3, DynamoDB, SQS, and Secrets Manager requires detailed knowledge of every API action the function uses — knowledge that is not always available or prioritised during rapid development cycles.

The Fix

Use AWS IAM Access Analyzer to identify roles with permissions that exceed actual usage. Implement permission boundaries on all workload roles. Establish a development practice of starting with minimal permissions and adding only what is needed, rather than starting with broad permissions and intending to restrict them later. Conduct quarterly IAM reviews using automated tooling to identify and remove unused permissions.

Misconfiguration 3: Disabled or Incomplete Audit Logging

The Finding

AWS CloudTrail, Azure Activity Log, or GCP Cloud Audit Logs not enabled across all accounts and regions, or enabled but not configured for complete coverage — missing data events, management events in specific regions, or logs stored with insufficient retention periods.

What It Looks Like in Practice

An Indian financial services company running workloads across three AWS regions has CloudTrail enabled in their primary Mumbai region but not in us-east-1, which hosts a legacy analytics workload. An attacker who gains access to IAM credentials operates exclusively through the us-east-1 region — outside the logging coverage. They spend three weeks enumerating resources, exfiltrating data, and establishing persistence before the breach is detected through external means. The security team has no audit trail for any of the attacker’s activity. Forensic investigation is severely hampered. The full scope of the breach cannot be determined with confidence.

Why It Keeps Happening

Logging is perceived as a cost rather than a security control. CloudTrail data events in particular generate significant log volumes and associated storage and analysis costs. Organisations optimising cloud spend frequently disable or restrict logging without fully understanding the security implications. Multi-region deployments also create gaps when logging is enabled manually on a region-by-region basis rather than through organisation-level configuration.

The Fix

Enable CloudTrail organisation trails that automatically apply to all accounts and all regions — including regions where you do not currently have active workloads. Enable S3 data events for buckets containing sensitive data. Ship logs to a dedicated security account where the operations team does not have write access. Implement AWS Config rules that detect and alert on CloudTrail being disabled. Establish a minimum log retention period of 12 months for compliance and forensic purposes.

Misconfiguration 4: Exposed Database Instances

The Finding

Cloud-hosted databases — RDS instances, MongoDB Atlas clusters, Elasticsearch deployments, Redis caches, or self-managed databases on EC2 — configured with network access from 0.0.0.0/0, making them directly reachable from the public internet.

What It Looks Like in Practice

A healthtech startup in Mumbai spins up a MongoDB instance on EC2 to support a new patient data feature during a hackathon. The security group is set to allow inbound access on port 27017 from anywhere — a standard hackathon shortcut to enable team members in different locations to access the database during development. The hackathon ends. The instance is repurposed for a production pilot. The security group rule is never updated. The database — now containing real patient records — is indexed by Shodan within days. Within weeks, a known MongoDB ransomware bot encrypts the data and leaves a ransom note.

Why It Keeps Happening

The same pattern as storage misconfiguration: temporary development shortcuts that persist into production. Database administrators focused on functionality rather than network configuration. And the absence of automated controls that prevent databases from being exposed to the internet regardless of how their security groups are configured.

The Fix

Databases should never be deployed in public subnets. Implement VPC architecture that places all database instances in private subnets reachable only from the application tier. Use AWS Config rules or Azure Policy to detect and alert on any database instance with a public endpoint or an overly permissive security group. For MongoDB and self-managed databases, enforce authentication and consider additional network-level controls such as VPN-required access for administrative connections.

Misconfiguration 5: Hardcoded Credentials in Code Repositories

The Finding

AWS access keys, Azure service principal credentials, database connection strings, API keys, and other secrets committed to source code repositories — public or private — rather than stored in a secrets management service.

What It Looks Like in Practice

A developer at an Indian e-commerce startup is debugging a production issue at midnight. They temporarily hardcode their personal AWS access key into the application configuration file to bypass a Secrets Manager retrieval that seems to be causing latency. They fix the issue, commit the changes to GitHub, and push to production. They forget to remove the hardcoded key before committing. An automated bot scanning GitHub for AWS credential patterns harvests the key within four minutes of the commit. The key has AdministratorAccess. By the time the developer wakes up the next morning, the attacker has exfiltrated the customer database, created three new IAM users with their own access keys, and launched 200 EC2 instances in us-east-1 for cryptomining. The AWS bill for that month is ₹47 lakh.

Why It Keeps Happening

Developer convenience, time pressure, and the cognitive overhead of context-switching to secrets management during debugging. Private repositories provide false confidence — private repositories can be made public accidentally, can be accessed by compromised developer accounts, and can be leaked through third-party integrations.

The Fix

Implement git-secrets or similar pre-commit hooks that prevent credential patterns from being committed. Enable GitHub’s secret scanning feature, which automatically detects and alerts on known credential patterns. Migrate all secrets to AWS Secrets Manager or Azure Key Vault and enforce this through code review processes. Rotate any credentials that may have been exposed, regardless of whether exploitation has been confirmed.

Misconfiguration 6: Missing Multi-Factor Authentication on Privileged Accounts

The Finding

Root accounts, IAM administrator accounts, Azure Global Administrator accounts, and other highly privileged cloud identities without MFA enforced — relying solely on username and password for authentication.

What It Looks Like in Practice

An Indian logistics company’s AWS root account is protected only by a password. The root account email address is the company’s generic admin email, which is also used for several SaaS subscriptions. One of those SaaS services suffers a data breach and the credentials are leaked. An attacker using the leaked password against the AWS console succeeds — the password has been reused. With root account access and no MFA, the attacker has unrestricted access to the entire AWS environment. They spend a weekend exfiltrating shipment data, customer addresses, and financial records before disabling CloudTrail and deleting S3 buckets containing operational data.

Why It Keeps Happening

Root account credentials are often set up during account creation and then deprioritised — the root account is rarely used day-to-day, and MFA setup is deferred indefinitely. Password reuse across accounts is endemic in organisations that do not enforce password manager usage. And the absence of automated enforcement — IAM policies that prevent console access without MFA — means the gap persists without visibility.

The Fix

Enable MFA on the root account immediately and store the MFA device and root credentials in a physically secure location, separate from day-to-day access. Implement an IAM policy that denies all console actions for IAM users who have not authenticated with MFA. Use AWS Organizations SCPs to enforce MFA requirements across all member accounts. Consider hardware security keys for the highest-privilege accounts.

Misconfiguration 7: Overly Permissive Security Group Rules

The Finding

EC2 security groups or Azure Network Security Groups with inbound rules that allow access from any IP address (0.0.0.0/0 or ::/0) on sensitive ports — SSH (22), RDP (3389), database ports (3306, 5432, 27017, 6379), or administrative interfaces.

What It Looks Like in Practice

A development team at an Indian SaaS company opens SSH access from anywhere on their EC2 instances for remote debugging during a product sprint. The rule is added to the default security group, which is attached to all instances in the VPC by inheritance. The sprint ends but the rule remains. An automated scanner identifies the exposed SSH service within 24 hours. The instance is running an older version of OpenSSH with a known vulnerability. The attacker exploits it, establishes a foothold in the VPC, and begins lateral movement toward the production database.

Why It Keeps Happening

Default security groups in AWS allow all outbound traffic and all inbound traffic from resources in the same security group — a configuration that encourages overpermissive rules rather than specific access controls. Development teams add broad rules for convenience and rarely have a formal process for reviewing and removing temporary access.

The Fix

Replace all 0.0.0.0/0 inbound rules with specific IP ranges or security group references. Implement AWS Config rules that detect and alert on security groups with unrestricted inbound access on sensitive ports. Use AWS Systems Manager Session Manager for administrative access to EC2 instances instead of SSH — it requires no open inbound ports and provides full session logging. Conduct a quarterly security group audit to identify and remove rules that are no longer needed.

Misconfiguration 8: Unencrypted Data at Rest and in Transit

The Finding

Cloud storage resources, databases, and backup systems storing sensitive data without encryption. Or data transmitted between cloud services and between cloud and client over unencrypted channels — HTTP rather than HTTPS, or TLS with weak cipher suites.

What It Looks Like in Practice

An Indian insurance company migrates its claims processing system to AWS RDS. The database is provisioned without encryption enabled — the checkbox is not ticked during setup, and the default in some older RDS configuration workflows is unencrypted. The database contains sensitive health and financial data for millions of policyholders. When a misconfigured security group briefly exposes the RDS instance to the internet during a network reconfiguration, an attacker is able to connect and extract data in plaintext. Under the DPDP Act and IRDAI cybersecurity guidelines, the company faces regulatory scrutiny not just for the breach but for the failure to encrypt sensitive personal data.

Why It Keeps Happening

Encryption is perceived as adding complexity and latency without visible benefit — until a breach occurs. Default configurations in cloud services have historically not always enforced encryption, and organisations migrating from on-premises infrastructure often carry forward assumptions about network perimeter security that do not apply in cloud environments.

The Fix

Enable encryption at rest on all RDS instances, S3 buckets, EBS volumes, and backup systems containing sensitive data. Use AWS KMS or Azure Key Vault for key management with formal rotation schedules. Enforce HTTPS on all load balancers and API gateways. Implement AWS Config rules that detect unencrypted storage and database resources. Use TLS 1.2 minimum with strong cipher suites — audit and disable deprecated protocols such as SSLv3 and TLS 1.0.

Misconfiguration 9: Insecure CI/CD Pipeline Configuration

The Finding

Continuous integration and deployment pipelines — GitHub Actions, Jenkins, GitLab CI, AWS CodePipeline, Azure DevOps — with direct production cloud access, secrets stored as plaintext environment variables, insufficient access controls on pipeline configuration, or no separation between deployment permissions for different environments.

What It Looks Like in Practice

A fintech startup’s GitHub Actions workflow deploys directly to production AWS using an IAM access key stored as a GitHub Actions secret with AdministratorAccess permissions. A disgruntled contractor who worked briefly on the project still has access to the repository. They modify the GitHub Actions workflow to add a step that exfiltrates the production database to an external server, triggered on the next deployment. The modification is subtle enough to pass a cursory code review. The next deployment executes the malicious step. Customer financial data is exfiltrated before the modification is noticed.

Why It Keeps Happening

CI/CD pipelines are often set up quickly during the early stages of a project with security as a secondary concern. The credentials stored in pipelines are rarely rotated and frequently have broader permissions than deployments actually require. Access to pipeline configuration is often tied to repository access, which may be granted broadly.

The Fix

Use short-lived credentials for CI/CD pipeline cloud access — AWS IAM Identity Center with OIDC federation for GitHub Actions eliminates the need for long-lived access keys entirely. Scope pipeline permissions to the minimum required for each specific deployment action. Implement required reviewers for pipeline configuration changes. Separate deployment credentials for development, staging, and production environments with strict permission boundaries between them.

Misconfiguration 10: Lack of Resource Tagging and Orphaned Infrastructure

The Finding

Cloud resources without consistent tagging — no owner, environment, data classification, or cost centre tags — leading to accumulation of orphaned resources that are unmonitored, unpatched, and outside the scope of security controls and assessments.

What It Looks Like in Practice

An Indian media company runs dozens of AWS accounts accumulated through acquisitions and internal team provisioning over several years. A security assessment reveals an EC2 instance running in a rarely used account — untagged, unmonitored, and running an operating system version from 2019 with dozens of unpatched critical vulnerabilities. The instance was provisioned by a developer who left the company two years ago for a proof of concept that was never productionised. It has been running continuously for three years. It hosts a web server that is reachable from the internet. An attacker has been using it as a pivot point into the broader network for an unknown period.

Why It Keeps Happening

Cloud’s self-service provisioning model makes it trivially easy to spin up resources. Without mandatory tagging enforced at provisioning time, resources accumulate without ownership. Employee turnover means knowledge of what resources exist and why is constantly being lost. And the economics of cloud — where a forgotten t3.small instance costs only a few hundred rupees a month — means orphaned resources do not create the cost pressure that would drive discovery.

The Fix

Implement AWS Config rules or Azure Policy that require mandatory tags on all resources at provisioning time — owner, environment, data classification, and cost centre at minimum. Use AWS Resource Explorer or Azure Resource Graph to conduct a full inventory of all resources across all accounts and regions. Establish a quarterly orphaned resource review process. Consider AWS Control Tower or Azure Landing Zones to enforce governance standards on all new account provisioning from the outset.

The Common Thread: Why These Misconfigurations Persist

Across all ten misconfigurations, a consistent pattern emerges. They are not the result of ignorance — most Indian cloud engineering teams know, at some level, that public S3 buckets and exposed databases are bad. They are the result of three structural factors that security programmes need to address directly:

Speed over security in development culture. When deployment velocity is the primary metric and security review is not embedded in the deployment process, security shortcuts accumulate faster than they are reversed. The fix is not to slow down development — it is to automate security enforcement so that secure configuration is the path of least resistance.

Absence of automated guardrails. Manual security review cannot keep pace with the rate at which cloud resources are provisioned in a fast-moving organisation. Automated enforcement — Config rules, SCPs, Azure Policy, pre-commit hooks — that prevents misconfigurations from persisting is the only scalable response.

No independent validation. Internal teams have blind spots. The developer who introduced a misconfiguration is not best-placed to identify it. Regular independent cloud security assessments from firms like FactoSecure provide the external perspective that identifies what internal processes have missed.

How FactoSecure Approaches Cloud Misconfiguration Assessment

FactoSecure’s cloud security assessment methodology is built around finding the misconfigurations that automated scanners miss and internal teams overlook. Their assessments combine automated configuration analysis across all cloud accounts and regions with manual review of IAM policies, network architecture, logging configuration, and CI/CD pipeline security — producing a prioritised finding set that reflects real-world exploitability rather than theoretical risk.

For each finding, FactoSecure’s reports provide the configuration evidence that confirms the issue, the attack scenario that demonstrates its real-world impact, the regulatory implication under DPDP, RBI, PCI-DSS, or other applicable frameworks, and specific remediation steps that a cloud engineer can implement directly.

The remediation roadmap sequences findings by risk severity and implementation complexity — giving Indian security teams a practical plan for addressing the highest-risk gaps first within realistic resource constraints.

Post-assessment, FactoSecure remains available to support remediation — answering engineering questions, validating proposed fixes, and conducting retests to confirm that misconfigurations have been genuinely resolved rather than superficially addressed. For organisations building their cloud security maturity, this ongoing engagement model is what converts a point-in-time assessment into lasting improvement.

The Bottom Line

The ten misconfigurations documented in this blog are not obscure. They are not sophisticated. They are the same gaps that appear in cloud environment after cloud environment across Indian firms of every size and sector — and they are the gaps that attackers, automated scanners, and criminal reconnaissance tools exploit most reliably.

The good news is that every one of them is fixable. None requires exotic expertise or prohibitive investment. All of them are caught by a thorough cloud security assessment before they become breach headlines.

The organisations that commission that assessment — that invest in understanding where their cloud environment actually stands rather than where they believe it stands — are the ones that avoid the data breach, the regulatory action, and the reputational damage that follows. The ones that do not are leaving their cloud security posture to chance in an environment where chance is increasingly expensive.