TL;DR: Directly calling Amazon EMR's RunJobFlow API can accept an unverified S3 LogUri and write cluster logs to an attacker-owned bucket, according to Upwind. The control gap is between console hardening and API trust: ownership must be checked before any logging path is accepted.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Upwind's research: Amazon EMR logging can be sent to an attacker-owned S3 bucket when RunJobFlow trusts an unvalidated LogUri.
Why it matters: IAM and cloud security teams need to treat logging destinations as governed access paths, because API-level trust gaps can bypass console protections and expose cluster output, secrets, and source code.
Context
A logging destination should be treated as an access-controlled asset, not a free-text field. When a cloud service accepts a bucket name without verifying ownership, the service can route sensitive operational output into an account the caller does not control.
This pattern matters in AWS EMR because the cluster logging path carries step output, provisioning detail, and Spark runtime secrets. Where automation calls the API directly, the identity and ownership checks that exist in the console can disappear from the workflow.
The result is not a privilege escalation in the usual sense, but a trust failure at the boundary between the workload and its storage destination. That makes the issue especially relevant to teams managing Amazon S3 security and workload logging governance.
Key questions
Q: What signs suggest EMR logs are being routed to the wrong bucket?
A: Common signs include logs landing in an unexpected account, bucket or region, empty or missing log objects, access denied errors from the cluster, and bucket ownership or ACL mismatches. Misconfigured bucket names, stale destinations and overwritten log paths can also point to routing errors. CloudTrail or cluster event records usually confirm where delivery failed.
Q: Why does a trusted LogUri let attackers capture EMR logs?
A: A trusted LogUri lets the logging service write to whatever S3 location is named there, so if that bucket is attacker-controlled or incorrectly claimed, log data can be delivered outside the intended account. The abuse usually depends on missing bucket ownership validation, weak destination controls, or failing to restrict who can create and own the bucket.
Q: How do S3 bucket ownership checks prevent log exfiltration?
A: bucket ownership checks verify that the S3 bucket named for logs is actually owned by the intended account before delivery starts. That stops attackers from registering the same bucket name elsewhere and receiving sensitive logs through bucket squatting, while also reducing misrouting caused by stale or misconfigured destinations.
Q: What is the difference between console validation and API validation?
A: Console validation checks a setting through the management interface, while API validation checks the same setting through the programmatic service endpoint. In security terms, API validation is usually the stronger control because it can be enforced automatically at creation or update time, whereas console-only checks can be bypassed by direct API calls or infrastructure code.
Technical breakdown
How RunJobFlow handles LogUri
Amazon EMR uses the LogUri parameter to decide where cluster logs are written. In the vulnerable pattern, the client constructs an S3 URI and passes it to RunJobFlow without first proving that the bucket exists or belongs to the caller. That matters because the API treats the string as a valid destination rather than as a security-sensitive reference that must be resolved and verified. The weakness is not in Spark itself. It is in the control boundary around log routing, where trusted input should have been checked against account ownership and bucket existence before the cluster started. See the Amazon S3 Security Guide.
Practical implication: Validate logging destinations before cluster creation and require an ownership check on every EMR log bucket.
Why console protection did not extend to the API
The console path adds a defensive check that the API path does not. That creates a split control model where a human-operated workflow gets bucket validation, but infrastructure-as-code, SDKs, and CLI calls can bypass it entirely. This is a classic governance gap: one interface enforces ownership, another relies on caller discipline. Security teams often assume a cloud service is uniformly protected because the console looks safe, but automation is usually the real production path. If the API layer does not enforce the same rule, the weaker path becomes the attacker’s entry point.
Practical implication: Review every API-based provisioning flow as a separate trust boundary, not as a clone of the console workflow.
Why late bucket creation still enables retroactive capture
EMR's log pusher buffers and retries writes, so the attacker does not need to own the bucket before the cluster starts. If the bucket appears later, buffered logs can still be delivered retroactively. That changes the threat from a simple pre-creation race into a persistence-like storage takeover, because the log stream keeps trying to resolve the same destination name. The practical issue is that destination validation must happen before the workload begins, not after logs start flowing. Once the service trusts the name, timing alone can be enough to capture earlier output. See the Cloud Storage Exposure Playbook.
Practical implication: Block name-based trust in logging paths and verify bucket ownership before any workload can buffer sensitive output.
Threat narrative
Attacker objective: Capture Spark logs, secrets, source code, and sensitive output from EMR clusters by redirecting log delivery to an attacker-controlled bucket.
- Entry occurs when the victim launches an EMR cluster or automation submits a RunJobFlow request with a predictable LogUri.
- Credential or ownership abuse follows when the attacker controls or later registers the matching S3 bucket name in a different account.
- Impact occurs when EMR writes buffered logs, secrets, source code, and operational output into the attacker-owned bucket.
- The attacker's objective is silent cross-tenant capture of cluster telemetry and application data without triggering failures in the victim account.
Breaches seen in the wild
- Football Australia AWS keys exposure 2024: AWS keys hard-coded in a Football Australia web page reportedly opened 127 storage buckets of player and fan data; fixed within hours, no misuse confirmed.
- Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.
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
The real failure is trust in a destination name, not just a missing validation call. EMR logging becomes vulnerable when the service accepts a bucket reference as if it were already authorised. That is a governance error in the data path, because the destination is part of the access model and must be proven before sensitive output is routed there. The practitioner conclusion is simple: storage targets need the same ownership discipline as credentials.
Console-only protection creates a false sense of coverage. If one interface validates ownership and another does not, the weaker interface becomes the production control plane. That split is especially dangerous in cloud automation, where SDKs and pipelines do most of the provisioning. AWS cross-account trust policies are a useful reminder that caller identity and resource ownership must be checked together, not assumed from context. Practitioners should treat every API path as its own policy surface.
Silent log exfiltration is a workload logging governance problem. The issue is not merely that logs can leak, but that the leak produces no obvious failure signal in the victim account. That means logging design must assume hostile ownership of names, retries, and delayed availability. The practitioner conclusion is to govern log destinations as security assets, with explicit approval, monitoring, and revocation paths.
Cross-tenant storage capture is an identity boundary failure for cloud workloads. EMR, S3, and automation tooling all participate in a chain where the workload identity, the storage owner, and the caller may not match. When that chain is not enforced, machine-to-machine trust becomes a route for exfiltration. The practitioner conclusion is to align log delivery with Amazon S3 security controls, not with convenience defaults.
Late binding of storage destinations creates a standing exposure window. A bucket that does not exist at launch can still become the capture point later because the service retries delivery. That turns temporary assumptions into durable risk. The practitioner conclusion is to remove that window by verifying ownership before cluster creation and by assuming buffered logs may still be delivered after the fact.
What this signals
API-level storage validation will matter more than console hardening. Cloud teams need to assume that the path most engineers use in production is the path attackers will target first. When a service trusts a storage destination by name, the right control is ownership verification at issuance time, not after the workload starts.
Log delivery should be governed as a security control, not an observability convenience. The combination of buffered retries and predictable bucket names means delayed capture can still expose sensitive content long after a cluster begins running. Practitioners should expect logging destinations to become a governance issue across IaC, SDKs, and platform guardrails.
Cross-tenant exfiltration through cloud logging is a boundary problem, not a single-service bug. The broader lesson is that machine-to-machine trust needs explicit ownership enforcement whenever a workload writes into shared cloud storage. Teams that manage EMR, data pipelines, or other managed compute services should review whether destination validation is present in every provisioning path.
For practitioners
- Audit every EMR logging destination List active and recent clusters, extract each LogUri, and verify that every bucket is owned by your account rather than relying on the default naming pattern.
- Verify bucket ownership before cluster launch Use bucket existence and ownership checks in provisioning workflows so that RunJobFlow cannot accept an unverified S3 location.
- Treat API paths as separate controls Review every SDK, CLI, and Terraform path that calls EMR directly, because console hardening does not automatically protect direct API usage.
- Instrument log destination drift detection Alert when a cluster points to a logging bucket that is missing, newly created, or owned by a different account, because delayed log delivery can still expose earlier output.
Key takeaways
- EMR log routing can become an exfiltration path when the service accepts a bucket name without proving ownership.
- The exposure is practical, not hypothetical, because delayed log delivery can still reach a bucket created after the cluster starts.
- Ownership validation belongs in every provisioning path that can set LogUri, especially SDKs and direct API calls.
Related NHI Mgmt Group resources: Amazon S3 Security Guide · T1530 Data from Cloud Storage Defensive Guide · Cloud Storage Exposure Playbook · Logging and Monitoring Policy Template
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | RunJobFlow accepts an unvalidated LogUri, which is an API-level configuration trust failure. |
| Recommendation — Require API-side validation for every LogUri before cluster creation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is unauthorized use of a storage destination across account boundaries. |
| Recommendation — Enforce ownership checks on storage destinations before workloads can write logs. | ||
| CIS Controls v8 | CIS-5 — Account Management | Cross-account bucket capture depends on weak account ownership governance for the logging target. |
| Recommendation — Inventory and verify ownership for every logging bucket used by managed compute services. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack uses trusted cloud paths to capture secrets and logs from managed workloads. |
| Recommendation — Map the logging path to credential access and exfiltration detections for cloud storage abuse. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud storage ownership and workload access governance are central to the LogUri failure. |
| Recommendation — Apply IAM controls to verify that every logging destination belongs to the caller's account. | ||
Key terms
- Amazon EMR: Amazon EMR is a managed big data platform for running distributed data-processing frameworks such as Hadoop and Spark on cloud infrastructure. It provisions clusters, manages much of the underlying configuration, and uses service and instance roles to control access to storage, logs and other cloud resources.
- LogUri: LogUri is the S3 URI that tells a service where to store its logs. It points log delivery to a specific bucket and prefix, so ownership, naming and access control on that destination determine whether logs are captured correctly or diverted.
- S3 bucket squatting: 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.
- Cross-tenant log exfiltration: Cross-tenant log exfiltration is the leakage of logs from one account or tenant to another tenant’s storage. It usually happens when a log destination is misconfigured, an attacker controls the target bucket name, or the service lacks ownership checks before writing the records.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends 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