En esta entrada se presenta la herramienta Hayabusa, una herramienta de código abierto orientada a la detección rápida de eventos sospechosos en logs .evtx de Windows y su uso en investigaciones forenses y de respuesta ante incidentes. Utiliza reglas basadas en Sigma y permite generar timelines en CSV y JSON, facilitando la investigación ágil de incidentes. Aunque no sustituye un análisis exhaustivo, es una herramienta complementaria eficaz que destaca por su rapidez y facilidad de uso. Se explican sus principales comandos y ejemplos prácticos.
Introducción
Esta herramienta no la conocía y he de decir que me ha sorprendido positivamente. Además, es una herramienta open source gratuita.
Os dejo por aquí el enlace al repositorio de Github: https://github.com/Yamato-Security/hayabusa
Se autodefine como el halcón peregrino del threat hunting y el forense. La verdad es que hay que reconocer que no se trata de humo, es realmente rápida y ofrece rápidamente unos resultados muy útiles a la hora de realizar investigaciones en respuesta ante incidentes, que es para lo que la vamos a enfocar. Esta dirigida a la detección rápida de eventos sospechosos en logs .evtx de sistemas Windows. Además, se puede ejecutar también desde Velociraptor. Os dejo el artículo donde hablamos sobre Velociraptor: https://dfirpills.com/dfir/triaje/velociraptor-parte-1-servidor/.
Aviso: Hayabusa no es la panacea y siempre debe usarse como método complementario en una investigación. A continuación sabréis porque os digo esto😉.
Así que vamos a por ello.
Core de la detección
La herramienta hace uso de reglas de detección basadas en formato Sigma. De hecho, la herramienta tiene incorporadas gran cantidad de reglas de detección del repositorio Sigma original y reglas propias. Se pueden encontrar en el directorio del proyecto llamado «Rules». Este directorio esta asociado al siguiente repositorio: https://github.com/Yamato-Security/hayabusa-rules. Dentro de este, se encuentran los directorios «sigma» y «hayabusa».
Tanto las reglas adaptadas del repositorio original de Sigma como las asociadas al desarrollo propio se organizan internamente en dos grupos:
- Builtin: reglas para logs que se generan a través de la funcionalidad integrada de Windows. Es decir, los que Windows ofrece por defecto o para configurar de manera nativa con el sistema.
- Sysmon: reglas para logs que se generan a través de sysmon.
Si no sabes que es Sysmon te dejo por aquí el capítulo 1 de la serie que escribió nuestro compañero Alberto Jodar: https://dfirpills.com/lab/laboratorio-de-deteccion-parte-3-que-es-sysmon/
Las reglas de Hayabusa además se categorizan por niveles de criticidad y estado de producción.
Los estados son:
- Experimentales
- Test
- Estables
Los niveles de criticidad de cada regla son:
- Informational
- Low
- Medium
- High
- Critical
A partir de «Low» se consideran alertas de seguridad todos aquellos eventos detectados con las reglas.
En otros artículos abordaremos en mayor profundidad cómo se crean nuevas reglas y otros detalles relacionados.
Ejecución de la herramienta
Hayabusa dispone de gran cantidad de opciones y módulos. No vamos a explicarlos todos en profundidad. No obstante, os voy a explicar los que he considerado más interesantes para la respuesta ante incidentes.
Podéis descargar la herramienta desde aquí: https://github.com/Yamato-Security/hayabusa/releases. Lógicamente, descargar el binario adecuado para vuestro sistema. Para mi entorno de pruebas he escogido este (a día de hoy la versión 2.19):
Una vez se descomprime el fichero, ya tenemos el ejecutable, reglas y dependencias.
Existen tres tipos de comandos:
- Comandos de análisis
- Comandos de DFIR
- Comandos generales
El uso de la herramienta es realmente simple y sigue este patrón:
hayabusa-2.19.0-win-x64.exe [comando] [opciones del comando]
Si tenéis dudas sobre que opciones incluye cada comando siempre podéis revisar la documentación del repositorio o bien ejecutar:
hayabusa-2.19.0-win-x64.exe [comando] -h
En mi opinión, para respuesta ante incidentes, los comandos más interesantes son los asociados a DFIR. Los comandos de análisis ofrecen la posibilidad de realizar búsquedas con expresiones regulares o palabras clave sobre los propios .evtx así como obtener estadísticas. No esta mal pero también existen otras herramientas para realizar esto. Los comandos generales no aportan ningún tipo de funcionalidad específica para el análisis.
Comandos DFIR
Llegamos a lo importante de la herramienta y por lo que estoy escribiendo este artículo. Esta herramienta es capaz de generar un timeline en diferentes formatos (csv y json) que recopila la información de los eventos de Windows contenidos en los .evtx que las reglas de detección han marcado como sospechosas. Y esto es muy potente. ¿Por que?, pues muy sencillo, cuando estamos en un incidente de seguridad lo que más nos importa es ser ágiles.
Lógicamente tenemos que analizar con criterio, tenemos que tener un plan inicial, indicios de por donde empezar la investigación, etc. No obstante, esto te ofrece la posibilidad de poder revisar de un plumazo una gran cantidad de eventos de aquellos dispositivos Windows de los que se haya obtenido un triage. De esta manera, lo que conseguimos es tener más pistas de manera de directa de por donde empezar a investigar los eventos y sobre todo, obtener probablemente hallazgos maliciosos sin haberlos buscados durante bastante tiempo sangrándonos los ojos. Mola bastante porque todo esto es en cuestión de segundos.
Y por último, me gustaría destacar que es en formato timeline. Para un forense es vital revisar los hallazgos, artefactos, etc en modo línea temporal para poder agilizar y ofrecer más comodidad a todo el proceso de investigación.
csv-timeline: Genera el timeline en formato CSVjson-timeline: Genera el timeline en formato JSONlevel-tuning: Ajuste personalizado del nivel de alertas.list-profiles: Enumera los perfiles de salida disponibles. Para ofrecer más información o menos en la salida.set-default-profile: Cambiar el perfil por defecto de salida.update-rules: Sincronice las reglas con las últimas reglas en el repositorio de GitHub hayabusa-rules
Con los comandos enumerados, vamos a comenzar con la ejecución. No obstante, antes de nada siempre recomiendo actualizar las reglas ejecutando:
hayabusa-2.19.0-win-x64.exe update-rules
Yo voy a escoger un perfil super-verbose. Vosotros podéis revisar cada uno de ellos y ver cual os interesa ejecutando:
hayabusa-2.19.0-win-x64.exe list-profiles
Cada uno incluye más o menos columnas de información. Por cierto aprovecho para comentar también que una cosa muy interesante de Hayabusa es que ofrece compatibilidad para exportar resultados para Timesketch del cual hablaremos en otras entradas en el futuro.
A mi me interesa obtener un timeline en formato CSV en este caso. No voy a entrar en el detalle de cada opción disponible para el comando csv-timeline pero si os diré que se puede obtener un timeline sobre un fichero .evtx en concreto o sobre un directorio con varios .evtx. Adicionalmente, también se puede ejecutar sobre un sistema en vivo aunque yo recomiendo hacerlo en caso de respuesta a incidentes sobre un triage. Eso si, no me meto en la situación concreta de cada uno.
Existen opciones para realizar filtrados sobre los eventos, ejecutar solo ciertas reglas, opciones de formato salida, formatos de fecha, etc. De hecho, dos muy interesantes en cuantos a filtrado de eventos son:
--timeline-end <DATE>
--timeline-start <DATE>
Si conocemos más o menos el rango temporal en el que se ha producido el incidente podemos tener más eficiencia y filtrar eventos no necesarios.
Yo la ejecutaré con el siguiente comando:
hayabusa-2.19.0-win-x64.exe csv-timeline -d "C:\Users\Adrian\Downloads\hayabusa-sample-evtx-main\EVTX-ATTACK-SAMPLES\Lateral Movement" -p super-verbose -U -o resultadosHayabusa.csv
Para el artículo he usado unos eventos ejemplo del repositorio: https://github.com/Yamato-Security/hayabusa-sample-evtx. En concreto he escogido un paquete con ejemplos de ataque de movimiento lateral. Mi comando incluye la opción -U para obtener la fecha en formato UTC y la opción -o para indicar el nombre del fichero con los resultados.
Al pulsar enter, la herramienta solicita indicarle una opción de escaneo basado en los estados de regla y niveles de criticidad de estas. Os recomiendo ejecutar siempre la última opción «All event and alert rules» salvo excepciones. Posteriormente siempre se pueden filtrar los resultados.
Tras seleccionar la opción, la herramienta indica si se quiere hacer uso de reglas desactualizadas, no soportadas, ruidosas o para Sysmon. Mi opinión es:
- Deprecated: no
- Unsupported: no
- Noisy: yes
- Sysmon: siempre que haya eventos .evtx de sysmon si, en caso contrario, no.
Resultados
Tras finalizar el proceso de ejecución, ofrece unos resultados a modos estadística que conviene revisar. Ya de entrada te puede dar información muy útil para agilizar la investigación. Ofrece información sobre que nombres de equipos o host aparecen mayormente sobre los eventos, fechas con mas detecciones y un resumen estadístico de las alertas más relevantes.
Una vez tenemos el fichero .csv con los resultados ya se puede comenzar con el análisis. Mi recomendación es ocultar aquellas columnas que no se vayan a utilizar y ordenar todo por fecha en orden ascendente, es decir, de mas antiguo a más reciente. A partir de esto, dirigirse a momento temporal aproximado del incidente y comenzar a filtrar desde las alertas más criticas a las menos relevantes. Otra opción ideal es pintar de colores las alertas por nivel de criticidad con el objetivo de visualizar de manera directa los momentos temporales más relevantes donde se han hallado más eventos sospechosos.
Os dejo un ejemplo de como lo he hecho:
Conclusiones finales
Lógicamente no todos los eventos detectados estarán relacionados con actividad maliciosa del incidente. Es por esto que comentaba anteriormente que no es la panacea. No obstante, es una herramienta que es fundamental para realizar un filtrado ágil que nos ayudará como analistas DFIR a complementar nuestra tarea manual de análisis de eventos de Windows. Hay que recordar que los eventos de Windows son artefactos fundamentales donde se pueden encontrar gran cantidad de evidencias para poder completar una investigación de un incidente de seguridad.
En definitiva, esta herramienta ya forma parte mi arsenal personal a la hora de enfrentarme a la investigación y análisis en un incidente de seguridad.
Hasta la próxima 😘
