Potentially millions of customers and employees
A severe data breach at Indian automotive giant Tata Motors has exposed over 70 terabytes of highly sensitive data. The incident, first discovered in 2023, was caused by a series of fundamental security misconfigurations, most notably the exposure of plaintext Amazon Web Services (AWS) access keys on a public-facing e-commerce website. These overly permissive credentials allowed unauthorized individuals to access a vast number of AWS S3 buckets. The exposed data includes customer databases with personally identifiable information (PII), financial records, fleet management data, and internal corporate reports, representing a catastrophic failure in cloud security management.
The root cause of the breach was a set of AWS access keys discovered in plaintext within the code of E-Dukaan, Tata Motors' e-commerce platform for vehicle spare parts. This is a classic example of hardcoded secrets, a common but critical security vulnerability. The exposed keys were not properly restricted and granted sweeping permissions, including read and write access to numerous S3 buckets.
Key Failures:
The attack path was straightforward. An attacker could simply inspect the source code of the E-Dukaan website, find the accessKeyId and secretAccessKey, and use them with the AWS Command Line Interface (CLI) or API to list and access the S3 buckets associated with the account. The exposed data was extensive and included:
FleetEdge, Tata Motors' fleet management system.A striking detail from the report notes that the powerful, exposed keys were used for a trivial task: downloading a single 4-kilobyte file of tax codes. This highlights a profound disconnect between the permissions granted and the actual operational need, creating a massive and unnecessary security risk.
The exposure of 70 terabytes of data has severe consequences for Tata Motors:
GetObject API calls.Prevent hardcoding of secrets in application code by using secure secrets management solutions.
Enforce the principle of least privilege on all IAM users and roles, ensuring they have only the minimum permissions required.
Continuously audit cloud configurations and logs for signs of misconfiguration or anomalous access.
Encrypt all sensitive data at rest in S3 buckets to add another layer of protection in case of unauthorized access.
The root cause of the Tata Motors breach was a failure in application configuration, specifically hardcoding AWS keys. To prevent this, development teams must adopt a 'no hardcoded secrets' policy. This should be enforced through both process and technology. Implement pre-commit hooks and CI/CD pipeline checks that scan code for patterns matching access keys, API tokens, and other secrets. Instead of embedding credentials, applications like E-Dukaan should be configured to use a secrets management service (e.g., AWS Secrets Manager) or IAM Roles for EC2/ECS to dynamically and securely fetch credentials at runtime. This eliminates the risk of keys being exposed in source code.
The second major failure was the overly permissive nature of the exposed keys. All IAM policies, whether for users or roles, must adhere strictly to the principle of least privilege. For the E-Dukaan application, the IAM role should have only been granted permissions to perform its specific function, such as s3:GetObject on a specific, non-sensitive bucket containing tax codes. It should never have had permissions to list all buckets or access customer data. Organizations should use tools like AWS IAM Access Analyzer to identify and remediate excessive permissions and regularly review policies to ensure they remain as restrictive as possible.
Effective monitoring could have detected this breach early. Organizations must enable and analyze AWS CloudTrail logs. For the Tata Motors scenario, security teams should have configured alerts for several high-risk activities. These include: any API call made using a long-lived IAM user's access keys (as roles are preferred), a ListBuckets call from an unexpected source, or an unusual volume of GetObject calls from a single user or IP address. Ingesting CloudTrail logs into a SIEM and correlating them with threat intelligence and network data can help identify when a compromised key is being used for reconnaissance or data exfiltration, enabling a much faster response.

Cybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Help others stay informed about cybersecurity threats