Combinación de machine learning supervisado y no supervisado para la detección de DGA

Estamos muy entusiasmados por anunciar nuestra primera integración de seguridad y ML supervisado. Hoy lanzamos un paquete de soluciones de ML supervisado para detectar la actividad de algoritmos de generación de dominios (DGA) en tus datos de red.

Además de un modelo de detección completamente entrenado, nuestro lanzamiento incluye configuraciones de pipeline de ingesta, trabajos de detección de anomalías y reglas de detección que facilitarán tu viaje desde la configuración hasta la detección de DGA. Navega a nuestro repositorio de reglas de detección para conocer cómo puedes dar los primeros pasos con machine learning supervisado para detectar la actividad de DGA en tu red e inicia hoy tu prueba gratuita con Elastic Security. 

DGA: Desglose

Los algoritmos de generación de dominios (DGA) son una técnica que emplean muchos autores de malware para asegurarse de que la infección de una máquina cliente evada las medidas defensivas. El objetivo de esta técnica es ocultar la comunicación entre una máquina cliente infectada y el servidor de comando y control (C & C o C2) usando cientos o miles de nombres de dominio generados de forma aleatoria, que en última instancia se resuelven en la dirección IP de un servidor C & C.

Para visualizar de un modo más sencillo lo que ocurre en un ataque de DGA, imagina por un momento que eres un soldado en un campo de batalla. Como muchos soldados, tienes un equipo de comunicación que usa frecuencias de radio. Tu enemigo puede intentar interrumpir tus comunicaciones saturando las frecuencias de radio. Una manera de idear un contrataque es alternando frecuencias: usar un sistema de radio que cambie muy rápido de frecuencia durante una transmisión. Para el enemigo, los cambios de frecuencia parecerán aleatorios e impredecibles, por lo que le resultará difícil saturarlas.

Los DGA son como un canal de comunicación que alterna frecuencias para el malware. Cambian los dominios con tanta frecuencia que bloquear el canal de comunicación de C2 del malware resulta inviable con el bloqueo de nombres de dominio de DNS. Simplemente hay demasiados nombres de DNS generados de forma aleatoria como para intentar identificarlos y bloquearlos. 

Esta técnica surgió con fuerza en el mundo del malware en 2009, cuando el gusano “Conficker” comenzó a usar una gran cantidad de nombres de dominio generados de forma aleatoria para la comunicación. Los autores del gusano desarrollaron este contrataque después de que una agrupación de investigadores de seguridad interrumpieron el canal de C2 del gusano desactivando los dominios de DNS que usaba para la comunicación. También se usó la mitigación de DNS en el caso del brote global de ransomware WannaCry en 2017.

Camuflado

Si el mejor sitio para ocultar un árbol es un bosque, los operadores de malware saben desde hace tiempo que camuflarse en el tráfico web normal es una de las mejoras formas de pasar desapercibido. Una solicitud HTTP con un nombre de dominio generado de forma aleatoria es un problema difícil para la detección y el monitoreo de seguridad de la red. La gran cantidad de tráfico HTTP en las redes modernas hace que una revisión manual sea inviable. Algunos malware y bots tienen cadenas de agente de usuario inusuales que pueden activar alertas con reglas de búsqueda, pero los autores de malware pueden aprovechar con facilidad una cadena de agente de usuario que tenga la misma apariencia que un navegador web.

Con el auge de la tecnología móvil y la IoT, ha aumentado tanto la cantidad de cadenas de agente de usuario que la revisión manual en busca de actividad sospechosa también se está volviendo inviable. Los proxies web usan desde hace tiempo la categorización para buscar URL que se conoce que son sospechosas, pero los dominios de DGA son tantos y de tan corta duración que por lo general no se categorizan. Las fuentes de inteligencia de amenazas pueden identificar direcciones IP y solicitudes HTTP asociadas con campañas y familias de malware conocidas, pero estas listas son tan fáciles de modificar para los operadores de malware que suelen estar desactualizadas para el momento de ponerlas en uso en las búsquedas.

