Whose encryption key is this? It's a secret to everybody.

The talk starts with a cloud security team inheriting a new AWS organization and trying to collect network telemetry from VPC flow logs. Reading the logs in S3 returned access denied, even though the presenters held broad permissions. The objects were encrypted, and the key they referenced belonged to an account nobody on the team recognised.

The presenters walk through how they traced the problem. Server-side encryption with KMS, where no key ARN is specified, falls back to the AWS-managed S3 key, whose policy blocks use from outside the owning account. A logging service writing into that bucket then encrypts objects with a key in its own account, which the customer cannot decrypt. They reproduced the setup, linked the unfamiliar account ID to Amazon's logging operations, and recovered their data only through AWS support. The failure was silent, with no error at write time.

For defenders, the takeaways are to look for buckets configured with KMS but no key ARN, using infrastructure-as-code scanning, AWS Config, or CloudTrail. Bucket policy conditions can restrict where encryption keys come from, although the presenters found service control policies hard to write precisely for this case. They stress testing that logs are actually readable before an incident needs them.