S3 bucket squatting is the takeover of an unclaimed or deleted bucket name by another account. If a service still sends data to that name, the new owner can receive objects intended for the original account, including logs and other sensitive files.
What bucket squatting means in cloud storage
S3 bucket squatting happens when a bucket name becomes available after deletion or abandonment, and another account claims it. The security issue is not the name itself, but the trust other systems continue to place in that name, which can turn an ordinary storage destination into a takeover point for misplaced data.
The pattern is especially dangerous in integrations that write logs, exports, telemetry, backups or application data to a fixed bucket name. If the producer keeps sending objects after the original owner has lost control of the name, the new owner receives data meant for someone else.
That makes bucket squatting a cloud governance problem as much as a storage problem. The name can remain stable while the ownership, policy boundary and data recipient have silently changed.
Why bucket squatting creates data exposure
Bucket squatting becomes dangerous when a deleted or unclaimed bucket name is still referenced by apps, scripts, log shippers or vendor services. The sender often has no way to know that the destination now belongs to a different account, so sensitive objects can be redirected without any obvious error.
The exposure may include audit logs, application output, customer records, tokens embedded in files, or other operational data that was never intended for a third party. In practice, the issue is a broken trust assumption: the system thinks “same name” means “same recipient,” but cloud storage naming is global and ownership is not.
For cloud teams, this is closely related to broader storage exposure patterns. Public access, misrouted writes and weak lifecycle controls can all create similar outcomes, even if the specific trigger is different.
Controls that reduce these failures include preserving authoritative inventory of every bucket name in use, tracking which systems write to each destination, and treating bucket retirement as a controlled decommissioning event rather than a simple delete.
How organisations check whether they are exposed
Exposure checks start with a complete inventory of bucket names, writers and downstream dependencies. Teams should know which applications, services and third parties still point to each bucket, because stale references are usually what turns deletion into an exposure event.
It also helps to review internet-facing references, code repositories, configuration files, infrastructure templates and vendor documentation for bucket names that may survive long after an environment change. A retired bucket name that still appears in code or operational tooling is a candidate for takeover.
Validation should include logs and storage telemetry. If a bucket is being written to but ownership changed unexpectedly, that is a strong sign the name is still embedded in an active workflow rather than fully retired.
NHIMG’s Amazon S3 Security Guide is a useful baseline for understanding the surrounding control environment, while the Cloud Storage Exposure Playbook helps teams reason about misrouted storage and exposure response.
How to prevent takeover and reduce impact
Prevention depends on lifecycle discipline. Do not delete a bucket name unless you are sure no active producer still depends on it, and do not assume that a rename elsewhere will update every sender automatically. Cloud storage names are often hard-coded, cached or reused by external systems.
Where possible, use explicit ownership and retention controls so that important data is not left to chance after decommissioning. Lifecycle rules, object retention and clear retirement procedures can reduce the odds that a name is abandoned while systems continue to trust it.
If immediate deletion is unavoidable, compensate by redirecting writers to a controlled replacement destination before removal, then monitor for residual traffic. The point is to eliminate the gap between “old bucket removed” and “all senders updated.”
For teams operating in AWS, the AWS Security Guide provides a broader operational context, and the Amazon S3 Security Guide covers the storage-side baseline that helps keep bucket lifecycle changes from becoming exposure events.
Detection and post-incident review
Detection should focus on unusual write activity, unexpected ownership changes, and data arriving in a bucket that no longer belongs to the original account. If a bucket was deleted or intentionally retired, any later objects delivered to a newly claimed name deserve immediate review.
Post-incident analysis should ask what kind of data was sent, how long the stale reference existed, and which systems or vendors still pointed at the old destination. That review matters because the root cause is often not the squatting itself, but the failure to discover and retire every live reference.
Where the delivered content includes logs, tokens, certificates or other operational secrets, the incident may require rotation or invalidation of adjacent material even if the bucket itself is the only visible compromise. The destination can be replaced, but the exposed data may already have been copied.
The T1530 Data from Cloud Storage Defensive Guide is especially relevant for detection patterns, because it focuses on how cloud storage theft is observed and blocked in practice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1530 — Data from Cloud Storage | Bucket squatting can redirect cloud data to an attacker-controlled bucket. |
| Recommendation — Map suspicious bucket writes and exfiltration patterns to T1530 and review storage logs for unintended delivery. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Reviewing storage and access logs is central to spotting stale bucket delivery and takeover effects. |
| CM-8 — System Component Inventory | Bucket squatting risk depends on knowing every bucket name and every system that still references it. | |
| AC-3 — Access Enforcement | Bucket policies and ownership controls determine whether a newly claimed name can receive data safely. | |
| Recommendation — Analyze object delivery and access logs under AU-6 to detect unexpected writes and ownership changes. Maintain a complete inventory of bucket names and dependencies so retired names can be removed safely. Enforce access restrictions and ownership controls so only intended accounts can receive stored objects. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | The issue is rooted in incomplete inventory of storage destinations and dependencies. |
| PR.AA-05 — Access permissions and authorizations are managed, incorporating the principles of least privilege | Least-privilege write access and ownership boundaries reduce the blast radius of bucket misuse. | |
| Recommendation — Inventory every bucket and downstream writer so stale storage references can be retired before deletion. Limit who can create, delete, or repoint buckets so storage ownership changes cannot silently expose data. | ||
| CIS Controls v8 | CIS-5 — Account Management | Retiring and reassigning bucket destinations is an access and ownership lifecycle problem. |
| Recommendation — Manage storage ownership changes through controlled account and asset lifecycle processes. | ||
| OWASP ASVS | V13 — Configuration | Hard-coded or stale storage destinations are configuration failures that can expose sensitive data. |
| Recommendation — Treat bucket names as security-sensitive configuration and validate them before deployment. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org