El mero volumen del tráfico de red recopilado en muchas organizaciones y la naturaleza aleatoria de los dominios generados por DGA hacen que la detección de esta actividad sea un desafío para las técnicas basadas en reglas, pero ideal para nuestro modelo de machine learning supervisado. Usando Inference (Inferencia), el modelo de ML de detección de DGA de Elastic examinará los datos de DNS de Packetbeat mientras se ingestan en tu cluster de Elasticsearch y determinará de forma automática qué dominios son potencialmente maliciosos. Sigue los pasos de la próxima sección para dar los primeros pasos. 

Primeros pasos

Para dar los primeros pasos con la detección de DGA en la app de seguridad, lanzamos un conjunto de características en nuestro repositorio de reglas disponible para el público que te ayudará con la importación de modelos de machine learning al Elastic Stack. Este repositorio no solo proporciona a nuestra comunidad un lugar para colaborar con la detección de amenazas, sino que también actúa como un sitio en el cual compartir las herramientas necesarias para probar y validar reglas.

Visita nuestro blog y webinar anteriores para obtener información adicional sobre la iniciativa. Si aún no tienes una suscripción a Elastic Cloud, puedes probarlo con una prueba en el cloud gratuita por 14 días para comenzar a experimentar con el paquete de soluciones de ML supervisado para detectar la actividad de DGA.

Una parte de este kit de herramientas de reglas es una CLI (interfaz de línea de comando) no solo para probar reglas, sino también para interactuar con tu stack. Por ejemplo, lanzamos varias bibliotecas de Python para interactuar con la API de Kibana. Esto fue fundamental para facilitar el proceso de importación de las dependencias del modelo y hacer que tus reglas sean operativas. Para comenzar a enriquecer los datos de DNS y a recibir alertas sobre la actividad de DGA, sigue estos tres pasos:

Paso uno: Importar el modelo

Primero, debes importar el modelo de DGA, scripts de Painless y procesadores de ingesta en tu stack. Actualmente, los modelos de DGA y cualquier modelo no supervisado para detección de anomalías (más próximamente) están disponibles en el repositorio detection-rules con versiones de Github. Para cargarlo, ejecuta el comando de CLI siguiente:

python -m detection_rules es <args_or_config> experimental setup-dga-model -t <release-tag>

Después de la carga, tendrás que actualizar la configuración de Packetbeat, debido a que el modelo enriquecerá los eventos de DNS de Packetbeat con una puntuación de DGA. Esto puede hacerse fácilmente agregando la configuración adicional en tu configuración de salida de Elasticsearch:

output.elasticsearch:
  hosts: ["your-hostname:your-port"]
  pipeline: dns_enrich_pipeline

El modelo supervisado analizará y enriquecerá entonces los eventos de DNS de Packetbeat, que contienen estos campos de ECS:

dns.question.name
dns.question.registered_domain

El modelo agregará después estos campos a los eventos de DNS procesados:

A continuación se muestra un ejemplo de captura de pantalla de datos de DNS enriquecidos:

Nota: Para obtener información más detallada, consulta el archivoléeme de detection-rules.

Acerca de las reglas de DGA

Ahora veamos algunas reglas de búsqueda condicional que detectan la actividad de DGA y alertan al respecto. En el paquete se proporcionan dos reglas de búsqueda que pueden habilitarse y ejecutarse en el motor de detección en la app Elastic Security:

1. Machine Learning Detected a DNS Request Predicted to be a DGA Domain
2. Machine Learning Detected a DNS Request With a High DGA Probability Score

La primera regla coincide con cualquier evento de DNS que tenga un valor de predicción de DGA de 1, lo que indica que el nombre de dominio de DNS probablemente fue el resultado de un algoritmo de generación de dominios y, por lo tanto, es sospechoso. La regla, que se encuentra aquí, simplemente busca la condición siguiente:

event.category:network and network.protocol:dns and ml_is_dga.malicious_prediction: 1

La segunda regla coincide con cualquier evento de DNS con una probabilidad de DGA mayor que 0.98, lo que indica que el nombre de dominio de DNS probablemente fue el resultado de un algoritmo de generación de dominios y, por lo tanto, es sospechoso. La regla, que se encuentra aquí, simplemente busca la condición siguiente:

