Seis ataques en Active Directory, que no podemos pasar por alto

En los últimos cuatro años, no han faltado informes sobre ataques contra Microsoft Active Directory. Los atacantes desarrollan nuevos vectores y técnicas, pero no hay que olvidarse de los consejos sobre cómo detectarlos y prevenirlos. En este artículo, veremos los métodos populares de atacar Microsoft Active Directory y brindaremos algunas recomendaciones que ayudarán a protegernos.

Pass-the-Hash

Esta técnica es posible debido a las características de la arquitectura del protocolo de autenticación NTLM, desarrollado por Microsoft en los años noventa del siglo pasado. Para iniciar sesión en el host remoto, se utiliza un hash de contraseña, que se almacena en la memoria de la computadora desde la cual se realiza la autenticación. En consecuencia, se puede extraer de allí.

Mimikatz

Para facilitar el uso del Pass-the-Hash Benjamin Delpy en el año 2014 desarrolló la herramienta mimikatz la cual permite volcar desde la memoria contraseñas de texto sin cifrar y hash NTLM.

Fuerza bruta

Si el atacante no tiene suficientes credenciales que haya extraído de un host, puede recurrir a una técnica de fuerza bruta que puede ser efectiva para adivinar contraseñas.

net user /domain

¿Dónde puedo encontrar el diccionario de nombres de usuario para realizar un ataque de fuerza bruta? Cualquier miembro del dominio puede ejecutar el comando net user / domain, que devuelve una lista completa de nombres de usuario de AD.

Kerberoasting

Cuando Kerberos es usado como protocolo de autenticación en el dominio, entonces el atacante puede recurrir al ataque Kerberoasting. Cualquier usuario autenticado en el dominio puede solicitar un ticket de Kerberos para acceder al servicio (Ticket Granting Service). El TGS se cifra con un hash de la contraseña de la cuenta desde la cual se lanzó el servicio objetivo. El atacante, habiendo obtenido así el TGS, ahora puede descifrarlo, seleccionar la contraseña y no tener miedo de ser bloqueado, porque lo hace offline. Si tiene éxito, recibe una contraseña de una cuenta de servicio asociada, que a menudo cuenta con elevados privilegios.

PsExec

Una vez que el atacante ha recibido las credenciales necesarias, se enfrenta a la tarea de ejecución remota de comandos. Para esto, la utilidad PsExec de la suite Sysinternals es genial. Ha demostrado ser buena tanto entre los administradores de TI como entre los atacantes.

Capturando Active Directory

Vamos los pasos, gracias a los cuales un atacante puede tener control total sobre Active Directory. Los dividimos en cuatro etapas:

Etapa 1. Reconocimiento

PowerView

Esta herramienta está incluida en el popular framework de PowerShell para test de intrusión: PowerSploit. También se basa en la herramienta BloodHound, que construye un gráfico de relaciones de objeto dentro de AD.

BloodHound proporciona las siguientes características:

  • Permite encontrar las cuentas de todos los administradores de dominio
  • Permite encontrar hosts en los que se registran los administradores de dominio
  • Permite detectar la ruta más corta desde el host del atacante hasta el host con la sesión del administrador del dominio

El último punto proporciona una respuesta a la pregunta de qué hosts se necesitan atacar para acceder a la cuenta de administrador del dominio. Este enfoque reduce en gran medida el tiempo para obtener control total sobre el dominio.

Para detectar ésta actividad hay que tener en cuenta que PowerView difiere de otras herramientas para obtener información de un objeto de AD (por ejemplo, Net.exe) básicamente en que opera a través de LDAP y no SAMR. El evento 1644 del controlador de dominio es adecuado para detectar esta actividad. El registro de este evento se incluye al agregar el valor correspondiente en el registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostic\\15 Field Engineering = 5

Vale la pena prestar atención al hecho de que puede haber una gran cantidad de tales eventos, y una buena alternativa a un detector de eventos será un detector de tráfico, puesto que LDAP es un protocolo de texto plano, todas las solicitudes son claramente visibles en el tráfico.

