Translated ['src/pentesting-cloud/pentesting-cloud-methodology.md', 'src

src/pentesting-cloud/pentesting-cloud-methodology.md

@@ -1,44 +1,44 @@
-# Pentesting Cloud Methodology
+# Metodología de pentesting en la nube
 
 {{#include ../banners/hacktricks-training.md}}
 
 <figure><img src="../images/CLOUD-logo-letters.svg" alt=""><figcaption></figcaption></figure>
 
-## Basic Methodology
+## Metodología básica
 
-Cada cloud tiene sus propias peculiaridades pero en general hay unas pocas **cosas comunes que un pentester debe comprobar** al evaluar un entorno cloud:
+Cada nube tiene sus propias peculiaridades pero en general hay algunas **cosas comunes que un pentester debería revisar** al evaluar un entorno en la nube:
 
-- **Benchmark checks**
-- Esto te ayudará a **entender el tamaño** del entorno y **los servicios usados**
-- También te permitirá encontrar algunas **configuraciones erróneas rápidas** ya que puedes realizar la mayoría de estas pruebas con **herramientas automatizadas**
-- **Services Enumeration**
-- Probablemente no encontrarás muchas más configuraciones erróneas aquí si realizaste correctamente las pruebas de benchmark, pero podrías encontrar algunas que no se buscaron en el test de benchmark.
-- Esto te permitirá saber **qué se está usando exactamente** en el entorno cloud
+- **Comprobaciones de benchmark**
+- Esto te ayudará a **entender el tamaño** del entorno y **los servicios utilizados**
+- También te permitirá encontrar algunas **misconfiguraciones rápidas**, ya que puedes realizar la mayoría de estas pruebas con **herramientas automatizadas**
+- **Enumeración de servicios**
+- Probablemente no encontrarás muchas más misconfiguraciones aquí si realizaste correctamente las comprobaciones de benchmark, pero podrías encontrar algunas que no se buscaron en las pruebas de benchmark.
+- Esto te permitirá saber **qué se está usando exactamente** en el entorno en la nube
 - Esto ayudará mucho en los siguientes pasos
-- **Check exposed assets**
-- Esto puede hacerse durante la sección anterior, necesitas **identificar todo lo que potencialmente está expuesto** a Internet de alguna forma y cómo puede accederse.
-- Aquí me refiero a **infraestructura expuesta manualmente** como instancias con páginas web u otros puertos expuestos, y también a otros **cloud managed services que pueden ser configurados** para estar expuestos (como DBs o buckets)
-- Luego debes comprobar **si ese recurso puede estar expuesto o no** (¿información confidencial? ¿vulnerabilidades? ¿configuraciones erróneas en el servicio expuesto?)
-- **Check permissions**
-- Aquí debes **averiguar todos los permisos de cada role/user** dentro del cloud y cómo se usan
-- ¿Demasiadas cuentas con **altos privilegios** (controlan todo)? ¿Claves generadas sin usar?... La mayoría de estas comprobaciones deberían haberse hecho ya en los tests de benchmark
-- Si el cliente está usando OpenID o SAML u otra **federation** puede que necesites pedirles más **información** sobre **cómo se asigna cada role** (no es lo mismo que el role admin esté asignado a 1 usuario que a 100)
-- **No basta con encontrar** qué usuarios tienen permisos de admin "\*:\*". Hay muchos **otros permisos** que dependiendo de los servicios usados pueden ser muy **sensibles**.
-- Además, hay **posibles formas de privesc** a seguir abusando de permisos. Todas estas cosas deben tenerse en cuenta y **deben reportarse tantas rutas de privesc como sea posible**.
-- **Check Integrations**
-- Es muy probable que **se usen integraciones con otras clouds o SaaS** dentro del entorno cloud.
-- Para **integraciones del cloud que estás auditando** con otra plataforma deberías notificar **quién tiene acceso para (ab)usar esa integración** y deberías preguntar **qué tan sensible** es la acción que se realiza.\
-Por ejemplo, quién puede escribir en un AWS bucket del que GCP está obteniendo datos (pregunta qué tan sensible es la acción en GCP al tratar esos datos).
-- Para **integraciones dentro del cloud que estás auditando** desde plataformas externas, deberías preguntar **quién tiene acceso externo para (ab)usar esa integración** y comprobar cómo se están usando esos datos.\
-Por ejemplo, si un servicio está usando una imagen Docker alojada en GCR, deberías preguntar quién tiene acceso para modificarla y qué información sensible y accesos obtendrá esa imagen cuando se ejecute dentro de un cloud AWS.
+- **Comprobar activos expuestos**
+- Esto puede hacerse durante la sección anterior; necesitas **identificar todo lo que potencialmente está expuesto** a Internet de alguna manera y cómo puede ser accedido.
+- Aquí me refiero a **infraestructura expuesta manualmente** como instancias con páginas web u otros puertos expuestos, y también a otros **servicios gestionados en la nube que pueden configurarse** para estar expuestos (como DBs o buckets)
+- Luego deberías comprobar **si ese recurso puede ser expuesto o no** (¿información confidencial? ¿vulnerabilidades? ¿misconfiguraciones en el servicio expuesto?)
+- **Comprobar permisos**
+- Aquí deberías **identificar todos los permisos de cada rol/usuario** dentro de la nube y cómo se usan
+- ¿Demasiadas cuentas con **privilegios elevados** (controlan todo)? ¿Claves generadas que no se usan?... La mayoría de estas comprobaciones deberían haberse hecho ya en los tests de benchmark
+- Si el cliente está usando OpenID o SAML u otra **federación** puede que necesites pedirles más **información** sobre **cómo se asigna cada rol** (no es lo mismo que el rol admin esté asignado a 1 usuario o a 100)
+- **No es suficiente encontrar** qué usuarios tienen permisos **admin** "*:*". Hay muchos **otros permisos** que, dependiendo de los servicios usados, pueden ser muy **sensibles**.
+- Además, existen **posibles rutas de privesc** que se pueden seguir abusando de permisos. Todas estas cosas deben tenerse en cuenta y **se deben reportar tantos caminos de privesc como sea posible**.
+- **Comprobar integraciones**
+- Es altamente probable que **se estén usando integraciones con otras nubes o SaaS** dentro del entorno en la nube.
+- Para **las integraciones de la nube que estás auditando** con otra plataforma, deberías notificar **quién tiene acceso para (ab)usar esa integración** y deberías preguntar **qué tan sensible** es la acción que se realiza.\
+Por ejemplo, quién puede escribir en un bucket de AWS del cual GCP está obteniendo datos (preguntar qué tan sensible es la acción en GCP al tratar esos datos).
+- Para **las integraciones dentro de la nube que estás auditando** desde plataformas externas, deberías preguntar **quién tiene acceso externamente para (ab)usar esa integración** y comprobar cómo se están usando esos datos.\
+Por ejemplo, si un servicio está usando una imagen Docker alojada en GCR, deberías preguntar quién tiene acceso para modificarla y qué información sensible y accesos obtendrá esa imagen cuando se ejecute dentro de una nube AWS.
 
-## Multi-Cloud tools
+## Herramientas Multi-Cloud
 
-Hay varias herramientas que pueden usarse para testear diferentes entornos cloud. Los pasos de instalación y los enlaces se indicarán en esta sección.
+Hay varias herramientas que se pueden usar para evaluar diferentes entornos en la nube. Los pasos de instalación y los enlaces se indicarán en esta sección.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Una herramienta para **identificar malas configuraciones y privesc path en clouds y entre clouds/SaaS.**
+Una herramienta para **identificar malas configuraciones y rutas de privesc en nubes y entre nubes/SaaS.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -171,8 +171,6 @@ steampipe check all
 <summary>Comprobar todos los proyectos</summary>
 
 Para comprobar todos los proyectos necesitas generar el archivo `gcp.spc` indicando todos los proyectos a probar. Puedes seguir las indicaciones del siguiente script
-
-</details>
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -196,7 +194,7 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-Para consultar **otros insights de GCP** (útiles para enumerar servicios) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Para comprobar **otros GCP insights** (útiles para enumerar servicios) utilice: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
 Para revisar código Terraform de GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
@@ -240,11 +238,11 @@ Requiere python2.7 y parece no estar mantenido.
 
 ### Nessus
 
-Nessus tiene un escaneo _**Audit Cloud Infrastructure**_ que soporta: AWS, Azure, Office 365, Rackspace, Salesforce. Se requieren algunas configuraciones adicionales en **Azure** para obtener un **Client Id**.
+Nessus tiene un escaneo _**Audit Cloud Infrastructure**_ que soporta: AWS, Azure, Office 365, Rackspace, Salesforce. Se necesitan algunas configuraciones adicionales en **Azure** para obtener un **Client Id**.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist es una **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) de Cloud Providers.
+Cloudlist es una **herramienta multi-cloud para obtener activos** (nombres de host, direcciones IP) de proveedores de nube.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -363,7 +361,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Descubre los usuarios más privilegiados en el entorno AWS o Azure escaneado, incluyendo los AWS Shadow Admins. Usa powershell.
+Detecta los usuarios más privilegiados en el entorno AWS o Azure escaneado, incluyendo los AWS Shadow Admins. Utiliza powershell.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -374,13 +372,13 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Una herramienta para encontrar la infraestructura, archivos y aplicaciones de una empresa (target) en los principales proveedores de la nube (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
+Una herramienta para encontrar la infraestructura de una empresa (objetivo), archivos y apps en los principales proveedores de nube (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox es una herramienta para encontrar exploitable attack paths en la infraestructura cloud (actualmente solo soporta AWS & Azure; GCP próximamente).
+- CloudFox es una herramienta para encontrar rutas de ataque explotables en la infraestructura en la nube (actualmente solo soporta AWS & Azure, con GCP próximamente).
 - Es una herramienta de enumeración destinada a complementar el pentesting manual.
-- No crea ni modifica ningún dato dentro del entorno cloud.
+- No crea ni modifica ningún dato dentro del entorno en la nube.
 
 ### More lists of cloud security tools
 
@@ -412,13 +410,12 @@ aws-security/
 azure-security/
 {{#endref}}
 
-### Attack Graph
+## Common Cloud Security Features
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter) crea un “attack graph” de los recursos en una suscripción de Azure. Permite a red teams y pentesters visualizar la superficie de ataque y las oportunidades de pivot dentro de un tenant, y potencia a tus defensores para orientarse y priorizar rápidamente el trabajo de respuesta a incidentes.
-
-### Office365
-
-Necesitas **Global Admin** o al menos **Global Admin Reader** (ten en cuenta que Global Admin Reader es algo limitado). Sin embargo, esas limitaciones aparecen en algunos PS modules y pueden ser eludidas accediendo a las funciones **vía la aplicación web**.
+### Confidential Computing
 
+{{#ref}}
+confidential-computing/luks2-header-malleability-null-cipher-abuse.md
+{{#endref}}
 
 {{#include ../banners/hacktricks-training.md}}