event.category:network and network.protocol:dns and ml_is_dga.malicious_probability > 0.98

Como todas las reglas en el motor de detección de Elastic, pueden bifurcarse y personalizarse para adaptarse a las condiciones locales. La puntuación de probabilidad en la segunda regla puede ajustarse a un valor superior o inferior si descubres que una puntuación de probabilidad diferente funciona mejor con tus eventos de DNS. Puedes aumentar la puntuación de riesgo de cualquier regla si deseas incrementar la prioridad de las detecciones de DGA en tu cola de alertas. Se pueden agregar excepciones a las reglas para ignorar falsos positivos como dominios de red de distribución de contenidos (CDN) que pueden usar nombres de dominio seudoaleatorios.

Otra posibilidad futura que planeamos explorar es el uso del lenguaje de búsqueda de eventos (EQL) para buscar clusters de alertas basadas en búsqueda o anomalía usando correlación multivariada. Por ejemplo, si vemos un cluster de alertas de un host involucrado en probable actividad de DGA, aumenta la confianza en que tenemos una detección de malware importante que requiere atención.

Dicho cluster podría consistir en alertas de DGA combinadas con otras alertas de detección de anomalías, como un proceso, proceso de red, dominio o URL inusuales. Estas detecciones de anomalías adicionales las produce la biblioteca de paquetes de machine learning incluidas en la app Elastic Security.

Paso dos: Importar reglas

Las reglas en el paquete de DGA pueden importarse usando la característica upload-rule de Kibana en la CLI detection-rules (en el formato .toml). Dado que las reglas proporcionadas en las versiones del repositorio detection-rules están en formato .toml, simplemente ejecuta el comando siguiente para cargar una regla desde el repositorio:

python -m detection_rules kibana upload-rule -h
Kibana client:
Options:
  --space TEXT Kibana space
  -kp, --kibana-password TEXT
  -ku, --kibana-user TEXT
  --cloud-id TEXT
  -k, --kibana-url TEXT
Usage: detection_rules kibana upload-rule [OPTIONS] TOML_FILES...
  Upload a list of rule .toml files to Kibana.
Options:
  -h, --help  Show this message and exit.
  -h, --help  Show this message and exit.

Paso tres: Habilitar regla y obtener los beneficios

Ahora que tenemos el modelo de ML supervisado y entrenado ya importado en el stack, que los eventos de DNS están siendo enriquecidos y que las reglas están a nuestra disposición, lo que nos queda por hacer es confirmar que la regla está habilitada y esperar las alertas. 

Cuando visualices la regla en el motor de detección, puedes confirmar que está activada como se muestra a continuación:

Y ahora espera las alertas. Una vez generada una alerta, puedes usar la característica Timeline (Línea de tiempo) para investigar el evento de DNS y comenzar tu investigación.

Sin embargo, ningún modelo de machine learning es perfecto. Algunos dominios benignos se etiquetarán erróneamente, lo que tiende a crear falsos positivos. En la siguiente sección, investigaremos cómo aprovechar trabajos de detección de anomalías preconfigurados y las reglas que los acompañan que se envían con esta versión para excluir falsos positivos.

¿Falsos positivos? Detección de anomalías, ¡al rescate!

Como con todas las técnicas de detección, siempre habrá falsos positivos. Pueden aparecer en forma de tráfico de CDN o dominios personalizados que parecen ser maliciosos pero en realidad son normales en el entorno. Para asegurarnos de que nuestra detección de DGA se adapte al entorno de cada usuario, creamos un trabajo de detección de anomalías preconfigurado denominado experimental-high-sum-dga-probability. Cuando está habilitado, este trabajo de ML examina las puntuaciones de DGA producidas por el modelo de DGA supervisado (sí, ML por donde lo mires) y busca patrones anómalos de puntuaciones inusualmente altas para una dirección IP de origen en particular. A tales eventos se les asigna una puntuación de anomalía.

