Threat Hunting, pero… ¿De dónde y qué? — Collection Management Framework
TL;DR
A menudo los equipos de DFIR debemos de realizar acciones de threat hunting para identificar comportamientos anómalos de manera proactiva en nuestras redes o de clientes. Sin embargo, en muchas ocasiones no sabemos donde buscar o directamente desconocemos que tecnologías tenemos para recabar dicha información.
Un Collection Management Framework (CMF) nos puede ayudar en estas situaciones. Este se basa en qué información nos da cada data source y cuales de estas fuentes están disponibles para hacer hunting.
Objetivo
Antes de comenzar a hablar sobre qué es el CMF, es importante explicar de manera resumida que es aquello que llamamos threat hunting, ya que la principal labor del CMF es apoyar a esta labor.
Threat hunting es aquella actividad que tiene como meta descubrir de manera proactiva actividad maliciosa de un actor o grupo de actores tras la generación previa de hipótesis. Debido a que es un proceso complejo, existen diferentes modelos de madurez para llevarlo a cabo.
Sin entrar mucho más en detalle del threat hunting porque no es el objetivo, se puede ampliar más información sobre esta actividad y en que consiste cada grado de madurez en la siguiente entrada de Sqrrl.
Dicho esto, las organizaciones deben de ser capaces de generar un CMF sobre aquella tecnología que disponen y que el equipo de threat hunting puede consumir para identificar amenazas en la red. De lo contrario, descubrir amenazas será una tarea tan fatigosa que el equipo no podrá conseguir los requerimientos de inteligencia que les hayan demandado.
Un CMF debe de ser capaz de responder a muchas de las preguntas que los threat hunters se hacen durante su actividad como por ejemplo:
- De donde obtengo los datos para hacer hunting?
- Qué datos están disponibles?
- Durante cuanto tiempo son almacenados dichos datos?
- Cómo puedo consumir los datos?
Flujo de trabajo
En muchas ocasiones, por no decir prácticamente en todas, para llevar a cabo la actividad de threat hunting es necesario saber qué es lo que vamos a buscar. Para ello, se puede generar hipótesis y trabajar en base a ellas. Sin embargo, para poder generar las hipótesis, debemos de conocer las amenazas a las que nos enfrentamos.
Si no seguimos lo último comentado, estaremos buscando algo que nosotros mismos desconocemos sobre cualquier amenaza genérica que podría no llevar un riesgo para la compañía.
Sirviendo como ejemplo, un posible flujo para llevar a cabo actividades de threat hunting de manera correcta con objetivos definidos sería el siguiente:
En primer lugar, es importante conocer nuestros adversarios y priorizar aquellos que puedan tener más actividad y motivaciones sobre el sector que opera la organización, ya que estos suponen más riesgo. Este trabajo es realizado por los equipos de Cyber Threat Intelligence.
Algo que puede ayudarnos en este caso es un Threat Modeling, consiguiendo ver de manera estructurada aquellos potenciales grupos que pudiesen tener interacción en algún momento con nosotros. Más información del threat modeling aquí.
Alguna de la información que obtendremos en la fase de conocimiento sobre el adversario podría ser la siguiente:
TTPs
Tácticas, técnicas y procedimientos utilizados por el actor o grupo de actores que pretendemos realizar actividades de hunting posteriormente.
Conseguir esta información a bajo nivel ayudará después a las siguientes dos fases, por ello, es extremadamente recomendable mapear las tácticas y técnicas con la base de conocimiento de Mitre ATT&CK en cualquiera de sus variantes (Enterprise, Mobile y PRE), además, acaban de lanzar una beta que incorpora sub-técnicas muy completa, más información sobre esto aquí.
Tradecraft
Cuando hablamos de tradecraft nos referimos a las técnicas, métodos y tecnologías usadas por un adversario durante una intrusión. Aunque pueda parecer muy similar a los TTPs, el tradecraft da otra visión diferente más específica, sin embargo los TTPs nos abstraen en parte del comportamiento.
Un ejemplo de tradecraft podría ser cuando hablamos de que un adversario utiliza spearphishing con un documento Word adjunto y macros embebidas. Tras la descarga y ejecución posterior, dropea un RAT de la familia FlawedAmmyy.
Todo esto mencionado anteriormente, si hablásemos de TTPs, quedaría en las tácticas y técnicas de MITRE a alto nivel, sin entrar en detalle de familias.
Malware
Se trata de todas las capacidades maliciosas desarrolladas por el actor o en su defecto, reutilizadas de otras ya existentes. Conocerlas es importante, ya que posteriormente ayudará en la generación del escenario y ejecución por parte de un red team. También es posible extraer tácticas y técnicas del malware de manera individual.
Software
Al igual que el malware, cuando nos referimos a software, hablamos de aquellas capacidades que los actores utilizan durante su intrusión pero que no es considerado como malware, ya que muchas de estas capacidades se tratan de funcionalidades que incorporan los sistemas operativos a día de hoy (LOLBINs). Para que quede claro esta categoría, un ejemplo podría ser wscript.exe o cmd.exe.
La generación de hipótesis en base a los adversarios seleccionados sería la siguiente actividad que debería de realizarse y, al igual que en el caso anterior, es responsabilidad del equipo de Cyber Threat Intelligence.
Una vez eres capaz de conocer cuales son tus adversarios, que TTPs llevan a cabo durante sus operaciones, que malware y/o software utilizan y que motivaciones y objetivos persiguen, tienes la capacidad de generar un escenario para llevar a cabo contra tu organización.
Estos escenarios pueden ser muy similares a campañas que hayan ejecutado en el pasado, pero sobre todo, deben de ser realistas de cara a que el red team puede emularlos de manera satisfactoria.
Toda esta información debería de quedar recogida en un reporting que será posteriormente entregado al equipo de red team para ejecutarlo, justamente en la siguiente fase que es la de ejecución de escenario.
Hoy en día existen muchas herramientas que permiten facilitar la tarea de emulación de escenario y detección de manera automatizada. Desde productos de pago como Cymulate hasta herramientas open source como Caldera y Mordor pueden ayudarnos en este caso.
Toda ejecución que se realice estará bajo la responsabilidad del equipo de red team, el cual es el encargado de llevar a cabo las operaciones para posteriormente poner a prueba al equipo de threat hunting de cara a la detección.
Por último, nos encontramos en la fase de hunting, donde el equipo debe de identificar actividades maliciosas que se han llevado a cabo en la red con el apoyo de un CMF generado previamente, consiguiendo de esta manera saber donde obtener la información que buscan y que tipo de información es.
Las actividades de hunting están completamente ligadas a defensas activas y, es importante saber que existe un factor muy significativo aquí, siendo el humano, lo que quiere decir que automatizar esta fase por completo no es posible, sin embargo, si que hay ciertos aspectos que pueden ayudarnos como puede ser por ejemplo una alerta generada por IDS, lo que podría desembocar en un proceso de hunting posterior.
Collection Management Framework (CMF)
Llegados a este punto, es hora de empezar a trabajar en un CMF para poder facilitar la vida al equipo de threat hunting. Este trabajo debe de ser el resultado de una colaboración entre diferentes departamentos como pueden ser telecomunicaciones, sistemas, arquitectura, seguridad… Dependiendo de cada organización, existirá mayor o menor colaboración de equipos por las operaciones que llevan en su día a día.
El principal objetivo de trabajar en el CMF es poder tener censado todas las tecnologías desde las cuales, se puede obtener información para realizar actividades de threat hunting y detectar actividades sospechosas.
Tal y como se ha comentado antes, es importante que el CMF pueda responder a preguntas como:
- De donde obtengo los datos para hacer hunting?
- Qué datos están disponibles?
- Durante cuanto tiempo son almacenados dichos datos?
- Cómo puedo consumir los datos?
Para ello, definiremos primero que información nos interesa conocer por cada data source disponible en la organización para hacer hunting. Lo bueno de esto, es que podemos adaptarlo a nuestras necesidades e incorporar o eliminar campos que no nos interese.
- Tipo de datos
- Fase del kill chain que cubre
- Colección de observable
- Tiempo de almacenamiento de datos
- Lugar de almacenamiento de datos
- Departamento que lo gestiona
- Data set
- Categoría
Definidos los puntos que vamos a rellenar por cada data source, es hora de que empecemos a identificar aquellas fuentes que durante una intrusión, pudiesen darnos información para poder buscar anomalías en la red de la organización. A modo de ejemplo para este post, nos vamos a centrar en los siguientes data sources:
- Firewall
- Sistemas Windows
- IDS
- Web logs
Definidos los campos que vamos a rellenar y los data sources, es hora de ponerse manos a la obra y realizar una simple tabla que pueda ayudarnos como la siguiente:
Simplemente con la información que hemos rellenado en la anterior tabla, podemos responder muchas preguntas en caso de que se lleve a cabo una intrusión.
En caso de que hayan explotado una vulnerabilidad de la aplicación web, sólo tendremos información para investigar 60 días atrás, todo lo que haya pasado después de esos días, el equipo de threat hunting no podrá satisfacer un requerimiento de inteligencia.
Por el contrario, si ha producido una intrusión en la red y establece algún tipo de comunicación con un C2, podríamos detectar ese comportamiento 90 días atrás en el mejor de los casos.
Otra información que la tabla puede darnos en este caso se trata de aquellas fases dentro del kill chain donde tenemos menos visibilidad. En este ejemplo, por el tipo de data sources que tenemos recogidos, si se produjera una infección en un sistema endpoint y realizase persistencia, tendríamos únicamente los logs de los sistemas de Windows para cubrir la fase de “installation”, ya que el resto de data sources no cubren dicha fase.
Hasta aquí, toda la información que hemos tratado puede ser integrada en una plataforma que la gente de Rabobank ha desarrollado llamada DeTTECT.
Tal y como dicen, el objetivo de la herramienta es ayudar a los blue teams en base a un scoring establecido en ATT&CK para identificar la calidad, visibilidad y detección que tiene una organización en sus data sources registrados. Llegados a este punto, con la información del CMF podríamos empezar a trabajar en esta herramienta.
Para entender mejor como funciona dicha aplicación, recomiendo ver la ponencia y presentación de Ismael Valenzuela donde pone ejemplos prácticos de DeTTECT.
LinkedIn: https://linkedin.com/in/joseluissm/
Referencias
Threat Hunting and Hunting Maturity Models — https://medium.com/@sqrrldata/the-cyber-hunting-maturity-model-6d506faa8ad5
Adversary Emulation Plans — https://attack.mitre.org/resources/adversary-emulation-plans/
Collection Management Frameworks — Beyond Asset Inventories for Preparing for and Responding to Cyber Threats — https://dragos.com/resource/collection-management-frameworks-beyond-asset-inventories-for-preparing-for-and-responding-to-cyber-threats/
