FTX Japan Breach Exposes 26M Records via Amazon S3 Error

By late 2024 the public cloud had become the default platform for building and running new applications, business workflows, and data processing pipelines. Cloud adoption continued to accelerate through 2025. Industry forecasts place overall cloud spend in the hundreds of billions of dollars by the end of 2025. Analysts also estimate that more than one hundred zettabytes of data will reside in cloud infrastructure by the end of 2025, representing a significant portion of global digital data. 

As more workloads move, more data follows. Customer records, payment history, internal analytics output, compliance evidence, audit logs, and operational reports are all copied into cloud storage. That data does not live in a single place. It is replicated across object storage, snapshots, file systems, analytics buckets, and backup archives in multiple regions and accounts.

Every storage location, for example an Amazon S3 bucket, an Azure Blob container, or a Google Cloud Storage bucket, has dozens of configuration options. A single misconfiguration can make internal data publicly reachable without any exploit.

Casmer Labs Observed Trend

Casmer Labs is the internal threat research team within Cloud Storage Security. In recent months Casmer Labs has observed several high profile cloud storage exposure events. In each case sensitive data was left accessible on the public internet due to object storage that was not properly restricted.

These were not advanced zero day intrusions. They were the result of human error, a lack of continuous monitoring or observability, and weak lifecycle control over cloud storage.

FTX Japan Exposure

FTX Japan, which suspended core operations following the broader collapse of FTX in November 2022 and later completed customer withdrawals in early 2023, is one of the most recent examples.

On May 12 2025 researchers from Cybernews identified an Amazon S3 bucket linked to infrastructure associated with FTX Japan. The bucket was publicly accessible. It did not require a password. 

According to public reporting the exposed bucket contained more than twenty six million files. Those files included data tied to roughly thirty five thousand users. The contents included

• Usernames and real names

   

• Email addresses

   

• Residential addresses

   

• FTX account identifiers

Detailed transaction logs, including borrowing and lending history, cryptocurrency balances and movements, collateral types, margin rates, and internal risk flags such as liquidation warnings and margin risk triggers 

Reporting noted that the files contained structured financial reports and operational logs. Some of the data was generated as recently as July 2024, well after FTX Japan was widely understood to have wound down and after customer withdrawals had been completed. This suggests that portions of the backend reporting infrastructure may have remained active after shutdown. 

Cybernews also reported that FTX Japan had been acquired by bitFlyer in 2024 and rebranded as Custodiem. Researchers stated that it was not yet clear whether the exposed S3 bucket belonged to infrastructure still in use under the rebranded entity or whether it was an abandoned system left running from before the acquisition. The uncertainty included whether the personal data belonged to historical FTX Japan users, Custodiem users, or both. 

Why This Matters

Even if an exchange is no longer processing withdrawals or trades, exposed customer data still has value to attackers. The reported exposed files contained names, addresses, account identifiers, and detailed transactional history. That level of detail can be used to build credible social engineering and phishing campaigns. An attacker can reference specific borrowing activity, collateral types, or margin warnings to appear legitimate and pressure a target.

Attackers can also use information about wallet behavior and collateral levels to identify individuals with higher balances or higher exposure. Those individuals are more attractive targets for extortion and credential theft. 

The FTX Japan exposure is part of a broader pattern that Casmer Labs continues to track. Cloud data exposures are increasingly driven by misconfigured object storage such as public Amazon S3 buckets. The exposure does not require compromise of an application or an identity provider. The data is simply there, online, for anyone who knows where to look.

Guidance for Affected Users

If you ever held an account with FTX Japan or if you interacted with any successor service that reused your data, standard protective steps include

• Change passwords on all accounts that may have shared credentials with that exchange. Do not reuse that password in other financial accounts. 

   

• Enable multifactor authentication wherever possible.

   

• Watch for phishing attempts that cite specific past trading activity, margin calls, borrowing history, or collateral details.

   

• Monitor accounts, email addresses, and crypto wallet activity for unusual access attempts.

These steps are intended to reduce downstream fraud and impersonation.

What Organizations Should Do Now

Incidents like this are preventable. The controls below are already available to most security and cloud platform teams. The challenge is applying them consistently across every account, region, and workload.

