Cuando estás realizando un análisis de intrusión, es fácil desorientarse.
Por lo general, hay cientos de ID de eventos de Windows para revisar, generados por potencialmente miles de endpoints. Sin duda, este nudo gordiano no es fácil de desenredar.
¿Cómo se encuentra la aguja en este proverbial pajar?
La mayoría de los análisis se enfocan en ID de eventos de Windows específicos: observa el ID de evento 4625 para encontrar ataques de fuerza bruta.
Con esta información, se abre una instancia del Visor de eventos de Windows y se filtra por eventos 4625, que muestran miles de resultados con distintos nombres de usuario y marcas de tiempo, algunos eventos de hace varios meses.
¿Esta organización ha sido vulnerada durante meses? ¿Todas estas cuentas de usuario están comprometidas?
Esta es la diferencia entre información y análisis.
Un evento 4625 es solo un dato. Para que aporte valor e información útil, hay que convertirlo en un análisis y contextualizarlo.
Este blog describe algunas de las técnicas y metodologías que usa el equipo de Huntress Tactical Response para detectar intrusiones y convertir la información en información útil y procesable para nuestros partners.
Eventos de autenticación
Comencemos por observar los eventos de autenticación. Aquí nos enfocaremos en los inicios de sesión exitosos (4624) y fallidos (4625), ya que estos eventos están habilitados por defecto y presentes en los endpoints en la mayoría de los casos.
Es muy fácil pasar por alto los matices que existen dentro de los eventos de fallos de autenticación, así que veamos algunos ejemplos.
Aquí tenemos dos eventos de Windows 4625 uno al lado del otro:
Figura 1: Imagen que muestra dos eventos de seguridad de Windows 4625
El Evento 1 muestra un inicio de sesión fallido para el nombre de usuario "Tom", mientras que el Evento 2 muestra un inicio de sesión fallido para el nombre de usuario "Administrator".
Aquí tenemos la "información": inicios de sesión fallidos para las cuentas "Tom" y "Administrator". También tenemos la dirección IP de origen y el nombre de la estación de trabajo. Esta es información fantástica, ya que ahora tenemos algunos puntos de pivote más. Sin embargo, necesitamos profundizar aquí para extraer un análisis de estos dos eventos.
Si observas con atención, notarás que el campo SubStatus de estos dos eventos es diferente.
El Evento 1 tiene un SubStatus de 0xC0000064, mientras que el Evento 2 tiene un SubStatus de 0xC000006A. Si observamos la documentación del ID de evento 4625 en Ultimate Windows Security, vemos una tabla práctica que traduce estos valores por nosotros:
Figura 2: Tabla de traducción de códigos de error del ID de evento de seguridad de Windows 4625
¡Ahora podemos convertir la información de los eventos 4625 en información útil!
En el contexto del análisis de intrusión, un evento de inicio de sesión fallido que contiene un nombre de usuario que no existe en el entorno resulta extremadamente sospechoso. Por supuesto, los escáneres y las aplicaciones mal configuradas pueden causar esta dinámica. Sin embargo, si la actividad no se ha observado históricamente, debe tratarse como un hilo prioritario para investigar.
Este tipo de análisis también te ayudará a distinguir los inicios de sesión fallidos sospechosos o maliciosos de aquellos que ocurren normalmente por contraseñas vencidas, usuarios que ingresan mal su contraseña, etc.
Si observamos de nuevo el Evento 1, ahora tenemos los siguientes puntos para trabajar:
- Se produjo un inicio de sesión fallido desde una estación de trabajo desconocida (WORKSTATION)
- Este inicio de sesión fallido intentó autenticarse con un nombre de usuario que no existe en el entorno
- El inicio de sesión se produjo desde una dirección IP que no se encuentra en ninguna herramienta de inventario de la organización
En este caso, tomamos un dato (un único evento 4625) y lo convertimos en información procesable simplemente observando de cerca los diversos códigos de estado y subestado que contiene.
Veamos otro ejemplo, esta vez usando eventos 4624 (inicio de sesión exitoso).
De nuevo, tenemos dos eventos 4624 de apariencia similar uno al lado del otro.
Figura 3: Dos ID de eventos de seguridad de Windows 4624 uno al lado del otro
Ambos eventos muestran un inicio de sesión exitoso para la cuenta Administrator, entonces, ¿cómo detectamos el sospechoso?
Un campo clave aquí es el campo AuthenticationPackageName: el Evento 1 tiene "NTLM" como valor, y el Evento 2 tiene "Kerberos".
Las herramientas que realizan ataques de fuerza bruta suelen tener opciones para configurar si se usa NTLM o Kerberos. El módulo scanner/smb/smb_login de Metasploit puede configurar este ajuste, por ejemplo:
Figura 4: Ilustración de los métodos de autenticación configurables dentro del módulo smb_login de Metasploit
Aunque esta opción se puede cambiar, ¿por qué no aprovechar la pereza de un actor de amenazas a nuestro favor?
En este caso, tenemos dos eventos 4624 de apariencia similar, pero mediante el análisis y la metodología, podemos diferenciar el Evento 1 como más sospechoso que el Evento 2, dados los siguientes factores:
- Se observó autenticación NTLM
- Este punto tiene mucho más peso si observas los patrones históricos de autenticación e identificas que esta es la primera vez que una cuenta en particular usa NTLM para autenticarse, en lugar de Kerberos
- Un nombre de estación de trabajo sospechoso: WORKSTATION
El primer y el segundo ejemplo descritos no deben verse de forma aislada. A menudo —y según lo que ha experimentado nuestro equipo en intrusiones reales— estas dos dinámicas se dan en conjunto. Es decir, un actor de amenazas llegará al entorno y realizará algún tipo de ataque de fuerza bruta o password spraying antes de lograr acceder con una cuenta del entorno.
Al observar de cerca solo dos ID de eventos de Windows, podemos potencialmente recopilar información sobre el origen del ataque de fuerza bruta, qué cuentas fueron comprometidas, desde dónde se comprometieron, y si esta actividad es maliciosa o legítima.
Hasta ahora, hemos estado analizando un evento a la vez. Sin embargo, si pensamos en cómo se ve un ataque de fuerza bruta exitoso, podemos asumir que se generarán eventos de inicio de sesión exitosos en varias estaciones de trabajo dentro de nuestro dominio.
Además, estos eventos probablemente compartirán las mismas características sospechosas descritas hasta ahora respecto a los protocolos de autenticación y los nombres de las estaciones de trabajo.
Veamos cómo se ve esto en la práctica.
En este escenario, un actor de amenazas ha ingresado a un entorno y logró un ataque de fuerza bruta exitoso en tres sistemas distintos de la red:
Figura 5: Imagen que muestra un ataque de fuerza bruta exitoso mediante Metasploit
En lugar de analizar un evento individualmente, veamos los tres eventos de autenticación generados por el ataque de fuerza bruta anterior.
Figura 6: Tres eventos distintos de seguridad de Windows 4624 que muestran un ataque de fuerza bruta exitoso
Podemos ver tres eventos 4624 distintos con inicios de sesión exitosos y eventos generados en el sistema donde la autenticación fue exitosa. ¿Qué podemos deducir de estos eventos? ¡Bastante!
Vemos:
- Una sola cuenta (Administrator) que se autentica en tres sistemas distintos: win11v, win11a, DC
- Las tres autenticaciones ocurrieron al mismo tiempo
- Las tres autenticaciones provinieron de la misma combinación de dirección IP y estación de trabajo
- Los tres eventos usaron el protocolo de autenticación NTLM, no Kerberos
Una vez más, podemos convertir la información de un solo evento en información útil con solo un poco de agregación.
Normalmente, se usaría algún tipo de plataforma de registro o SIEM para analizar estos datos, pero este tipo de sistemas no está al alcance de todos. E incluso si lo están, escribir consultas efectivas suele ser difícil y conlleva una curva de aprendizaje pronunciada que no es viable para algunas organizaciones. A veces solo contamos con herramientas básicas como el Visor de eventos de Windows o PowerShell, ¡y debemos aprovecharlas al máximo!
Solo dos ID de eventos de Windows diferentes, cuando se analizan correctamente, pueden darnos muchísima información y revelar hilos adicionales para investigar. A continuación hay un mapa mental con algunas consideraciones y técnicas de análisis para estos dos eventos.
Figura 7: Mapa mental del análisis de los ID de eventos 4624/4625
Cambiemos un poco de enfoque y veamos algunas vías de acceso a credenciales, en particular el volcado de credenciales del registro.
Acceso a credenciales
Uno de los tipos más comunes de intentos de acceso a credenciales que vemos en el equipo de Respuesta Táctica es el volcado de credenciales del registro. Esta técnica se puede ejecutar de forma remota desde la máquina del actor de amenazas y les da diversos materiales de credenciales en forma de hashes que luego se pueden transmitir (pass the hash) o descifrar.
Esta técnica no requiere que el actor de amenazas suba nada a la máquina de la víctima y no requiere interacción con el proceso LSASS, lo que la convierte en una técnica popular para los actores de amenazas que buscan evitar la detección de endpoints.
La vista del actor de amenazas sobre el volcado de credenciales del registro se ve algo así.
Figura 8: Imagen de un volcado exitoso de credenciales del registro mediante Impacket secretsdump
Si luego observamos los registros de eventos generados por esta actividad, podemos ver otra vez a nuestro viejo amigo, el 4624.
Podemos ver de nuevo que el protocolo de autenticación de este evento es NTLM, y la dirección de red de origen pertenece a la misma dirección IP que observamos realizando fuerza bruta en nuestro entorno.
Figura 9: Imagen que muestra un evento 4624 resultante del volcado de credenciales del registro
Este evento contiene un campo extremadamente útil llamado ID de inicio de sesión, que aún no hemos cubierto, así que veámoslo.
Piensa en este campo como el “pegamento” entre eventos de Windows dispares. Es una forma de rastrear qué hizo una sesión de inicio de sesión en particular en un equipo mediante un campo común. A menudo escucharás a los profesionales de seguridad del lado defensivo del espectro de infosec hablar de “pivotear” a partir de ciertos valores. De hecho, un ID de inicio de sesión es un candidato ideal para pivotear.
Idealmente, usarías un SIEM para crear una consulta que muestre las distintas actividades realizadas por un determinado ID de inicio de sesión, pero un SIEM no siempre está disponible. Un truco útil es simplemente ingresar un ID de inicio de sesión sospechoso en un bot de texto de búsqueda dentro del visor de eventos y hacer clic en “buscar siguiente” para ver los eventos que aparecen.
A continuación se muestra un ejemplo de esta técnica de baja tecnología.
Figura 10: Animación que muestra una técnica sencilla para pivotear a partir de un ID de inicio de sesión
Podemos ver dentro de los ID de evento 5145 los diversos valores sospechosos de tmp escritos en recursos compartidos de archivos administrativos en el equipo que fue el objetivo del volcado de credenciales.
También podemos ver nombres de destino relativos como winreg, samr, svcctl. Si combinamos los elementos sospechosos observados en estos eventos junto con el inicio de sesión sospechoso inicial, ahora tenemos una buena idea de qué técnica se realizó, desde dónde se realizó y qué equipo fue el objetivo del volcado de credenciales del registro.
Una vez más, tomamos distintas piezas de información, como los eventos 4624 y 5145, y las analizamos para convertir esta información en información procesable. Este es un ejemplo claro de lo importante que es la metodología para las investigaciones de intrusiones.
Usar herramientas sofisticadas definitivamente es divertido, pero si no tienes un proceso y una metodología sólidos detrás de tu análisis, las herramientas solo serán una distracción. A menudo, las herramientas también abstraen el análisis. Por ejemplo, es posible que solo trabajes con herramientas que etiquetan la actividad como "Registry Credential Dumping" y te presentan la información que tienen, pero no exponen la telemetría cruda que usaron para llegar a esa conclusión. Mientras más cerca posiciones tus técnicas de análisis de la telemetría cruda, más refinada se vuelve tu metodología.
Movimiento lateral
Uno de los métodos más populares de movimiento lateral que encontramos es el protocolo de escritorio remoto (RDP). A los actores de amenazas les gusta apuntar al RDP porque ofrece una interfaz gráfica y, por lo general, está habilitado en las redes.
Cuando empiezas a buscar en Google información relacionada con eventos de autenticación de RDP, probablemente encuentres orientación que te dice que revises el evento de seguridad con ID 4624 y tipo de inicio de sesión 10. Puedes ver un ejemplo de este evento a continuación.
Figura 11: evento de Windows con ID 4624 que muestra un inicio de sesión de RDP exitoso
Este es, de hecho, un excelente indicador de actividad de RDP. Este evento muestra claramente de dónde provino el inicio de sesión, así como el nombre de usuario que se usó para la conexión RDP.
Durante una intrusión, si sospechas que hay movimiento lateral por RDP, generalmente te apresuras a abrir el Visor de eventos, buscas en el registro de seguridad y te encuentras con lo siguiente:
Figura 12: imagen que muestra el evento con ID 1102: registro de seguridad borrado
La eliminación de indicadores, en particular la limpieza del registro de eventos de Windows (específicamente el canal del registro de seguridad), es una técnica que lamentablemente encontramos con frecuencia.
Si tienes la fortuna de contar con un SIEM, esta técnica probablemente te preocupe menos, ya que la telemetría ya se envió fuera del sistema en el que se borraron los registros.
Pero, ¿qué pasa si no cuentas con un SIEM y quieres investigar este movimiento lateral por RDP? Los siguientes canales de registro pueden venir al rescate:
Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
y
Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
En concreto, podemos usar el evento con ID 25 y el evento con ID 1149 para encontrar el origen del movimiento lateral por RDP, en caso de que se haya borrado el registro de seguridad.
Figura 13: imagen que muestra dos eventos de Windows activados por una autenticación de RDP exitosa
Estos eventos son extremadamente valiosos e importantes, incluso si no se ha borrado el registro de eventos de seguridad, ya que no siempre se genera un evento 4624 tipo 10 en cada inicio de sesión relacionado con RDP. En este caso, las direcciones IP son internas. Sin embargo, si tu servidor RDP está expuesto a internet, es posible que encuentres direcciones IP externas en esta telemetría. A partir de ahí, puedes usar el enriquecimiento de IP, en particular la información de ASN, para determinar si el evento es malicioso o benigno.
¡Consulta nuestro blog sobre cómo usar esta información de ASN para la caza de amenazas y la respuesta!
Esta dinámica ilustra, una vez más, la diferencia entre buscar información en eventos aislados y aplicar una metodología sólida para extraer información útil de esos datos. Es muy fácil pasar por alto ciertos rincones dentro de los registros de eventos. Si no ves eventos 4624 tipo 10, eso no significa necesariamente que no haya ocurrido movimiento lateral por RDP.
Conclusión
Hoy en día, la información abunda. Hay miles de artículos, videos, blogs, tutoriales, cursos, etcétera, sobre prácticamente cualquier tema de seguridad ofensiva o DFIR. Esto sin mencionar las capacidades que ofrecen los LLM. Sin embargo, en medio de esta abundancia de información, faltan los conocimientos útiles.
A menudo nos enfocamos tanto en presentar la mayor cantidad posible de información a distintas partes interesadas que olvidamos que esa información necesita procesarse y analizarse mediante un proceso repetible, sustentado en una metodología sólida y comprobada.
Este blog presentó varios escenarios en los que la información se transforma en conocimientos útiles gracias a la metodología que usa el equipo de Respuesta Táctica aquí en Huntress.