Otra característica importante de este marco es que está escrito en PowerShell puro y no tiene dependencias. Y aquí, para la detección, la opción de auditoría mejorada que apareció en la versión 5 de PowerShell nos ayudará. El evento 4104 muestra el cuerpo del script, en el que podemos buscar nombres de funciones específicas de PowerView.

SPN Scan

Esta técnica puede reemplazar el uso de Nmap. Después de que el atacante descubriera qué usuarios y grupos están dentro del AD, para completar su ataque, necesitará información sobre qué servicios son.

Usualmente esto se resuelve escaneando los puertos usando la utilidad Nmap. Pero ahora esta información se puede obtener directamente desde AD: es almacenada en la forma de los denominados SPN (Service Principal Names). SPN consta de una clase de servicio, es única para cada tipo de servicio, luego va el nombre de host en forma de FQDN y para algunos servicios se añade información sobre el puerto.

Lista completa de SPN

Es importante tener en cuenta que el escaneo SPN tiene una clara ventaja sobre Nmap: es menos ruidoso. Al usar Nmap, debe conectarse a cada nodo y enviar cientos de paquetes al rango de puertos que se especificó. Sin embargo, para obtener la lista de SPN, solo necesita enviar una solicitud.

Enumeración de sesiones remotas

Una tarea importante para el atacante entes de entrar en la etapa de movimiento lateral es determinar qué usuario en qué máquina se registra. O bien ya tiene credenciales de usuario (hash o Kerberos-Ticket) y busca hosts donde puedan iniciar sesión fácilmente o bien está buscando un host en el que haya una sesión viva del administrador del dominio.

Para detectar esta técnica se pueden usar eventos. El evento 4624 informa de un inicio de sesión exitoso en el sistema remoto del tipo 3, así como los eventos de acceso al nodo de red IPC$, y el matiz: el nombre del pipe es srvsvc. Por qué el pipe se llama así, se puede entender por el tráfico.

En la parte izquierda en los recuadros rojos están las llamadas a SMB, así como la llamada al pipe srvsvc. Aquí, este pipe permite interactuar en el protocolo especial Server Service Remote Protocol. Para los hosts finales, esta llamada permite obtener diversa información administrativa, incluso entre las solicitudes hay una llamada a NetSessEnum. Como resultado de esta solicitud, se devuelve una lista completa de los usuarios que iniciaron sesión en el sistema remoto con IP y nombres de usuario.

Etapa 2. Avance por AD

Overpass-the-Hash

¿Qué puede hacer un atacante si tiene un hash NTLM? Puede llevar a cabo un ataque Pass-the-Hash, pero éste tipo de ataque ya puede ser detectado por multitud de SIEM’s. Por lo tanto, se ha desarrollado un nuevo vector de ataque: el ataque Overpass-the-Hash.

El protocolo Kerberos se desarrolló específicamente para garantizar que las contraseñas de usuario de una forma u otra no se transmitan a través de la red. Para hacer esto, en su máquina, el usuario codifica su contraseña para encriptar la solicitud de autenticación. En respuesta, el Centro de distribución de claves (un servicio especial alojado por un controlador de dominio) emite un ticket para recibir otras entradas, el llamado Ticket-Granting Ticket (TGT). Ahora el cliente se considera autenticado, y en un plazo de diez horas puede solicitar boletos para acceder a otros servicios. En consecuencia, si un atacante adivina la contraseña de un usuario que usa un servicio de su grupo de interés, por ejemplo el sistema ERP o una base de datos, el atacante puede emitir un pase para iniciar sesión con éxito en este servicio.

Cómo detectar este ataque: si el atacante usa la versión de mimikatz de PowerShell para este ataque, entonces el registro del cuerpo del script es de mucha ayuda, porque "Invoke-Mimikatz" es un registro muy evidente.

O bien, en caso de renombrar el script tenemos que tener en cuenta que el evento 4688 indica un inicio de proceso desde línea de comandos. Por tanto Incluso si se renombra el ejecutable, entonces encontramos un comando muy característico para mimikatz.

