Movimiento lateral en AD y ataques a AWS
Este módulo cierra las dos fronteras de la post-explotación moderna. Primero, el movimiento lateral en Active Directory: cómo, con una credencial o un hash, saltas de máquina en máquina hasta controlar el dominio. Segundo, la nube (AWS): un modelo distinto donde el objetivo ya no es una shell, sino los permisos de identidad (IAM).
- Reutilizar credenciales sin conocer la contraseña: pass-the-hash, pass-the-ticket, overpass-the-hash.
- Ejecutar código en remoto en AD (WMI, WinRM, PsExec) y entender sus diferencias.
- Comprender la persistencia definitiva: Golden y Silver Tickets.
- Entender el modelo de seguridad de AWS (IAM) y de dónde salen las credenciales.
- Reconocer los ataques cloud clásicos: S3 mal configurado, privesc por IAM, robo de credenciales por IMDS/SSRF.
Parte A — Movimiento lateral en Active Directory
1. La idea: reutilizar, no adivinar
Tras comprometer un equipo (módulo 18) sueles tener secretos: hashes NTLM del secretsdump, tickets de Kerberos en memoria, contraseñas en claro. El movimiento lateral consiste en reutilizar esos secretos contra otros equipos donde esa misma cuenta tenga acceso, hasta llegar a uno donde haya un administrador del dominio conectado. No necesitas crackear nada: el propio secreto es la llave.
2. Pass-the-Hash (PtH)
NTLM no usa la contraseña en claro para autenticar, sino su hash. Por tanto, si tienes el hash, tienes lo que hace falta: no necesitas la contraseña. Con el hash NTLM de un usuario administrador local, te autenticas y ejecutas en cualquier equipo donde esa cuenta sea admin:
$ nxc smb 10.10.0.0/24 -u Administrator -H aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0
impacket-wmiexec -hashes :31d6cfe0...c089c0 ghost.lab/Administrator@10.10.0.15Por eso un hash robado es tan valioso como la contraseña, y por eso la reutilización de la contraseña de administrador local entre equipos (sin LAPS) es catastrófica: un hash abre toda la red.
3. Pass-the-Ticket (PtT) y Overpass-the-Hash
En entornos Kerberos el equivalente es robar tickets:
- Pass-the-Ticket: extraes un TGT o TGS de la memoria de un equipo (con Mimikatz/Rubeus en Windows, o de un keytab/ccache en Linux) y lo inyectas en tu sesión para autenticarte como esa cuenta, sin su hash ni su contraseña.
- Overpass-the-Hash (pass-the-key): a partir del hash de una cuenta, pides un TGT legítimo de Kerberos. Es el puente entre el mundo NTLM (hash) y el mundo Kerberos (tickets).
$ # ejemplo con impacket en Linux (ccache):
export KRB5CCNAME=ticket.ccache
impacket-wmiexec -k -no-pass ghost.lab/Administrator@dc01.ghost.lab4. Ejecución remota: WMI, WinRM, PsExec
Con la credencial (o el hash/ticket) validada, hay varias formas de ejecutar en el objetivo, y conviene conocer sus diferencias porque unas son más ruidosas que otras:
| Método | Cómo | Nota |
|---|---|---|
PsExec (impacket-psexec) | Crea un servicio remoto | Fiable pero ruidoso: deja rastro de servicio |
WMI (impacket-wmiexec) | Ejecuta vía WMI | Más sigiloso, semi-interactivo |
WinRM (evil-winrm) | Gestión remota de Windows (5985/5986) | Shell cómoda si el usuario está en "Remote Management Users" |
| SMBexec | Similar a PsExec por SMB | Alternativa |
5. Golden y Silver Tickets
El premio final. La cuenta krbtgt del dominio cifra todos los TGT. Si robas su hash (con un DCSync, módulo 18), puedes forjar tus propios TGT válidos para cualquier usuario, incluido Domain Admin, que existan o no: es el Golden Ticket. Da control total y persistente, y sobrevive a cambios de contraseña de los usuarios (solo se corta rotando dos veces la clave de krbtgt). El Silver Ticket es su versión acotada: con el hash de una cuenta de servicio, forjas TGS válidos solo para ese servicio, más sigiloso porque no toca el DC.
$ # forjar un Golden Ticket (ilustrativo, con impacket): impacket-ticketer -nthash-domain-sid -domain ghost.lab Administrator
Parte B — Ataques a la nube (AWS)
6. La nube es otro modelo mental
En AWS no persigues una shell en un servidor: persigues permisos de identidad. El control de acceso lo lleva IAM (Identity and Access Management), y comprometer una cuenta significa acumular permisos hasta poder hacer lo que quieras. Además rige el modelo de responsabilidad compartida: AWS asegura la infraestructura; el cliente es responsable de su configuración (y ahí están casi todos los fallos). Las credenciales de AWS son claves de API (AKIA... + secreto), no usuario/contraseña.
7. Primer paso: ¿quién soy y qué puedo?
Con unas claves en la mano, lo primero es identificarlas y enumerar sus permisos:
$ aws sts get-caller-identity # ¿a qué cuenta/usuario/rol pertenecen?
aws iam list-attached-user-policies --user-name <usuario>
# herramientas: enumerate-iam, y Pacu / ScoutSuite para auditoría amplia8. S3 mal configurado
El fallo cloud más famoso: buckets de almacenamiento S3 con permisos públicos o demasiado abiertos, que exponen datos. Se listan y descargan con el propio CLI:
$ aws s3 ls s3://bucket-de-la-empresa
aws s3 cp s3://bucket-de-la-empresa/backup.sql . # exfiltrar9. Escalada de privilegios por IAM
Un usuario IAM con permisos aparentemente inocuos puede escalar a administrador si esos permisos permiten modificar la propia política o asumir roles más potentes. La vía clásica es iam:PassRole combinada con lanzar un recurso (una función Lambda, una instancia EC2) que asuma un rol privilegiado: pasas un rol de admin a un servicio que tú controlas y heredas sus permisos. Hay decenas de estas vías (crear una nueva versión de una policy, adjuntar una policy administrada, etc.); Rhino Security Labs las catalogó, y Pacu las automatiza.
10. Robo de credenciales: el metadata (IMDS)
Toda instancia EC2 puede consultar un servicio interno de metadatos en la dirección 169.254.169.254 (IMDS) para obtener, entre otras cosas, las credenciales temporales del rol asignado a la instancia. Si encuentras un SSRF en una aplicación que corre en EC2, lo usas para pedir esas credenciales al IMDS y suplantar el rol de la instancia:
$ # desde un SSRF hacia el IMDS (v1): curl http://169.254.169.254/latest/meta-data/iam/security-credentials/# -> AccessKeyId, SecretAccessKey y Token temporales del rol de la instancia
La defensa es IMDSv2 (exige un token previo, lo que frena muchos SSRF). Ver credenciales del IMDS es una de las vías más habituales de pasar de "una web vulnerable" a "acceso a la cuenta de AWS".
- GOAD (Game Of Active Directory) para el lateral en vivo; The Hacker Recipes (AD) como referencia.
- CloudGoat (Rhino Security Labs), Pacu y ScoutSuite para AWS; la matriz de privesc IAM de Rhino.
- Las guías de Impacket, NetExec, CrackMapExec y Sliver C2 de Ghost Academy (ver "Herramientas relacionadas").
Guías y laboratorios ya publicados en Ghost Academy sobre las herramientas de este módulo:
Impacket · NetExec · CrackMapExec · Responder / LLMNR · Sliver C2
Descomprime, lee el LEEME.md y lanza startlab.sh. Identifica las 8 fases (4 de movimiento lateral en AD + 4 de AWS) y verifícalas en http://localhost:9595.
Para practicar en vivo: GOAD para AD y CloudGoat (o tu propia cuenta AWS) para la nube.
¿Atascado o ya terminado? La solución paso a paso da la técnica y el comando de cada fase. Úsala cuando lo hayas intentado.
Cierre del curso
Con este módulo cierras GhostOffensive: del reconocimiento inicial (módulo 3) al control de un dominio y de una cuenta cloud. Recuerda siempre lo del módulo 1: todo esto es legítimo solo con autorización, dentro del alcance y con confidencialidad. Aprendiste a atacar para saber defender. Ahora, a seguir practicando en entornos reales y legales, y a documentar bien (módulo 20). ¡Enhorabuena!
Autoevaluación
- ¿Por qué un hash NTLM sirve para autenticarse sin conocer la contraseña?
- Diferencia entre Pass-the-Ticket y Overpass-the-Hash.
- Nombra tres métodos de ejecución remota en AD y una diferencia entre ellos.
- ¿Qué hace tan poderoso (y persistente) a un Golden Ticket, y cómo se corta?
- ¿Por qué en AWS el objetivo son los permisos IAM y no una shell?
- Explica la escalada por
iam:PassRole. - ¿Cómo se roban credenciales de un rol vía IMDS, y qué defensa lo mitiga?