IAM and KMS Post Exploitation extended

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md

@@ -96,6 +96,91 @@ If an S3 bucket is given as a principal, because S3 buckets do not have an Accou
 
 A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **some services might not support that** (like CloudTrail according to some sources).
 
+### Credential Deletion 
+With any of the following permissions — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — an actor can remove access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates or CloudFront public keys, or disassociate roles from instance profiles. Such actions can immediately block legitimate users and applications and cause denial-of-service or loss of access for systems that depend on those credentials, so these IAM permissions must be tightly restricted and monitored.
+
+```bash
+# Remove Access Key of a user
+aws iam delete-access-key \
+  --user-name <Username> \
+  --access-key-id AKIAIOSFODNN7EXAMPLE
+
+## Remove ssh key of a user
+aws iam delete-ssh-public-key \
+  --user-name <Username> \
+  --ssh-public-key-id APKAEIBAERJR2EXAMPLE
+```
+
+### Identity Deletion
+With permissions like `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, or `iam:RemoveUserFromGroup`, an actor can delete users, roles, or groups—or change group membership—removing identities and associated traces. This can immediately break access for people and services that depend on those identities, causing denial-of-service or loss of access, so these IAM actions must be tightly restricted and monitored.
+
+```bash
+# Delete a user
+aws iam delete-user \
+  --user-name <Username>
+
+# Delete a group
+aws iam delete-group \
+  --group-name <Username>
+
+# Delete a role
+aws iam delete-role \
+  --role-name <Role>
+```
+
+### 
+With any of the following permissions — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — an actor can delete or detach managed/inline policies, remove policy versions or permissions boundaries, and unlink policies from users, groups, or roles. This destroys authorizations and can alter the permissions model, causing immediate loss of access or denial-of-service for principals that depended on those policies, so these IAM actions must be tightly restricted and monitored.
+
+```bash
+# Delete a group policy
+aws iam delete-group-policy \
+  --group-name <GroupName> \
+  --policy-name <PolicyName>
+
+# Delete a role policy
+aws iam delete-role-policy \
+  --role-name <RoleName> \
+  --policy-name <PolicyName>
+```
+
+### Federated Identity Deletion
+With `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, and `iam:RemoveClientIDFromOpenIDConnectProvider`, an actor can delete OIDC/SAML identity providers or remove client IDs. This breaks federated authentication, preventing token validation and immediately denying access to users and services that rely on SSO until the IdP or configurations are restored.
+
+```bash
+# Delete OIDCP provider
+aws iam delete-open-id-connect-provider \
+  --open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
+
+# Delete SAML provider
+aws iam delete-saml-provider \
+  --saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
+```
+
+### Illegitimate MFA Activation
+With `iam:EnableMFADevice`, an actor can register an MFA device on a user’s identity, preventing the legitimate user from signing in. Once an unauthorized MFA is enabled the user can be locked out until the device is removed or reset (note: if multiple MFA devices are registered, sign-in requires only one, so this attack will have no effect on denying access).
+
+```bash
+aws iam enable-mfa-device \
+  --user-name <Username> \
+  --serial-number arn:aws:iam::111122223333:mfa/alice \
+  --authentication-code1 123456 \
+  --authentication-code2 789012
+```
+
+### Certificate/Key Metadata Tampering
+With `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, an actor can change status or metadata of public keys and certificates. By marking keys/certificates inactive or altering references, they can break SSH authentication, invalidate X.509/TLS validations, and immediately disrupt services that depend on those credentials, causing loss of access or availability.
+
+```bash
+aws iam update-ssh-public-key \
+  --user-name <Username> \
+  --ssh-public-key-id APKAEIBAERJR2EXAMPLE \
+  --status Inactive
+
+aws iam update-server-certificate \
+  --server-certificate-name <Certificate_Name> \
+  --new-path /prod/
+```
+
 ## References
 
 - [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md

@@ -98,27 +98,33 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
 ```
 
 > [!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 perfoemed from a cross account**.
+> 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
 
-#### Global 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** encrypted with the previous version with the new one.
+- **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
 
-### Destroy keys
+### 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
-# Destoy they key material previously imported making the key useless
-aws kms delete-imported-key-material --key-id 1234abcd-12ab-34cd-56ef-1234567890ab
+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 \
@@ -128,6 +134,74 @@ aws kms schedule-key-deletion \
 > [!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}}