Threat Hunting: detección basada en la prevalencia

Borja Merino Febrero

March 18, 2024

•

lectura mínima

Una de las fases en las que hacemos más hincapié al terminar nuestros ejercicios de Purple Team es la revisión, creación y mejora de las consultas que nos permiten identificar de manera eficiente aquellas técnicas ejecutadas por el Equipo Rojo que no han generado ningún tipo de alerta en el EDR correspondiente. Este ciclo de trabajo nos permite enriquecer significativamente las capacidades de detección de nuestros clientes. El resultado de este tipo de ejercicios suele ser un conjunto de consultas automáticas (a veces herramientas) que cubren los TTP no identificados por la propia lógica de detección del EDR, con el fin de seguir ampliando el escudo de protección contra un mayor número de amenazas.

Por lo general, las consultas basadas en el LFO y la prevalencia son los recursos que más utilizamos con algunos clientes para detectar anomalías que «escapan» a la línea de base conocida. El objetivo de este post es explicar con precisión este segundo criterio, predominio, por ser de gran valor a la hora de identificar códigos maliciosos ejecutados por Threat Actors y Red Teams.

MDATP le permite enriquecer, a través de Perfil de archivo () función, la información relacionada con un archivo que ha sido objeto de una consulta determinada. Esta función permite recuperar, por ejemplo, el tamaño del archivo, si es ejecutable, el estado de su firma, etc. Uno de los campos más atractivos para identificar anomalías es GlobalPrevalencia, que devuelve el número de instancias observadas por Microsoft en todo el mundo (otros campos, como GlobalFirstSeen y GlobalLastSeen, también son muy útiles para la búsqueda). ¿Desde Documentación propia de Microsoft, puede ver varios ejemplos de uso:

DeviceFileEvents | where ActionType == "FileCreated" and Timestamp > ago(1d) | project CreatedOn = Timestamp, FileName, FolderPath, SHA1 | invoke FileProfile("SHA1", 500) | where GlobalPrevalence < 15

Nota: Es importante tener en cuenta que el Perfil de archivo () La función tiene varias limitaciones, como se indica en su documentación: «Las funciones de enriquecimiento mostrarán información complementaria solo cuando estén disponibles. La disponibilidad de la información es variada y depende de muchos factores»

Aunque la existencia de un archivo con baja prevalencia no significa necesariamente que sea malicioso (archivos temporales, actualizaciones de software, etc.), si se usa quirúrgicamente para localizar archivos binarios sospechosos, puede ser de gran valor para detectar amenazas avanzadas.

Veamos un ejemplo práctico. Sabemos que, hasta el día de hoy, técnicas basadas en la carga lateral popularizado por grupos como Korplug/Sogu (o el La propia CIA) e incluso el desarrollo de complementos para aplicaciones firmadas de confianza siguen siendo bastante eficaces para lograr la ejecución de código y eludir algunas soluciones de EDR. En un ejercicio de equipo realizado recientemente en Purple, en el que se intentaba replicar este tipo de acciones, se desarrolló un complemento para que Notepad++ cargara y ejecutara una baliza de CS. El cargador (NppRust.dll), básicamente, después de cargar y ejecutar cierto código basura para retrasar su ejecución unos segundos, lee de un supuesto archivo de configuración (plugin.cfg) el stager correspondiente (cifrado RC4) para recuperar y ejecutar una baliza CS dentro del espacio de direcciones de Notepad++.

El campo GlobalPrevalence que proporciona MDATP es de gran valor contra este tipo de ataques, ya que nos permite generar reglas de detección que buscan periódicamente eventos de creación de procesos (DeviceProcessEvents) con DLL sospechosas bajo ciertos criterios (por lo general, muchas de estas consultas tienen varias excepciones y condiciones para reducir los falsos positivos y ajustar la búsqueda al ecosistema del cliente).

Un posible criterio de búsqueda para complementos sospechosos o de carga lateral es identificar las DLL sin firmar con una prevalencia baja que se cargan en procesos firmados. La siguiente imagen muestra una consulta de estas características, ordenando de forma ascendente el campo de la prevalencia global, sobre la telemetría generada por el implante descrito anteriormente.

Se observa que se ha ejecutado una DLL (NpRust.dll) con una prevalencia de 1 dentro del proceso «Notepad++.exe» cuya prevalencia global es 62817. Si observamos la prevalencia del resto de plugins cargados, se manifiesta claramente una anomalía en la DLL maliciosa.

Las posibilidades de este campo a la hora de crear consultas son ilimitadas; por ejemplo, podemos buscar procesos con una prevalencia baja ejecutados desde ciertas rutas, procesos con una prevalencia baja que ejecutan cierto ActionType («ProcessPrimary TokenModified», «QueueUserAPICall RemoteAPICall», «CreateRemoteThreadAPICall», etc.), procesos con una prevalencia baja que resuelven dominios de Slack, Telegram, etc. Siguiendo con el ejemplo anterior, si incorporamos como criterio los procesos firmados que cargan DLL sin firmar que tienen una prevalencia baja y que han creado una conexión exitosa, podemos limitar aún más la búsqueda a las DLL maliciosas que se aprovechan de procesos legítimos.

En nuestro escenario, esta consulta devuelve el C2 al que se conecta el implante, datos que nos permiten identificar nuevos implantes que aprovechan la carga lateral (en el ejemplo, un binario legítimo de hp, discfcsn.exe).

Si bien los ejemplos se han creado con MDATP, sistemas EDR y soluciones SIEM que recopilan este tipo de información en su telemetría, dan un gran peso a Hunting y, al mismo tiempo, limitan las rutas de ejecución de Threat Actors y Red Team (más aún cuando las técnicas se basan en»Intérprete de comandos y scripts» también se supervisan de cerca). Los cazadores, por otro lado, deberían centrar sus esfuerzos en pulir las consultas en función de la prevalencia de una manera precisa para limitar y reducir el número de FPs en la medida de lo posible.

Referencias

‍