¡Estimados amigos de Visionarios!
En el episodio de hoy, seguimos con la serie de Azure Sentinel ( 1,2,3,4,5 y 6 ) esta vez con el episodio 7, hablando del conector syslog para Logstash.
Cuando hace ya bastantes meses, años ya, decidimos valorar la opción de migrar nuestra infraestructura favorita SIEM de Splunk y ELK hacía el sistema de Microsoft una de las cosas que más nos preocupaba era la migración de los sistemas existentes.
Tener un catálogo de datasources “on the box” es algo que se agradece. No tener que estar picando código para parsear, o directamente, depende de un agente cerrado que transporte los logs es algo impensable en entornos complejos.
Contar con el datasource de Logstash fue algo tranquilizador, ya que podríamos usarlo de capa intermedia para todo de transformaciones y despliegues en los que ya usábamos FileBeat como agente para ELK.
No es mi intención probar todos los data connector disponibles, pero para cierto proceso de formación interna hemos tenido que usarlo, y es por esto del artículo 🙂
Os pongo en situación. Imagina un proceso de Purple Team habitual, en el que generamos un ataque sobre un sistema, generamos eventos, los guardamos en un fichero EVTX de eventos de Windows para poder cargarlo en otros equipos y poder hacer un training de la detección. Nosotros lo llamamos “hacer ruido”. Ya sabes, para probar la detección del ataque… si no realizas el ataque… Ya se habló de este asunto largo y tendido en el post de mi amigo Rafa Martínez de visionarios que podéis leer aquí.
Lo primero que debemos hacer es un Clear-WinEvents para limpiar la rama o ramas que nos interesa.
Ejecutamos el proceso ofensivo.
Ahora podemos acceder gráficamente a un evento o eventos y guardarlos, o hacerlo por línea de comandos wevtutil epl System C:\system.evtx
Hasta aquí ya tenemos los eventos generados, los ataques, lo podemos usar para un reto forense, entrenamiento, evidencias, lo que sea. Ahora ¿como me lo llevo a Azure Sentinel? Si yo cargo el fichero Evtx en el visor de eventos, lo hace en la rama Registros guardados, y el agente de Sentinel no reconoce esa rama para importar los datos.
Aquí echamos en falta un servicio syslog para poder exportar estos datos, pero en Windows no existe. Si usamos alguna alternativa como Syslog-NG ocurre lo mismo, no podemos “exportar” la rama Registros Guardados, solo las clásicas del sistema.
Necesitamos una manera de importar el fichero Evtx en Azure Sentinel. Para ellos vamos podemos usar Winlogbeat, el agente para ELK y el transporte de logs, pero tenemos un problemita, y es que el output de winlogbeat del tipo syslog no está disponible en Windows… hay que chutarlo a un logstash, y desde logstash si podemos “chutarlo” a Azure Sentinel… Se complican las cosas con la informática como siempre 🙂
Como sabes, logstash es el complemento del stack ELK que se encarga de la transformación de los datos, y no tiene porque tener como output un Elasticsearch…así como tampoco tiene que tener de input winlogbeat… podemos tener json, csv…etc…
Voy a usar un script del señor Sbousseaden que hace la llamada del winfilebeat de una ubicación recursivamente, es decir, si tenemos varios Evtx en un directorio los ingesta todos. Además, en el mismo proyecto tiene un increíble dataset de ficheros Evtx ya listos para nuestro uso y disfrute. El trabajo de este tipo es brutal.
Usar Winfilebeat pasándole un Evtx es algo trivial.
El procedimiento es sencillo, bajo winlogbeat, bajo el script de carga masiva, configuro el fichero winlogbeat para decirle que lo vuelque a logstash y listo
.\Winlogbeat-Bulk-Read.ps1 -Exe “c:\winlogbeat\winlogbeat.exe” -Config “C:\winlogbeat\winlogbeat.yml”-Reset -Verbose
Mi fichero Winlogbeat.yml es muy sencillo, solo añado:
winlogbeat.event_logs:
– name: ${EVTX_FILE}
no_more_events: stop
y
output.logstash:
enabled: true
hosts: [‘192.168.1.102:5044’]
Hacemos un resumen.
1.- Generamos un ataque que produce eventos.
2.- Los guardamos en formato EVTX
3.- Lanzamos estos ficheros contra winfilebeat.
4.-Winfilebeat los lanza contra logstash.
Ahora falta instalar logstash con un siguiente siguiente ( se baja un zip).
Cargamos un plugin que hace que logstash tenga como salida Azure Sentinel, y no el clásico ElasticSearch.
logstash-plugin install microsoft-logstash-output-azure-loganalytics
En mi caso ejecuto logstash con esta sentencia: .\bin\logstash.bat -f .\config\logstash.conf
En el fichero de configuración establezco el id y la key del workspace Azure Sentinel.
Si sigues un poco este blog, sabrás que meter una “clave” como es el workspace_key es un fichero no es una buena práctica de seguridad, pero para este escenario en el que el blue team es el encargado de realizar las pruebas, y la instancia Azure Sentinel es de pruebas, no me he complicado la vida. No obstante, el propio Logstash tiene un sistema de “vault” para gestionar estas claves, puedes leer como usarlo aquí.
Si todo ha ido bien, tendremos una nueva tabla en Azure Sentinel con nuestros eventos reproducidos.
Algunos repositorios con dataset de seguridad en formato Evtx:
https://github.com/mdecrevoisier/EVTX-to-MITRE-Attack
https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES
https://github.com/sans-blue-team/DeepBlueCLI/tree/master/evtx
https://github.com/splunk/botsv1
Existe otro proyecto de los hermanos Rodríguez.
https://securitydatasets.com/introduction.html
- Roberto Rodriguez @Cyb3rWard0g
- Jose Luis Rodriguez @Cyb3rPandaH
El antiguamente denominado Mordor. Es un proyecto más completo que no solo ofrece dataset ya grabados, sino que nos ofrece los scripts para generar los eventos.
Por poner alguna pega, o más bien diferencia, el proyecto guarda los eventos en formato json, por lo que tenemos que usar sus propios scripts para la ingesta en logstash los eventos, y desde ahí a Azure Sentinel.
Si tu equipo de purple team tiene claros los dos procesos, el de ingesta mediante Evtx y formato Json, el resultado es que podrás tener toda la “inteligencia” ya generada por la comunidad con ejemplos de eventos, y así poder agilizar el proceso de pruebas de las reglas del siem etc.
No obstante, no quiero decir con esto que debamos prescindir de realizar internamente el proceso Red Team de generar el ataque, ya que de esta manera no solo tenemos los eventos, sino que adquirimos un conocimiento vital a la hora de dar soporte al incidente. No solo se trata de detectarlo con una regla en el SIEM, sino de crear un procedimiento de respuesta apropiado, y si no has generado el “ruido”, es más complicado.
¡Sigue Aprendiendo!
Si quieres que te ayudemos a poner en marcha este tipo de proyecto, no dudes en contactar con nosotros. También puedes aprovechar las formaciones existentes para ampliar tus conocimientos 👇🏼
>> Más info
