Imperva disclosed that its Cloud WAF data exposure stemmed from unauthorised use of an administrative API key in a production AWS account, leading to access to a database snapshot containing email addresses, hashed and salted passwords, API keys and TLS keys for a subset of customers.
Imperva’s investigation tied the attack chain to several compounding control failures: a test database snapshot existed, an internal compute instance was reachable from the public internet, that instance stored an AWS API key and the compromised key was then used to access the snapshot. The incident highlights the exact governance and detection gaps that repeatedly create cloud breach paths: public exposure of internal infrastructure, reliance on long-lived credentials instead of constrained short-lived access, insufficient monitoring of API key usage and weak controls around snapshot access and movement. Imperva later added tighter access controls, more audit coverage, key rotation, VPN-by-default internal access, decommissioning of inactive instances and broader monitoring. For enterprise defenders, the lesson is clear: cloud incidents often come from operational shortcuts and poor credential architecture rather than product flaws and snapshot governance must be treated as a high-risk data exfiltration path.
| What’s happening | Cause | Action |
|---|---|---|
| Publicly reachable internal compute created an initial compromise path | Imperva confirmed an internal compute instance was accessible from the outside world and was later compromised. This exposed a path into a production AWS environment that should have been restricted. | Validate that internal/admin compute is not internet-accessible unless explicitly justified, documented and protected. SkySiege would assess internet exposure on compute, associated security groups/ACLs, ingress paths and whether internal workloads are isolated behind private networking or VPN controls by default. |
| Long-lived AWS API key on a compute instance enabled credential theft | Imperva stated the accessible instance contained an AWS API key and that key was stolen and used in the attack chain. This aligns with the risk of static credentials stored on hosts rather than ephemeral, environment-bound access. | Validate whether workloads use embedded or long-lived IAM user/API keys instead of instance roles or short-lived credentials. SkySiege would assess presence of static access keys, credential age, administrative scope, rotation practices and whether roles/token-based access can replace persistent keys. |
| Administrative key scope appears excessive for the workload | Imperva identified the stolen credential as an administrative API key in a production AWS account. The source does not provide the exact IAM policy, but the described outcome shows the key could access high-value data resources beyond least privilege expectations. | Validate that API credentials cannot perform snapshot discovery, sharing, copy, restore or export actions unless operationally required. SkySiege would assess overly broad IAM permissions, privilege concentration in access keys and whether administrative credentials are unnecessarily available to workloads. |
| API key activity was not restricted or detected early enough | Imperva later increased audit of snapshot access, expanded CloudTrail/GuardDuty/UEBA workflows and created alerts around key events. That sequence indicates prior visibility and alerting were not sufficient to rapidly detect or constrain this key’s misuse. | Validate logging coverage for IAM, snapshot and database-related API activity and confirm detections exist for unusual credential use, especially from unexpected hosts, accounts or workflows. SkySiege would assess audit trail coverage, alertability of sensitive API actions and gaps in detective controls around credential misuse. |
| Snapshot governance was weak for sensitive data | Imperva created a database snapshot for testing and the attacker ultimately accessed a snapshot containing customer data. The commentary priority is clear here: snapshot creation and access were not governed tightly enough for sensitive data. | Validate whether snapshots containing production data are necessary, encrypted, tagged, retained minimally and blocked from unauthorised sharing/copy/restore patterns. SkySiege would assess snapshot inventory, exposure pathways, encryption posture, sharing permissions, age, data sensitivity indicators and governance controls around snapshot movement. |
| Test artefacts retained sensitive production-era data | The exfiltrated dataset came from a snapshot dated September 15, 2017, while the exfiltration occurred in October 2018. This shows sensitive historical data remained accessible well after its operational need. | Validate retention and lifecycle policies for snapshots, backups and test artefacts derived from production. SkySiege would assess stale snapshots, dormant assets, lifecycle gaps and whether historical copies materially expand breach impact beyond current business need. |
| Inactive and experimental infrastructure increased attack surface | Imperva said the compromised instance and other unused and experimental instances discovered during the investigation were later archived and decommissioned. This indicates unmanaged asset sprawl in the environment. | Validate that unused compute is identified and removed quickly, especially test and experimental systems. SkySiege would assess dormant compute orphaned assets, ownership gaps and whether asset hygiene controls reduce externally reachable attack surface. |
| Monitoring controls lagged the architecture shift to cloud-managed services | Imperva acknowledged its DAM product did not support AWS RDS in 2017 and that CDS was implemented only after the incident. This left a visibility gap over cloud-native data assets during migration. | Validate whether security monitoring capabilities actually cover managed services such as RDS, snapshots and related control plane events. SkySiege would assess control coverage across cloud-native services and identify where legacy tooling assumptions leave blind spots. |
This incident is a clear cloud governance failure, not a software flaw. Imperva explicitly said the exfiltration was not caused by a Cloud WAF product vulnerability. The breach path came from operational decisions around infrastructure exposure, credential handling and snapshot control. That distinction matters in diligence and enterprise risk review because it shows how mature products can still be undermined by weak cloud operating practices.
The most important security lesson is the combination of an internet-accessible AWS instance and a long-lived administrative API key stored on that host. That is a high-risk pattern because compromise of the host becomes compromise of the control plane. When the credential is broad enough to reach sensitive snapshots, the blast radius extends immediately from one server to customer data. The source supports the exposure, the key theft and the subsequent snapshot access; it does not publish the exact IAM policy, so least-privilege failure is an evidence-based interpretation rather than a directly documented policy fact.
The next issue is visibility. Imperva later expanded CloudTrail, GuardDuty, UEBA ingestion, VPC flow visibility, alerting workflows and audit of snapshot access. Those post-incident actions strongly indicate pre-incident detection and monitoring were not sufficient for rapid identification of abnormal API key use or sensitive snapshot activity. In practice, this is where organisations lose time: the logs may exist, but not in a form that produces useful detections around key misuse, anomalous region/account activity, snapshot access or administrative actions originating from atypical infrastructure.
Snapshot governance is also central. The exposed data came from an old database snapshot created for testing and the commentary correctly emphasises that snapshots are a durable exfiltration mechanism inside AWS. If organisations allow broad copy/share/restore access or fail to tightly govern who can interact with snapshots, sensitive data can leave the intended trust boundary without touching the live database. Even where the source does not detail cross-account sharing mechanics, it clearly supports that snapshot access was sufficient to obtain the dataset. For security reviews, that makes snapshots, AMIs and backups first-class exfiltration surfaces.
The business impact was significant. Imperva disclosed exposure of customer emails, password hashes, API keys and TLS keys, then had to notify regulators and support large-scale customer remediation including password changes, certificate rotation and API key regeneration. That creates direct operational cost, customer friction, trust erosion and potential contractual or regulatory exposure. The reputational impact is amplified because the affected company is itself a security provider. For enterprise buyers and M&A diligence, this kind of incident raises questions about control maturity, secure cloud migration discipline and whether security architecture kept pace with platform adoption.
From a SkySiege perspective, this maps cleanly to actionable assessment areas: public exposure of internal compute, use of static access keys, concentration of privilege in API credentials, lack of guardrails on snapshot access and retention, unmanaged dormant assets and insufficient telemetry around control-plane abuse. Those are the conditions that should be surfaced early because they are exploitable, measurable and directly tied to breach outcomes.
