Détection des DGA à l'aide du Machine Learning supervisé et non supervisé

Nous sommes très heureux d'annoncer notre toute première intégration de ML supervisé et de sécurité. Aujourd'hui, nous lançons un package de ML supervisé pour vous aider à détecter l'activité des algorithmes de génération de noms de domaine (DGA) dans vos données réseau.

Notre version comprend un modèle de détection complètement entraîné, ainsi que des configurations de pipeline d'ingestion, des tâches de détection des anomalies et des règles de détection. Notre objectif est de vous aider à définir et à détecter les DGA en toute simplicité. Consultez notre référentiel de règles de détection pour savoir comment utiliser le Machine Learning supervisé afin de détecter l'activité des DGA dans votre réseau. Et profitez d'un essai gratuit d'Elastic Security dès aujourd'hui. 

Présentation des DGA

Les algorithmes de génération de noms de domaine (DGA) constituent une technique employée par bon nombre de créateurs de malware. Cette technique fait en sorte que l'infection d'une machine client passe à travers les mailles des mécanismes de défense. Son but ? Cacher la communication entre une machine client infectée et le serveur de commande et contrôle (C&C ou C2). Pour y parvenir, elle s'appuie sur des centaines, voire des milliers de noms de domaines générés de manière aléatoire, afin de déterminer à terme l'adresse IP d'un serveur C&C.

Pour illustrer plus facilement ce qui se passe lors d'une attaque par DGA, imaginez que vous soyez un soldat sur un champ de bataille. Comme bon nombre de soldats, vous disposez d'un équipement qui utilise des fréquences radio pour communiquer. Pour perturber vos communications, votre ennemi peut chercher à brouiller vos fréquences radio. Pour contrer le problème, vous pouvez utiliser la technique du saut de fréquence, avec un système qui change de fréquence très rapidement au cours d'une transmission. Pour l'ennemi, les changements de fréquence sembleront aléatoires et imprévisibles. Il sera donc difficile de brouiller vos communications.

Le fonctionnement des DGA s'apparente à celui d'un canal de communication à fréquence de saut, mais pour les malwares. Les DGA changent de domaines si souvent qu'il est impossible de bloquer le canal de communication C2 d'un malware au moyen d'un blocage des noms de domaine DNS. Il y a tout simplement trop de noms DNS générés aléatoirement pour essayer de les identifier et de les bloquer. 

Cette technique a fait une entrée tonitruante dans l'univers des malwares en 2009, lorsque le ver "Conficker" a commencé à utiliser un très grand nombre de noms de domaines générés aléatoirement pour communiquer. Les créateurs du ver ont créé cette contre-mesure après qu'un consortium de chercheurs en sécurité a interrompu le canal C2 du ver en fermant les domaines DNS servant à communiquer. Une limitation des DNS a également eu lieu dans le cas de l'attaque mondiale par ransomware WannaCry en 2017.

Comment passer inaperçu

Si le meilleur endroit pour cacher un arbre est une forêt, les opérateurs de malware ont compris depuis longtemps que le meilleur moyen de ne pas se faire repérer était de se fondre dans le trafic web normal. Une requête HTTP avec un nom de domaine généré aléatoirement pose un vrai problème au niveau du monitoring de la sécurité du réseau et de la détection. Le trafic HTTP des réseaux modernes est tellement dense qu'il est impossible d'effectuer une vérification manuelle. Certains malwares et bots contiennent des chaînes user-agent inhabituelles, qu'il est possible de repérer à l'aide de règles de recherche. Néanmoins, les créateurs de malware peuvent parfaitement exploiter une chaîne user-agent qui ressemble à s'y méprendre à un navigateur web.

Avec l'ascension des dispositifs mobiles et IoT, les chaînes user-agent sont devenues si nombreuses qu'il est devenu impossible de vérifier manuellement une activité suspecte. Pendant longtemps, les proxys web se sont appuyés sur la catégorisation pour rechercher les URL suspectes connues. Cependant, les domaines DGA sont extrêmement volumineux, avec une durée de vie courte, ce qui fait qu'ils sont très rarement catégorisés. Les flux de Threat Intelligence peuvent identifier les adresses IP et les requêtes HTTP associées à des familles et des campagnes de malware connus. Mais, celles-ci sont régulièrement modifiées par les opérateurs de malware, ce qui fait que les listes utilisées sont souvent obsolètes au moment où elles sont appliquées dans les recherches.