Para maximizar el beneficio del trabajo de detección de anomalías, lo lanzamos junto con una regla complementaria: Potential DGA Activity. Esto creará una alerta basada en anomalías en la página de detección en la app de seguridad.

Tanto el trabajo de detección de anomalías preconfigurado como la regla complementaria están disponibles en nuestras versiones del repositorio de reglas de detección. 

Cómo elegir la configuración adecuada para tu entorno

Todo comienza con el modelo de DGA supervisado. Cada solicitud de DNS ingestada a través de Packetbeat es analizada por el modelo y recibe una probabilidad que indica la maliciosidad probable del dominio involucrado en la solicitud. Puedes usar las salidas del modelo supervisado directamente en la app de seguridad usando las reglas de lógica condicional mencionadas en la sección “Primeros pasos” o puedes importar y habilitar nuestras reglas y trabajo de detección de anomalías preconfigurado para personalizar aún más las detecciones según las sutilezas de tu entorno. 

¿Cómo elegir la configuración adecuada para tu entorno? Comienza con algo simple. Habilita las reglas de búsqueda condicional mencionadas en la sección “Primeros pasos”. Estas reglas actúan directamente en las salidas del modelo supervisado y rápidamente te darán una idea de la cantidad de ruido en segundo plano por falsos positivos que existe en tu entorno. Si encuentras que las reglas de búsqueda condicional que operan en las salidas directas del modelo supervisado producen demasiadas alertas, quizá te beneficies con la importación y habilitación del trabajo de detección de anomalías. 

En particular, la regla de detección de ML que opera en los resultados del trabajo de detección de anomalías puede ser útil para encontrar fuentes con grandes cantidades agregadas de actividad de DGA en lugar de alertar sobre puntuaciones de DGA individuales una por una. Si no tienes el módulo de ML en ejecución, inicia una prueba gratuita o pruébalo en Elastic Cloud.

A continuación verás ejemplos de capturas de pantalla del modelo de detección de anomalías y reglas asociadas proporcionadas con la versión:

Caso de estudio: Detección de actividad de DGA en el mundo real en el ataque SUNBURST

Intentemos aplicar este flujo de trabajo de DGA experimental a la reciente campaña SUNBURST. 

A modo de recapitulación, el 13 de diciembre, SolarWinds lanzó una advertencia de seguridad sobre un ataque exitoso a la cadena de suministro en la plataforma de gestión de red Orion. Al momento de redacción de este documento, el ataque afecta a las versiones de Orion lanzadas entre marzo y junio de 2020. También, el 13 de diciembre, FireEye compartió información sobre una campaña global que involucraba el compromiso de la cadena de suministro de SolarWinds que afectaba algunas versiones del software Orion.

Previamente lanzamos un blog sobre los usuarios de Elastic y el caso de SolarWinds, comúnmente llamado SUNBURST. En ese blog se destaca que la tecnología de prevención de malware de Elastic Security que usan tanto Elastic Endgame como la seguridad de endpoint de Elastic se actualizó con detecciones para los ataques descritos en la divulgación de SolarWinds.

SUNBURST era un ataque sofisticado a la cadena de suministro que supuestamente insertaba malware en el producto SolarWinds Orion y lo distribuía usando un mecanismo de actualización automática. El tamaño, alcance y extensión del incidente aún se están evaluando al momento de redacción de este documento. 

Detecciones de Elastic Security existentes

Un investigador de seguridad compartió un conjunto de 1722 nombres de dominio generados por DGA usados por el malware SUNBURST. Una de las reglas de detección basadas en machine learning de Elastic Security existentes, DNS Tunneling, genera dos alertas basadas en anomalías sobre los nombres de DNS en esta muestra. De modo similar a la tunelización de DNS, la proporción de dominios secundarios-principales en la muestra de nombres de SUNBURST es muy alta. Este trabajo de ML asociado con esta regla está codificado para analizar los datos de Packetbeat, pero se puede clonar y modificar para ingestar otros eventos de DNS en formato Elastic Common Schema (ECS). Este es el trabajo de ML de DNS Tunneling:

Este trabajo de ML tiene una regla de detección asociada denominada DNS Tunneling:

