Threat hunting (I): cazando sin salir de casa

Muchas veces, hablando con amigos que se dedican a otras profesiones, les comento la gran suerte que tenemos los que nos dedicamos a la informática. Nosotros, a diferencia del 99% de las profesiones, podemos crear entornos realistas para hacer pruebas, aprender, practicar… y cuando terminamos con esos entornos podemos destruirlos y el gasto de material habrá sido cero. ¡Cuánta suerte tenemos!

A los que nos apasiona la seguridad informática aún tenemos más suerte; desde sus inicios la comunidad de la ciberseguridad se ha caracterizado por su defensa de la libertad de la información, el software libre y el aprendizaje colectivo, lo que ha hecho que estemos en el mejor momento de la historia para aprender sobre ciberseguridad.

En este caso, quiero hacer una guía para poder construir un laboratorio de Threat Hunting desde casa y a coste cero (sin contar en la inversión de nuestro equipo).

Antes de ponernos manos a la obra, vamos a hacer una breve introducción sobre el Threat Hunting, es importante asentar bien los cimientos de nuestro laboratorio.

1. ¿Qué es el Threat Hunting?

Una vez escuché que si quieres saber que es el Threat Hunting y preguntas a tres expertos, tendrás cuatro opiniones diferentes sobre qué es y qué no es el Threat Hunting. Dentro de la modernidad de la ciberseguridad, el Threat Hunting es de las disciplinas más recientes y eso hace que tanto las empresas como los investigadores lo afronten de una manera diferente.

En lo que todos están de acuerdo es que las empresas tardan mucho tiempo en descubrir que han sido vulneradas, y se viene utilizando la cifra de seis meses de media entre que son vulneradas y se descubre el incidente. ¿Por qué tanto tiempo para descubrir una intrusión? Podríamos estar hablando horas sobre esto, sobre si los antivirus están preparados para hacer frente a las amenazas modernas, sobre si los administradores de sistemas están lo suficientemente preparados o incluso si debería ser o no su responsabilidad el defender a la organización… pero no.

Una de las cosas que caracteriza al Threat Hunting es el cambio en el paradigma de una investigación.

La seguridad convencional parte de la base de que la organización está a salvo y el trabajo es mantenerla a salvo con la creación de reglas, ya sean sobre un hash de un fichero, una dirección IP, un acceso a una ruta, un comando… la mayoría  de las veces para controlar que nadie entre en la organización. Cuando son cruzadas con los eventos de un sistema, esta reglas generan alertas que un analista evalúa si son o no falsos positivos.

En el Threat Hunting se trabaja de otra manera. Partimos del supuesto de que alguien ha utilizado cierta técnica en la organización y nuestro trabajo es comprobar por todos los medios posibles si estamos en lo cierto o no. Hemos introducido el concepto “técnica”, que nos lleva los tan mencionados actualmente TTPs (Tácticas, Técnicas y Procedimientos). Este es un tema en el que no nos adentraremos por el momento, pero por supuesto os invito a pasar por la página de Mitre ATT&CK y descubrir este maravilloso proyecto.

Cómo os podréis imaginar, técnicas hay cientos y por cada una de ellas, varias maneras de detectarlas o varias fuentes de información que podremos utilizar para detectarlas.

Aunque hay muchos acercamientos posibles al Threat Hunting, en esta serie de artículos nos vamos a centran en dos grandes vertientes, la basada en el análisis del tráfico de red y la basada en análisis de eventos en los equipos. Ya tenemos algunos conceptos claros así que vamos a ir poniéndonos manos a la obra-

2. Los eventos

Windows recoge muchísima información en forma de eventos por defecto y mucha otra que podemos configurar. Para trabajar con ellos, Windows ofrece la herramienta “EventVwr” o “Visor de Eventos”. Vamos a mencionar rápidamente los tipos de eventos más interesantes desde el punto de vista del Threat Hunting.

Security Logs

Quizá uno de los más importantes que podemos analizar. En estos eventos queda registradas muchísimas acciones de los usuarios, programas y servicios que ocurren en el equipo. Disponemos desde eventos relacionados con ficheros a permisos especiales asignados a un login. Aquí os dejo un enlace con una lista de eventos que es muy útil tener cerca.

Powershell

Para encontrar estos eventos, será necesario buscarlos en la ruta “Registros de aplicaciones/Microsoft/Windows/Powershell/Operational”.

Aquí podremos ver algo de información, pero para poder ver toda la información posible de cada sesión de PowerShell será necesario activar el “PowerShell Transcript”. Esto permitirá no solo conocer los comandos ejecutados en Powershell si no las respuestas de dichos comandos. Os dejo aquí un enlace a un tutorial de Powershell para activarlo.

