AWS Hacks: A Timeline of Major Cloud Security Breaches and Lessons Learned

muninder Adavelli

Updated: April 15, 2025

SHARE:

Amazon Web Services (AWS) powers a massive portion of the internet, from personal blogs to platforms used by global corporations. Its speed, scalability, and reliability have made it the leading cloud provider for millions of businesses worldwide.

But with grand scale comes significant risk. Cloud environments like AWS are a common target for attackers, not because AWS itself is weak, but because the way it’s used can leave gaps. In fact, over 94% of organizations have experienced a data breach due to poor security implementations.

This article doesn’t focus on AWS being compromised. Instead, it looks at real security incidents where AWS environments were misused or misconfigured, exposing sensitive data and systems. Many of these breaches were preventable, and they offer practical lessons for anyone building in the cloud.

Chronological Timeline of Notable AWS Security Incidents

Over the years, several organizations have experienced serious security breaches involving their AWS environments. While these incidents vary in size and impact, they often share common themes: misconfigurations, leaked credentials, and insufficient access controls. 

Below is a year-by-year look at some of the most notable AWS security failures, how they happened, and what went wrong.

2014 AWS Hacks

Uber – May 2014

Uber experienced its first AWS-related security incident when developers accidentally included AWS credentials in a public GitHub Gist. An attacker found the keys and used them to access an S3 bucket containing sensitive driver data. The breach exposed the personal information of over 50,000 drivers.

• Root Cause: AWS credentials exposed on GitHub
• How It Happened: Unauthorized access to S3 using static keys
• Impact: Personal data of 50,000 drivers was compromised

Code Spaces – June 2014

Code Spaces suffered a critical attack after a phishing campaign allowed an intruder to access the company’s AWS console. The attacker created new IAM accounts and began deleting vital resources. When the ransom demand was refused, the remaining infrastructure was wiped. The damage was so severe that Code Spaces was forced to shut down its business.

• Root Cause: Phishing attack led to AWS console access
• How It Happened: Creation of backup IAM users followed by deletion of resources
• Impact: Complete loss of infrastructure and permanent business closure

Code Spaces shows how phishing can lead to a complete shutdown. One compromised account gave attackers AWS console access, letting them wipe out critical resources. With nearly 83% of organizations hit by phishing in 2022, this breach is more common than you might think.

BrowserStack – November 2014

BrowserStack was breached when attackers exploited the Shellshock vulnerability on a forgotten prototype server hosted in AWS. Although not meant for public access, the server had been left online and unpatched. Attackers used it to gain remote access, leading to data exposure and a temporary shutdown of services.

• Root Cause: Unpatched Shellshock vulnerability on an old server
• How It Happened: Remote code execution through a publicly accessible endpoint
• Impact: Unauthorized access to internal systems and service disruption

2016 AWS Hacks

Uber – October 2016

In a second major breach, Uber was compromised again after attackers purchased stolen credentials on the dark web. These credentials gave access to a private GitHub repository that contained hardcoded AWS keys. Using those keys, the attackers accessed an AWS S3 bucket holding sensitive data on 57 million users and drivers. Uber did not disclose the breach until a year later, raising further concerns over its security and response practices.

• Root Cause: Exposed AWS keys in a private GitHub repository
• How It Happened: Stolen credentials provided unauthorized access to S3
• Impact: Data of 57 million users and drivers compromised
  

Lynda.com – December 2016

Lynda.com, an online learning platform owned by LinkedIn, experienced a breach when AWS credentials were exposed in a private GitHub repository. Attackers used the credentials to access user data, resulting in the compromise of approximately 9.5 million accounts. The breach included names, email addresses, and courses viewed, although passwords were not exposed.

• Root Cause: AWS credentials exposed in private source code
• How It Happened: Unauthorized access using leaked keys from a GitHub repo
• Impact: 9.5 million user records compromised

Stolen or exposed credentials are a leading cause of AWS breaches. In cases like Uber and Lynda.com, leaked keys gave attackers direct access. With 81% of hacks linked to weak or stolen passwords, protecting credentials is non-negotiable.

2019 AWS Hacks

Capital One – April 2019

Capital One suffered one of the most publicized AWS-related breaches to date. A misconfigured Web Application Firewall (WAF) allowed an attacker to exploit a Server-Side Request Forgery (SSRF) vulnerability. This incident gave them access to AWS metadata and credentials to download data from Capital One’s S3 buckets. The breach exposed the personal information of more than 100 million customers, including credit scores, Social Security numbers, and bank account details.

• Root Cause: Misconfigured WAF combined with SSRF vulnerability
• How It Happened: Access to AWS metadata exposed temporary credentials
• Impact: Over 100 million customer records were compromised

