In a typical incident where S3 buckets have been left exposed to the internet, UpGuard reported that Accenture left four AWS S3 buckets publicly accessible on the internet, allowing anyone with the bucket URLs to download sensitive data tied to the Accenture Cloud Platform and related environments.
The exposed contents included API data, authentication credentials, certificates, decryption keys, VPN keys, database backups, plaintext passwords, event logs and credentials for what appeared to be AWS, Google and Azure accounts. Based on the reported bucket contents, this was not just a data exposure issue; it created a plausible path to direct compromise of the cloud platform, connected environments and potentially client-facing assets. The core lessons are clear: internet-exposed storage remained insufficiently governed, highly privileged long-lived credentials were stored in object storage and sensitive key material was not adequately segregated or protected. For cloud security and due diligence, this incident highlights the need to validate public access controls, secret storage practices, credential rotation and whether exposed platform components could enable secondary attacks against customers or managed environments.
| What’s happening | Cause | Action |
|---|---|---|
| Public S3 buckets exposed sensitive cloud platform data to anyone on the internet | UpGuard found four S3 buckets configured for public access and downloadable by anyone who entered the URLs into a browser. This indicates failed storage access control and weak governance over internet exposure. | Validate that no cloud storage buckets are publicly accessible unless explicitly approved and continuously monitored. SkySiege would assess bucket public access settings, internet-reachable object storage exposure, account-level block public access controls and whether sensitive data is stored in publicly reachable locations. |
| Full credentials for the Accenture Cloud Platform were stored in accessible bucket contents | The exposed data reportedly included cloud platform credentials, Identity API configuration files, master access keys, access keys, VPN keys and credentials for Google and Azure accounts. This created risk of direct platform compromise, not just data disclosure. | Validate whether credentials, API keys, cloud account keys and administrative secrets are stored in object storage, backups or deployment artefacts. SkySiege would assess secret exposure in storage paths, instances of embedded credentials, cross-cloud credential placement and whether stored secrets could provide control-plane or production access. |
| Long-lived secrets were retained in storage instead of being tightly controlled | The source describes plaintext master access keys, passwords stored alongside keystore files, private signing keys and production VPN keys. This suggests use of durable credentials with insufficient lifecycle management and poor secret handling practices. | Validate use of long-lived credentials, static keys and certificates in storage repositories and operational buckets. SkySiege would assess IAM access key age where available, presence of unmanaged static credentials, certificate/private key storage practices and whether secrets are rotated and centrally managed through approved secret stores. |
| Key material and certificates could enable impersonation or decryption scenarios | Exposed client.jks files, plaintext passwords, private signing keys, private keys and certificates were reported in the buckets. UpGuard noted these could potentially enable access to Accenture environments and, in theory, decryption of traffic between Accenture and clients. | Validate whether keystores, signing keys, TLS private keys and decrypt-capable certificate material are stored outside hardened key management systems. SkySiege would assess where encryption keys and certificates reside, whether KMS or equivalent controls are enforced and whether sensitive cryptographic assets are improperly stored in buckets, snapshots or deployment packages. |
| Operational logs and session-related data increased attacker visibility and follow-on attack potential | The exposed buckets reportedly contained logs for cloud instance events, Zenoss event data, IP addresses and JSession IDs that could potentially be reused if still valid. This expanded attacker reconnaissance and possible session abuse opportunities. | Validate whether logs, session artefacts and administrative telemetry are exposed through storage, backups or diagnostic exports. SkySiege would assess publicly exposed logging repositories, sensitive operational metadata in object stores and whether monitoring outputs reveal privileged workflows, internal assets or reusable tokens. |
| Large backup and software buckets concentrated too much sensitive data in one place | The 137 GB acp-software bucket reportedly contained database dumps, plaintext passwords, client-related credentials, internal email information and platform data. This reflects poor data minimization and weak segmentation of sensitive operational assets. | Validate whether backups and software repositories contain production secrets, customer data and administrative artefacts without segmentation or compensating controls. SkySiege would assess backup storage exposure, data classification gaps, excessive data concentration in buckets and whether production, client and administrative data are improperly co-located. |
| Multi-cloud access risk expanded the blast radius beyond AWS | The source reports credentials for what appeared to be Google and Azure accounts inside the exposed bucket contents. This means one AWS storage exposure may have created compromise paths into other cloud environments. | Validate whether one cloud environment stores credentials for other clouds or third-party platforms. SkySiege would assess cross-cloud trust dependencies, exposed credentials spanning AWS/Azure/GCP and whether a single storage misconfiguration can cascade into broader enterprise compromise. |
| Client environments may have been exposed through a managed platform trust model | UpGuard states the exposed contents appeared to support the Accenture Cloud Platform used by major enterprise customers, raising the possibility of secondary attacks against clients if the credentials and keys were valid. | Validate whether managed service platforms create inherited risk to customer environments when provider storage or credentials are exposed. SkySiege would assess shared-service architecture, tenant separation assumptions, privileged access paths from provider environments to customer assets and concentration risk in management-plane components. |
This incident matters because the failure was not limited to accidental data disclosure. UpGuard’s findings indicate that internet-accessible storage exposed the credentials and cryptographic material needed to operate or access parts of the Accenture Cloud Platform itself. That materially changes the risk from confidentiality loss to possible control-plane compromise, impersonation, lateral movement and downstream customer impact.
From a security operations perspective, the incident exposes several detection and visibility gaps:
From a governance standpoint, this reflects weak control over:
Business impact could have included platform compromise, client breach notification obligations, service disruption, contractual exposure, reputational damage and significant financial loss. For due diligence, this is a clear indicator to test public access controls, credential hygiene, key management and managed-service tenant isolation rather than treating storage exposure as an isolated configuration mistake.
