You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
+85Lines changed: 85 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -96,6 +96,91 @@ If an S3 bucket is given as a principal, because S3 buckets do not have an Accou
96
96
97
97
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).
98
98
99
+
### Credential Deletion
100
+
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.
101
+
102
+
```bash
103
+
# Remove Access Key of a user
104
+
aws iam delete-access-key \
105
+
--user-name <Username> \
106
+
--access-key-id AKIAIOSFODNN7EXAMPLE
107
+
108
+
## Remove ssh key of a user
109
+
aws iam delete-ssh-public-key \
110
+
--user-name <Username> \
111
+
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
112
+
```
113
+
114
+
### Identity Deletion
115
+
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.
116
+
117
+
```bash
118
+
# Delete a user
119
+
aws iam delete-user \
120
+
--user-name <Username>
121
+
122
+
# Delete a group
123
+
aws iam delete-group \
124
+
--group-name <Username>
125
+
126
+
# Delete a role
127
+
aws iam delete-role \
128
+
--role-name <Role>
129
+
```
130
+
131
+
###
132
+
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.
133
+
134
+
```bash
135
+
# Delete a group policy
136
+
aws iam delete-group-policy \
137
+
--group-name <GroupName> \
138
+
--policy-name <PolicyName>
139
+
140
+
# Delete a role policy
141
+
aws iam delete-role-policy \
142
+
--role-name <RoleName> \
143
+
--policy-name <PolicyName>
144
+
```
145
+
146
+
### Federated Identity Deletion
147
+
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.
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).
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.
> 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**.
101
+
> 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**.
There is another way to perform a global KMS Ransomware, which would involve the following steps:
110
108
111
109
- Create a new **key with a key material** imported by the attacker
112
-
-**Re-encrypt older data** encrypted with the previous version with the new one.
110
+
-**Re-encrypt older data**of the victim encrypted with the previous version with the new one.
113
111
-**Delete the KMS key**
114
112
- Now only the attacker, who has the original key material could be able to decrypt the encrypted data
115
113
116
-
### Destroy keys
114
+
### Delete Keys via kms:DeleteImportedKeyMaterial
115
+
116
+
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.
117
117
118
118
```bash
119
-
# Destoy they key material previously imported making the key useless
> Note that AWS now **prevents the previous actions from being performed from a cross account:**
130
136
137
+
### Change or delete Alias
138
+
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.
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.
152
+
153
+
```bash
154
+
# Firts cancel de deletion
155
+
aws kms cancel-key-deletion \
156
+
--key-id <Key_ID>
157
+
158
+
## Second enable the key
159
+
aws kms enable-key \
160
+
--key-id <Key_ID>
161
+
```
162
+
163
+
### Disable Key
164
+
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.
165
+
166
+
```bash
167
+
aws kms disable-key \
168
+
--key-id <key_id>
169
+
```
170
+
171
+
### Derive Shared Secret
172
+
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.
173
+
174
+
```bash
175
+
aws kms derive-shared-secret \
176
+
--key-id <key_id> \
177
+
--public-key fileb:///<route_to_public_key> \
178
+
--key-agreement-algorithm <algorithm>
179
+
```
180
+
181
+
### Impersonation via kms:Sign
182
+
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.
183
+
184
+
```bash
185
+
aws kms sign \
186
+
--key-id <key-id> \
187
+
--message fileb://<ruta-al-archivo> \
188
+
--signing-algorithm <algoritmo> \
189
+
--message-type RAW
190
+
```
191
+
192
+
### DoS with Custom Key Stores
193
+
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.
0 commit comments