Imperva – October 2019

Imperva, a well-known cybersecurity company, was hit by a breach that started with an exposed AWS server. The server was accidentally left open to the public, and attackers found it. Inside, they discovered AWS API keys that gave them access to customer data stored in backups. What followed was unauthorized access to sensitive information the company thought was secure.

• Root Cause: Publicly exposed compute instance with hardcoded AWS API keys
• How It Happened: API keys were used to access RDS backups
• Impact: Customer data from Web Application Firewall accounts was compromised

2020 AWS Hacks

Twilio – March 2020

Twilio was targeted in a supply chain attack when an exposed AWS S3 bucket allowed attackers to inject malicious JavaScript into the TaskRouter SDK. This code was then delivered to any application that used the compromised SDK, enabling Magecart-style attacks that captured sensitive user data during online transactions.

• Root Cause: Misconfigured S3 bucket with public write access
• How It Happened: Attackers injected malicious code into a JavaScript SDK
• Impact: End-user data was exposed through downstream Magecart attacks

Drizly – July 2020

The alcohol delivery platform Drizly was breached when attackers accessed an inactive GitHub account containing hardcoded AWS credentials. The credentials were used to access internal systems, compromising data belonging to 2.5 million users. The breach included names, email addresses, and hashed passwords.

• Root Cause: AWS credentials embedded in a forgotten GitHub account
• How It Happened: Stolen credentials were used to access AWS-hosted systems
• Impact: 2.5 million user records were compromised

2021 to 2025 AWS Hacks

FlexBooker – December 2021

FlexBooker, an online appointment scheduling platform, suffered a major breach after misconfigured S3 buckets left over 10 million lines of customer data exposed. The leaked data included names, email addresses, driver’s license photos, and hashed passwords.

• Root Cause: Misconfigured S3 bucket with public access
• How It Happened: Unauthorized parties accessed exposed customer files
• Impact: 10 million records containing sensitive personal information were leaked

Pegasus Airlines – May 2022

Pegasus Airlines experienced a significant data breach when misconfigured AWS servers exposed more than 6.5 terabytes of sensitive information. The data included flight details, personal identification numbers, and staff records.

• Root Cause: Misconfigured servers with insufficient access controls
• How It Happened: Sensitive data was accessible through open AWS infrastructure
• Impact: 6.5 terabytes of customer and employee data were exposed

LastPass – October 2022

Attackers compromised IAM user accounts associated with LastPass development environments hosted on AWS. Using the stolen credentials, they accessed internal systems and exfiltrated a large volume of sensitive data, including encrypted password vaults.

• Root Cause: Compromised IAM credentials
• How It Happened: Unauthorized access to development environments through valid user accounts
• Impact: Widespread data compromise affecting LastPass users and infrastructure

Sisense – April 2024

Sisense, a business intelligence company, was breached after AWS credentials were stolen from a GitLab repository. The attackers used the credentials to access and extract extensive customer data from S3 storage buckets.

• Root Cause: Exposed AWS credentials in a GitLab repo
• How It Happened: Credentials were used to access S3 buckets
• Impact: Terabytes of customer data were exfiltrated

Otelier – January 2025

Otelier, a hospitality technology platform, was targeted by infostealer malware that uncovered AWS credentials stored in Bitbucket repositories. The attackers used the credentials to access S3 buckets containing reservation data and extracted approximately eight terabytes of information.

• Root Cause: Credentials exposed through infostealer malware
• How It Happened: Compromised Bitbucket repositories led to unauthorized S3 access
• Impact: 8 terabytes of hotel reservation data were exfiltrated

Common Vulnerabilities Exploited

Across the timeline of AWS-related security incidents, certain patterns continue to emerge. These vulnerabilities are not caused by flaws in AWS itself but in how cloud environments are configured, accessed, and managed. Below are the most common security gaps that attackers have exploited in multiple high-profile cases.

Misconfigured S3 Buckets

S3 bucket misconfigurations are one of the most frequent causes of cloud data breaches. When access settings are not properly restricted, sensitive files stored in these buckets can be publicly accessible without anyone realizing it.

• Examples: Twilio, FlexBooker, Pegasus Airlines
• Risk: Exposes personal or corporate data to anyone with the link
• Why It Happens: Lack of access restrictions or incorrect permission settings during setup

Exposed API Keys and Credentials

Many organizations have unintentionally left AWS keys and secrets in public or poorly secured repositories. Attackers often discover these credentials by scanning platforms like GitHub, GitLab, or Bitbucket for exposed secrets.

• Examples: Uber, Sisense, Otelier
• Risk: Full access to AWS services using valid credentials
• Why It Happens: Hardcoding secrets in code or pushing them to version control without secret management tools