Sysmon

He aquí la joya de la corona. Sysmon es un proyecto dentro de la suite Sysinternals. Está compuesta por un driver y un servicio, el driver es el encargado de monitorizar el equipo esperando ciertas llamadas al sistema y cuando las detecta, genera eventos.

Cualquiera podría pensar que si ya tenemos los eventos del propio sistema, ¿Por qué generar nuevos eventos? Los eventos nativos de Windows son demasiado diversos y en muchas ocasiones es muy tedioso trabajar con ellos; sin embargo Sysmon ofrece en la actualidad 23 tipos de eventos, haciéndole el trabajo mucho más sencillo al analista.

Os dejo el enlace a la documentación de Sysmon donde se habla de todos los eventos.

3. El laboratorio

Aunque como hemos mencionado anteriormente hay dos acercamientos al Threat Hunting, el basado en el análisis de tráfico de red y el basado en los eventos del equipo, nos vamos a centrar inicialmente en el segundo y para ellos vamos a instalar el proyecto HELK.

HELK

HELK es un proyecto desarrollado por Roberto Rodríguez y basado en la arquitectura de Elastic Seach, Logstash y Kibana, aunque es mucho más que eso, como se puede apreciar en la imagen.

Para la instalación del laboratorio necesitaremos una máquina Linux, preferiblemente Ubuntu, y dependiendo de las características que queramos en nuestro laboratorio con unas especificaciones u otras. Pero antes vamos a hablar de qué funcionalidades ofrece para saber elegir posteriormente.

Kafka y KSQL

Este es un sistema de recepción de información, especializado en la concurrencia y en la tolerancia a fallos; permite que nuestro laboratorio pueda recibir información de multitud de equipos sin que ello suponga un problema. También servirá para la añadir información de datasets, pero de eso hablaremos más adelante.

KSQL es la tecnología que permitirá consumir los datos de Kafka.

ELK

Elastic Search, Logstash y Kibana. Cada vez es más difícil no montar una arquitectura como esta en un proyecto y cada vez más proyectos de software libre se basan en ella.

• ElasticSearch es una base de datos no relacional; su mayor potencia reside en el indexado de grandes cantidades de datos, su arquitectura distribuida y su API.
• Logstah es el encargado de preparar los datos para ser almacenados en ElasticSearch: los agrupa, los organiza, los enriquece… todo es posible en logstash.
• Kibana es la parte visual de esta arquitectura; desde ella podremos crear consultas y visualizaciones sobre nuestros datos.

Elastalert

Elastalert permite la creación de reglas sobre los datos que tenemos en ElasticSearch y poder generar alertas de multitud de tipos, hablaremos de él más en detalle.

Spark y Jupyter

Spark es un framework que permite ejecutar Jupyter playbooks y que permitirá generar playbooks con la inteligencia que saquemos de nuestras investigaciones. Trabajaremos con ello también más adelante.

4. Instalación

Una vez que conocemos las partes más esenciales del proyecto vamos a hablar de las diferentes modalidades de instalación que permite HELK.

Para comenzar con la instalación descargaremos el proyecto de Github con Git y ejecutaremos el instalador.

git clone https://github.com/Cyb3rWard0g/HELK.git

…

cd HELK/docker

La instalación se realiza en contenedores Docker, pero no tenemos que preocuparnos por ello, HELK lo instalará si no lo tenemos. Vamos a realizar una modificación en un fichero de configuración para después poder trabajar con Grafiki más cómodamente.

Durante este tutorial vamos a instalar la opción completa de HELK, así que necesitaremos modificar el fichero “helk-kibana-notebook-analysis-alert-basic.yml” en la ubicación “HELK/docker”.

En la línea 20, añadiremos la configuración para que el puerto 9200 quede abierto al exterior del contenedor de Docker. Debería quedar así:

Una vez modificado este detalle procederemos con la instalación.

sudo ./helk_install.sh

El script de instalación preguntará que opción de instalación queremos y elegiremos la opción 4. Recordad que la máquina de instalación tiene que tener más de 8GB de RAM. Después preguntará por la IP que queremos en la instalación, en nuestro caso elegiremos la que viene por defecto, y preguntará por una contraseña que permitirá acceder a Kibana y esperaremos hasta que la instalación se termine. Cuando termine dirá algo como esto:

Guardad estos datos en un lugar a mano porque harán falta más adelante.

¡Ya tenemos nuestro panel de investigaciones desplegado! Y ahora que ya disponemos de una plataforma para almacenar los datos hay que conseguir datos… pero eso lo veremos en la próxima entrada.