Con estas reglas de Elastic Security, estas detecciones de anomalías que se muestran a continuación pueden transformarse en alertas de detección y notificaciones opcionales para colocarlas en las colas de trabajo adecuadas de priorización de incidentes y respuesta. Así se ven estas detecciones de anomalías de SUNBURST en la app Elastic Machine Learning:

Esta detección es útil, pero este trabajo puede no detectar actividad de DGA todo el tiempo. Para fortalecer la detección de DGA, enviamos el flujo de trabajo de detección de DGA experimental.

Uso del flujo de trabajo de DGA experimental

Descubrimos que el flujo de trabajo de detección de ML de DGA experimental detecta la mayor parte de esta actividad. Ejecutamos estos dominios de DGA de SUNBURST a través del modelo de detección de DGA mencionado aquí (consulta arriba para conocer los detalles de cómo descargar y ejecutar este modelo y sus reglas). Encontramos que el modelo etiquetó el 82 % de los nombres en la muestra como DGA, lo que hubiera producido 1420 alertas en el conjunto de muestra. Esta es una captura de pantalla de los nombres de DNS de SUNBURST etiquetados como actividad de DGA por el modelo supervisado:

Estos eventos pueden convertirse en alertas de detección con la regla de detección Machine Learning Detected a DNS Request Predicted to be a DGA Domain. También podemos hacer una copia de esta regla y modificarla para que coincida con el dominio principal observado usado por una instancia de malware en particular como SUNBURST. Podemos hacer coincidir este conjunto de eventos de DGA de SUNBURST agregando una prueba a la búsqueda de regla de la siguiente manera:

network.protocol:dns and ml_is_dga.malicious_prediction: 1 and dns.question.registered_domain: "avsvmcloud.com"

Después podemos asignarle a esta regla un nivel de gravedad crítico y una puntuación de riesgo alto de 99 para pasarla al frente de la cola de trabajo de análisis y alertas. Esta es una captura de pantalla de las alertas generadas por esta regla modificada para atraer la atención a la detección de actividad de DGA de SUNBURST:

Incluimos esta regla, Machine Learning Detected DGA activity using a known SUNBURST DNS domain, en el paquete. En condiciones de infección en el mundo real, una población de instancias de malware que usen DGA de alta frecuencia podría producir suficientes alertas para activar el interruptor max_signals configurado en 100 de forma predeterminada. En ese caso, podríamos tener alertas sobre algunas instancias de malware y no otras, según los eventos con los que la búsqueda haya encontrado coincidencias primero. 

Para asegurarnos de identificar una mayor cantidad de hosts infectados que tengan actividad de DGA, aumentamos el valor de max_signals en las reglas de búsqueda de DGA a 10 000. Nota: Esta configuración no se puede modificar en el editor de reglas, se debe modificar en un archivo de regla externo y después importarse. Esta configuración puede observarse visualizando un archivo de regla en un editor.

En los casos de mucha actividad de DGA y muchas alertas, también podemos agregar y tamizar los eventos o alertas de DGA para contarlos por nombre de host o IP de origen en una tabla de datos como esta:

También incluimos un dashboard de muestra para eventos de DGA de Packetbeat con visualizaciones y agregaciones, incluida esta visualización de tabla de datos, agregada por source.ip. Como alternativa, puedes agregar por host.name si tus eventos de DNS contienen ese campo. El nombre de este archivo es dga-dashboard.ndjson, y se puede importar a Kibana seleccionando Import (Importar) en la página Saved Objects (Objetos guardados) que se puede encontrar después de seleccionar Stack Management (Gestión del stack).

Esta es una captura de pantalla de este dashboard en el que se proporcionan los eventos de DGA en un índice packetbeat-*:

Estamos aquí para ayudarte

No estás solo. Si tienes algún problema en este proceso o simplemente quieres saber más sobre nuestras filosofías sobre detección de amenazas y machine learning, comunícate con nosotros a través de nuestro canal de Slack de la comunidad, nuestros foros de debate o incluso pon manos a la obra y trabaja con nosotros en nuestro repositorio abierto de detección. Gracias, ¡que lo disfrutes!