Pour les techniques basées sur des règles, c'est un vrai défi de détecter cette activité suspecte. Le volume du trafic réseau collecté et la nature aléatoire des domaines générés par DGA leur compliquent grandement la tâche. Mais la bonne nouvelle, c'est que notre modèle de Machine Learning supervisé peut nous aider ! En exploitant l'inférence, le modèle de ML de détection des DGA d'Elastic examine les données DNS Packetbeat au moment où elles sont ingérées dans votre cluster Elasticsearch. Il détermine ainsi de manière automatique les domaines qui sont potentiellement malveillants. Nous allons maintenant voir comment faire de façon détaillée. Suivez le guide ! 

Premiers pas

C'est parti pour la détection des DGA ! Pour vous aider à importer les modèles de Machine Learning dans la Suite Elastic, nous avons défini un ensemble de fonctionnalités dans notre référentiel de règles disponible publiquement. Ce référentiel est un espace qui permet à notre communauté de collaborer sur la détection des menaces, mais pas que. C'est également un endroit pour partager les outils nécessaires pour tester et valider des règles.

Pour en savoir plus sur cette initiative, consultez notre article précédent et notre webinar. Vous n'avez pas encore d'abonnement à Elastic Cloud ? Profitez d'un essai gratuit de 14 jours pour tester cette solution et le package de ML supervisé dans le cadre de la détection de l'activité des DGA.

Dans cette boîte à outils se trouve une CLI (interface de ligne de commande) qui permet non seulement de tester les règles, mais aussi d'interagir avec votre suite. Par exemple, nous avons publié plusieurs bibliothèques en Python pour interagir avec l'API Kibana. C'était là une étape incontournable pour faciliter le processus d'importation des dépendances de modèle pour que vos règles soient opérationnelles. Pour commencer à enrichir les données DNS et à recevoir des alertes concernant l'activité des DGA, procédez comme suit :

Étape 1 : importation du modèle

