Del Log al Threat Hunting

La búsqueda proactiva de amenazas (también llamada Threat Hunting) es un proceso fundamentalde cualquier estrategia de ciberseguridad que se considere madura. En pocas palabras implica labúsqueda activa del atacante dentro de nuestra infraestructura antes de que puedan causar algúndaño.

Dentro de los ambientes de TI, se ejecutan tareas y programas, a veces generan cambios en el ambiente, o solo hacen uso de los recursos de red (por ejemplo), todos esos eventos son capturados por las diferentes aplicaciones y reflejados como rastros en forma de una línea de texto en un archivo de log, un evento del SO, un paquete de red capturado, o como hemos analizado anteriormente en forma de DataFlow (Post anterior). Haciendo una abstracción, podemos decir que esos rastros son la unidad mínima dentro de la caza de amenazas.

Una estrategia de detección de amenazas eficiente intentará responder preguntas sobre esas fuentes de datos de detección. Decidir QUÉ datos de detección capturar, CUANDO capturarlos, DONDEcapturarlos, por CUANTO tiempo retenerlos son algunas de las piezas que nos ayudarán a construir la mejor implementación de este proceso de threat hunting.

En esta publicación, exploraremos cómo es que pasamos de un puñado de registros y distintos tipos datos a una ingeniería de detección y el diseño de analíticas para detectar comportamientos maliciosos.

Sobre la detección

Entendemos que la detección de los distintos eventos en sus diversos formatos es la herramienta que nos permite encontrar una amenaza. Es por esto que haremos hincapié en obtener la mejor de las detecciones.

Alertar ante la conexión de un dispositivo desconocido en la red basado en la observación de en un listado de direcciones IPs (registrados anteriormente como válidas) parece ser un método de detección eficaz (y lo es), pero implica la posibilidad de generar montones de falsos positivos (alertas que no son de interés). Hablamos aquí de la precisión de la detección.

Por otro lado sí pensamos en una detección basada en firmas, podemos estar seguros, de que prácticamente todas las alertas que recibamos serán consideradas de interés y representarán conclaridad una amenaza. Aunque de esta forma existen montones de otras situaciones de riesgo que no se encontrarán comprendidas en las firmas por lo que no serán detectadas. Generamos aquí montones de falsos negativos, hacemos referencia entonces a exhaustividad de la detección (o “recall” en inglés)

Podemos definir estos aspectos en un diagrama tomando como referencia la detección de correos de spam siendo los rojos los correos de spam y los verdes correos legítimos:

Mejorar la exhaustividad de nuestras detecciones nos permitirá “No dejar comportamiento malicioso afuera” y la precisión nos permitirá “No alertar por error ante eventos válidos”.

Adicionalmente, encontramos en la detección algunas categorías típicas que debemos resaltar antes de avanzar sobre una de estas.

Detección basada en Firmas: En esta detección generalmente hacemos uso de los IoC (Indicadores de Compromiso) como direcciones IP maliciosas, hashes de archivos o cadenas de caracteres contenidas en binarios. Conjuntos de elementos que específicamente se han encontrado en incidentes previos.

Esta detección cuenta con una excelente precisión, pero muchas veces estamos a un bit de quedar con una firma desactualizada.

Detección basada en Anomalías: Este tipo de detección parte de “definir una normalidad” en el entorno como un listado de aplicaciones, listados de equipos, tipo de tráfico en la red, eventos esperados, y monitorear las diferencias que haya contra este “estado normal”. Todo lo que se encuentre “fuera de lo normal” se considerará malicioso.

Este tipo de detección puede encontrar un comportamiento malicioso previamente desconocido, por otro lado no es fácil de sostener estos patrones de “normalidad”, los comportamientos válidos en un entorno suelen cambiar (como todo).

Detección basada en comportamiento: Sobre este tipo de detección basaremos la detección en el comportamiento que generalmente se considera malicioso sobre el entorno particular en donde se realiza la detección. Podemos pensar por ejemplo

No importa si un cibercriminal utiliza tecnología y habilidades de última generación, o si utiliza malware escrito en go, python o assembler, su ataque dependerá 100% de nuestras debilidades. Eso nos da una ventaja.
No podemos entonces avanzar entonces en este camino de detección sin recorrer la Pirámide del dolor de David Bianco, en donde esquematizamos desde la base hasta la punta como aumenta para el adversario la dificultad de reemplazar un elemento dentro de un ataque:


De la detección al entendimiento

Generalmente, en relación con la caza de amenazas, se nos viene a la mente “Buscar una aguja en un pajar” pero a diferencia de esta última, el threat hunting puede mejorarse, con una metodología dar una respuesta más efectiva, la experiencia acorta sus tiempos.

Tomemos como referencia el siguiente caso:

El “Visor de eventos de Windows” al abrirse se ejecuta a través de la consola de administración de Microsoft (MMC Microsoft Management Console), esto implica una ejecución en un contexto de altos privilegios. Adicionalmente, el “visor de eventos de windows” es un software que al ejecutarse intenta en primera instancia hacerlo basado en una configuración de la clave de registro ubicada en HKCU\Software\Classes\mscfile\shell\open\command al no detectarse esta clave se ejecuta según la configuración de HKCR\mscfile\shell\open\command.