With a cyberattack happening every 39 seconds, securing access keys and secrets is crucial and even necessary.

Server-Side Request Forgery (SSRF)

SSRF attacks exploit vulnerabilities in web applications that allow attackers to send requests themselves. SSRF can access the metadata service in AWS environments and retrieve temporary credentials.

• Examples: Capital One, Prezi
• Risk: Unauthorized access to sensitive AWS APIs and privilege escalation
• Why It Happens: Web applications do not validate outbound requests or block access to internal AWS endpoints

Credential Compromises

Attackers often gain access to cloud systems by compromising usernames and passwords through phishing, malware, or weak account security. If there’s no multi-factor authentication or access control, stolen credentials can give attackers direct access to sensitive systems.

• Examples: LastPass, Drizly
• Risk: Direct access to AWS consoles, development environments, or production data
• Why It Happens: Lack of MFA, shared accounts, or poor credential hygiene

The AWS Shared Responsibility Model

Regarding cloud security, many users assume that AWS is responsible for protecting everything. But that’s not the case. AWS follows a shared responsibility model, which divides security tasks between AWS and its customers.

What AWS Secures Behind the Scenes

AWS takes care of protecting the infrastructure that runs all of its services. This function includes the hardware, software, networking, and facilities that support its cloud platform. Customers don’t need to worry about physical security, hypervisors, or data center protection; AWS manages everything behind the scenes.

Securing Your Side of the Cloud

Once you’re using AWS, it becomes your job to secure how you use the platform. That includes managing who has access to your systems, setting up proper permissions, encrypting sensitive data, and configuring services like S3, EC2, and IAM correctly. Most of the breaches covered in this article happened because customers didn’t secure these areas properly.

Why It Matters

Knowing who’s responsible for what in the cloud is key to keeping your setup secure. AWS gives you the tools, but it’s up to you to use them correctly. Misconfigurations, exposed credentials, and weak access controls often come down to human error, not flaws in AWS itself. Recognizing what you’re responsible for is the first step in preventing future incidents.

Lessons Learned and Best Practices

The security incidents discussed in this article reveal a common theme: many AWS-related breaches could have been prevented with better practices. Below are key actions that organizations of any size can take to reduce risk and protect their cloud environments.

Implement Strict Access Controls

Use AWS IAM roles to give users and services only the necessary access. Following the principle of least privilege ensures that no one has more access than necessary, reducing the chance of accidental or intentional misuse.

Regularly Audit and Monitor

Set up services like AWS Config, CloudTrail, and GuardDuty to monitor your environment continuously. These tools help detect unusual activity, flag configuration issues, and provide visibility into user actions so you can respond before minor issues become big problems.

Secure Development Practices

Never hardcode credentials in your codebase or push them to version control systems. Instead, use AWS Secrets Manager, environment variables, or IAM roles for secure resource access. This way, you can keep sensitive information out of reach from attackers scanning for exposed keys.

Enable Multi-Factor Authentication (MFA)

Adding MFA to AWS accounts, especially those with administrative privileges, creates a second layer of protection. Even if login credentials are stolen, MFA can stop attackers from accessing your console or API.

Conduct Regular Security Training

Your team is your first line of defense. Regular training helps developers, engineers, and support staff stay current on best practices, social engineering tactics, and new vulnerabilities. Awareness reduces the risk of mistakes that could lead to a breach.

Conclusion

The security breaches covered in this article show a consistent pattern; most weren’t the result of AWS being compromised, but how AWS was used. Misconfigured settings, leaked credentials, and weak access controls have opened the door to some of the biggest cloud-related incidents in recent years. These were not flaws in the platform but in how it was implemented and managed.

That’s why taking security seriously before something goes wrong matters. Simple steps like setting the correct permissions, keeping an eye on your systems, and making sure your team knows what to look out for can make a big difference. Cloud environments change quickly, and so do the ways attackers try to break in. Staying secure means staying aware and informed and always looking for ways to improve.

AWS gives you powerful tools, but it’s up to you to use them wisely.

FAQs on AWS Hacks

Has AWS itself ever been hacked?

No, there is no public record of AWS’s core infrastructure being directly hacked. Most incidents involve customer-side misconfigurations or exposed credentials, not flaws in AWS itself.

What is the most common cause of AWS-related breaches?

Most AWS-related breaches happen due to misconfigured services, especially open S3 buckets, exposed access keys, and weak access controls.

What tools does AWS offer for security monitoring?

AWS provides services like CloudTrail for logging user activity, GuardDuty for threat detection, AWS Config for tracking configurations, and Security Hub for centralized visibility.