En su exitosa canción "War," el cantante de Motown Edwin Starr hizo una pregunta contundente: "War, huh, yeah, ¿para qué sirve?" Bueno, desde la perspectiva de un purple teamer, se puede hacer la misma pregunta sobre Performance Monitor (PerfMon), y la respuesta será la misma: "¡PARA NADA!”
Eso es exactamente lo que pensé cuando empecé a investigar medios "alternativos" de telemetría de Kerberos (es decir, más allá del estándar de los eventos de Windows 4768/4769) cuando Charlie Clark y yo lanzamos nuestra herramienta WonkaVision durante nuestra charla “I’ve Got a Golden Twinkle in My Eye” en SANS PenTest HackFest 2022.
Durante nuestra investigación inicial sobre el ataque de falsificación de tickets Kerberos y su detección, recordé haber leído el post de Microsoft de 2018 escrito por Mark Morowczynski, "Domain and DC Migrations: How to Monitor LDAP, Kerberos, and NTLM Traffic to Your Domain." En ese momento no le di mucha importancia, ya que estaba enfocado en el ataque de falsificación de tickets Kerberos y no en el panorama más amplio de los ataques de Kerberos. Sin embargo, al volver a revisar los contadores de rendimiento de Kerberos para este post, recordé el blog de Mark de 2018 y eso me llevó a repasar sus ideas de nuevo. Esto me hizo pensar en el valor de rastrear y analizar el tráfico de Kerberos dentro de un dominio, y en cómo los contadores de PerfMon podrían ser útiles para eso. Cuando se analizan correctamente, estos contadores ofrecen metadatos ricos que pueden dar un contexto valioso y mejorar considerablemente las capacidades de detección.
Primero, ¿qué es PerfMon?
PerfMon es una herramienta integrada de Windows que se usa para rastrear el rendimiento del sistema y reunir datos detallados sobre varios aspectos de la actividad del sistema, como el CPU, la memoria, el uso del disco y el tráfico de red. Además del rendimiento del sistema, PerfMon también se puede usar para monitorear el rendimiento relacionado con el dominio, incluidos los procesos de autenticación y la actividad de Active Directory, lo que da información valiosa sobre los eventos relacionados con Kerberos.
Ten en cuenta que mi laboratorio es un dominio pequeño de Windows Active Directory (AD), así que, por supuesto, los resultados pueden variar (YMMV) 🙂!
Contexto
Según Microsoft, la herramienta Performance Monitor es:
Principalmente para ver estadísticas en tiempo real. Por defecto solo se selecciona un contador: el contador %Processor Time. Sin embargo, puedes agregar contadores adicionales haciendo clic en el signo verde más. Esto te permitirá monitorear cualquier contador que quieras en tiempo real.
Después de iniciar Performance Monitor (perfmon.exe) en un controlador de dominio (DC), se observa lo siguiente, que muestra el rendimiento de los procesos de nuestro DC a lo largo del tiempo:
Registro
PerfMon puede aprovechar Event Trace for Windows (ETW), un mecanismo de eventos, para dar visibilidad sobre acciones detalladas. Por suerte para nosotros, admite la capacidad de recopilar información avanzada sobre ataques a Active Directory. La fuente Active Directory Diagnostics, como se muestra en la Figura 2, puede consumir eventos de la sesión de seguimiento de eventos "Active Directory". Exploraremos cómo estos registros pueden ser útiles para detectar ataques a Active Directory como Kerberoasting, AS-REP Roasting, y Roasting desde el AS.
Para un repaso rápido sobre cómo funcionan los ataques de las próximas dos secciones, recomiendo mucho una de mis publicaciones favoritas: "Kerberosity Killed the Domain: An Offensive Kerberos Overview" de Ryan Hausknecht. Hace un excelente trabajo explicando los conceptos y mostrando tanto Kerberoasting como AS-REP Roasting.
Kerberoasting
Usando el Active Directory Diagnostics, Data Collector Set (System) predeterminado, podemos iniciar un seguimiento antes de ejecutar el ataque. Al ejecutar un simple ataque Kerberoast con Rubeus, sin aplicar ninguna técnica de "opsec", se obtienen los siguientes resultados:
La Figura 3 muestra de inmediato la acción de solicitudes TGS masivas por parte de una sola cuenta, lo que es una de las formas más comunes y simples de detectar este ataque. La evidencia de este ataque se refuerza aún más con el registro de la consulta LDAP (con el infame serviceprinicaplname=*):
Ahora tenemos una clara indicación de ataque (IOA), con un contexto sustancial, de la relación entre un cliente (es decir, el origen) y un servidor, lo que ayuda a impulsar una respuesta eficaz.
AS-REP Roasting
Si iniciamos otra traza y, de forma alternativa, realizamos un ataque de AS-REP Roasting con Rubeus, podemos obtener resultados contextuales "similares":
Esto también brinda información relevante sobre el ataque: el atacante tocó nuestras cuentas, Thanos y Warmachine, que están configuradas para no requerir autenticación previa.
Roasting desde el AS
Si bien este ataque comparte similitudes con Kerberoasting y AS-REP Roasting, es distinto y quizás no tan ampliamente reconocido. Este método fue descubierto por Charlie Clark, quien escribió una excelente publicación que lo detalla aquí. Una vez que iniciamos nuestra traza, también se registran los siguientes eventos:
Tenemos un fuerte indicio de que se realizó una solicitud masiva de tickets AS. Lo más interesante es que, como resultado de la ejecución de este ataque, podemos ver un claro pico en nuestro contador de solicitudes AS de Kerberos, ya que ejecuté este ataque contra todos los usuarios de mi dominio.
Conclusión
Esta publicación exploró un método alternativo para detectar ataques de roasting de Kerberos sin depender únicamente de los eventos de Windows 4768 o 4769. Si bien este enfoque puede no ser ideal para alertas escalables en tiempo real y requiere familiaridad con las tácticas del atacante, abre nuevas vías de detección al aprovechar contadores de rendimiento que suelen pasarse por alto. Estos contadores contienen una gran cantidad de metadatos que, cuando se analizan correctamente, podrían añadir una capa adicional de contexto a los esfuerzos de detección.
Es importante señalar que, si bien PerfMon en sí no está diseñado como fuente directa de detección, los datos subyacentes que utiliza podrían ser muy valiosos si otras fuentes los recopilan y analizan. Este enfoque podría permitir a los analistas de ingeniería de detección incorporar información de las métricas de rendimiento del sistema a la detección de amenazas, enriqueciendo así la información disponible para descubrir patrones sospechosos.
Soy un firme defensor de pensar fuera de lo convencional cuando se trata de ingeniería de detección. Si podemos aportar aunque sea un poco de contexto adicional, como visualizar relaciones cliente/servidor o patrones de comportamiento inesperados, mejoramos nuestra visibilidad general y fortalecemos nuestra postura defensiva. Siempre hay más por explorar, y creo que enfoques creativos como este pueden ampliar los límites de las estrategias de detección de formas significativas.
Extra: LDAP ofuscado
Las técnicas de ofuscación mediante intérpretes de scripts o la línea de comandos no son nuevas, pero podrían estar ganando más terreno con el lanzamiento de MaLDAPtive. La función -Obfuscate de Charlie Clark en su bifurcación de PowerView existe desde 2021. Usando esta función, podemos enviar consultas LDAP ofuscadas a nuestro controlador de dominio y ver los resultados en PerfMon:
En la ingeniería de detección, brindar información contextual sobre la ofuscación en las consultas LDAP es importante para obtener mayor visibilidad sobre Active Directory, una de las tres patas críticas que también incluyen Kerberos y NTLM. LDAP funciona como la puerta de entrada para consultar servicios de directorio, lo que lo convierte en un objetivo prioritario para los adversarios que buscan enumerar usuarios, grupos y permisos.
Al capturar y analizar detalles contextuales, como patrones de consulta, técnicas de ofuscación y metadatos asociados, como direcciones IP de origen o cuentas de usuario, podemos iluminar los puntos ciegos en la visibilidad e identificar comportamientos maliciosos que intentan camuflarse entre las operaciones normales.
Un gran agradecimiento a Jonathan Johnson (@jsecurity101) por sus valiosos aportes y explicaciones sobre cómo se captura la telemetría subyacente y cómo funciona la mecánica interna, lo que enriqueció enormemente esta publicación del blog.
