Diario de un equipo Red Team: de un solo correo de phishing a administrador de dominio en seis días

Proyecto representativo. Datos del cliente anonimizados y detalles específicos modificados bajo NDA.

Un único usuario hizo clic en un enlace un martes por la tarde. Para el lunes siguiente ya controlábamos su Active Directory, habíamos leído el export de nóminas y teníamos una captura de pantalla del mismo en nuestra carpeta de botín. Nadie de su lado se dio cuenta hasta el quinto día.

Este cliente estaba orgulloso de su perímetro y, sinceramente, tenía motivos para estarlo. VPN endurecida, EDR en cada portátil, MFA en todas partes. Así que cuando definieron el alcance de esta evaluación de red team, el encargo fue tajante: dejad de tratarnos como un escaneo de vulnerabilidades. Tratadnos como un adversario que quiere algo concreto. Partid de cero acceso, llegad a administrador de dominio y veamos quién se da cuenta.

Aquí está el diario, día a día. Los nombres y las cifras están cambiados. El camino es exactamente el que recorrimos.

Puntos clave

• Una sola credencial obtenida por phishing suele bastar para alcanzar la red interna. El perímetro expuesto a Internet rara vez es lo que te salva.
• La ruta más rápida hasta administrador de dominio casi nunca es un exploit. Son configuraciones erróneas apiladas: cuentas con privilegios excesivos, contraseñas de administrador local reutilizadas y una delegación de Active Directory débil.
• Que un EDR detecte una payload no es lo mismo que tu SOC respondiendo a ella. A menudo hacemos mucho ruido y aun así seguimos sin respuesta durante días.
• El Kerberoasting, las credenciales de administrador local compartidas y las sesiones privilegiadas que quedan abiertas son los tres hallazgos que reportamos en casi todos los proyectos internos.
• Una evaluación de red team mide la detección y la respuesta, no solo si existe un agujero. Eso es lo que la diferencia de un test de intrusión estándar.

¿Qué es una evaluación de red team y por qué no hacer simplemente un pentest?

Una evaluación de red team es una simulación orientada a objetivos de un atacante real, ejecutada a la vez contra tus personas, procesos y tecnología. El objetivo no es “encontrar todos los bugs de esta aplicación”. Es algo que un criminal querría de verdad: leer el buzón del director financiero, exfiltrar la base de datos de clientes, desplegar un cambio en producción. Elegimos un camino y avanzamos hacia él en silencio.

Un test de intrusión responde a dónde están los agujeros. Un red team responde a qué ocurre cuando alguien atraviesa uno. Ambos tienen su lugar. Pero si ya has hecho unos cuantos pentests y tu consejo de administración se pregunta si sobrevivirías a una intrusión dirigida, el pentest ha dejado de ser la herramienta adecuada. Necesitas a alguien jugando para ganar, contra el reloj, con tus defensores ajenos a los tiempos.

Día 1: el correo en el que se hizo clic

No lanzamos miles de mensajes. El phishing dirigido de red team es silencioso por diseño. La primera tarde fue para reconocimiento de fuentes abiertas: LinkedIn, el blog de la empresa, una charla de conferencia que había dado uno de sus ingenieros, un par de direcciones presentes en viejas filtraciones de datos. Eso nos dio la convención de nombres del correo ([email protected]) y suficiente contexto para redactar algo que un ingeniero ocupado abriría sin pensar.

El pretexto era un documento compartido sobre una migración de herramientas interna, dirigido al equipo de plataforma. No al CEO. Los ingenieros tienen un acceso más amplio y hacen clic en más enlaces. La página de destino era un clon impecable de su inicio de sesión de Microsoft, servido desde un dominio parecido que habíamos registrado y dejado envejecer dos semanas para que no pareciera recién creado. La ejecutamos tras un reverse proxy al estilo de evilginx, lo que significa que capturamos la contraseña y la cookie de sesión. Esa cookie pasa de largo directamente ante el MFA.

Dos clics en la primera hora. Un inicio de sesión completado. Ya teníamos una sesión válida y credenciales válidas de un ingeniero de nivel intermedio. Encaja limpiamente con MITRE ATT&CK T1566 (Phishing) y T1078 (Valid Accounts), y es donde realmente comienzan la mayoría de nuestros proyectos.

Día 2: afianzar un punto de apoyo y mirar alrededor

Las credenciales robadas están bien. La ejecución de código en un host interno es mejor. Aprovechamos la sesión para llegar a su portal VPN, aterrizamos en una posición de bajos privilegios y conseguimos un punto de apoyo en la estación de trabajo del ingeniero. Eso cambia todo el juego. Ahora podemos enumerar el dominio desde dentro.

