TL;DR
El proceso de threat hunting que existe actualmente puede ser utilizado en paralelo con otro llamado ciclo de vida de los indicadores.
Ambos ciclos se basan en lo mismo, teniendo como objetivo la detección proactiva de amenazas y comportamientos en la redes corporativas, dejando de lado el enfoque reactivo el cual cada vez más se intenta evitar.
Esto se debe a que los procesos de incident response tradicionales tienen una metodología basada en trabajar sobre un hecho que ha tenido lugar, cuando el ciclo de vida de los indicadores y el proceso de threat hunting lo hacen desde la perspectiva de trabajar para evitar que suceda algo.
Durante este blog explicaré el ciclo de vida de los indicadores y cómo puede utilizarse en paralelo con el proceso de threat hunting, exponiendo también un caso práctico al final.
Ciclo de vida de los indicadores
El ciclo de vida de los indicadores no tiene como objetivo definir cuanto tiempo un indicador es válido o no, ya que eso depende de una gran cantidad de variables no controladas por los analistas.
El enfoque que recibe este ciclo tiene como objetivo que a partir de ciertos indicadores, sean utilizados de manera proactiva para madurarlos y posteriormente, automatizar nuevas búsquedas que puedan revelar otros indicadores relacionados.
Aunque el concepto de manera inicial puede parecer un poco confuso, este ciclo tiene mucho sentido aplicarlo en actividades de threat hunting, ya que será en dichas actividades en donde se le pueda sacar el máximo valor.
Antes de entrar en detalle sobre la explicación de este ciclo, es importante conocer que tipo de indicadores son válidos para estas operaciones, ya que a día de hoy, el término indicador es demasiado ambiguo, no todo el mundo entiende lo mismo por indicador.
Personalmente, me resulta muy útil los tres conceptos diferenciados que exponen en el paper de Lockheed Martin Corporation. Dichos conceptos son los siguientes.
- Indicadores atómicos (atomic): Los indicadores atómicos son obtenidos en base al contexto de una intrusión que ha tenido lugar. El “problema” de este tipo de indicadores, es que no tiene por qué ser actividad exclusiva de un adversario en concreto, es decir, un indicador atómico puede ser identificado en varias intrusiones de diferentes adversarios. Algunos ejemplos de estos indicadores son direcciones IP, dominios, el nombre de un path de un dominio…
- Indicadores calculados (computed): El concepto de indicador calculado es bastante confuso. Estos indicadores son desarrollados a partir de atributos que tienen lugar en un incidente. Por ejemplo, un hash de un archivo que se ha visto en un incidente puede ser calculado, por lo que su MD5, SHA1… Son indicadores calculados. Otro ejemplo podría ser una expresión regular, la cual podemos desarrollar para detectar algo específico.
- Indicadores de comportamiento (behavioral): Estos indicadores están compuestos de una combinación de los dos tipos anteriores descritos. Por ejemplo, dentro de esta categoría podríamos declarar lo siguiente; “Los adversarios establecieron un C&C [IP y/o dominio del C&C] con el equipo comprometido por el malware [Hash MD5]. Las comunicaciones se ejecutaban en un intervalo de [Intervalo de tiempo] entre cliente y servidor. Podían identificarse mediante la búsqueda de la expresión regular [Expresión regular de identificación] en los logs del proxy.”
Como podrá imaginarse, este último tipo de indicador es el que más valor presenta, ya que tiene un contexto asociado de lo que ha sucedido y combina los indicadores atómicos y calculados. Además, es sencillo también extraer posibles técnicas y tácticas de MITRE para poder conocer mejor que acciones se están realizando.
Una vez conocemos los tipos de indicadores que podemos utilizar en el proceso del ciclo de vida de los indicadores, es momento de explicar cómo funciona dicho ciclo.
Consta de tres fases o etapas principales, siendo estas las fases de revelado, madurado y utilizado. Además, este proceso es indispensable que involucre personas, procesos y tecnología, lo que lo hace realmente dinámico y útil en diferentes operaciones, como por ejemplo el threat hunting.
Aplicando este modelo a nuestras actividades de threat hunting, nos va a proveer de las siguientes capacidades:
- Generar inteligencia de amenazas internas
- Implementar un proceso de pivoting estable
- Identificar nuevos indicadores a partir de otros indicadores
De revelado a madurado
Esta primera fase tiene como input diferentes fuentes. En la imagen anterior, se muestran algunas de las que podrían ser un origen de información para empezar el ciclo. Por ejemplo, reportes externo (o internos), fuentes de inteligencia, SIEM o cualquier otra herramienta de monitorización, como podría ser un IDS.
Las anteriores fuentes mencionadas llevarán consigo indicadores, los cuales, deben de ser sometidos a una examinación, que consistirá en buscar históricamente en nuestras fuentes de datos internas disponibles si dicho indicador se observó o no en el pasado (ver entrada sobre CMF). En caso de que el resultado fuese positivo, se debe de investigar más a fondo para determinar si la actividad fue maliciosa o no.
Con un resultado positivo, deben de implementarse de manera interna contramedidas de detección (por si volviese a existir actividad del indicador) y mitigación, es decir, no sólo queremos detectar sino que de manera activa no permitir que consiga sus objetivos.
Un indicador se considera madurado cuando de manera retrospectiva se ha identificado actividad maliciosa y se han implementado contramedidas de detección y mitigación.
De madurado a utilizado
Un indicador es utilizado cuando las contramedidas de detección dan un positivo, es decir, el indicador ha sido identificado realizando alguna acción y se considera que ha sido usado para detectar un posible escenario que en principio debería de ser malicioso.
Es importante por lo tanto, que los indicadores tengan aplicadas contramedidas de detección, de lo contrario nunca podrán considerarse utilizados, rompiendo así el ciclo completamente y siendo incapaces de identificar nuevos indicadores.
De utilizado a revelado
Esta etapa del ciclo requiere gran interacción de los analistas ya que tendrán que llevar a cabo un análisis de los sucesos que hayan sido detectados en la anterior etapa. El motivo es sencillo, el indicador por si sólo es una pequeña porción de lo que podría ser una intrusión o intento de, es decir, habrá que investigar todo el contexto de lo que podría estar ocurriendo y construir una imagen completa de la operación que los adversarios están llevando en ejecución.
Durante este análisis es muy probable que aparezcan nuevos indicadores de los cuales no se tenía conocimiento antes, por lo que dichos indicadores deberán de pasar al estado de revelado nuevamente y empezar así el ciclo.
En aquellos casos donde se identifiquen gran cantidad de nuevos indicadores, o sin importar la cantidad, habrá que priorizar la calidad. Esto quiere decir que existirán indicadores que tengan más impacto y detecten de una manera más clara la actividad maliciosa. Un ejemplo podría ser un path de un dominio, suponiendo que un malware se comunica con baddomain.com/data?systeminfo=value, cabe la posibilidad de que hayamos visto otro dominio realizando la comunicación con el mismo path, ya sea porque el malware incorpora varios dominios hardcodeados en su código o cualquier otro motivo, por lo que sería importante madurar indicadores para detectar nuevo comportamiento de otras comunicaciones con /data?systeminfo=.
Aplicando el ciclo en las actividades de threat hunting
Todo el ciclo de vida de los indicadores que se ha explicado hasta el momento tiene cabida en el famoso proceso de threat hunting, donde en primer lugar el equipo realiza la generación de hipótesis priorizando las amenazas que podrían llegar a tener más impacto contra su actividad. Siendo el siguiente paso la actividad pura de hunting, donde se puede implementar el otro ciclo para estructurar el trabajo aún más y conseguir objetivos de una manera más eficaz.
La fase de descubrimiento también podría estar enmarcada dentro del ciclo de vida de los indicadores, más concretamente con la etapa de madurado, que sería aquellos casos donde se ha detectado algún comportamiento pasado con el hunt que está llevando el equipo a cabo.
Caso práctico
Imaginemos que estamos generando diferentes escenarios de manera interna para llevar a cabo actividades de hunting.
#1 — Generación de hipótesis
Tenemos interés en identificar creaciones de tareas programadas en los sistemas durante el pasado, porque un adversario que tiene especial motivación en el sector de nuestra empresa podría materializar algún incidente.
Objetivo: Identificar tareas programadas sospechosas en los sistemas.
Búsquedas: Eventos de Windows 4698 y 4702.
#2 — Hunting
El equipo empieza a realizar actividades de threat hunting en los sistemas mediante la tecnología que se disponga, ya sea consolas EDR, herramientas opensource, SIEM, etc…
Se identifica un positivo en un sistema, donde se verifica una tarea programada.
#3 — Revelado a madurado
El hallazgo en este caso se puede comprobar como se ha habilitado una tarea programada enmascarada con un nombre de “Mozilla Firefox Update” lanzando por línea de comandos un archivo llamado “jstnk.exe” que se encuentra en el directorio de AppData.
En este punto tendríamos dos indicadores, uno calculado y otro de comportamiento.
Indicador calculado: Hash MD5 del archivo jstnk.exe
Indicador de comportamiento: Un adversario establece la tarea programada “Mozilla Firefox Update” (T1053.005) la cual ejecuta el archivo jstnk.exe [MD5].
con ambos indicadores, hay que verificar de manera retrospectiva si en otros sistemas de la red corporativa se ha realizado persistencia similar, ya sea con el mismo malware llamado jstnk.exe o mediante la misma técnica de tarea programada.
Imaginando que se detectan nuevos equipos donde se ha hecho la persistencia mediante T1053.005, se procede por lo tanto a implementar contramedidas de detección y mitigación.
Contramedida de detección: Ejecución del comando “schtasks /create “, poniendo foco en archivos referenciados en Appdata. Una regla sigma parecida a la siguiente podría servirnos -> https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/win_susp_schtask_creation.yml
Contramedida de mitigación: Establecer una política para limitar el uso de schtasks en el sistema.
#4 — Madurado a Utilizado
En este caso, imaginemos que la contramedida de detección mencionada anteriormente ha funcionado, y están apareciendo nuevos hallazgos de creación de tareas programadas en otros sistemas.
Estas detecciones por lo tanto significan que el indicador ha sido utilizado.
#5 — Utilizado a revelado
Los analistas empiezan a realizar labores de investigación para las alertas que han dado positivo en la creación de tareas programadas. Esto lo que desencadena es que, se está evidenciando que el malware usado para la persistencia de esta técnica es diferente en todos los casos, pero cuando se analiza el comportamiento, muchas de las muestras comparten infraestructura para la comunicación con los C&C.
Todos esos nuevos indicadores pasarán por el ciclo de vida de nuevo para automatizar nuevas detecciones y comportamientos que pudiesen estar relacionados con el hunting que se está realizando.
#6 — Descubrimiento
Como los hallazgos están alineados con las hipótesis que se generaron en el primer paso, esta etapa del proceso de threat hunting quiere decir que habrá que recopilar la mayor información sobre los TTPs que han utilizado a bajo nivel para poder automatizar o documentar los hallazgos.
#7 — Reporte y enriquecimiento
En último lugar, el proceso de threat hunting requiere automatizar al máximo posible la misión de hunt llevada a cabo, de esta manera, conseguiremos que el equipo no pierda tiempo nuevamente ejecutando la misma misión cada X tiempo y puedan centrar sus esfuerzos en elaborar nuevas misiones de otras técnicas que pudiesen estar siendo utilizadas en las redes corporativas.
Twitter: https://twitter.com/Joseliyo_Jstnk
LinkedIn: https://www.linkedin.com/in/joseluissm/