El tráfico de overpass-the-Hash se puede detectar en función de una anomalía que resulta del hecho de que Microsoft recomienda que los dominios de autenticación actuales utilicen la solicitud de autenticación AES-256 para el cifrado. Y mimikatz, cuando envía datos de solicitud de autenticación, lo cifra usando el obsoleto RC4, lo cual se aprecia en el eTYPE(23)

Ataque mediante Golden Ticket

¿Qué puede hacer un atacante si tiene un hash de contraseña de una cuenta especial llamada krbtgt? Anteriormente, consideramos el caso cuando el usuario podría no tener privilegios. Ahora estamos considerando un usuario cuyo hash de contraseña ha sido firmado para absolutamente todos los tickets es decir puede recibir cualquier otro ticket (TGT). En consecuencia, el atacante ya no se dirige al Centro de Distribución de Claves para obtener tickets, sino que él mismo genera cualquier ticket, ya que el Golden Ticket, de hecho, es un TGT. Entonces el atacante puede enviar solicitudes de autenticación a cualquier servicio dentro de AD, y además, por un tiempo ilimitado. Como resultado, el atacante puede acceder libremente a cualquier recurso. Como vemos el Golden Ticket recibe este nombre por una buena razón.

Cómo detectar este ataque por eventos: Hay un evento 4768, que determina que ha sido emitido un TGT, y además el evento 4769, que nos dice que se emitió un ticket de servicio que se requiere para la autenticación en algún servicio dentro de AD.

Aquí se puede observar la diferencia: desde el ataque Golden Ticket no se solicita un TGT de un controlador de dominio (ya que lo genera él mismo), pero en TGS (Ticket-Granting Service) su solicitud si es necesaria, por lo tanto si encontramos una diferencia en el TGT resultante y TGS, podemos suponer que estamos sufriendo un ataque Golden Ticket.

Etapa 3. Exploit

Una vez resuelta la tarea de autenticación y autorización en los hosts deseados, el atacante puede comenzar a ejecutar tareas de forma remota.

WMI (Windows Management Instrumentation) Remote Execution

WMI es un mecanismo integrado para la ejecución remota, este mecanismo es ideal para llevar a cabo tareas maliciosas. En los últimos años se viene usando mucho la metodología living off the land, que implica usar los mecanismos y recursos incorporados en Windows, de forma que se haga más difícil la tarea de detección, puesto que permite disfrazar una acción maliciosa como una actividad legítima.

Cómo detectar el uso de WMI remote execution: Debemos hacer un seguimiento a los eventos de login remoto, evento 4624. Además hay que prestar atención a la ID de inicio de sesión y el evento 4688, que informa sobre el inicio de un proceso desde la línea de comandos. El evento 4688 permite ver que el padre del proceso en ejecución es WmiPrvSE.exe, un proceso de servicio WMI especial que se utiliza para la administración remota. Se puede ver que el comando que enviamos net user/add, y Logon ID coincide con el evento 4624. En consecuencia, podemos decir con bastante precisión desde qué host se ejecuta este comando.

Detectar el ataque mediante el tráfico: Aquí vemos claramente las palabras características Win32 process create, así como command line, lo que se usa para lanzar exploits y malware. Recientemente nos encontramos con diverso software malicioso que se extiende por la red basado en el mismo principio que WannaCry, sólo que en lugar de cifrar los archivos establece un proceso para minar criptomonedas. Éste malware llevaba con él EthernalBlue y mimikatz, gracias a los cuales puede acceder a todos los hosts y desde ellos acceder a toda la red. Mediante WMI ejecutado en PowerShell, descarga un payload de PowerShell, que contiene mimikatz, EthernalBlue y el programa de minado.

