Hola a tod@s,
Me gustaría comenzar dando las gracias al equipo de Follow the White Rabbit, que me han permitido publicar de nuevo en su blog.
En este artículo quiero hablar de Microsoft ATA (On-premise) o Azure ATP (Online).
Lo primero a comentar sería, ¿Qué es Microsoft ATA? Pues bien, la respuesta corta, sería algo así como, “La tecnología que analiza, supervisa y evalúa el comportamiento y uso de los diferentes recursos en un dominio de Active Directory, por parte de cada cuenta de usuario o PC.”
Bien, ¿y esto que significa? Bueno, sin entrar en demasiados detalles comerciales, que no es mi intención, yo diría que ATA nos ayuda a localizar comportamientos “sospechosos” de usuarios dentro de nuestro dominio o dominios.
Y ¿Cómo hace esto? Microsoft ATA recopila eventos del sistema, eventos de red, registros, etc. para analizar el comportamiento de los usuarios. ATA realiza varias acciones antes de ser efectivo al 100%. Primero, cuando implementas la solución, es necesario dejarlo unos 30 días analizando todo el entorno. En este proceso, analizará lo almacenado y además comenzará a trazar un uso diario de la infraestructura y recursos de Active Directory, por parte de cada usuario. Con esto, conseguirá hacerse una idea de que realiza de forma cotidiana cada usuario. De esta forma, si de repente un usuario realiza una acción “rara”, Microsoft ATA nos advertiría de este comportamiento.
Por poner un ejemplo, imaginad que un usuario normalmente accede a los recursos de red (Unidad de almacenamiento mapeada), su correo electrónico y un site de SharePoint, donde comparte información con los compañeros de su departamento. Un día, este usuario realiza una acción extraña, intentando acceder a un recurso de red al que no tiene permiso, o intenta listar los controladores de dominio existentes en el dominio, o consultar los servidores DNS, esto haría saltar una alerta, por comportamiento extraño, indicándonos que esa cuenta está realizando tareas no habituales, y que además puede estar intentando acceder a información a la cual no tiene permiso. Esto evidentemente, puede ser porque la cuenta de usuario o su PC han podido ser vulnerados o porque el usuario no es tan “inocente” como inicialmente se pensaba de él.
No quiero entrar en debates de si es la mejor solución o las hay mejores, pero desde mi punto de vista, es una tecnología muy completa, sencilla, intuitiva y eficaz. Inicialmente, debo reconocer que dudé de la efectividad de la herramienta, pero tengo que decir que me está sorprendiendo. Sé que existen otras tecnologías que hacen esto, algo parecido o intentos de hacer lo mismo. Que cada uno opine y tome la decisión que crea conveniente. Como dije antes, este no es un artículo comercial, y no tengo intención de vender nada.
Llegado este punto, es el momento de explicar porque es necesario ATA o alguna herramienta similar. Hoy en día, Active Directory es el centro neurálgico de la mayoría de las organizaciones. Muchas de estas organizaciones tienen sus propios sistemas de seguridad, que defienden el perímetro y las diferentes redes, mediante firewalls avanzados y demás electrónica de red, además de utilizar soluciones muy avanzadas de sistemas IDS y SIEM. Pero es muy probable, que no se estén monitorizando los diferentes comportamientos de las cuentas de usuario. De todos es sabido que el mayor de los problemas o el principal “agujero” de seguridad, puede ser el usuario final. Digamos que es el eslabón más débil, sin que nadie se ofenda. Si estas cuentas no son monitorizadas, y alguna de estas cuentas es vulnerada, mediante varias técnicas, se pueden realizar movimientos laterales, escalación de privilegios y conseguir acceso total al sistema.
Microsoft ATA se encuentra actualmente en su versión recién liberada 1.9 y además contempla una versión en la nube (Azure Advance Threat Protection), donde además se contempla soluciones en la nube, Azure y Office 365, soluciones on-premise y soluciones híbridas. Se puede integrar con los sistemas SIEM más utilizados, como pueden ser IBM QRadar, HP ArcSight, RSA Security Analytics y Splunk.
Por hablar un poco de la arquitectura de ATA, se basa en los siguientes roles:
- ATA Center: Es el servidor donde se implementa la consola central de ATA y donde se enviarán todos los eventos, registros y demás. Desde aquí se pueden ver las alertas y tomar las acciones necesarias para corregir los problemas encontrados.
- ATA Gateway: Los Gateway, son los encargados de enviar los eventos, registros etc., a la consola central de ATA Center. Existen dos tipos de Gateway
- Gateway Full: Implementado en un servidor, en dominio o no, desde donde se enviará la información recopilada al ATA Center, pero mediante port mirroring.
- Gateway lightweight: Implementado directamente en los controladores de dominio. Desde aquí, se envía la información al ATA Center.
Desde el punto de vista de tipos de ataques que ATA es capaz de detectar, estos son los siguientes:
- Pass-the-Ticket (PtT)
- Pass-the-Hash (PtH)
- Overpass-the-Hash
- PAC falsificado (MS14-068)
- Golden ticket
- Replicaciones malintencionadas
- Reconocimiento
- Fuerza bruta
- Ejecución remota
Muy bien, ya lo he vendido bastante. Ahora vamos con lo más interesante, que es poner Microsoft ATA a prueba. He realizado una PoC en un entorno controlado para poder mostraros el funcionamiento y comportamiento de ATA en las diferentes fases de un tipo de ataque, intentando realizar varias de las técnicas más utilizadas para vulnerar un sistema y conseguir avanzar en el ataque. Tengo que puntualizar, que he tenido la oportunidad de implementar y utilizar ATA en entornos de producción y los resultados son sencillamente asombrosos.
Sin más, comienzo explicando el entorno de laboratorio utilizado para esta demo. El laboratorio consta de los siguientes elementos:
- Un controlador de dominio, con un lightweight Gateway implementado. El dominio es lab.com.
- Un servidor con Windows 2016 y ATA Center implementado.
- Un PC con Windows 10 (W10), que será vulnerado con un spear phising, por ejemplo, o cualquier otro método de ingeniería social. Ponedle imaginación.
- Un PC con Windows 10 (W10-Admin), donde se intentará realizar un movimiento lateral desde el otro PC.
Bueno, partimos de un PC Windows 10 dentro del dominio lab.com, que se llama “W10”. Este PC está gestionado por un usuario llamado “User01” (Muy original, 😉). Este usuario recibió una de tantas campañas de Spear Phising, y en una de ellas le cogió en un renuncio y ha “picado” haciendo clic en uno de los enlaces. Consecuencia; PC vulnerado. La parte menos mala es que el usuario no tiene ningún tipo de permiso especial dentro del dominio. No obstante, el usuario es administrador local de su PC, como en tantas y tantas ocasiones ocurre dentro de las compañías. A veces con tal de facilitar la usabilidad de los usuarios o simplemente, para reducir el número de peticiones al departamento de IT, se suele dar este caso. Si no, pues habría que utilizar uno de tantos métodos para escalar privilegios locales.
Tras esto, el atacante lo primero que intenta hacer, como en la mayoría de los casos, es recopilar toda la información que pueda e intentar enumerar, también todo lo que pueda. Yo he realizado algunas de las tareas de data gathering y enumeración más comunes, como se puede ver a continuación.
1.- Reconnaissance
Durante esta fase de reconocimiento, el atacante intenta recoger el máximo de información posible, acerca del entorno, del PC, del usuario y de los diferentes grupos. Evidentemente, faltan muchas acciones más, pero estas son a modo de ejemplo. He realizado las siguientes pruebas, sencillas para que se pueda analizar el comportamiento de ATA.
- nslookup ls lab.com: Como se puede ver en la imagen siguiente, el usuario no tiene permiso para realizar esta acción, pero podría haberla tenido. Independientemente de que tenga o no permiso, esta acción ya es detectada por ATA.
Como podemos ver a continuación, ATA está avisando de un posible intento de reconocimiento a través de DNS.
Podríamos obtener mayor información de este warning, haciendo clic en la alerta. Aparecería más información, con el intento, que se ha ejecutado, si el fin se ha conseguido o no, etc.
- exe DC01: Mediante la ejecución de este comando, se intenta conseguir información acerca de los usuarios autenticados. Existen otras herramientas, e incluso scripts en powershell, pero el resultado es el mismo.
De nuevo, ATA nos avisa de que se está intentando enumerar y obtener información. Como podemos ver, existe un usuario que ha realizado logon en el PC que hemos conseguido vulnerar y además en otro PC donde además también se ha logado un Administrador del dominio. Esto será muy importante después.
Y más en detalle nos muestra la siguiente información.
Con esta información, podríamos ver que cuenta a ejecutado el comando o herramienta, y que cuentas han podido ser expuestas.
Como sabéis, mediante esta herramienta se pueden obtener las cuentas de usuario que han realizado logon en el dominio. Con esta información, además de obtener un listado de cuentas de usuario y PCs, también se puede obtener un camino para realizar movimientos laterales, e ir pasando entre PCs hasta encontrar o vulnerar una cuenta con permisos elevados, mediante por ejemplo ataques Pass-The-Ticket o Pass-The-Hash.
2.- Movimientos laterales
Como hemos comentado antes, si se obtiene un camino para realizar un movimiento lateral se pueden vulnerar otras cuentas de usuario hasta obtener una con permisos elevados, y porque no, un administrador del dominio.
El movimiento lateral, para todo aquel que no lo conozca, consta a alto nivel entre otras cosas, en encontrar un índice común entre diferentes PCs o dispositivos. Es decir, si un usuario ha realizado logon en un PC, pero también lo ha realizado en otro dentro del mismo dominio, podemos hacer logon en el segundo PC o servidor, enviando el ticket de logon de sesión. De esta forma, podemos encontrar otras cuentas de usuario, hashes o ticket, e intentar vulnerarlas. Claro está, sin disponer de las credenciales del usuario.
Existen otros tipos de movimiento laterales, pero en este caso utilizaremos este caso de uso. Por lo tanto, como hemos conseguido vulnerar un PC donde esta logado “nuestro” usuario User01 y otro llamado “User02” que además este está logado en otro PC, vamos a intentar robar el hash de “User02” para hacer logon de forma “legítima” en el otro PC (W10-Admin), mediante el uso de la famosa herramienta mimikatz.
- Ejecutamos el siguiente comando para enumerar las credenciales que están en memoria en el PC W10.
Mediante este comando, se vuelcan en el archivo txt, los hashes localizados en memoria. En el caso que nos ocupa, nos interesa sobre todo el hash ntlm del usuario que ha accedido al PC W10, pero que también ha hecho logon en el W10-Admin, que pudimos comprobar anteriormente, “Uuser02”.
- A continuación, ejecutamos de nuevo a través de la herramienta mimikatz, un intento de Pass-The-Hash, para poder levantar una consola con las credenciales de User02.
Al ejecutar este comando nos abrirá una consola con las credenciales de User02, desde donde se pueden ejecutar acciones hacia el PC W10-Admin, sobre el que también se ha logado el usuario y por tanto tiene permisos.
Este proceso utiliza el hash ntlm de User02, por lo que a priori, este proceso es totalmente legítimo, pero, no obstante, ATA nos avisa que se está utilizando un proceso no habitual para realizar un logon.
3.- Domain Escalation
Una vez que hemos conseguido movernos lateralmente al PC W10-Admin, vamos a realizar una serie de tareas, para ejecutar en remoto de nuevo mimikatz y listar las credenciales almacenadas en memoria, al igual que se realizó en el PC W10.
- Para ejecutar mimikatz en remoto utilizaremos psexec, por ejemplo, de la siguiente forma.
Ahora tan solo nos haría falta filtrar los datos volcados y nos encontraríamos con una sorpresa. Hay un usuario llamado Administrator dentro del dominio lab.com logado en este PC, aunque ya pudimos verlo antes. Para ayudarnos, ejecutamos el siguiente comando. Este comando filtrará los tickets volcados (.kirbi) que contengan la palabra administrator y los copiará en el PC W10.
ATA reconocerá la ejecución remota de mimikatz.
- Con los tickets obtenidos en el paso anterior, podremos conseguir hacer logon con las credenciales del administrador del dominio, sin conocer la password. Pero primero me gustaría realizar una prueba, para comprobar si desde la sesión de User02 podríamos acceder al controlador de dominio.
Vemos que efectivamente no tenemos permiso.
Ahora comenzamos con el pass-the-ticket. Para realizar esto, hay que ejecutar el siguiente comando.
Podemos ver que se ha importado el ticket kerberos del usuario administrator. A continuación, vamos a validar que se ha importado correctamente.
Parece que todo ha ido bien. Se ha importado correctamente. Pues bien, vamos a ver si tenemos permiso ahora para acceder al controlador de dominio, ejecutando de nuevo un “dir”.
Pues nada, ya estamos dentro del controlador de dominio. No obstante, ATA ha detectado cada uno de los pasos que hemos ido dando. Así mismo, ha detectado este pass-the-ticket.
4.- Remote Code Execution
Ya tenemos acceso al controlador de dominio, pero a través de la consola que conseguimos abrir anteriormente en el PC W10. Ahora llegaría el momento de ejecutar código en remoto. Algo muy sencillo que se puede hacer para realizar este paso, es crear un usuario en el dominio y después darle los permisos de administrador del dominio. Con esto podríamos conseguir la persistencia, de cara a futuras conexiones. Bueno, al menos es una de las formas. Seguro que se os ocurren un montón más, 😉.
- Para la creación del usuario y para darle permisos, ejecutamos los siguientes comandos.
La creación del usuario se ha realizado correctamente. Ahora vamos a darle permisos de administrador del dominio.
También se ha ejecutado correctamente. Si accedemos al controlador de dominio, podemos ver como en la consola de Usuarios y Equipos, está creado y con los permisos de administrador del dominio.
Estos comandos, también han sido detectados, al igual que los anteriores.
5.- Domain Dominance
Con el paso anterior ya podríamos tener un acceso posterior, ya que hemos creado un usuario con permisos de administrador del dominio. No obstante, ahora vamos a intentar conseguir un Golden Ticket. Para aquellos que no lo conozcan, el Golden Ticket es un premio muy cotizado, ya que, mediante este, se obtendrá recurrencia en el dominio, además de darnos acceso total al mismo, pudiendo incluso modificar y renovar la caducidad de este ticket.
- Para comenzar, ejecutaremos el siguiente comando para exportar el hash kerberos mediante mimikatz.
Se obtiene la siguiente información. Que entre otras cosas, será el hash ntlm de la cuenta kerberos del dominio y además su Security ID, que nos hará falta para el siguiente comando.
ATA vuelve a indicarnos que está ocurriendo algo. En este caso, nos avisa que se está realizando un intento de replicación malintencionada con la cuenta Administrator.
- A continuación, ejecutamos el siguiente comando, para conocer el SID del usuario con el que iniciamos todo el ataque, que es User01.
- Con toda la información anterior, vamos a ejecutar el comando definitivo, para conseguir el ansiado Golden Ticket. Esto nos generará un ticket nuevo para que posteriormente podamos importarlo y usarlo como Golden Ticket.
- Importamos el ticket recién creado mediante el siguiente comando en mimikatz.
Acabamos de importar el ticket kerberos que hemos generado nosotros mismos, y mediante este tenemos acceso a todo el entorno de Active Directory. Este ticket podemos utilizarlo siempre que queramos, y además como he comentado anteriormente, podemos modificar su caducidad y renovarlo.
Afortunadamente, ATA es capaz también de detectarlo y avisarnos que se ha producido un robo del ticket kerberos.
Como hemos visto a lo largo de esta demo, ATA es capaz de detectar cada uno de los pasos que hemos ido dando durante todo el ataque. Además de detectarlo, ATA es capaz de pararlo, bloqueando la cuenta, por ejemplo.
También me gustaría comentar, que ATA dispone de la parte de honeypots para poder ayudar a detectar posibles ataques a cuentas diseñadas para tal fin.
Al final de todo esto, es necesario sacar una serie de conclusiones, que a mi entender al menos, son muy importantes y han de tenerse en cuenta:
- El eslabón más débil en una compañía es el usuario. Es por este motivo, que es extremadamente importante formar a los usuarios para que no “caigan” en las trampas que les harán llegar.
- Si aún así, por cualquier motivo, bien porque el usuario ha caído en la trampa, o bien porque una determinada cuenta ha sido expuesta, es necesario detectarlo lo antes posible, para poder corregirlo lo antes posible.
- Después de esta demo, creo que queda claro que es necesario disponer de una herramienta que sea capaz de detectar, parar y corregir este tipo de acciones, controlando el uso de los recursos y los permisos de acceso de Active Directory.
Me da igual que tecnología utilicéis, pero por favor, utilizad alguna. Puede que dentro de vuestras compañías se esté produciendo algún tipo de ataque o ya se haya producido, el atacante tenga persistencia generada y mediante este tipo de tecnologías, seremos capaces de detectarlo y corregirlo.
Espero que os haya gustado y os haya podido concienciar. Me encantaría conocer vuestras experiencias con ATA y el resto de tecnologías similares.
Un saludo !!
Colaborador: Raúl Beamud, (@raulbeamud)