El lector atento se preguntará:

¿Qué es lo que sucede si dentro de esa clave, que se encuentra al alcance del usuario (CURRENT_USER), se introduce un valor como C:\Users\Documents\TrustMeImNotAMalware.exe?
Hagamos la prueba, intentamos acceder a la clave y modificar su valor. En nuestra prueba, el resultado de esta simple prueba no parece haber sido efectivo, incluso notamos un problema en el editor de registro, intentamos ejecutar como usuario estándar, incluso como usuario administrador. El editor se cerraba abruptamente al aplicar un nuevo valor a esta clave.

Pocos minutos después y sin haber encontrado aún registros sobre esta situación, el equipo del SOC se pone en contacto para consultar acerca de un comportamiento sospechoso desde la terminal en la que estábamos realizando la prueba, una alerta referenciando a una táctica de Escalación de Privilegios:


La pregunta entonces para empezar a definir el proceso de caza de amenazas es:

¿POR QUÉ se estaba monitoreando este comportamiento?
La pregunta, aunque parece trivial, requiere saber que no es posible de ninguna manera recolectar todos y cada uno de los cambios, o eventos que ocurren en un grupo de dispositivos dentro de una Organización. Ya sea por una cuestión técnica o una cuestión de recursos asociados, siempre algo estará “fuera del radar”.

Por otro lado, el CÓMO podemos entenderlo rápidamente haciendo un pequeño análisis, la modificación en esa clave de registro genera algún tipo de rastro, ya sea en la propia modificación del valor o en algún archivo de registro, ese rastro es tomado (por una solución de EDR en este caso), y contrastado con una técnica, la cual corresponde con un comportamiento, este comportamiento es el que llamamos generalmente “Táctica”, y puesta dentro de un contexto es la forma en la que responderemos el PORQUÉ.

Detectamos entonces eventos, pero alertamos sobre comportamientos
Metodología de MITRE
Para darle forma a todo el proceso de caza de amenazas, es que tomaremos una metodología. El equipo de MITRE Engenuity nos comparte para esto una serie de etapas en donde comenzaremos con la comprensión de la “Actividad maliciosa” para decantar luego en elementos concretos para la ejecución de detecciones concretas.

Comenzando desde arriba hacia abajo sobre esta metodología, para poder detectar actividad considerada maliciosa dentro de entorno debemos entender esa actividad. Entender entonces ese modelo de amenazas nos ayuda a darle forma por ejemplo haciendo uso de MITRE ATT&CK. Tomando como referencia el caso anterior podemos decir:

“Un adversario podría mejorar sus privilegios de ejecución dentro del entorno afectado para causarmayor impacto”
Avanzando y para lograr un correcto análisis y entender que detectar es que desarrollamos hipótesis que puedan ser confirmadas a partir de la implementación de un comportamiento. Siguiendo con el caso anterior:

“Si la clave de registro correspondiente al comando del visor de eventos de Windows dentro del registro del usuario se modifica, un adversario está realizando una elevación de privilegios”
Ya por debajo en el ángulo de nuestra V metodológica nos encontramos bien cerca de los datos, ¿Qué datos debemos recolectar para validar las hipótesis? Es ahí en donde respondemos una pregunta anterior para nuestro ejemplo:

“Evaluamos los valores de una clave de registro en particular, para detectar un comportamiento de Escalación de privilegios”
Desde otra mirada y analizando nuestra V, de izquierda a derecha podemos encontrar a la izquierda las acciones de entendimiento, investigación y planificación alrededor de la caza de amenazas, un proceso muchas veces realizado “en el papel”, aquí encontramos descripciones de comportamiento, hipótesis de detección y requisitos de datos.

Del lado derecho en cambio empezamos a ir cuesta arriba en el proceso de “caza” propiamente dicho, Identificamos los datos necesarios, confirmamos las hipótesis y hacemos la detección de las amenazas (o no). Recién aquí es que encontraremos todas las herramientas, software, soluciones, SIEMs, EDRs, IDS, etc.

En la práctica, esta metodología no es aplicada de forma lineal, se realizan múltiples iteraciones en distintos sentidos siempre tomando en cuenta los resultados de cada paso. La metodología llevada adelante de la mano de un experto podría tener múltiples retroalimentaciones basadas en nuevos hallazgos para cada ejecución.


Existen desde hace años algunos modelos más o menos difundidos para realizar caza de amenazas, aún así todos comparten la necesidad de comprender que es lo que sucede “del otro lado” para poder tomar medidas “de este lado”.

La caza de amenazas como una implementación de ciberdefensa activa nos permite no solo detectar al adversario, sino también generar mejores métodos para pasar cuanto antes de la detección a la erradicación.

En nuestras próximas entregas estaremos explorando las distintas formas de “hipótesis” para la detección y analizaremos algunas TTPs (Tácticas, Técnicas y procedimientos) bajo los lentes de esta metodología de caza de amenazas.