Recomendaciones para las etapas 1-3

  • Usar contraseñas complejas y largas (> 25 caracteres) para cuentas de servicio. Esto eliminará la posibilidad de que un atacante pueda lanzar un ataque de Kerberoasting, ya que consumiría mucho tiempo en el uso de fuerza bruta.
  • Iniciar sesión en PowerShell. Esto ayuda a detectar el uso de muchas herramientas modernas para ataques en AD.
  • Actualizar a Windows 10 y Windows Server 2016. Microsoft ha desarrollado Credential Guard mediante el cual ya no es posible descargar los hashes NTLM y los tickets Kerberos desde la memoria. Al habilitar Credential Guard de Windows Defender, se proporcionan las siguientes características:
    • Seguridad de hardware NTLM, Kerberos y el Administrador de credenciales usan las características de seguridad de plataforma, como el arranque seguro y la virtualización, para proteger las credenciales.
    • Seguridad basada en la virtualización Windows NTLM, las credenciales derivadas de Kerberos y otros secretos se ejecutan en un entorno protegido que está aislado del sistema operativo en ejecución.
    • Mejor protección contra las amenazas persistentes avanzadas Cuando se protegen las credenciales de dominio del Administrador de credenciales, NTLM y las credenciales derivadas de Kerberos mediante seguridad basada en virtualización, las herramientas y técnicas de ataque de robo de credenciales que se usan en muchos ataques dirigidos se bloquean. Con la ejecución de malware en el sistema operativo con privilegios administrativos no se pueden extraer secretos que están protegidos con la seguridad basada en la virtualización. Aunque Credential Guard de Windows Defender es una mitigación eficaz, los ataques de amenazas persistentes, probablemente, cambiarán por nuevas técnicas de ataque y también deberías incorporar Device Guard de Windows Defender y otras arquitecturas y estrategias de seguridad.
  • Establecer una estricta distinción de roles. Es peligroso combinar AD y DC así como todos los servidores y máquinas de trabajo en un solo rol.
  • Cambiar dos veces la contraseña para krbtgt (esta es la misma cuenta a la que están suscritos los boletos de TGT)
    • La contraseña debe cambiarse dos veces, porque se almacenan tanto la contraseña actual como la contraseña anterior
    • La contraseña debe cambiarse cada año, así como después de la salida del administrador del dominio. Incluso si la red ya está comprometida y los atacantes han usado un ataque de Golden Ticket, el hecho de cambiar la contraseña inutiliza el Golden Ticket.
  • Usar medios de protección con una base de conocimientos expertos que sea continuamente actualizada. Es necesario detectar la posibilidad de ataques reales.

Etapa 4. Captura de dominio

DCShadow

El 24 de enero de 2018 se introdujo un nuevo módulo de mimikatz que implementa el ataque DCShadow. La esencia del ataque es que se crea un controlador de dominio falso para modificar y crear nuevos objetos en AD a través de la replicación. Los investigadores fueron capaces de determinar la cantidad mínima de SPN de Kerberos necesaria para la replicación – se necesitan únicamente dos. Además, introdujeron una función especial que puede usarse para forzar la replicación de los controladores. Este ataque impide la detección mediante un SIEM, dado que el controlador de dominio falso no envía eventos al SIEM, lo que significa que los atacantes pueden actuar sin ser detectados.

Esquema del ataque: El sistema en el que se realizará el ataque, deben existir dos SPN para que otros controladores de dominio puedan autenticarse por Kerberos para la replicación. Dado que de acuerdo con la especificación, el controlador de dominio está representado en la base de datos de AD por un objeto de la clase nTDSDSA, es necesario crear dicho objeto. Finalmente, la replicación se lleva a cabo haciendo uso de la función DRSReplicaAdd.

Cómo detectar un ataque mediante DCShadow. En el tráfico, vemos claramente la adición de un nuevo objeto al esquema de configuración del tipo de controlador de dominio y luego la replicación forzada.

Conclusión

El ejemplo DCShadow muestra como están proliferando nuevos vectores de ataque para las empresas, por lo que es muy importante mantenerse a la vanguardia y avanzar rápido. En TELINSEC investigamos nuevas amenazas y desarrollamos métodos y herramientas de detección para ellas.