En esta entrada, continuamos con algunos ataques conocidos sobre entornos de Active Directory utilizando Kerberos, principalmente movimiento lateral y persistencia.
Una de las maneras mas conocidas y antiguas de movimiento lateral es Pass the hash, donde utilizamos el hash NTLM de un usuario para poder acceder a los recursos o equipos donde este tiene algún nivel de privilegio.
Como se vio en un post anterior, Pass the hash llega a ser bastante critico, ya que no es necesario que el atacante conozca la contraseña del usuario para poder personificarlo, donde el impacto incrementa de manera exponencial cuando se utilizan cuentas de administradores locales, ya que, sin las herramientas correctas de monitoreo, será complicado detectar este tipo de ataques.
Cuando un atacante obtiene acceso a una cuenta de administración local, podría explotar PTH si se dan las siguientes condiciones:
- Existen otros equipos donde el administrador local tiene la misma contraseña que el usuario comprometido.
- Los equipos Windows permiten la autenticación remota utilizando cuentas locales.
- Los usuarios administradores locales estan habilitados en los equipos.
Sin embargo, existen herramientas de monitoreo avanzado que podrían detectar posibles ataques de PTH, tanto a nivel de dominio como nivel local. (Ya que la autenticación en PTH es usando administradores locales, los logs de acceso no son registrados en un controlador de dominio, se quedan en el equipo, por lo que un equipo de Blue Team tendría que analizar los logs locales de los equipos internos, o implementar un SIEM para obtener toda esta información que no esta siendo almacenada en los controladores de dominio)
Existen numerosos artículos de como detectar PTH o indicios que se pueden observar en los logs de acceso de los equipos respectivos que dan a entender que se esta realizando este ataque.
Por este motivo, se presenta en este post una técnica un poco mas sigilosa que PTH, denominada Pass the ticket.
El flujo de autenticación por Kerberos es un poco complicado de explicar en pocas palabras (Aun no lo entiendo completamente como para escribir con confianza sobre eso), pero para este escenario, mantendremos las cosas simples.
Cuando un usuario realiza autenticación por Kerberos, como resultado, obtiene un Ticket, ya sea de servicio o un “ticket granting ticket (TGT)”, este ticket se podría considerar como un documento de identidad, que puede ser utilizado en el dominio interno para acceder a ciertos recursos sin necesidad de autenticarse con usuario y contraseña.
Si un atacante llega a obtener control de uno de estos tickets, puede utilizarlos para personificar al usuario afectado y acceder a recursos internos del dominio como si fuera el dueño del ticket.
Escenario 1 – Pass the ticket
Para armar el escenario en nuestro Active Directory de pruebas, lo único que necesitamos hacer es iniciar sesión en algún equipo con múltiples usuarios, en este caso, “TECNOLOGIA01”.
Para este post, accedi al mismo equipo con el usuario “Administrator“, para fines demostrativos.
Explotación
Utilizaremos la suite de herramientas Impacket para la explotación respectiva, incluyendo un script que automatiza la extracción de información.
Como se menciono en anteriores posts, la información de autenticación de dominio se almacena en memoria, a través del proceso LSASS.EXE, por lo que si dumpeamos la información del proceso, podemos observar datos de autenticación de los usuarios en el equipo.
Para esta tarea, podemos utilizar múltiples métodos:
- Desde la GUI en el equipo Windows, volcar el proceso en el administrador de tareas.
- Utilizar Procdump (procdump64, segun la arquitectura del OS) de Sysinternals para realizar el volcado. (procdump64.exe -accepteula -ma lsass.exe -o lsass.dmp)
- Utilizar un modulo de crackmapexec (crackmapexec smb IP …… -M lsassy) *Creo que existe el modulo Procdump, no actualice crackmapexec.
- Utilizar una DLL propia del sistema operativo: C:\Windows\System32\rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump PID-LSASS C:\temp\lsass.dmp full
- Otras herramientas (Processdump de Cisco Jabber, SQLDumper de MSSQL, mimikatz, etc.)
La herramienta que personalmente utilizo es un script llamado autoProc.py.
Enlace: https://gist.github.com/knavesec/0bf192d600ee15f214560ad6280df556
Depende de Impacket para su ejecucion correcta.
Es necesario editar el script, para indicar la ruta correcta del binario procdump64.exe en tu equipo.
Como estoy utilizando kali linux, aloje el binario en “/home/jsec/tools/procdump64.exe”
Este script se autentica por wmiexec hacia el equipo, sube el binario, lo ejecuta, descarga el dump generado y elimina el binario respectivo, para luego procesarlo con pypykatz (Mimikatz escrito en Python, no con todas las funcionalidades, pero suficiente para extraer las credenciales y los tickets Kerberos).
Validando que el script funciona.
Como se vio en posts anteriores, conseguimos acceso administrativo en TECNOLOGIA01 a través del administrador local en ATENCION01, por lo que usaremos esa información para este escenario.
Si ejecutamos autoProc.py en ATENCION01, obtendremos las sesiones almacenadas en el equipo y sus tickets de kerberos respectivos.
Para tener un poco mas de orden, generaremos nuevos directorios para almacenar nuestros tickets.
Cuando generamos el dump por autoProc.py, obtenemos la información de credenciales en memoria, pero no los tickets respectivos, para extraer los tickets, utilizaremos pypykatz nuevamente.
Comando: pypykatz lsa minidump lsass.dmp -k RUTA-DE-EXTRACCION
Ejecutamos el comando, obtendremos la información nuevamente, pero al final del resultado indicara que se guardaron los tickets kerberos en la ruta especificada, si listamos el directorio donde se almaceno en la prueba realizada obtenemos la lista de tickets.
Observamos múltiples tickets de servicio y TGTs, pero para dos usuarios, cosme.fulanito y ATENCION01$ (Usuario del equipo que se unió al dominio).
Ahora podemos usar esos tickets para personificar a cualquiera de los usuarios respectivos, pero sabemos que los mismos no son privilegiados, por lo que se repite la acción respectiva en el equipo TECNOLOGIA01.
Se obtiene un error similar al de anteriores posts, donde el antivirus se encuentra en ejecución y bloquea el acceso a LSASS.EXE, por lo que repasando un poco, deshabilitaremos el mismo.
El equipo cuenta con Windows Defender, por lo que se puede realizar la deshabilitación desde la linea de comandos, ya sea desde una sesión interactiva, wmiexec, psexec o similares, el comando por Powershell es:
PS C:\Windows\System32> Set-MPPreference -disableRealTimeMonitoring $true
Una ves ejecutado el comando, volvemos a ejecutar autoProc.py
Esta ves si obtenemos los contenidos de memoria, por lo que se procede a extraer los tickets respectivos.
Listamos los tickets obtenidos.
Observamos que existen tickets de servicio y TGTs de dos usuarios adicionales, Service_BD y Administrator.
Ahora, podemos usar el ticket del usuario Administrator para personificarlo.
Realizamos una serie de pasos, ya que los tickets se encuentran en formato .kirbi, tenemos que convertirlos a formato .ccache, para que sean utilizables por Linux, luego exportamos los tickets como una variable de entorno y posteriormente los listamos.
Comandos:
- kirbi2ccache TICKET-FORMATO-KIRBI.kirbi TICKET-CCACHE.ccache
- export KRB5CCNAME=RUTA-TICKET-CCACHE
- klist (Requiere instalar krb5-user)
Observamos que tenemos un ticket kerberos para el usuario Administrator, por lo que validaremos si el mismo es funcional.
Intentaremos obtener una sesión de comandos utilizando wmiexec en el controlador de dominio.
Comando: impacket-wmiexec -k -no-pass DOMINIO/USUARIO@HOSTNAME -debug
El parámetro -k le indica a la herramienta que realice la autenticación por Kerberos, usando el ticket que exportamos, -no-pass evita que la herramienta nos pida introducir la contraseña del usuario, ya que la misma no es necesaria porque tenemos su ticket respectivo y -debug para observar los pasos que realiza y en caso de que falle, identificar la posible causa.
El ticket es funcional y obtenemos acceso al controlador de dominio como el usuario Administrator, sin necesidad de conocer su contraseña o su hash NTLM.
Este es un vistazo rapido sobre el ataque Pass the ticket, que llega a ser un poco mas sigiloso.
En algunos casos, al dumpear LSASS, vi que por alguna razón, el hash de usuarios privilegiados no se encontraba en el proceso respectivo, si se identificaba que el usuario había accedido al equipo recientemente, pero su hash no estaba almacenado, por lo que esta técnica si me permitió obtener su ticket y personificarlo.
PERSISTENCIA – GOLDEN TICKET
Aprovecharemos el hecho de que tenemos un ticket valido del usuario Administrator para personificarlo, un atacante siempre intentara obtener distintos métodos de persistencia, uno de los mas conocidos es un Golden ticket, que de manera simplificada, es la creación de un ticket de kerberos con privilegios de administración del dominio, valido por 10 años que puede ser utilizado para tener persistencia total en la infraestructura.
Para forjar estos tickets, se necesita la siguiente información.
- Hash NTLM del usuario KRBTGT
- SID del dominio
- Nombre completo del dominio
Para obtener esta información, utilizaremos el ticket obtenido previamente.
Utilizando impacket-secretsdump para obtener el hash del usuario KRBTGT.
Comando: impacket-secretsdump -k -no-pass DOMINIO/USUARIO@HOSTNAME -just-dc-user krbtgt
El parámetro -just-dc-user indica a la herramienta que obtenga la información de un solo usuario, en lugar de dumpear todo el NTDS.dit
Obtenemos el hash NTLM del usuario KRBTGT: 7f9b6cfb……bf1
Para extraer el SID del dominio, podemos utilizar otra herramienta de impacket.
Comando: impacket-lookupsid DOMINIO/USUARIO:PASS@CONTROLADOR-DE-DOMINIO
Para obtener esta información, no es necesario contar con un usuario administrador.
Obtenemos el Domain SID: S-1-5-21…..13415
Para el nombre completo del dominio, podemos utilizar un comando desde una sesión de Powershell, para simplificar las cosas, utilizaremos el ticket kerberos nuevamente.
Comando: Get-WmiObject Win32_ComputerSystem
Obtenemos el nombre del dominio completo: jsec.local
Con esta información, ya podemos forjar nuestro propio Golden Ticket utilizando Impacket.
impacket-ticketer -nthash HASH-KRBTGT -domain-sid SID -domain NOMBRE-COMPLETO-DOMINIO USUARIO
En este caso, creamos un ticket para personificar al usuario ‘DC01$’, que es el usuario del controlador de dominio, obteniendo su ticket en el fichero “DC01$.ccache“.
Exportamos el ticket con export KRB5CCNAME=’RUTA/DC01$.ccache’ y lo utilizamos.
Obtenemos todos los hashes del dominio, confirmando que tenemos privilegios de Domain Admin.
De igual manera, el usuario al cual vamos a personificar no importa, ya que es un ticket valido de administración de dominio, incluso podemos especificar un usuario que ni existe en el dominio respectivo e igual tener control administrativo.
Generamos un nuevo ticket con el usuario “goldenticket“, el cual no existe en el dominio interno, exportamos la variable de entorno y validamos el acceso, obteniendo de igual manera el acceso respectivo.
Estos son algunos ataques conocidos de Kerberos, principalmente para movimiento lateral y persistencia, en posts futuros exploraremos ataques un poco mas complicados (Constrained delegation, Domain Admin to Enterprise Admin, etc.).
Espero que la información los ayude, saludos.