Public S3 Bucket Exposure: Misconfiguration Risks in 2025

Casmer Labs, the threat research team within Cloud Storage Security, continues to observe cases in 2025 where sensitive data is exposed through publicly accessible cloud storage. In these cases, exposure typically comes from configuration, not intrusion. A storage resource such as an Amazon S3 bucket is left open to the internet and contains real customer data, financial records, or other regulated information.

When an S3 bucket is publicly readable, often called an S3 bucket misconfiguration, anyone with the URL can download its contents. That is a cloud data exposure event even if there is no exploit, malware, or credential theft involved.

Incident Summary

In late August and early September 2025, a security research firm reported a publicly accessible Amazon S3 bucket containing hundreds of thousands of PDF files related to bank transfer mandates and recurring debit authorizations in the Indian financial system.

Public reporting on the incident noted the following

• The PDF files included customer names, home addresses, phone numbers, and email addresses

• The files referenced bank account numbers and IFSC routing codes

• Many forms documented authorization for recurring debits and payment instructions

• The data appeared to span multiple financial institutions and payment processors

• New files continued to appear in the bucket during the time researchers were analyzing it, which indicates the bucket was actively in use and not an abandoned test resource

• After coordinated disclosure attempts, public read access to the bucket was removed

No advanced technique was required to retrieve the data. The bucket allowed public read access. This matches prior cloud storage exposure events, where sensitive data is copied into object storage, access is broadened for convenience, and that setting is never fully reversed.

How Exposed Buckets Are Created

Amazon S3 includes native controls to prevent this outcome. These controls include S3 Block Public Access, IAM policies, service control policies, access points, and explicit bucket policies. These controls are effective when they are applied consistently and monitored over time.

In most cloud environments, storage is created quickly to support a specific workflow. Common examples include onboarding, loan processing, analytics, customer document intake, file exchange with a partner, or internal reporting. The bucket is considered temporary. Over time, actual production data is written to it because that is the fastest way to keep a process moving.

Casmer Labs has observed the following recurring pattern

• A bucket created for testing or partner exchange begins receiving live production data

• Public or broadly accessible read permissions are enabled so an outside party or downstream system can pull files easily

• That access setting is left in place after the immediate need passes

• The bucket continues to collect sensitive data and is treated as part of the normal workflow

At that point, the organization is effectively running a public download source for regulated data, often without realizing it.

This is a storage governance issue. It is not a perimeter defense issue. It is not an endpoint issue. It lives entirely in the configuration and monitoring of cloud object storage.

It is also the class of problem that data security posture management, also called DSPM, for cloud storage is intended to surface. DSPM for cloud storage maps where sensitive data is stored, evaluates how those locations are exposed, and raises an alert when the two do not match.

Why Exposures Take Time to Contain

When a public S3 bucket containing sensitive data is reported, security teams, compliance teams, and legal teams all need the same baseline information

• Which specific storage resource is involved

• Who is responsible for it

• What types of data are present, for example personally identifiable information, bank account details, authorization language, or internal records

• Whether the data is regulated

• Whether the data was accessed at scale while it was exposed

Answering those questions is rarely instant. Four recurring gaps tend to slow response

1. Lack of authoritative storage inventory
   Many organizations do not maintain a complete and current inventory of their cloud storage footprint. That footprint includes S3 buckets, EBS snapshots, EFS file systems, FSx file systems, Glacier, and similar services across all AWS accounts and regions. As a result, security may not be aware that a given bucket exists until an external party flags it. This is a core DSPM for storage problem. You cannot secure what you do not know you own.

2. Lack of data classification and sensitivity labeling
   Most buckets are not tagged with reliable indicators of what they contain. Examples include customer payment information, personal identifiers, health data, credentials, or documents intended only for internal reference. Without basic classification, teams cannot immediately determine the severity of a cloud data exposure. A public bucket with marketing screenshots is not the same as a public bucket with active banking mandate forms.

3. Limited visibility into object level activity
   Many organizations log high level management events but do not capture object level list, read, and download activity at scale. Without storage activity monitoring, it is difficult to answer the question of whether anyone systematically enumerated or pulled these files. That matters for incident reporting, breach notification decisions, and later regulatory review.

4. Ownership gaps
   Buckets and file shares often move between teams. A bucket may be created by one group, consumed by another, and later become part of a workflow that no longer has a clear technical owner. During an exposure, this slows containment because no single team immediately accepts responsibility for access control and shutdown.

During that entire period, the data is still exposed.

Business and Regulatory Impact

Public access to cloud object storage that contains personal or financial information introduces three immediate issues

1. Fraud and social engineering
   

   Information in recurring debit authorization forms, payment instructions, or onboarding packets is highly specific. An attacker can reuse that detail to impersonate a bank, a loan servicer, an insurer, a collections agent, or a support representative. They can also build targeted phishing around phrases such as we need to verify your mandate or your recurring debit failed.

2. Regulatory and contractual exposure
   

   In many regions, bank account details, certain personal identifiers, and financial authorization language are treated as sensitive data. If that data can be retrieved from an S3 bucket on the public internet, the organization that controls it may have notification or retention obligations under financial, privacy, or sector regulations. Business partners such as banks and payment processors will also request evidence of containment and a defined plan to prevent repeat exposure.

