Ghost AcademyGhostOffensive · Ghost Academy
GhostOffensiveMódulo 19Con laboratorio

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).

Objetivos de la unidad
Sobre el laboratorio. Ni un DC ni un AWS reales se pueden emular con fidelidad aquí: Samba AD no arranca en Docker (ACL de SYSVOL) y LocalStack no aplica las políticas IAM, así que un privesc de nube no sería fiel. Por eso el laboratorio es un campo de identificación combinado; los comandos son los reales. Para practicar en vivo: GOAD (AD) y CloudGoat o una cuenta propia (AWS).

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:

kali@lab
$ nxc smb 10.10.0.0/24 -u Administrator -H aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0
impacket-wmiexec -hashes :31d6cfe0...c089c0 ghost.lab/Administrator@10.10.0.15

Por 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:

kali@lab
$ # ejemplo con impacket en Linux (ccache):
export KRB5CCNAME=ticket.ccache
impacket-wmiexec -k -no-pass ghost.lab/Administrator@dc01.ghost.lab

4. 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étodoCómoNota
PsExec (impacket-psexec)Crea un servicio remotoFiable pero ruidoso: deja rastro de servicio
WMI (impacket-wmiexec)Ejecuta vía WMIMá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"
SMBexecSimilar a PsExec por SMBAlternativa

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.

kali@lab
$ # 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:

kali@lab
$ 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 amplia

8. 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:

kali@lab
$ aws s3 ls s3://bucket-de-la-empresa
aws s3 cp s3://bucket-de-la-empresa/backup.sql .   # exfiltrar

9. 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:

kali@lab
$ # 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".

Para profundizar
🧰 Herramientas relacionadas (Ghost Academy)

Guías y laboratorios ya publicados en Ghost Academy sobre las herramientas de este módulo:

Impacket · NetExec · CrackMapExec · Responder / LLMNR · Sliver C2

Laboratorio: Lateral AD + AWS

⬇ Descargar laboratorio (ZIP)

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

  1. ¿Por qué un hash NTLM sirve para autenticarse sin conocer la contraseña?
  2. Diferencia entre Pass-the-Ticket y Overpass-the-Hash.
  3. Nombra tres métodos de ejecución remota en AD y una diferencia entre ellos.
  4. ¿Qué hace tan poderoso (y persistente) a un Golden Ticket, y cómo se corta?
  5. ¿Por qué en AWS el objetivo son los permisos IAM y no una shell?
  6. Explica la escalada por iam:PassRole.
  7. ¿Cómo se roban credenciales de un rol vía IMDS, y qué defensa lo mitiga?