Atomic Hunting con Atomic Red Team: Empezando tu camino como Threat Hunter
Por Valentina Palacin
Este artículo también está disponible en inglés.
¿Atomic qué…?
Threat Hunting es el tema del momento. Ya sea porque estás familiarizado con el increíble trabajo que personas como Olaf Hartong, Roberto Rodriguez y Jose Luis Rodriguez, entre otros, están haciendo con MITRE ATT&CK Framework, Sysmon, ETW, ELK/Splunk… o simplemente porque oíste algo al respecto de esa nueva frontera que es la “caza del adversario” como un enfoque proactivo de la ciberseguridad y querías saber algo más al respecto, puede que te encuentres un poco confundido y no sepas bien por dónde empezar.
Creo que existe una idea equivocada acerca de la experiencia necesaria para dedicarse a esta linea de trabajo y, algunas veces, la gente asume que necesitas tener un nivel muy alto de experiencia como analista senior de seguridad para llevar a cabo este tipo de actividad. En mi opinión, no hay mejor manera de aprender que sumergiéndose en la actividad misma, así que no importa si te consideras un principiante en temas de ciberseguridad, también puedes aprender a cazar adversarios.
Más de una vez me han preguntado por dónde conviene empezar, por lo que decidí escribir este artículo sobre cómo mi colega Ruth Barbacil (root) y yo abordamos el tema cuando comenzamos.
Antes de empezar…
Hay una cosa que vas a necesitar sin importar cuál sea tu nivel de experiencia: un laboratorio de hunting.
Si no tienes uno, te invito a leer el artículo (en inglés) de Roberto Rodriguez sobre cómo preparar un laboratorio de threat hunting antes de continuar leyendo: https://cyberwardog.blogspot.com/2017/02/setting-up-pentesting-i-mean-threat.html
Mi propio laboratorio está basado en el artículo de Roberto (parte 5), pero en lugar de preparar una instancia de ELK, te recomendaría explorar la plataforma especializada para threat hunting desarrollada también por Roberto, The HELK: https://github.com/Cyb3rWard0g/HELK
Puedes echar un vistazo al proyecto Mordor Labs de Roberto para armar un laboratorio en Cloud: https://github.com/OTRF/mordor-labs. Su artículo (en inglés) sobre cómo armar un laboratorio usando Azure Sentinel es otro recurso de gran utilidad: https://medium.com/threat-hunters-forge/azure-sentinel-to-go-b5f6848d3c61
No importa que ambiente elijas, lo importante es que definas la configuración que mejor se ajuste a tus necesidades, como por ejemplo el laboratorio en Azure que armó Roberto para las evaluaciones de APT29:
Y por supuesto, último, pero no por ello menos importante, tener ATT&CK abierto para aprender más sobre las técnicas, consultar las fuentes de datos o como mera referencia es casi una obligación: https://attack.mitre.org/
Ya tengo un laboratorio. ¿Ahora qué?
Una vez que tienes el ambiente de laboratorio andando, todavía tienes que familiarizarte con dos proyectos: Atomic Red Team de Red Canary (@redcanaryco) y Open Source Security Events Metadata (OSSEM), de Roberto y José Luis Rodriguez.
- Atomic Red Team
Atomic Red Team es un proyecto desarrollado por Red Canary. Los test se centran en replicar las técnicas usadas por los adversarios mapeadas por el Framework de MITRE, ATT&CK. Puedes encontrar más información sobre cómo ejecutar estos test atómicos en el repositorio oficial del proyecto: https://github.com/redcanaryco/atomic-red-team
2. OSSEM
Open Source Security Events Metadata (OSSEM) es un proyecto open source diseñado por Roberto y José Luis Rodriguez. OSSEM se enfoca en “la documentación y estandarización de logs de eventos de seguridad provenientes de fuentes de datos y sistemas operativos diversos”. Los diccionarios de datos de OSSEM mapean las fuentes de datos con las analíticas para relacionarlos con las técnicas de los adversarios al mismo tiempo que proveen un modelo de datos para la normalización. En resumidas cuentas, el objetivo del proyecto OSSEM es ayudarte a entender los datos que estás recolectando. Puedes aprender más sobre el proyecto en su repositorio oficial: https://github.com/hunters-forge/OSSEM
Ejecutando Atomic Hunts
Ahora procederé a mostrarles cómo ejecutamos lo que me gusta llamar cazas atómicas.
- Elige el test atómico que quieres “cazar”
Lo primero que necesitas hacer es elegir el test atómico que quieras cazar. Para ello a mí me gusta usar la matriz de test atómicos de Windows para ayudarme a elegir qué test ejecutar: https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/Indexes/Matrices/windows-matrix.md. Para este artículo, voy a usar la técnica de elevación de privilegios Process Hollowing.
2. Haz una hipótesis sobre qué es lo que va a pasar en el sistema de la víctima
Lo siguiente que haré será realizar una hipótesis sobre qué es lo que creo que va a pasar en el dispositivo víctima del test una vez que lo ejecute. No te preocupes sobre la exactitud de tu hipótesis en este paso. Habrá ocasiones donde sepas exactamente cómo funciona un proceso y habrá ocasiones en las que no. El propio ejercicio de “cazarlo” te ayudará a darte cuenta de qué es lo que sabes, qué cosas todavía necesitas aprender y cuáles son tus áreas de mejora.
Haré un diagrama de mi hipótesis intentando reflejar cómo creo que será el flujo de acontecimientos de acuerdo a lo que sé sobre la técnica y lo que se especifica en su descripción.
Por ejemplo, de acuerdo a lo que dice la técnica en la página de ATT&CK, process hollowing (vaciado de proceso, en español)es una forma de inyectar código malicioso en un proceso suspendido para evadir defensas basadas en procesos a través de la “ejecución de código arbitrario en el espacio de memoria de otro proceso activo”. Sé que el test atómico para process hollowing “usa PowerShell para crear un vacío a partir de un PE en disco con [el proceso] explorer como padre”.
Con esta información puedo elaborar un diagrama del que creo que es un flujo posible para este comportamiento. De nuevo, no se preocupen sobre si su suposición está bien o no.
Una vez que mi diagrama está terminado, con la ayuda de OSSEM, estableceré posibles identificadores de eventos (Event IDs) u otros campos relacionales.
Ten en cuenta que este es simplemente mi acercamiento inicial para entender el test, pero tu puedes profundizar tanto como quieras sobre lo que el test atómico va a hacer. Por ejemplo, para este test específico evité analizar en detalle el script “Start-Hollow.ps1” que es necesario ejecutar, pero si quieres puedes hacerlo. Tan solo recuerda que profundizar demasiado no necesariamente resulta práctico para el planteamiento inicial de una investigación.
3. Borra los log anteriores y ejecuta el test
Si he estado trabajando con mi laboratorio antes de ejecutar el test, voy a borrar todos los logs (borrando el índice) que hubiera recopilado anteriormente. Reducir la cantidad de “ruido” en el laboratorio me ayudará a identificar mejor la actividad que estoy buscando sin dar lugar a confusiones sobre qué es exactamente lo que estoy viendo.
Luego, procederé a ejecutar el test atómico en el sistema víctima tal y como se indica en el repositorio de Atomic Red Team: https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1055.012/T1055.012.md.
4. “Caza” el test ejecutado
El siguiente paso será “cazar” dicho test de acuerdo al diagrama que diseñé en el punto 2. Si no puedo encontrar dicha actividad de acuerdo a mi suposición, puesto que sé exactamente qué fue lo que se ejecutó durante el test, haré “trampa” y buscaré esa información específica. De este modo, lo que haré será una “caza inversa”, encadenando procesos según su GUID u otro indicador de relación para reconstruir la cadena de acontecimientos.
5. Verifica tu hipótesis y documenta
De ser necesario, modificaré mi diagrama para que refleje el resultado real de la caza y documentaré lo que aprendí sobre los distintos comportamientos: ¿Dónde me equivoqué en mi hipótesis? ¿Por qué? ¿Pasó algo que no estuviera contemplado dentro de la hipótesis original?
Como pueden ver en el diagrama que aparece a continuación, mi hipótesis inicial estaba muy lejos de lo que pasó en realidad:
Es cierto que probablemente no necesite centrarme en cada uno de los nodos del diagrama para llevar a cabo la caza, pero el conocimiento sobre qué es y qué no es relevante se irá desarrollando con tiempo y práctica.
6. Repetir
Tan simple como dice el título, repetiré esta actividad con tantos test como quiera.
Conclusión
Para poder detectar las anomalías, necesitas aprender cuál es el comportamiento base de tu ambiente. Este enfoque te permitirá entender exactamente cuáles son los logs que corresponden a ese comportamiento base y cómo cazar actividades específicas comprendiendo mejor cuáles son los eventos que desencadenan. Además, deberás asegurarte de que tu laboratorio cuente con las fuentes de datos y las políticas de auditoria adecuadas que te darán visibilidad sobre dichos eventos. Este punto Roberto lo cubre en profundidad en su artículo sobre cómo preparar un laboratorio para la caza de amenazas (parte 3).
Personalmente me gusta ejecutar test atómicos, ya que estos replican actividad maliciosa, pero mi recomendación es que repitas este tipo de ejercicio no sólo con lo que consideres maligno, sino también con cosas más simples como abrir un buscador, abrir documentos, ejecutar ciertos programas… cualquier cosa que te permita entender qué es comportamiento “normal” o “bueno”.
También te recomiendo que busques el significado de los eventos que encuentres y te resulten sospechosos o que no entiendas por qué se loguearon. Con tiempo y paciencia te darás cuenta de que no sólo has aprendido sobre como llevar a cabo una caza de amenazas, sino que también has ganado un conocimiento invaluable sobre cómo funciona el sistema operativo mismo.
Espero que este artículo te haya sido de ayuda. Comentarios y sugerencias siempre son bienvenidos. Puedes mandarme un mensaje directo con cualquier duda a @fierytermite.
Happy hunting!
— — — — — — — — — — — — — —
Agradecimiento especial a root, Roberto Rodriguez y Jose Luis Rodriguez por sus comentarios y ediciones! :)