1. Restrict public access to cloud storage
   

   Apply Amazon S3 Block Public Access at both the account and bucket level unless there is a documented, time bound exception with a named owner. Review bucket policies and access control lists for any principal that can list or read objects. Treat public read access to storage as an exception state with an expiration, not a normal operating mode.

2. Maintain a continuous inventory of storage
   

   Maintain a live inventory of all cloud storage resources, including S3 buckets, EBS snapshots, EFS file systems, FSx file systems, object backups, and other repositories. Track ownership, business purpose, data sensitivity, external exposure, encryption status, and last activity for each location. This is foundational data security posture management for cloud storage. Without this inventory, security teams often first learn of a bucket from an outside researcher.

3. Classify sensitive data
   

   Identify which buckets or file systems hold personal data, financial records, transaction logs, or other regulated data. Apply stricter access control, logging, and review requirements to those locations. Do not place regulated data into temporary or legacy storage without hardening access first.

4. Monitor activity in storage
   

   Capture object level access logs for sensitive storage. Alert on bulk listing, large transfers, and unusual read activity from unfamiliar sources. This type of activity monitoring helps detect data exfiltration, insider misuse, and ransomware staging in storage.

5. Continuously assess storage posture
   

   Continuously evaluate storage for public access, broad cross account access, missing encryption, missing logging, weak retention or immutability controls, and other posture gaps. Detect configuration drift. A bucket that was private last week and public this week should generate an alert. Extend these posture checks to vendor and partner owned storage, not only first party accounts.

How DataDefender Helps

DataDefender by Cloud Storage Security focuses on cloud storage security and on data security posture management for cloud storage, sometimes referred to as DSPM for cloud storage. It is designed to help security and compliance teams govern sensitive data in object storage, snapshots, and file systems in Amazon Web Services.

DataDefender provides

1. Continuous storage inventory
   

   DataDefender maintains an up to date inventory of storage resources across connected AWS accounts. This includes Amazon S3, EBS snapshots, EFS file systems, FSx file systems, and Glacier vaults. The inventory includes owner, business purpose, exposure status, encryption state, recent activity, and other metadata. This allows teams to answer where sensitive data lives and who is responsible for it.

2. Sensitive data discovery and classification
   

   DataDefender identifies storage locations that contain sensitive or regulated data, such as personal identifiable information, transaction history, internal reports, or credentials. This supports prioritization. High risk storage locations can be reviewed and locked down first.

3. Activity monitoring and anomaly detection
   

   DataDefender records which identities accessed which objects and when. It highlights unusual access such as large transfers, mass listing, or activity from unfamiliar identities. This supports investigation of data exfiltration, insider misuse, or ransomware style staging in storage.

4. Continuous posture evaluation
   

   DataDefender continuously evaluates storage posture and checks for publicly accessible S3 buckets, permissive access control lists, broad cross account access, insecure or unencrypted snapshots, missing logging, weak retention controls, and lack of immutability. The intent is to surface misconfigurations before they become public exposure events.

5. Evidence for audit and response
   DataDefender links actor, time, and object level access, along with configuration state. During an exposure review this helps answer when a storage location became exposed, which identities accessed which objects, and when access was removed. That evidence supports legal review, notification decisions, and regulatory response.
   

DataDefender performs more than ninety automated storage security checks across multiple AWS storage services and prioritizes those checks by severity. High impact issues such as publicly accessible Amazon S3 buckets and broadly shared snapshots are surfaced first.

Summary

The FTX Japan exposure demonstrates a recurring failure pattern in public cloud storage. A publicly accessible Amazon S3 bucket, containing more than twenty six million files and data tied to roughly thirty five thousand users, was left exposed long after the company was believed to be inactive. The data reportedly included names, addresses, account identifiers, and detailed transaction activity.

Attackers do not need to breach production applications to gain value from that type of exposure. They only need to find the open bucket. Tools and search engines exist to locate publicly accessible cloud storage.

For that reason, cloud storage is now a primary attack surface. Security teams must maintain continuous storage inventory, classify sensitive data, monitor activity inside storage, assess storage posture continuously, and preserve evidence that shows who accessed which data and when. This is the control layer that DataDefender is built to provide.

Click Here to Register for the Beta