En el artículo anterior repasábamos diez técnicas de Red Team que, aunque muchas siguen siendo perfectamente válidas, ya no utilizaríamos como primera opción en una operación moderna. PowerShell, los bypasses genéricos de AMSI, rundll32, Kerberoasting indiscriminado, NTLM relay, macros o un Cobalt Strike prácticamente salido de fábrica tienen algo en común: nacieron en un escenario en el que el endpoint y Active Directory eran el centro de prácticamente todo.
Pero ese escenario ha cambiado.
Hoy una organización puede tener Active Directory on-premise, Entra ID, Microsoft 365, Azure, AWS, decenas o cientos de aplicaciones SaaS, dispositivos registrados en la nube, pipelines de CI/CD, identidades de aplicaciones, service principals, certificados, secretos y todo tipo de relaciones de confianza entre estos mundos. El usuario que tenemos delante puede autenticarse en el portátil corporativo, consultar el correo, acceder a GitHub, desplegar en Azure y utilizar varias aplicaciones SaaS con la misma identidad o con identidades estrechamente relacionadas.
Y esto cambia bastante la película.
Si antes conseguir una shell en un equipo era un paso fundamental de la operación, ahora puede que esa shell no nos sirva absolutamente para nada. Podemos tener ejecución local y seguir estando a kilómetros del objetivo. En cambio, una aplicación OAuth con permisos excesivos, una identidad de workload mal protegida o una relación de confianza entre Active Directory y Entra pueden proporcionarnos un camino mucho más interesante sin necesidad de ejecutar un payload especialmente sofisticado.
La evolución que estamos viendo no consiste tanto en sustituir una herramienta por otra como en cambiar el objeto que intentamos comprometer.
El Red Team empieza a mirar menos al proceso y más a la identidad.
1. Identity-First Red Team
Probablemente este sea el cambio más importante.
Durante mucho tiempo, una campaña de Red Team podía representarse de una manera bastante sencilla: encontrar una vulnerabilidad, conseguir un foothold, escalar privilegios, moverse lateralmente y acabar llegando a Domain Admin. Era un modelo muy orientado a máquinas y procesos.
Ahora podemos tener una situación bastante diferente. Tenemos un usuario comprometido, pero ese usuario no tiene por qué darnos una máquina interesante. Lo realmente importante es qué identidad representa, en qué aplicaciones está autorizada, qué grupos tiene, qué recursos puede utilizar y qué otras identidades puede alcanzar desde ahí.
La pregunta deja de ser "¿qué puedo ejecutar en este equipo?" y pasa a ser algo bastante más interesante: "¿qué puedo hacer siendo este usuario?".
Esta diferencia parece pequeña, pero cambia completamente la metodología. En un entorno moderno deberíamos prestar atención no solamente a usuarios y grupos, sino también a aplicaciones, service principals, managed identities, dispositivos, permisos delegados, permisos de aplicación, certificados, secretos y relaciones de confianza.
Y cuando empezamos a representar todo esto como un grafo aparecen caminos que no tienen absolutamente nada que ver con el clásico WORKSTATION → SERVER → DC.
Por ejemplo, un usuario aparentemente poco privilegiado puede tener acceso a una aplicación que dispone de determinados permisos sobre Microsoft Graph. Esa aplicación puede tener una identidad propia en el tenant, esa identidad puede tener acceso a determinados recursos y alguno de esos recursos puede contener credenciales o información que nos lleve al siguiente salto.
El camino puede ser perfectamente legítimo desde el punto de vista de cada componente. Lo interesante es la cadena.
Esta es precisamente la filosofía que hay detrás de los attack paths modernos: no buscar únicamente una vulnerabilidad crítica, sino descubrir cómo varias relaciones aparentemente inocuas pueden combinarse para terminar alcanzando un activo importante.
2. Entra ID ya no es "el Azure AD de antes"
Durante años, para muchos pentesters Entra ID era poco más que el sitio donde estaban los usuarios de Microsoft 365. Esto se ha quedado bastante corto.
Entra ID se ha convertido en una pieza fundamental del plano de identidad de muchas organizaciones y, por tanto, también en un objetivo de Red Team. Microsoft lo plantea como un sistema de identidad y control de acceso que se encuentra en el centro de numerosos servicios cloud y aplicaciones corporativas.
Además, la cantidad de objetos que encontramos allí es considerablemente mayor que la que solemos tener en un Active Directory tradicional. Tenemos usuarios y grupos, pero también aplicaciones, service principals, dispositivos, roles, managed identities y diferentes mecanismos de autenticación y autorización.
Y aquí aparece una diferencia importante respecto al AD tradicional: una aplicación puede ser una identidad.
Microsoft distingue entre el objeto de aplicación y el service principal que representa esa aplicación dentro de un tenant. Esto significa que cuando analizamos permisos no deberíamos mirar únicamente quién puede acceder a una aplicación, sino también qué puede hacer la aplicación y quién tiene capacidad para modificarla o administrarla. Esto abre una superficie de ataque enorme.
Una aplicación con permisos excesivos puede ser mucho más interesante que un usuario con una contraseña débil. Un service principal con privilegios innecesarios puede convertirse en un camino hacia recursos críticos. Y una identidad de aplicación olvidada, con un secreto que nadie ha rotado en años, puede ser precisamente el tipo de hallazgo que un Red Team debería buscar.
En otras palabras, el directorio ya no contiene solamente personas. Contiene máquinas, aplicaciones y servicios que también tienen identidad y privilegios.
3. OAuth: cuando no necesitas robar la contraseña
Uno de los cambios más interesantes es que cada vez resulta menos necesario pensar en términos de "robar una contraseña".
OAuth permite que una aplicación obtenga permisos para acceder a determinados recursos en nombre de un usuario o mediante su propia identidad. En Microsoft Entra encontramos permisos delegados y permisos de aplicación, y estos últimos son especialmente relevantes porque permiten que una aplicación acceda a recursos sin que exista necesariamente un usuario interactivo detrás.
Esto introduce una situación curiosa: el usuario puede autenticarse correctamente, MFA puede funcionar correctamente, el proveedor de identidad puede considerar que todo está bien y aun así podemos acabar concediendo a una aplicación más permisos de los que deberíamos.
El conocido consent phishing es un ejemplo bastante claro. En lugar de intentar obtener la contraseña del usuario, se intenta conseguir que éste conceda permisos a una aplicación controlada por el atacante. Microsoft documenta precisamente este escenario como una amenaza específica y proporciona mecanismos para revisar y revocar los permisos concedidos a aplicaciones. Para un Red Team esto cambia bastante el enfoque.
En lugar de buscar únicamente credenciales, merece la pena mirar quién puede registrar aplicaciones, quién puede conceder consentimiento, qué aplicaciones existen en el tenant, qué permisos tienen, quién aparece como propietario y qué secretos o certificados utilizan.
Y hay algo especialmente interesante: OAuth puede convertir una autenticación perfectamente legítima en un acceso perfectamente legítimo... hacia un recurso que no debería estar al alcance de esa aplicación.
Es decir, no se ha explotado Windows, no se ha hecho bypass de AMSI, no se ha lanzado Cobalt Strike. Simplemente se ha abusado de una relación de confianza. Y probablemente veremos mucho más de esto en los próximos años.
4. Cloud Attack Paths: el grafo es el nuevo mapa
Una de las cosas que más cambia cuando entramos en cloud es la forma de entender el movimiento lateral.
En un entorno tradicional estamos acostumbrados a pensar en máquinas: una IP lleva a un servidor, el servidor nos proporciona credenciales, esas credenciales permiten acceder a otra máquina y así sucesivamente.
En cloud, el concepto de "máquina" deja de ser suficiente. Un recurso puede tener asignada una identidad administrada, esa identidad puede disponer de un rol sobre otro recurso, ese recurso puede tener acceso a un secreto y ese secreto puede permitirnos autenticarnos como otra identidad.
Cada elemento por separado puede parecer poco interesante pero la combinación puede ser crítica.
Microsoft Defender for Cloud utiliza precisamente un Cloud Security Graph para representar recursos, permisos, conexiones, exposición y vulnerabilidades y encontrar caminos de ataque que permitan alcanzar recursos críticos. Desde el punto de vista ofensivo, la idea es tremendamente atractiva. En vez de preguntarnos: "¿Qué vulnerabilidad tiene este servidor Azure?" podemos preguntarnos: "¿Qué camino existe desde la identidad que tengo ahora hasta el recurso que realmente me interesa?"
Y esto nos lleva a escenarios como:
Web App
↓
Managed Identity
↓
Key Vault
↓
Secret
↓
Service Principal
↓
Azure ResourceLo interesante no es necesariamente que exista una vulnerabilidad crítica en ninguno de esos componentes. Lo interesante es que todos confían entre sí. El ataque consiste en recorrer esa confianza.
5. SaaS: el movimiento lateral ya no necesita una red
Aquí es donde el concepto clásico de lateral movement empieza a quedarse un poco viejo.
Antes pensábamos en algo parecido a:
PC01 → PC02 → FILESERVER → SQL → DC
Ahora puede ser:
Microsoft 365 → GitHub → Jira → CI/CD → Azure → producción.
Y lo más divertido es que quizá esos sistemas ni siquiera estén en la misma red.
Las organizaciones utilizan cada vez más servicios SaaS y los conectan mediante SSO, OAuth, API tokens, aplicaciones y automatizaciones. El resultado es una enorme red de confianza que no aparece en un diagrama de red tradicional.
Un usuario puede tener acceso a GitHub y, al mismo tiempo, a Jira. Una integración puede tener acceso al repositorio y otra al pipeline. El pipeline puede disponer de una identidad con permisos sobre Azure. Y en algún punto puede existir un secreto que conecta dos mundos que, sobre el papel, parecían completamente separados.
Por eso, cuando comprometemos una cuenta SaaS durante un Red Team, la pregunta no debería ser simplemente: "¿Qué datos puedo robar aquí?" También deberíamos preguntarnos: "¿Qué otras identidades, aplicaciones, tokens o sistemas confían en esta cuenta?"
El movimiento lateral ya no necesita ser lateral. Puede ser de servicio en servicio.
6. AD CS: cuando la credencial es un certificado
Mientras en cloud aparecen nuevos tipos de identidad, en el mundo on-premise también tenemos tecnologías que merecen mucha más atención. Una de ellas es Active Directory Certificate Services.
AD CS permite emitir certificados utilizados para diferentes propósitos dentro de una organización. El problema aparece cuando las plantillas y permisos no están correctamente configurados. Algunas configuraciones permiten escenarios donde un usuario puede obtener certificados que representan identidades que no debería poder asumir.
Microsoft documenta, por ejemplo, el riesgo asociado a determinadas plantillas en las que el solicitante puede especificar información del Subject Alternative Name.
Aquí el cambio de mentalidad es importante: no estamos robando una contraseña, no estamos haciendo pass-the-hash, no estamos crackeando un ticket... Estamos aprovechando la confianza que el dominio deposita en su infraestructura de certificados. Y una vez más aparece el mismo patrón:
identidad → confianza → privilegio.
AD CS es especialmente interesante porque conecta perfectamente el Red Team clásico de Active Directory con el nuevo modelo basado en identidades. Es una de esas tecnologías que llevan años ahí, pero que adquieren una importancia enorme cuando dejamos de pensar exclusivamente en hashes y contraseñas.
7. Windows Hello for Business: atacar donde antes no había nada que robar
Otro cambio interesante llega precisamente de la evolución de la autenticación. Durante años, el atacante buscaba contraseñas, hashes, tickets o credenciales almacenadas. Pero si una organización adopta autenticación resistente al phishing y mecanismos basados en claves, algunas de esas oportunidades desaparecen.
Windows Hello for Business utiliza credenciales basadas en claves y vincula la autenticación al dispositivo, evitando depender de una contraseña reutilizable como principal secreto de autenticación.
Esto obliga al atacante a cambiar de mentalidad. Si antes podíamos pensar:
Usuario → contraseña → reutilizaciónahora tenemos algo más parecido a:
Usuario
+
Dispositivo
+
Clave privada
+
PIN / biometría
↓
AutenticaciónY de repente el dispositivo adquiere mucha más importancia. ¿Cómo se registra? ¿Dónde se protege la clave? ¿Qué ocurre durante el provisioning? ¿Qué modelo de confianza se está utilizando? ¿Qué sucede cuando se pierde el dispositivo? ¿Qué relaciones existen entre la identidad del usuario y la identidad del dispositivo?
Estas preguntas son mucho más interesantes que intentar encontrar otra manera de robar una contraseña que ya no existe.
La moraleja es bastante sencilla: cuando una defensa elimina una credencial, el Red Team tiene que buscar dónde se ha desplazado la confianza.
8. Device Identity: no eres solamente tú, también es desde dónde llegas
Y esto nos lleva directamente a la identidad del dispositivo.
En los entornos modernos ya no basta con saber quién está realizando una autenticación. También importa desde qué dispositivo, cuál es su estado, si está registrado, si está gestionado y, dependiendo de la política, si cumple determinados requisitos. Esto permite construir decisiones de acceso mucho más complejas.
Un usuario autenticado desde un dispositivo corporativo y gestionado puede recibir un tratamiento completamente diferente al mismo usuario desde un equipo desconocido. Para el Red Team esto significa que el dispositivo deja de ser simplemente "la máquina que tenemos delante". Forma parte del contexto de autenticación.
Y eso abre una superficie que merece ser investigada: dispositivos antiguos, registros huérfanos, procesos de enrolamiento, dispositivos híbridos, relaciones usuario-dispositivo, mecanismos de recuperación y, sobre todo, quién tiene capacidad para registrar o modificar esas identidades.
Es un cambio sutil, pero importante. La pregunta ya no es únicamente: "¿Quién eres?" También puede ser: "¿Desde dónde estás intentando demostrar que eres tú?"
9. Workload Identity: usuarios que no tienen nombre
Hay otro tipo de identidad que suele pasar bastante desapercibida: la identidad de las aplicaciones y workloads.
Un pipeline de CI/CD necesita autenticarse. Una aplicación necesita acceder a una base de datos. Un servicio necesita leer un secreto. Una automatización necesita desplegar recursos. Y todas esas cosas necesitan identidad.
El problema es que nadie se va de vacaciones, cambia de departamento o recuerda que tiene que rotar su contraseña. Son identidades que pueden permanecer años funcionando con permisos que fueron concedidos para resolver un problema puntual.
Microsoft engloba este tipo de identidades bajo el concepto de workload identities y destaca precisamente el riesgo que representan cuando acumulan credenciales y permisos excesivos. Para un Red Team esto es oro, porque una cuenta humana comprometida puede darnos acceso limitado, mientras que una identidad utilizada por un pipeline puede tener permisos para desplegar código, leer secretos o modificar infraestructura. Y volvemos al mismo patrón que estamos viendo en todo el artículo: la identidad que más poder tiene no tiene por qué ser una persona.
10. AD → Entra: probablemente el camino más interesante
Y si hay un escenario que resume perfectamente todo lo anterior es el híbrido. La mayoría de las grandes organizaciones no han abandonado Active Directory para pasar mágicamente a Entra ID. Conviven ambos.
Tenemos usuarios locales sincronizados con la nube, infraestructura de Microsoft Entra Connect, dispositivos híbridos, aplicaciones que todavía dependen de Kerberos y otras que utilizan OAuth, Microsoft Graph o tokens.
Y eso crea algo que desde el punto de vista ofensivo resulta especialmente interesante: un puente entre dos mundos de identidad.
Microsoft considera determinados componentes de la infraestructura de sincronización como sistemas críticos porque pueden afectar directamente a la relación entre Active Directory y Entra ID. Esto significa que comprometer el dominio local ya no tiene necesariamente como objetivo final conseguir Domain Admin. Puede ser simplemente el camino para conseguir influencia sobre la identidad cloud.
Y también funciona al revés. Una cuenta cloud comprometida puede proporcionar acceso a aplicaciones, secretos o recursos que permitan regresar posteriormente al entorno local. El antiguo concepto de perímetro desaparece un poco aquí.
Ya no tenemos: Internet -> Firewall -> AD
Tenemos algo mucho más parecido a:
Active Directory
↕
sincronización
↕
Entra ID
↙ ↓ ↘
M365 Azure SaaS
↘ ↓ ↙
dispositivos
↕
identidadesY precisamente por eso los ataques híbridos son tan interesantes: el atacante puede entrar por un lado y buscar el impacto en el otro.
Del arsenal de técnicas al mapa de confianza
Si juntamos todo esto aparece una conclusión bastante clara. El Red Team tradicional acumulaba técnicas. Teníamos un conjunto de herramientas y sabíamos qué hacer cuando conseguíamos determinadas posiciones: PowerShell, Mimikatz, Kerberoasting, NTLM relay, Cobalt Strike, DLLs, LOLBins...
El Red Team moderno necesita seguir conociendo todo eso, pero debe añadir otra capa. Necesita entender cómo se relacionan las identidades.
Porque una operación puede empezar con una cuenta de usuario y terminar con una aplicación. Puede comenzar en un endpoint y acabar en Azure. Puede empezar con un certificado y terminar en Entra. Puede comenzar con un SaaS aparentemente inocente y acabar en un pipeline de producción.
Y en muchos casos no necesitamos una técnica espectacular. Necesitamos encontrar la relación que alguien configuró y que permite que una identidad confíe demasiado en otra.
Ese es probablemente el cambio más importante:
- Antes buscábamos la vulnerabilidad. Ahora buscamos el camino de ataque.
- Antes queríamos una shell. Ahora queremos una identidad con capacidad de llegar al objetivo.
- Antes el movimiento lateral significaba saltar entre máquinas. Ahora puede significar saltar entre identidades, aplicaciones, servicios y clouds.
¿Y qué debería aprender un Red Teamer?
La respuesta no es abandonar Active Directory ni dejar de aprender Windows. Al contrario. Kerberos, LDAP, AD CS, Windows internals, autenticación y las técnicas clásicas siguen siendo fundamentales. Lo que ocurre es que ahora hay que añadir otra dimensión.
Hay que entender Entra ID, OAuth, Microsoft Graph, service principals, managed identities, RBAC, Conditional Access, dispositivos, certificados, SaaS, CI/CD y las relaciones entre todo ello. Y, sobre todo, hay que aprender a pensar en términos de trust relationships.
Porque probablemente el operador más peligroso de los próximos años no será el que conozca el mayor número de bypasses de EDR. Será el que sea capaz de mirar un entorno y decir: "Este usuario confía en esta aplicación, esta aplicación confía en este recurso, este recurso puede obtener esta identidad y esta identidad tiene acceso a aquello."
Y entonces descubrir que, sin explotar ninguna vulnerabilidad especialmente llamativa, el camino completo hasta el objetivo ya estaba construido.
Conclusiones
Las técnicas clásicas no van a desaparecer. Seguiremos haciendo Kerberoasting cuando tenga sentido. Seguiremos utilizando PowerShell cuando sea la mejor herramienta. Seguiremos encontrando escenarios donde NTLM relay sea válido y donde un endpoint comprometido sea precisamente lo que necesitamos.
Pero cada vez será menos suficiente conocer únicamente las técnicas.
El Red Team está desplazando su foco desde el endpoint hacia la identidad, desde la ejecución hacia la autorización y desde las vulnerabilidades aisladas hacia los caminos de ataque.
Y esto tiene una consecuencia interesante: la operación puede ser mucho más silenciosa sin necesidad de hacer ninguna magia de evasión.
Si conseguimos que una aplicación nos entregue un token válido, que un service principal nos permita acceder a un recurso o que una relación de confianza nos lleve hasta una identidad privilegiada, no necesitamos necesariamente romper el sistema. Podemos simplemente conseguir que haga lo que fue diseñado para hacer. Solo que en nuestro beneficio.
En el próximo paso, el reto será precisamente combinar ambos mundos: AD + Entra + Cloud + SaaS + Device Identity y empezar a construir campañas donde el objetivo no sea "ser Domain Admin", sino demostrar cómo una identidad aparentemente poco privilegiada puede terminar afectando a un activo crítico.
Comentarios
Publicar un comentario