diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md
index a34dd0426..2db024cce 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md
@@ -52,6 +52,42 @@ aws secretsmanager delete-secret \
     --recovery-window-in-days 7
 ```
 
+## secretsmanager:RestoreSecret
+
+It is possible to restore a secret, which allows the restoration of secrets that have been scheduled for deletion, since the minimum deletion period for secrets is 7 days and the maximum is 30 days. Together with the secretsmanager:GetSecretValue permission, this makes it possible to retrieve their contents.
+
+To recover a secret that is in the process of being deleted, you can use the following command:
+```bash
+aws secretsmanager restore-secret \
+  --secret-id <Secret_Name>
+```
+
+## secretsmanager:DeleteResourcePolicy
+
+This action allows deleting the resource policy that controls who can access a secret. This could lead to a DoS if the resource policy was configured to allow access to a specific set of users.
+
+To delete the resource policy:
+```bash
+aws secretsmanager delete-resource-policy \
+  --secret-id <Secret_Name>
+```
+
+## secretsmanager:UpdateSecretVersionStage
+
+The states of a secret are used to manage versions of a secret. AWSCURRENT marks the active version that applications use, AWSPREVIOUS keeps the previous version so that you can roll back if necessary, and AWSPENDING is used in the rotation process to prepare and validate a new version before making it the current one.
+
+Applications always read the version with AWSCURRENT. If someone moves that label to the wrong version, the apps will use invalid credentials and may fail.
+
+AWSPREVIOUS is not used automatically. However, if AWSCURRENT is removed or reassigned incorrectly, it may appear that everything is still running with the previous version.
+
+```bash
+aws secretsmanager update-secret-version-stage \
+  --secret-id <your-secret-name-or-arn> \
+  --version-stage AWSCURRENT \
+  --move-to-version-id <target-version-id> \
+  --remove-from-version-id <previous-version-id>
+```
+
 {{#include ../../../banners/hacktricks-training.md}}
 
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
index 3d1170ccf..c970c8876 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
@@ -20,6 +20,9 @@ aws secretsmanager get-secret-value --secret-id <secret_name> # Get value
 
 **Potential Impact:** Access high sensitive data inside AWS secrets manager service.
 
+> [!WARNING]
+> Note that even with the `secretsmanager:BatchGetSecretValue` permission an atatcker would also need `secretsmanager:GetSecretValue` to retrieve the sensitive secrets.
+
 ### `secretsmanager:GetResourcePolicy`, `secretsmanager:PutResourcePolicy`, (`secretsmanager:ListSecrets`)
 
 With the previous permissions it's possible to **give access to other principals/accounts (even external)** to access the **secret**. Note that in order to **read secrets encrypted** with a KMS key, the user also needs to have **access over the KMS key** (more info in the [KMS Enum page](../aws-services/aws-kms-enum.md)).