Tout d'abord, vous devez importer le modèle DGA, les scripts painless et les processeurs d'ingestion dans votre suite. Actuellement, les modèles DGA et les modèles non supervisés pour la détection des anomalies (plus d'info à venir) sont disponibles dans le référentiel detection-rules à l'aide de publications github. Pour les charger, exécutez la commande de CLI suivante :

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

Une fois le chargement terminé, vous devrez mettre à jour votre configuration Packetbeat, car le modèle enrichira les événements DNS Packetbeat avec un score DGA. Pour cela, rien de plus facile. Ajoutez simplement la configuration additionnelle à votre configuration de sortie Elasticsearch :

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

Le modèle supervisé analysera et enrichira alors les événements DNS Packetbeat, qui contiennent les champs ECS suivants :

dns.question.name
dns.question.registered_domain

Puis, le modèle ajoutera ces champs aux événements DNS traités :

La capture ci-dessous présente un exemple de données DNS enrichies :

Remarque : Pour en savoir plus, consultez le fichier readme du référentiel detection-rules.

À propos des règles DGA

Étudions à présent certaines règles de recherche qui détectent l'activité des DGA et génèrent des alertes. Dans le package, deux règles sont fournies. Vous pouvez les activer et les exécuter dans le moteur de détection de l'application 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 première règle renvoie tous les événements DNS ayant une valeur de 1, c'est-à-dire tous les événements dont le nom de domaine DNS est probablement le résultat d'un algorithme de génération de noms de domaine, et par conséquent, suspect. La règle, accessible ici, recherche simplement la condition suivante :

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

La deuxième règle renvoie tous les événements DNS dont le score de probabilité est supérieur à 0,98, c'est-à-dire tous les événements dont le nom de domaine DNS est probablement le résultat d'un algorithme de génération de noms de domaine, et par conséquent, suspect. La règle, accessible ici, recherche simplement la condition suivante :

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

Comme toutes les règles du moteur de détection Elastic, vous pouvez adapter ces règles pour qu'elles conviennent à l'environnement local. Le score de probabilité de la deuxième règle peut être ajusté sur une valeur supérieure ou inférieure, si vous estimez qu'un score différent serait plus approprié pour vos événements DNS. Vous pouvez aussi augmenter le score de risque de ces règles, si vous souhaitez que les détections DGA aient une priorité plus élevée dans votre file d'attente d'alertes. Par ailleurs, vous pouvez ajouter des exceptions aux règles pour ignorer les faux positifs, comme les domaines de réseau de diffusion de contenu (RDC), qui utilisent parfois des noms de domaines pseudo-aléatoires.

Une autre possibilité que nous prévoyons d'approfondir, c'est l'utilisation de l'Event Query Language (EQL) pour rechercher des clusters d'alertes basées sur des anomalies ou sur des recherches à l'aide de corrélations à plusieurs variables. Par exemple, si nous constatons qu'il existe un cluster d'alertes pour un hôte impliqué dans une activité DGA probable, nous pouvons être pratiquement sûrs qu'il s'agit là d'une détection significative de malware qui nécessite qu'on lui prête attention.

Un cluster de ce type pourrait se composer d'alertes DGA et d'autres alertes de détection des anomalies, comme un processus, processus réseau, URL ou domaine inhabituel. Ces détections d'anomalies supplémentaires sont générées par la bibliothèque de packages de Machine Learning incluse dans l'application Elastic Security.

Étape 2 : importation des règles

Les règles du package DGA peuvent être importées à l'aide de la fonctionnalité kibana upload-rule de la CLI detection-rules (au format .toml). Étant donné que les règles fournies dans les publications du référentiel detection-rules sont au format .toml, exécutez simplement la commande suivante pour charger une règle à partir du référentiel :

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.

Étape 3 : activation de la règle et exécution

Maintenant que le modèle entraîné de ML supervisé a été importé dans la suite, que les événements DNS ont été enrichis et que les règles sont à notre disposition, tout ce qu'il nous reste à faire est de confirmer que la règle est bien activée et attendre que les alertes se déclenchent ! 

Pour cela, accédez au moteur de détection et vérifiez que la règle est bien activée, comme ci-dessous :

Maintenant, il n'y a plus qu'à attendre les alertes. Lorsqu'une alerte se déclenche, vous pouvez utiliser la fonctionnalité de chronologie pour enquêter sur l'événement DNS et démarrer votre examen.

Néanmoins, prudence est mère de sûreté. Aucun modèle de Machine Learning n'est parfait ! Certains domaines sans risque peuvent être étiquetés par erreur comme étant des faux positifs. Dans la section suivante, nous allons voir comment tirer profit des tâches préconfigurées de détection des anomalies et des règles qui les accompagnent pour chasser les faux positifs.

Vous avez des faux positifs ? La détection des anomalies arrive à la rescousse !

Quelle que soit la technique de détection employée, il y aura forcément des faux positifs. Ces faux positifs peuvent se présenter sous forme de trafic RDC ou de domaines personnalisés qui semblent être malveillants alors qu'ils sont en réalité sans risque. Pour que notre détection DGA s'adapte à l'environnement de chaque utilisateur, nous avons créé une tâche préconfigurée de détection des anomalies appelée experimental-high-sum-dga-probability. Lorsqu'elle est activée, cette tâche de ML examine les scores DGA générés par le modèle DGA supervisé et recherche les cas dans lesquels les scores d'une adresse IP source spécifique sont anormalement élevés. De tels cas se voient attribuer un score d'anomalie.

Pour tirer pleinement profit de la tâche de détection des anomalies, nous la publions avec une règle complémentaire : Potential DGA Activity. Cette règle créera une alerte basée sur les anomalies dans la page de détection de l'application de sécurité.

La tâche préconfigurée de détection des anomalies et la règle complémentaire sont toutes deux disponibles dans les publications de notre référentiel detection-rules. 

Comment choisir la configuration appropriée pour votre environnement

Le point de départ, c'est le modèle DGA supervisé. Chaque requête DNS ingérée via Packetbeat est analysée par le modèle, qui lui attribue un score selon la probabilité que le domaine impliqué dans la requête soit malveillant. Vous pouvez utiliser les sorties du modèle supervisé directement dans l'application de sécurité à l'aide des règles de logique conditionnelle abordées dans la section "Premiers pas". Ou, si vous préférez, vous pouvez importer et activer notre tâche préconfigurée de détection des anomalies et les règles afin de personnaliser les détections et les adapter aux subtilités de votre environnement. 

Comment choisir la configuration appropriée pour votre environnement ? Pour le début, faites simple. Activez les règles de recherche conditionnelle abordées dans la section "Premiers pas". Ces règles agissent directement sur la base des sorties du modèle supervisé. Elles vous donneront rapidement une idée du volume de faux positifs de votre environnement. Si vous estimez que ces règles génèrent trop d'alertes, vous pouvez alors importer et activer la tâche de détection des anomalies. 

Plus particulièrement, la règle de détection de ML, qui s'appuie sur les résultats de la tâche de détection des anomalies, peut être utile pour repérer les sources qui cumulent de hauts volumes d'activités DGA, plutôt que de créer des alertes sur chacun des scores DGA individuels. Si vous n'avez pas de module de ML opérationnel, profitez d'un essai gratuit ou passez par Elastic Cloud pour vous faire une idée du fonctionnement.

Vous trouverez ci-dessous des exemples de captures d'écran du modèle de détection des anomalies et des règles associées fournis dans la version :

Étude de cas : détection d'une attaque DGA concrète dans le cadre de la campagne SUNBURST

Essayons d'appliquer ce workflow DGA expérimental à la récente campagne SUNBURST. 

Commençons par un bref récapitulatif. Le 13 décembre, SolarWinds publie un avertissement de sécurité concernant une attaque supply-chain sur la plate-forme de gestion réseau Orion. À la date de cette publication, l'attaque concerne les versions d'Orion publiées entre mars et juin 2020. En parallèle, le 13 décembre, FireEye communique des informations concernant une campagne mondiale impliquant l'attaque supply-chain de SolarWinds qui compromet certaines versions d'Orion.

Nous avons précédemment publié un article s'adressant aux utilisateurs Elastic et présentant le cas SolarWinds, communément appelé SUNBURST. Cet article indique que la technologie de prévention contre les malware d'Elastic Security, utilisée à la fois par Elastic Endgame et dans la sécurité aux points de terminaison Elastic, a été mise à jour pour pouvoir détecter les attaques décrites dans la publication de SolarWinds.

SUNBURST était une attaque supply-chain sophistiquée qui injectait, d'après certaines informations, un malware dans le produit Orion de SolarWinds et le distribuait à l'aide d'un mécanisme de mise à jour automatique. À la date de cette publication, l'envergure, la portée et l'étendue de l'incident sont toujours en cours d'étude. 

Détections Elastic Security existantes

Quelque 1 722 noms de domaine générés par DGA et utilisés par le malware SUNBURST ont été partagés par un chercheur en sécurité. L'une des règles de détection existantes basées sur le Machine Learning d'Elastic Security, DNS Tunneling, génère deux alertes d'anomalie sur les noms DNS de cet ensemble. De même, le rapport des domaines enfant-à-parent dans l'ensemble de noms SUNBURST est très élevé. La tâche de ML associée à cette règle est codée pour analyser les données Packetbeat mais elle peut être clonée et modifiée pour ingérer d'autres événements DNS au format Elastic Common Schema (ECS). Voici la tâche de ML en question :

Cette tâche de ML a une règle de détection associée, appelée DNS Tunneling :

À l'aide de ces règles d'Elastic Security, la détection des anomalies peut prendre la forme d'alertes de détection et de notifications optionnelles, le but étant qu'elles soient placées par la suite dans les files d'attente de tri d'incidents et de résolutions appropriées. Voici à quoi ressemble la détection des anomalies SUNBURST dans l'application de Machine Learning Elastic :

Il s'agit d'une détection utile, mais cette tâche risque de ne pas détecter une partie de l'activité des DGA. Pour renforcer la détection des DGA, nous transférons le workflow expérimental de détection des DGA.

Utilisation du workflow expérimental de détection des DGA

Nous avons constaté que le workflow expérimental de détection des DGA par ML détectait une grande partie de cette activité. Nous avons exécuté ces domaines DGA SUNBURST dans le modèle supervisé de détection des DGA que nous avons présenté dans cet article (lisez les sections précédentes pour en savoir plus sur le téléchargement et l'exécution de ce modèle et de ses règles). Résultat : le modèle a étiqueté 82 % des noms de l'ensemble en tant que DGA, ce qui aurait entraîné le déclenchement de 1 420 alertes. Voici une capture d'écran des noms DNS SUNBURST ayant été étiquetés comme DGA par le modèle supervisé :

Ces événements peuvent être convertis en alertes de détection à l'aide de la règle de détection Machine Learning Detected a DNS Request Predicted to be a DGA Domain. Nous pouvons également faire une copie de cette règle et la modifier pour la faire correspondre au domaine parent utilisé par une instance de malware spécifique comme SUNBURST. Nous pouvons établir des correspondances avec les événements DGA SUNBURST de cet ensemble en ajoutant un test à la requête de règle, comme suit :

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

Nous pouvons ensuite attribuer à cette règle un niveau de sévérité critique et un score de risque élevé de 99 afin de la placer en début de file d'attente d'analyse et d'alerte. Voici une capture d'écran des alertes générées par cette règle modifiée pour attirer l'attention sur la détection de l'activité des DGA SUNBURST :

Nous avons inclus cette règle, Machine Learning Detected DGA activity using a known SUNBURST DNS domain, dans le package. Dans des conditions d'infection réelle, les instances malware utilisant des DGA à haute fréquence pourraient entraîner la génération d'un nombre suffisant d'alertes pour déclencher le disjoncteur max_signals, défini sur 100 par défaut. Dans un tel cas, nous pourrions avoir des alertes pour certaines instances malware, et pour d'autres non, selon les premiers événements repérés par la recherche. 

Pour pouvoir identifier un plus grand nombre d'hôtes infectés ayant une activité DGA, nous avons accru la valeur max_signals dans les règles de recherche de DGA à 10 000. Remarque : Il n'est pas possible de modifier ce paramètre dans l'éditeur de règles. Pour cela, vous devez passer par un fichier de règle externe, que vous importerez. Pour afficher ce paramètre, ouvrez un fichier de règle dans un éditeur.

Dans les cas où l'activité des DGA est intense et où les alertes sont nombreuses, nous pouvons aussi agréger et passer au crible les alertes ou les événements DGA pour les compter par nom d'hôte ou IP source dans un tableau de données, comme ci-dessous :

Nous incluons aussi un exemple de tableau de bord pour les événements DGA Packetbeat qui contient des visualisations et des agrégations, notamment cette visualisation de tableau de données agrégée par source.ip. Si vous préférez, vous pouvez effectuer une agrégation sur host.name si vos événements DNS contiennent ce champ. Ce fichier s'appelle dga-dashboard.ndjson et peut être importé dans Kibana en sélectionnant Import (Importer) sur la page Saved Objects (Objets sauvegardés), accessible après avoir sélectionné Stack Management (Gestion de la suite).

Voici une capture d'écran de ce tableau de bord renvoyant les événements DGA dans un index packetbeat-* :

Nous sommes là pour vous aider

Vous n'êtes pas seul ! Si vous rencontrez des problèmes lors de cette procédure, ou si vous souhaitez tout simplement en savoir plus sur nos philosophies en matière de détection des menaces et de Machine Learning, contactez-nous sur le canal Slack de notre communauté, sur nos forums de discussion ou, si vous avez envie de vous retrousser les manches et de travailler avec nous, dans notre référentiel de détection ouvert. Merci et bonne détection !