Nuestro primer movimiento en cualquier red interna es un reconocimiento silencioso con BloodHound. Recopilar datos de sesión, ACL y pertenencia a grupos, y luego dejar que el grafo nos diga por dónde pasa el camino más corto hasta administrador de dominio. Casi nunca es una línea recta. Casi siempre hay una línea.

# Collect Active Directory data from the foothold (low and slow)
SharpHound.exe --collectionmethods DCOnly,Session --stealth

# Then in the BloodHound UI: mark our compromised user as Owned,
# and run "Shortest Paths to Domain Admins from Owned Principals"

El grafo se iluminó. Nuestro ingeniero comprometido estaba en un grupo con administrador local sobre un clúster de servidores de build. Ese tipo de grupo con privilegios excesivos que nadie recuerda haber concedido y que nadie ha revisado desde entonces. Esa fue nuestra vía de entrada.

Día 3: Kerberoasting y cracking sin conexión

Cualquier usuario del dominio puede solicitar tickets de servicio Kerberos para las cuentas que tengan configurado un Service Principal Name. Esos tickets están cifrados con el hash de la contraseña de la cuenta de servicio. Así que los solicitas, los descargas y los crackeas sin conexión, donde ninguna política de bloqueo ni ninguna alerta puede tocarte. Esto es Kerberoasting (T1558.003), y es el truco más fiable que tenemos en las redes internas.

# Request roastable service tickets with Impacket
GetUserSPNs.py acme-corp.example/j.doe -request -dc-ip 10.10.0.5 -outputfile roast.txt

# Crack offline with Hashcat (mode 13100 = Kerberos TGS-REP)
hashcat -m 13100 roast.txt rockyou.txt -r best64.rule

Una cuenta de servicio crackeada en menos de una hora. La contraseña era Summer2023!, establecida por un humano, en una cuenta con una política sin caducidad y, según resultó, con pertenencia a un grupo privilegiado. Este es el patrón en todas partes: una cuenta de servicio se crea una vez, se le conceden más derechos de los que necesita “por seguridad” y luego nadie la toca durante cuatro años.

Día 4: movimiento lateral y recolección de credenciales

Tener administrador local en los servidores de build significaba que podíamos movernos lateralmente. Aquí fuimos deliberados. Esta es la fase en la que un instrumental ruidoso hace que pillen a los equipos, y en la que un SOC competente debería haber despertado. Evitamos escribir Mimikatz en disco y extrajimos las credenciales en caché desde la memoria, dentro del proceso, y luego reutilizamos el hash del administrador local para autenticarnos en otros sitios.

Esa contraseña de administrador local era idéntica en todos los servidores del segmento. Un hash. Pass-the-hash (T1550.002). Decenas de hosts. En uno de ellos, un administrador había dejado una sesión RDP iniciada, y recolectar ese token nos entregó el contexto de un administrador de dominio sin llegar a aprender la contraseña. Las credenciales de administrador local reutilizadas y las sesiones privilegiadas olvidadas son, según nuestra experiencia, las dos cosas que con más frecuencia convierten un punto de apoyo contenido en una pérdida total.

Día 5: administrador de dominio y la primera llamada

Para el quinto día teníamos un token de administrador de dominio. Para demostrar el impacto sin romper nada, ejecutamos un DCSync controlado (T1003.006) para extraer el hash de la cuenta krbtgt, la clave que permite a un atacante forjar golden tickets y persistir más o menos para siempre. No construimos el golden ticket en producción. Documentamos la capacidad y nos detuvimos ahí.

Este fue también el día en que el SOC por fin llamó a nuestro punto de contacto. Nuestro movimiento lateral del día anterior había disparado una alerta del EDR. La payload quedó marcada. Pero la alerta permaneció en una cola durante buena parte de un día antes de que nadie la triara. La tecnología funcionó. La respuesta no. Esa brecha es precisamente lo que una evaluación de red team existe para medir, y ningún escáner la encontrará jamás.

Día 6: alcanzar el objetivo

El objetivo acordado era el acceso a datos financieros sensibles. Con administrador de dominio, esa parte fue trivial. Montamos el recurso compartido de archivos de finanzas, encontramos un export de nóminas y una carpeta con PII de clientes sin cifrar, capturamos pruebas, pusimos marca de tiempo a todo y nos retiramos. Ningún dato salió de su entorno. Tiempo total transcurrido desde el primer clic hasta el objetivo: seis días, la mayor parte de ellos avanzando despacio a propósito para probar si alguien estaba mirando.

Lo que encontramos: las verdaderas causas raíz

Nada de esto necesitó un zero-day. No hubo ni una sola CVE de por medio. Toda la cadena se construyó a partir de la configuración y la higiene:

