TL;DR: Amazon EMR's logging path can be redirected to an attacker-owned bucket through RunJobFlow, according to Upwind's analysis. Practitioners need ownership checks before cluster launch because console-only protections do not cover API-driven automation.
Editorial analysis by NHI Mgmt Group, based on content published by Upwind: “Spark in the Dark: Silent Cross-Tenant Log Exfiltration in Amazon EMR”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: EMR log routing can become an exfiltration path when the service accepts a bucket name without proving ownership.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A question worth separating out:
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.
👉 Read our full editorial: EMR log URI trust lets cross-tenant log exfiltration succeed