Anatomy of a Real AWS Breach: Imperva, 2019

Imperva, a company whose entire business is building security products including a cloud web application firewall, disclosed on August 27, 2019 that it had itself been breached. A follow-up technical post-mortem published October 10, 2019 laid out the specific root cause: a startlingly ordinary mistake, an AWS API key left reachable from the internet. It's one of the more instructive case studies precisely because the company involved builds security tooling for a living, and it still happened.

What Happened

Imperva's own investigation, which the company published in detail, traced the root cause back to October 2018. A database snapshot had been created for testing purposes, standard practice, but that snapshot ended up reachable from an internal compute instance that was itself accessible from outside Imperva's network. That compute instance held an AWS API key. The instance was compromised, the API key was stolen, and the attacker used it to access the database snapshot.

Imperva learned of the incident on August 20, 2019, nearly a year after the actual exposure. The snapshot itself dated back to September 15, 2017, meaning it contained data for customers of Imperva's Cloud WAF product who had signed up on or before that date: email addresses, hashed and salted passwords, and, for a subset of customers, API keys and TLS/SSL certificates.

The Response

Once confirmed, Imperva's remediation was substantial: roughly 13,000 passwords were reset, more than 13,500 SSL certificates were rotated and regenerated, and approximately 1,400 API keys were reissued. The company stated it found no evidence of malicious activity actually carried out against affected customers using the exposed data, though that doesn't change what was exposed or how long it sat exposed.

The Real Lesson: It Wasn't a Complex Attack

There was no sophisticated exploit chain here. The entire breach reduces to one compute instance that shouldn't have been reachable from the internet, holding one credential that shouldn't have been sitting in plaintext on that instance, which then had access to one database snapshot that shouldn't have still existed a year after it was created for a testing purpose.

Each of those three facts is independently, and continuously, checkable.

The Specific Checks That Would Have Caught This

• Network exposure scanning. An internal compute instance genuinely reachable from the public internet is exactly the kind of finding a continuous posture scan flags immediately, not a year later.
• Secrets scanning on live infrastructure. An AWS API key sitting in plaintext on a compute instance, rather than in a proper secrets manager with rotation, is a directly detectable misconfiguration, the same class of finding secrets detection tooling is built to catch on EC2, Lambda, and container workloads.
• Snapshot lifecycle management. A database snapshot created "for testing" that quietly persists for over a year, holding a full copy of production customer data, is a data-retention and access-scope problem an inventory and posture review would surface.
• Least-privilege scoping on the API key itself. A key limited to only the specific action and resource it was created for would have reduced or eliminated what the attacker could actually do with it once stolen.

The uncomfortable part of this case study isn't the technical chain, it's genuinely simple. It's that a company whose core product is cloud security still had this gap sit undetected for roughly a year. That's the strongest possible argument for continuous, automated scanning over point-in-time reviews: a human review might reasonably have missed this too, an always-on scan checking network exposure and secrets placement wouldn't have.

Sources: Imperva's own initial disclosure (CEO Chris Hylen, August 27, 2019) and the technical follow-up post-mortem (CTO Kunal Anand, October 10, 2019), plus contemporaneous reporting from Security Affairs and Help Net Security.