• Un MFA que no sobrevivió al robo de sesión. Su MFA aguantaba bien frente al password spraying y era inútil frente a un phishing con reverse proxy que roba la cookie de sesión. Un MFA resistente al phishing con llaves de hardware FIDO2 rompe la cadena el primer día.
• Una cuenta de servicio kerberoasteable con una contraseña débil y estática. Un secreto gestionado de más de 25 caracteres, o un group Managed Service Account, y deja de ser crackeable.
• Contraseñas de administrador local compartidas. Windows LAPS aleatoriza la contraseña de administrador local por máquina. Con él, nuestra racha de pass-the-hash termina en exactamente un host.
• Detección sin respuesta. La alerta existía. El runbook para actuar sobre ella en minutos, no.

Cómo se detiene esto normalmente

Aquí viene la parte incómoda. Gastar más en herramientas de prevención no habría ayudado mucho a este cliente. Ya tenía buenas herramientas. Lo que le faltaba era higiene de configuración y un proceso de respuesta que se hubiera probado bajo presión. Rota y guarda en un almacén seguro las credenciales de las cuentas de servicio. Despliega LAPS. Pasa las cuentas privilegiadas a un MFA resistente al phishing. Segmenta por niveles tus cuentas de administración para que el compromiso de una estación de trabajo no pueda alcanzar un token de administrador de dominio. Y, por encima de todo, realiza pruebas en vivo contra tu SOC hasta que una alerta se convierta en una acción en lugar de en una entrada en una cola.

Cómo ayuda CyberXplore

Este es el trabajo que hacemos durante todo el año. Nuestro servicio de evaluación de red team ejecuta simulaciones de adversario orientadas a objetivos que reflejan cómo operan los intrusos reales: phishing, punto de apoyo, rutas de ataque en Active Directory y movimiento lateral silencioso, para que descubras hasta dónde llega alguien y si tu equipo lo detecta a tiempo. Recibes una narrativa de ataque como la anterior, con cada paso mapeado a MITRE ATT&CK, además de una remediación sobre la que tus ingenieros pueden actuar el lunes por la mañana. Si quieres saber cómo aguanta tu entorno, solicita un presupuesto y cuéntanos cuáles son tus joyas de la corona.

FAQ

¿Cuánto dura una evaluación de red team?

La mayoría de los proyectos duran de tres a seis semanas de principio a fin, según el alcance y cuánto sigilo quieras. La intrusión activa de este diario tomó seis días, pero los red teams reales suelen avanzar despacio a propósito para probar la detección a lo largo del tiempo. El reconocimiento, el reporting y un taller de debriefing se suman al calendario.

¿En qué se diferencia una evaluación de red team de un test de intrusión?

Un test de intrusión enumera y demuestra vulnerabilidades en un alcance definido, normalmente con los defensores conscientes de que está ocurriendo. Una evaluación de red team está orientada a objetivos y es encubierta. Pone a prueba a la vez a las personas, los procesos y la detección, y el éxito significa alcanzar una meta como administrador de dominio o exfiltración de datos. Si nunca has hecho un pentest, empieza por ahí. El red teaming presupone un nivel razonable de madurez de base.

¿Una evaluación de red team interrumpirá nuestros sistemas de producción?

No. Trabajamos bajo reglas de enfrentamiento estrictas acordadas de antemano, evitamos las acciones destructivas y nos coordinamos con un pequeño grupo de confianza de vuestro lado. Los pasos de prueba de impacto como DCSync se realizan de forma controlada, y nunca sacamos datos reales de vuestro entorno. La seguridad y la reversibilidad están escritas en el alcance.

¿Necesitamos avisar a nuestro equipo de seguridad de que está ocurriendo?

Normalmente solo una pequeña “white cell” de partes interesadas de confianza conoce los tiempos, para que la respuesta del SOC sea genuina. Ese es todo el sentido. Si los defensores están pendientes de ti, no aprendes nada sobre la detección en el mundo real. Acordamos de antemano una palabra de seguridad y contactos de escalado para que nadie persiga una falsa alarma hasta convertirla en una crisis.

¿Qué obtenemos al final?

Una narrativa de ataque completa, con cada paso mapeado a MITRE ATT&CK, evidencias de cada hallazgo, un plan de remediación priorizado que tus ingenieros pueden ejecutar y un debriefing tanto para audiencias técnicas como directivas. El valor no está en la lista de problemas. Está en la historia de cómo se encadenaron y de qué es lo que rompe la cadena.

¿Con qué frecuencia deberíamos hacer una?

Anualmente para la mayoría de las organizaciones, o después de un cambio importante como una fusión, una migración a la nube o la puesta en marcha de un nuevo SOC. Los entornos se desvían, el personal rota y las configuraciones erróneas que nos dejaron entrar tienden a reaparecer poco a poco. Una evaluación de red team periódica mantiene honestas tu detección y tu respuesta.