KMS key policy tampering: how encrypted data is read by an outsider

Encryption at rest only protects you while the key policy stays honest. A KMS key policy is the access control for the key itself, so rewriting it to trust an external account turns ciphertext into readable data for an outsider, without touching a single data permission.

How the attack works

With kms:PutKeyPolicy on a customer-managed key, the attacker rewrites the policy to grant their own AWS account kms:Decrypt and kms:Encrypt. Cross-account Decrypt calls then arrive from the newly trusted account against ciphertext from the protected S3 data set and snapshot-derived volumes, reading database files that were encrypted only with this key. CloudTrail records the PutKeyPolicy event adding the external principal, followed by a steady stream of Decrypt from that account. In ATT&CK terms this is T1578, Modify Cloud Compute Infrastructure, with T1098, Account Manipulation.

Why it works

Too broad a principal held kms:PutKeyPolicy and policy edits were not gated by review. The key is meant to name only internal principals, but nothing prevented an external account from being added.

How to fix it

Never delete the key, which schedules deletion and can orphan legitimately encrypted data forever. The key policy is the control plane, so restore the original policy to remove the external principal, and disable the key as a safe interim brake while you assess. Then deny the offending session by aws:TokenIssueTime. Afterward, scope kms:PutKeyPolicy to a narrow admin set, add a service control policy that blocks external principals in key policies, gate policy edits with change review, and re-encrypt exposed data under a clean key. Note that once Decrypt was obtained, encryption safe-harbor no longer applies to the decrypted data.

Practice it

We built this as a GraphLattice Range scenario so administrators restore the key policy and deny by issue time, rather than deleting the key or chasing a database password.