TL;DR: Public S3 reads can leak an organization’s management account ID through undocumented IAM condition keys, according to Upwind, because the request context exposes resource ownership metadata even when the caller has no access to Organizations APIs. Account IDs are not secrets, but public resources now reveal enough structure to support targeted reconnaissance.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Upwind's research: Public S3 access can disclose AWS organization management account IDs through undocumented IAM condition keys.
Why it matters: This matters because organizational metadata can help attackers target phishing, role assumption and reconnaissance against high-value AWS accounts, while defenders may wrongly assume account IDs are harmless.
Context
Public S3 objects can expose more than data. In AWS, the request context may include ownership metadata that condition keys can reference, which turns an apparently ordinary read into a source of organisational intelligence. AWS security guide is the natural follow-on for teams that need to understand how public exposure, logging and account boundaries intersect.
The security gap here is not credential theft but metadata disclosure. A public resource can reveal an organisation’s management account ID even when the requester has no access to AWS Organizations APIs, which means the boundary being crossed is informational rather than transactional.
Key questions
Q: How do public S3 buckets leak AWS organisational metadata?
A: Public S3 buckets can disclose AWS organisational metadata through response headers, bucket names, object paths, account-linked error messages, and ownership-related request context. Attackers use this to map accounts, regions, naming patterns, and sometimes adjacent resources. Limit public access, strip sensitive identifiers from object names, and enforce bucket policies that block anonymous listing and read access.
Q: Why does an AWS management account ID matter to attackers?
A: An AWS management account ID helps attackers target the highest-value account in an organisation because it reveals an identifier that can be used in phishing, support impersonation, and account enumeration. Keep the management account separate, minimise exposure of the account ID, and protect it with strong authentication, restricted use, and organisation-level logging.
Q: How should teams block public metadata disclosure in AWS?
A: Teams block public metadata disclosure in AWS by preventing anonymous access, tightening bucket policies, and applying organisation-wide guardrails that deny public resource policies and risky sharing patterns. Use SCPs or equivalent policy controls, continuous configuration checks, and alerting on public ACLs, public bucket policies, and exposed account identifiers.
Q: What is the best way to protect an AWS management account?
A: The best way to protect an AWS management account is to keep it for billing and organisation control only, with no routine workloads or administrator use. Protect it with strong authentication, separate administrative roles, limited federation paths, organisation-level logging, and tight policy controls that reduce who can change guardrails or billing settings.
Technical breakdown
How AWS condition keys reveal request context
AWS evaluates condition keys against the internal request context on every API call. Some keys are documented and others are not, but undocumented keys can still influence authorization decisions if the engine populates them. A caller can combine sts:AssumeRole with a session policy that denies requests when a candidate value matches, then test the outcome of a harmless API call. The allow or deny result becomes a side channel for inferring whether the key exists and what value it holds. See the AWS IAM Policies and Roles Guide.
Practical implication: Review policy logic for information disclosure paths, not just direct access paths.
Why public S3 objects expose organisation metadata
A public S3 object gives the requester a target resource whose ownership metadata is evaluated in the resource context. That means aws:ResourceAccount, aws:ResourceOrgID and aws:ResourceOrgMasterAccountId can all be populated even when the caller has no relationship with the target organisation. The issue is not that the bucket grants access to the management account itself. The issue is that AWS returns enough context for an attacker to enumerate organisational structure through repeated policy tests. See the AWS Security Guide.
Practical implication: Treat public object access as metadata exposure and remove it where the information is sensitive.
Why account IDs are not a security boundary
AWS account IDs are often treated as if they were opaque identifiers that protect organisational structure, but they are exposed by several AWS request paths and can be inferred from public resources. Once exposed, the management account ID can support focused reconnaissance and more convincing targeting, even though the number alone does not grant access. The deeper governance mistake is using account identifiers as if they were secret material rather than operational references. See the AWS Organizations and SCPs Guide.
Practical implication: Design controls so that security does not depend on keeping account identifiers hidden.
Threat narrative
Attacker objective: The attacker wants to map an organisation’s AWS structure and identify the management account for follow-on targeting.
- Entry occurs when an attacker accesses a public S3 object that belongs to the target organisation.
- Credential access is replaced by context probing, where repeated policy tests infer aws:ResourceOrgMasterAccountId from the request evaluation path.
- Impact is organisational reconnaissance, which can support targeted phishing, role assumption attempts and further cloud enumeration.
Breaches seen in the wild
- 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
- Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Public resource metadata has become a reconnaissance surface: a bucket that is meant to expose content can also expose organisational identifiers through the authorisation engine. That changes the risk model for public cloud storage, because the leak is generated by policy evaluation rather than by the object itself. The practical conclusion is that public access must be treated as an information disclosure decision, not only a data-sharing decision.
Account identifiers are operational data, not secrets: this technique reinforces that a 12-digit account ID should not be treated as a protective control. When attackers can derive the management account from ordinary resource access, obscurity offers no meaningful boundary. Practitioners should base cloud segmentation on policy and isolation, not on the assumption that identifiers remain hidden.
Organisation-level control is the real defence line: the relevant failure mode is allowing public resources to exist without fully accounting for the metadata they disclose. AWS Organizations and SCPs matters here because it frames how organisation-wide guardrails, public access restrictions and management account hardening need to work together. The management account should be designed as a control plane, not a routinely exposed asset.
Management account exposure is a governance problem before it is a technical one: if teams assume only direct API access reveals sensitive account structure, they miss the side channel created by policy introspection. That assumption gap spans cloud security, IAM governance and incident response planning. Practitioners should close it by treating metadata leakage as a first-class risk in public cloud reviews.
What this signals
Metadata exposure is the new cloud reconnaissance layer: when public access reveals ownership context, defenders need to review exposure decisions as intelligence decisions. Cloud programmes that still separate data classification from control-plane metadata handling will miss this class of leakage.
Control-plane identifiers should be treated as discoverable, not confidential: once teams accept that account IDs and organisation IDs can be inferred from public resources, the emphasis moves to containment, segmentation and logging. The practical question is no longer whether attackers can learn the identifier, but whether that knowledge meaningfully expands blast radius.
For practitioners
- Restrict public S3 exposure Use account or organization-level controls to block public access wherever the bucket contents or ownership metadata should not be discoverable.
- Harden the AWS management account Keep the management account isolated from day-to-day workloads, require hardware MFA, use a dedicated email address and limit direct access to admin roles.
- Audit policies for metadata side channels Review whether session policies, condition keys and resource-based policies reveal ownership or organisation metadata during normal reads.
- Log public object access centrally Enable organisation-level CloudTrail logging and S3 data event logging so unusual public reads and probing patterns can be investigated.
Key takeaways
- Public S3 access can leak AWS management account identifiers through request-context evaluation, which turns ordinary reads into reconnaissance.
- The evidence matters because the leak comes from undocumented IAM condition keys, not from direct access to AWS Organizations.
- Defenders should block public exposure where possible, harden the management account and treat metadata disclosure as part of cloud governance.
Related NHI Mgmt Group resources: AWS Organizations and SCPs Guide · AWS Security Guide · Admin panels and super admin accounts · AWS IAM Policies and Roles Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Public S3 reads disclose organisation metadata through an undocumented request-context path. |
| Recommendation — Treat public resource metadata as exposed and remove or contain any path that leaks ownership information. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The probe depends on broad read access and condition evaluation paths that should be tightly limited. |
| Recommendation — Limit who can access public-facing resources and reduce the permissions that expose sensitive request context. | ||
| CIS Controls v8 | CIS-5 — Account Management | The issue centers on management account exposure and governance across AWS organisations. |
| Recommendation — Centralise and review account lifecycle governance so management accounts are isolated and tightly controlled. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Public object access and organisational metadata are governed through permissions and entitlements. |
| Recommendation — Review authorisations for public S3 objects and remove any entitlement that exposes organisational metadata. | ||
| MITRE ATT&CK | TA0007;TA0043 — Discovery;Reconnaissance | The technique is used to enumerate organisational structure for later targeting. |
| Recommendation — Map metadata probing to discovery and reconnaissance tactics and hunt for repeated policy-testing behaviour. | ||
Key terms
- AWS Organizations: AWS Organizations is an AWS control for managing multiple accounts under a shared governance structure. It lets security teams standardise account structure, centralise policy enforcement, and scale access administration across a fleet of accounts without treating each account as a separate governance island.
- IAM Condition Key: An IAM condition key is a field in an access control policy that lets you restrict when, where, or how a request is allowed. It is evaluated against request context such as source IP, principal tags, MFA use, VPC endpoint, or resource tags, and can narrow permissions without changing the action list.
- Management Account: The management account is the AWS account that controls the organisation and its member accounts. Because it sits at the top of the cloud control hierarchy, any trust path into it must be treated as highly sensitive and tightly governed.
- Session Policy: Session policy defines how long a user stays authenticated, when the session expires, and whether it survives browser restarts. In an identity provider, these settings are critical because long-lived or persistent sessions increase the chance that an unattended device, stolen cookie, or hijacked browser session can be abused.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security practitioners connect identity controls to the broader cloud and access risks their programmes depend on.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org