3. Evidence and audit requirements
   Executive leadership, legal, and auditors will ask for a clear timeline. Specifically, when did the bucket become public, who accessed which objects, and when was public access removed. If that timeline cannot be produced, the event is harder to close internally and harder to explain externally.
   

These impacts do not require a targeted attack. They come directly from public access to storage that was assumed to be private.

Recommended Actions

The controls below are available today in most cloud environments. The operational difficulty is enforcing them everywhere, across every account, and keeping them current.

1. Restrict public access by default

• Enforce Amazon S3 Block Public Access at the account level and bucket level unless there is a documented exception with a named owner and an expiration

• Review bucket policies, ACLs, and IAM permissions that allow the s3 GetObject action to any principal

• Treat anonymous or broadly accessible read access to storage as a temporary condition, not a normal state

This applies to development accounts, testing accounts, and partner facing accounts, not only production. Many public S3 exposures begin outside the core production account and later end up containing production data.

2. Maintain a continuous inventory of cloud storage

• Keep a live inventory of all S3 buckets, EBS snapshots, EFS file systems, FSx file systems, Glacier vaults, and other object or file storage across all AWS accounts and regions

• Track for each resource the business owner, business purpose, data sensitivity, last activity, encryption status, cross account exposure, and internet exposure

• Update this inventory automatically rather than by spreadsheet

This is foundational data security posture management for cloud storage. Without this capability, an organization can be surprised by its own asset.

3. Classify and label sensitive data

• Identify which buckets or file systems hold customer PII, financial records, health data, credentials, or legal and contract documents

• Apply stricter access policies, logging requirements, and review processes to those locations

• Avoid copying production data into temporary or vendor exchange buckets without hardening those buckets first

Classification drives priority. A storage exposure that includes regulated data triggers a different response path than one that involves generic internal reference material.

4. Monitor for unusual or high volume access

• Capture object level list and read activity for storage locations that contain sensitive data

• Alert on patterns such as rapid enumeration of many objects, large scale downloads, unexpected identities accessing regulated data, or bulk delete and encrypt behavior inside storage

• Use this activity record to assess possible data exfiltration, insider misuse, or ransomware style behavior in storage

This moves the conversation from we think it was exposed to we know whether data actually left.

5. Continuously check storage posture

• Evaluate storage on an ongoing basis for public exposure, broad cross account access, missing encryption, missing logging, weak or absent retention controls, and lack of immutability or versioning in places where durability is expected

• Detect configuration drift. A bucket that was private last week and is public this week should generate an alert

• Extend these posture checks to vendor and partner storage locations, not only first party locations

This is where continuous posture monitoring, which is a core part of DSPM for cloud storage, prevents silent drift from turning into public exposure.

6. Preserve and produce evidence

Security, compliance, and legal stakeholders will require three facts in any exposure review

• When the storage resource first became broadly or publicly accessible

• Which identities accessed which objects, and in what volume

• When access was restricted or removed

Being able to provide this timeline shortens incident handling, supports notification decisions, and reduces audit friction.

Role of DataDefender

DataDefender by Cloud Storage Security focuses on data security posture management for cloud storage. The product is designed to help organizations apply the practices described above in AWS environments at scale.

It is built to do the following

1. Inventory storage across accounts
   DataDefender maintains a live view of object and file storage across connected AWS accounts. Covered services include Amazon S3, EBS snapshots, EFS, FSx, and similar storage services. The inventory includes owner, business label, exposure status, encryption state, recent activity, and other metadata that is difficult to maintain manually.

2. Identify and label sensitive data
   DataDefender helps locate storage that contains financial records, customer PII, and other regulated data. This allows teams to focus controls and monitoring on the locations that would have the highest impact if exposed.

3. Monitor activity at the data layer
   The platform records which identities accessed which objects and when. It highlights unusual or bulk access patterns. This supports investigation of possible data exfiltration, insider misuse, or ransomware style activity in storage.

4. Continuously assess storage posture
   DataDefender runs ongoing checks against storage related configuration controls such as public exposure, cross account access, encryption, logging, retention, replication, versioning, and immutability. The goal is to detect and surface risky conditions before they become public exposure events.

5. Provide investigation and audit evidence
   When a possible storage exposure is reported, DataDefender supports drill down into activity in other words actor, time, and object. This evidence helps answer the standard questions from leadership, legal, and audit.

Cloud Storage Security also provides Antivirus for Cloud Storage. Antivirus for Cloud Storage is an in tenant, multi engine malware scanning capability for object storage. This is relevant for teams that want to block known malicious files, including ransomware payloads, from being ingested into buckets or redistributed.

Summary

Most significant cloud storage exposures in 2025 are not the result of advanced attackers. They are the result of public access on storage locations that contain real data.

Reducing that risk depends on five practices

1. Restrict public access by default, including in non production accounts

2. Keep an authoritative and continuously updated inventory of cloud storage

3. Classify and label sensitive data so that high impact locations can be prioritized

4. Monitor object level access, including bulk retrieval and unusual activity

5. Continuously assess storage posture and retain evidence

These practices align with the goals of DSPM for cloud storage. The objective is to understand where sensitive data lives, how it is exposed, who accessed it, and how to prove it.