Détection efficace des balises C2

Introduction

Les attaquants ajoutent à leurs malware des capacités nouvelles et sophistiquées de commande et contrôle (C2), qui contournent facilement les défenses statiques courantes reposant sur des signatures IPS ou des listes de blocage d’IP, de domaines ou d’URL, en utilisant des outils de framework C2 courants et largement disponibles tels que Cobalt Strike, Brute Ratel, Mythic, Metasploit, Sliver et Merlin. Ces outils fournissent des capacités post-exploitation, notamment de commande et contrôle, d’élévation de privilèges et d’actions sur l’hôte, et ont été conçus à l’origine pour les tests d’intrusion et les opérations d’équipe rouge.

Toutefois, les attaquants ont détourné et intégré ces mêmes boîtes à outils à des fins malveillantes, car de nombreux produits, tels que Mythic et Merlin, sont open source, tandis que d’autres produits commerciaux, comme Cobalt Strike et Brute Ratel, ont été dérobés par des attaquants au moyen de copies piratées ou de code source divulgué. Cela a effectivement transformé ces mêmes outils en frameworks C2 adverses destinés à une post-exploitation malveillante.

Les outils permettent de façonner et de modifier facilement de nombreux paramètres des communications C2, ce qui permet aux malware de contourner les défenses actuelles encore plus facilement et pendant de plus longues périodes, causant davantage de dommages au sein des réseaux des victimes, notamment : vol de davantage de données, découverte de données de plus grande valeur, indisponibilité d’applications ou de services métier et maintien d’un accès dissimulé aux réseaux en vue de dommages futurs.

Les approches actuelles de détection des malware les plus récents utilisant des frameworks C2 s’appuient sur des signatures et des indicateurs statiques, notamment la détection des exécutables d’implants, les signatures IPS pour la détection du trafic C2 et les filtres IP/URL, qui sont inadaptés aux profils dynamiques et malléables des outils de framework C2 largement disponibles.

Une nouvelle approche est nécessaire, qui ne soit pas aussi rigidement liée aux attaques connues, mais qui repose sur la détection d’anomalies à partir d’un ensemble complet de signaux alimentant des modèles d’apprentissage automatique entraînés, avec un suivi précis du risque associé aux appareils et aux utilisateurs. Cette approche complétera les approches existantes, mais peut considérablement augmenter les taux de détection tout en maintenant un faible nombre de faux positifs et en assurant une protection durable face à l’évolution des schémas de trafic C2, facilement rendue possible par ces mêmes outils de framework C2.

Ce document examine les lacunes des approches actuelles et l’efficacité accrue obtenue grâce à une approche ciblée d’apprentissage automatique intégrant des signaux réseau supplémentaires et des métriques de risque précises fondées sur des modèles au niveau de l’utilisateur et de l’organisation. Nous examinons également certains des principaux défis liés aux tests de l’efficacité de toute solution de détection des balises C2.

Frameworks C2 adverses

Cobalt Strike, Metasploit, Mythic et Brute Ratel font partie des outils commerciaux et open source de simulation d’adversaires conçus à l’origine pour tester la détection des malware par les équipes rouges. Ces boîtes à outils sont parfois appelées outils d’émulation des menaces ou frameworks C2, car elles offrent un ensemble riche de fonctionnalités (Gill) permettant de simuler une activité de menace réelle lors d’opérations d’équipe rouge, en mettant l’accent sur les parties de commande et contrôle post-exploitation de la chaîne d’attaque.

Nous pouvons employer certains de ces termes de manière interchangeable dans l’ensemble du document, mais nous utiliserons généralement « frameworks C2 » afin de souligner que ces outils sont utilisés par des acteurs malveillants pour affecter des environnements de production et que le problème à résoudre va bien au-delà des simulations ou émulations menées par des équipes rouges internes bienveillantes.

Ces outils de framework C2 ont été intégrés, piratés ou dérobés et utilisés par de nombreux attaquants (“Cobalt Strike : une opération internationale des forces de l’ordre s’attaque aux utilisations illégales de cet outil de test d’intrusion « couteau suisse »”), notamment des acteurs étatiques tels que l’APT29 russe dans SolarWinds (“L’attaque de la chaîne d’approvisionnement SolarWinds utilise la porte dérobée SUNBURST”) et le TA415 de la RPC (Larson et Blackford), afin d’améliorer et de faire évoluer les capacités de communication furtive de divers RAT, botnets et malware compatibles C2.

Cobalt Strike est l’outil de framework C2 le plus populaire, et nous l’utilisons comme exemple précis tout au long de ce document, bien que les observations s’appliquent à tous les outils similaires. Le diagramme d’architecture générale de Cobalt Strike ci-dessous présente ses composants de base (Rahman) et le flux d’attaque à l’exécution.

Cobalt Strike et les boîtes à outils similaires offrent une configurabilité simple et étendue du trafic HTTP/S, produisant un trafic C2 qui paraît souvent bénin, ressemble à un trafic HTTP/web normal et est similaire au trafic d’un navigateur web ou d’une application populaire. Les outils fournissent des configurations par défaut qui émulent à la fois des malware connus et des applications valides connues.

Bien que DNS soit également pris en charge en tant que protocole C2, nous concentrerons la discussion sur le C2 via HTTP/S, car il représente l’essentiel du trafic réseau entrant et sortant d’une organisation, est plus complexe en raison de la variété des applications utilisant HTTP/S et attire la majorité des acteurs malveillants qui tentent de se dissimuler dans le bruit du réseau, notamment parmi les balises C2 légitimes et bénignes.

Les boîtes à outils sont hautement configurables, au moyen de profils malléables, et peuvent facilement faire varier le calendrier, la fréquence, le volume, les protocoles applicatifs, les IP/domaines de destination, les agents utilisateurs, les en-têtes HTTP, les verbes HTTP, les URI, les paramètres, les certificats SSL/TLS, le délai des balises avec une gigue aléatoire, ainsi que la charge utile ou le contenu. Les outils de framework C2 permettent également un grand nombre d’actions post-exploitation, qui sont chiffrées, téléchargées et exécutées en mémoire, ce qui rend très difficile la détection de l’activité post-compromission sur les terminaux.

Nous nous concentrerons sur les capacités spécifiques de communication C2 des outils de framework C2, par exemple les balises C2, sur la facilité avec laquelle les communications sont modifiées, par exemple au moyen des C2 Malleable Profiles de Cobalt Strike, et sur les défis auxquels sont confrontées les organisations qui tentent de détecter des malware furtifs.

Plusieurs ressources de qualité décrivent le fonctionnement des Malleable Profiles de Cobalt Strike (Gill), mais nous mettrons en évidence certaines des fonctionnalités couramment utilisées. Voici un extrait du profil malléable permettant d’imiter l’application Gmail dans un navigateur avec Cobalt Strike (Mudge) :

Voici quelques-unes des principales fonctionnalités et sections du profil :

# Use an existing certificate or generate a self-signed certificate as seen in the above example.

# These global options below set the C2 beacon sleep time to 60 seconds with a
# random jitter of +/- 15%, showing the ability to vary the call-home timing to avoid
# easy detection.
set sleeptime “60000”;
set jitter “15”;

# Other global options specify on-host post-exploit action parameters such as the
# process name spawned to execute commands using in-memory injection or the
# pipename used for IPC communications. These are not relevant to C2.
set pipename “interprocess_##“;
set spawnto “userinit.exe”;

# The uri path used for beacon->server communications can be varied with a list
set uri “//scs/mail-static//js/”;

# Client (beacon->server) communications including cookies, headers, and encoding
# can all be specified and varied easily at the HTTP protocol level
client {
    metadata {}
    header {}
}

# Similarly, server->beacon communications can also be varied at the HTTP
# protocol level
server {
    header {}
}

# Cobalt Strike allows shaping of the 2-way communications flow between the
# Beacon client and C2 Team Server (“A Beacon HTTP Transaction Walk-through”):
# 0. http-stager {}    optional stager to download full Beacon
# 1. http-get {client}  client  — call home -> server
# 2. http-get {server}  server  — cmds -> client
# 3. http-post {client} client  — cmd output -> server
# 4. http-get {server}  server  — confirm -> client

Comme on peut le constater ci-dessus, de simples modifications de ces profils peuvent facilement changer le comportement des communications C2 afin d’imiter des applications courantes, leurs balises et leur trafic web. Plus de 240 profils malléables publics sont disponibles pour Cobalt Strike uniquement, prêts à l’emploi ou faciles à modifier.

Approches de détection actuelles

Les approches actuelles de détection du trafic C2 malveillant tendent à rechercher des correspondances avec des signatures d’octets codées en dur ou à utiliser des expressions régulières pour faire correspondre la charge utile ou les en-têtes (signatures IPS), ou reposent sur la mise en correspondance avec des listes d’IP, de domaines ou d’URL. Ces approches sont statiques et peuvent facilement être contournées grâce à la nature dynamique et configurable des boîtes à outils de framework C2 intégrées par les attaquants.

Signatures IPS

Afin d’illustrer les difficultés rencontrées par les solutions IPS, voici l’une des règles Snort permettant de détecter le cheval de Troie Zeus (Snort) :

Snort et de nombreuses solutions IPS permettent diverses correspondances de contenu ou d’en-têtes aux couches 3 et 4, ainsi qu’au niveau applicatif, comme l’indiquent les verbes d’action de la règle. De nombreuses correspondances, telles que l’option de règle content, sont des correspondances statiques d’octets ou de caractères, tandis que l’option de règle pcre correspond à une expression régulière.

Lorsque l’on examine côte à côte le point de vue de l’adversaire, par exemple le C2 Malleable Profile pour gmail présenté précédemment, et celui de la défense, par exemple la règle Snort pour Zeus, la fragilité et le caractère statique des correspondances codées en dur apparaissent clairement. Imaginons qu’un attaquant ait créé et déployé une nouvelle variante de Zeus utilisant Cobalt Strike et qu’un IPS Snort ait mis en place la règle Zeus ci-dessus, qui détecte efficacement le nouveau malware. L’attaquant pourrait facilement modifier un seul caractère dans le profil, par exemple en ajoutant une espace dans MSIE afin d’éviter la correspondance : content:"|3B 20|MSIE|20|"; le malware pourrait alors contourner la signature IPS.

Bien qu’il existe une connaissance contextuelle et un suivi d’état, l’approche fondée sur les signatures IPS est intrinsèquement limitée en raison de ses correspondances statiques, ce qui entraîne des faux négatifs et permet un contournement facile : la modification d’un seul caractère dans un seul champ pourrait littéralement contourner une règle IPS.

Cela ne signifie pas que les solutions IPS sont inutiles. Au contraire, les signatures IPS doivent être conservées, car elles constituent une défense périmétrique utile en bloquant de nombreux exploits réseau connus de manière rapide et efficace. Dans ce cas, même si un IPS n’atteignait qu’un taux de détection de 60 %, ces 60 % pourraient facilement être bloqués ou signalés, évitant ainsi un traitement coûteux en aval.

Listes de blocage d’IP/URL

D’autres approches traditionnelles, telles que l’utilisation de listes de blocage d’IP ou d’URL, sont souvent appliquées afin d’empêcher l’accès initial ou le téléchargement de malware lors de la navigation web, ainsi que pour bloquer un éventuel trafic C2.

Une difficulté courante liée aux listes de blocage tient au fait qu’elles sont souvent obsolètes, ce qui provoque des faux positifs, et qu’elles sont réactives, puisqu’elles sont mises à jour après la compromission de la cible nº 1 ou du patient zéro.

Ce problème est aggravé par les techniques d’indirection d’IP ou de domaine utilisées pour dissimuler le domaine ou l’adresse IP du serveur C2. Cobalt Strike dispose de redirecteurs, qui peuvent être de simples proxys IP, afin d’obscurcir le véritable domaine ou la véritable IP du serveur C2. Il existe également d’autres techniques, telles que le domain fronting utilisant des CDN ou le camouflage de domaine, qui exploitent les incohérences entre TLS (SNI) et HTTPS (hôte) pour masquer le domaine malveillant final à certains filtres de sécurité des URL.

Heuristiques du trafic réseau

Une autre approche consiste à utiliser des heuristiques, généralement appliquées aux schémas de trafic réseau en fonction du volume ou du temps. L’exemple classique consiste à détecter des communications sortantes régulières, par exemple toutes les 60 minutes, éventuellement vers une adresse IP ne disposant d’aucun enregistrement DNS A enregistré.

Pour contourner la détection, les boîtes à outils de framework C2 permettent de configurer facilement un facteur aléatoire dans le délai des balises au moyen du paramètre de gigue d’un Cobalt Strike Malleable Profile :

Figure 4 : paramètres du C2 Malleable Profile (calendrier des balises)

Ces paramètres définissent un intervalle de rappel de 60 secondes +/- 15 %, ce qui signifie que l’intervalle réel sera compris entre 51 et 69 secondes, permettant ainsi de contourner les vérifications simples recherchant des balises récurrentes à intervalles constants.

Efficacité

Le problème des approches actuelles est qu’elles ne détectent pas efficacement les communications C2 malléables et peuvent facilement être contournées, même lorsqu’elles sont spécifiquement ajustées. Elles sont utiles pour détecter efficacement les techniques d’attaque statiques associées à des indicateurs bien connus, mais elles ne détectent pas les attaques plus dynamiques ou sophistiquées, ou génèrent un grand nombre de faux positifs.

À titre de point de référence, lors de tests portant sur les C2 Malleable Profiles de Cobalt Strike les plus courants issus de dépôts publics, des solutions IPS prêtes à l’emploi telles que Snort et Suricata ont détecté nettement moins de 20 % des communications C2 provenant des boîtes à outils de framework C2 les plus courantes.

Même après l’ajout spécifique de règles visant à faire correspondre autant de profils publics que possible, en optimisant la configuration pour ce test précis, la couverture ne pouvait raisonnablement être portée qu’à environ 60 % sans introduire d’importants faux positifs, qui seraient très problématiques dans un environnement de production.

L’efficacité pose de nombreux problèmes : non seulement le nombre de faux positifs est plus élevé, mais la configuration qui en résulte est également construite de manière rigide pour le test précis concerné et peut facilement être contournée par de légères modifications des profils. En définitive, environ 40 % des profils restent non détectés, ce qui représente un taux de faux négatifs très élevé. Sans même compter les faux négatifs supplémentaires générés par un attaquant déterminé qui personnaliserait les profils C2 afin d’imiter des applications existantes bien connues d’une manière légèrement différente.

Nouvelle approche de détection

Une approche plus efficace est nécessaire. Elle ne doit pas reposer uniquement sur des indicateurs statiques, mais sur des modèles ciblés d’apprentissage automatique capables de détecter des anomalies dans le trafic réseau à l’aide d’une multitude de signaux réseau indiquant une activité suspecte de commande et contrôle par rapport au comportement normal des applications valides pour les utilisateurs concernés au sein de l’organisation concernée. En outre, des métriques de risque précises doivent être suivies au niveau de l’utilisateur afin de permettre les mesures d’atténuation les plus précises et les plus efficaces. Des innovations dans ces trois domaines sont nécessaires pour améliorer considérablement la détection des balises C2 furtives provenant des outils de framework C2 :

Signaux complets

Un ensemble complet de signaux est nécessaire et doit inclure les caractéristiques de la source, de la destination et du trafic, telles que les certificats SSL/TLS utilisés à la fois sur la source, c’est-à-dire le malware présent dans l’environnement, et sur la destination, c’est-à-dire le serveur C2, le domaine, l’IP ou l’URL, les caractéristiques de la source telles que celles de l’agent utilisateur ou du processus, la taille, les rafales et les schémas du trafic, ainsi que les en-têtes, la charge utile et l’URI HTTP, pour n’en citer que quelques-unes.

Lors de l’examen de différents signaux selon le temps, le volume, les couches réseau et le profilage global du trafic, la détection comportementale peut fournir un mécanisme général et efficace pour détecter les malware les plus récents grâce à une activité de balises C2 suspecte et malveillante.

Les types de signaux comportent plusieurs dimensions :

• Flux réseau : attributs de la source et de la destination, ainsi que schémas de trafic
• Couches réseau : différents signaux des couches 3 à 7, notamment des anomalies dans les en-têtes TCP/IP, les empreintes SSL/TLS, les en-têtes et charges utiles HTTP, ainsi que le contenu au niveau applicatif
• Temps : fréquence et schémas temporels anormaux permettant de détecter une activité peu fréquente et lente
• Données : contenu et volume, notamment tailles de paquets anormales, rafales et statistiques cumulées

Il existe en outre plusieurs types de signaux :

• Fondés sur les schémas de trafic (volume, calendrier, contenu), notamment des balises répétées associées à un agent utilisateur ou à un domaine inhabituel.
• Heuristiques (par exemple, bureaux d’enregistrement suspects ou empreintes SSL malveillantes connues)
• Anomalies (domaine, agents utilisateurs ou empreintes SSL inhabituels)

Il est important de noter que certains des signaux ci-dessus font partie des approches actuelles et des solutions existantes. Cela renforce l’idée qu’un signal particulier, tel qu’un pic de trafic, c’est-à-dire un volume important, n’est en soi ni bon ni mauvais, ni efficace ni inefficace. Le contexte et le traitement du signal constituent plutôt le facteur déterminant. Lorsqu’il est utilisé au niveau du périmètre réseau pour bloquer ou autoriser le trafic, un signal sujet aux faux positifs peut entraîner de graves problèmes opérationnels. Toutefois, lorsqu’il alimente un système de détection d’anomalies qui l’intègre à une métrique de risque granulaire, abordée ci-dessous, et à un modèle correctement entraîné, il peut se révéler extrêmement efficace pour détecter de nouvelles menaces de manière robuste, avec peu de faux positifs.

Détection d’anomalies

La détection efficace des balises C2 provenant des boîtes à outils de framework C2 nécessite des modèles d’apprentissage automatique fondés sur une gamme plus complète de signaux afin d’identifier les boîtes à outils de framework C2 actuelles et les futurs comportements réseau suspects susceptibles d’indiquer une activité C2.

La détection d’anomalies doit reposer sur des modèles au niveau de l’utilisateur ou de l’appareil, du rôle et de l’organisation. Autrement dit, les anomalies supposent que nous disposions d’une référence « normale » valide d’activité ou de comportement à laquelle effectuer une comparaison. La détection d’une activité suspecte peut survenir dans différentes circonstances. Certaines anomalies reposent sur la comparaison des actions d’un utilisateur avec sa référence « normale » historique, avec la référence « normale » de l’organisation ou avec les personnes occupant des rôles similaires. Chacune possède des cas d’usage valides distincts des autres, et une bonne approche intégrera plusieurs modèles ayant des portées différentes.

Données d’entraînement

Les ensembles de données d’entraînement doivent inclure du trafic malveillant et du trafic bénin :

• Le trafic malveillant peut être simulé à l’aide d’outils généraux de test C2, de tests spécifiques de balises C2 adverses fondés sur les configurations publiquement disponibles d’outils de framework C2, ainsi que de configurations personnalisées du point de vue d’une équipe rouge et d’exercices officiels d’équipe rouge.
• Le trafic bénin, ou trafic valide, est idéalement recueilli auprès d’un nombre significatif d’utilisateurs réels au sein d’organisations réelles, sur une période suffisamment longue pour permettre une normalisation tenant compte des biais propres aux utilisateurs et aux organisations.

Les ensembles de données d’entraînement constituent l’autre face des ensembles de données de test, et il convient de consacrer beaucoup de temps à l’analyse et à la validation de données d’entraînement et de test de qualité. Certains des facteurs nécessaires à la création de bons ensembles de données de test sont abordés dans une section ultérieure.

Métriques de risque granulaires

Le résultat de la détection d’anomalies est essentiel. La meilleure approche n’effectue pas de simples décisions de blocage ou d’autorisation, ni de signalement ou de silence, à partir d’un signal brut. Elle suit et ajuste plutôt des métriques de risque précises au niveau de l’utilisateur, du rôle et de l’organisation, qui peuvent ensuite servir à des mesures correctives telles que le signalement, l’accompagnement ou le blocage.

Cette approche du suivi du risque et des actions associées est fondamentalement différente de celle généralement utilisée aujourd’hui. La plupart des défenses périmétriques préventives qui bloquent, signalent ou autorisent habituellement le trafic sont généralement statiques et sujettes à des taux élevés de faux positifs. En conséquence, ces solutions sont activées avec une politique prudente visant à bloquer les risques certains et connus, ce qui ouvre ensuite la voie à un grand nombre de faux négatifs. Avec les pare-feu, nous constatons des problèmes de faux positifs lorsque des actions de blocage trop agressives reposent sur des renseignements sur les menaces liés aux IP. Concernant les solutions IPS, nous avons évoqué les difficultés posées par les faux positifs lorsque des signatures statiques tentent de détecter un trafic C2 hautement configurable et dynamique.

Cependant, les faux positifs au niveau d’une couche périmétrique peuvent constituer un signal très utile pour une couche plus intelligente. Dans ce scénario, nous ne les utiliserions pas pour une évaluation binaire, comme autoriser ou bloquer, signaler ou ignorer, mais comme une métrique de risque précise ajustée au fil du temps, par exemple un score de risque utilisateur, avec un seuil réglé avant toute action. Une métrique de risque granulaire, par exemple un score de risque allant de 1000, aucun risque, à 0, risque extrême, appliqué à un utilisateur, un appareil ou même une adresse IP, nous permet de modéliser le spectre de gris associé aux menaces réelles, pour lesquelles il est rare de pouvoir conclure qu’elles sont malveillantes ou bénignes à 100 %.

Sur le plan conceptuel, cela est représenté dans l’illustration suivante, où trois signaux différents peuvent être détectés et seraient, pris isolément, sujets aux faux positifs. Toutefois, lorsqu’ils sont associés à un risque incrémentiel et évalués par un modèle d’apprentissage automatique réglé, les mêmes signaux permettent d’évaluer le risque cumulé au fil du temps et aboutissent finalement à la détection d’une anomalie avec un niveau de confiance élevé.

Il convient de noter que les signaux de cet exemple peuvent ne pas être aussi simples que des signaux statiques. Par exemple, un « domaine inhabituel, un agent utilisateur non reconnu et un certificat SSL/TLS » pourrait constituer une anomalie par rapport à la référence « normale » historique du trafic de cet utilisateur précis, à celle d’utilisateurs occupant des fonctions similaires ou à celle de l’ensemble de l’organisation. Un « bureau d’enregistrement suspect » peut résulter d’un regroupement de la réputation de domaines corrélée au fil du temps. Et les « balises périodiques » ne correspondent plus simplement à un taux ou à une durée fixe, mais peuvent consister à détecter une activité anormale, régulière et répétée au sein d’une fenêtre temporelle, semblable à l’activité d’un bot plutôt qu’aux appels sortants valides du démon d’une application.

En pratique, cela nous permet d’ajuster un score de risque de façon incrémentielle et appropriée à partir d’un signal de faible fidélité. Aucune action de blocage ou de signalement n’est déclenchée tant que le score de risque cumulé ne dépasse pas un seuil élevé et réglé. Cela permet de traiter les cas dans lesquels de nombreux indicateurs de faible fidélité et légèrement risqués, lorsqu’ils sont associés à un indicateur de plus haute fidélité et présentant un risque plus élevé pour un utilisateur ou un appareil particulier, génèrent de manière cumulative une alerte de risque critique et une action, avec une probabilité de faux positifs considérablement réduite.

Évaluation et tests

Une nouvelle approche peut être théoriquement solide et échouer lamentablement en pratique ; la preuve dépend très souvent des données ou des tests. Les fournisseurs de solutions et les organisations qui recherchent des solutions ont besoin d’une approche robuste pour tester les nouvelles menaces et évaluer les solutions. Afin d’obtenir des résultats précis, il est essentiel d’effectuer les tests avec un ensemble de données diversifié comprenant du trafic malveillant et du trafic bénin.

Trafic bénin

Le trafic bénin doit être réaliste, complet et similaire à celui de la production en termes de nombre d’utilisateurs et d’activité. Le trafic légitime, souvent dépendant des utilisateurs, doit être étudié sur un large échantillon d’utilisateurs et pendant une période raisonnable. Cet ensemble de données de test mesurera les taux de faux positifs (FP). Les principales variations dans les ensembles de données concerneront les signaux du client, tels que les applications, les agents utilisateurs et les certificats SSL/TLS clients utilisés, les signaux de destination observés dans les domaines ou adresses IP de destination, ainsi que les signaux de schémas de trafic dans les en-têtes, la charge utile, la taille et le calendrier.

La bonne nouvelle est qu’un trafic bénin de qualité peut facilement être recueilli dans le cadre des activités quotidiennes des utilisateurs de l’organisation ; la mauvaise est qu’il doit être validé comme bénin. L’approche pratique consiste à échantillonner statistiquement le trafic bénin selon un facteur de confiance raisonnable, puis à consacrer la majorité du temps aux alertes émises par la solution de détection C2 testée, en vérifiant si elles constituent des vrais positifs ou des faux positifs. Autrement dit, il faut d’abord échantillonner et vérifier afin d’établir une référence, supposer que l’ensemble de données bénignes est propre, puis identifier les faux positifs au cours des tests.

Trafic malveillant

L’utilisation de profils publics issus d’outils de framework C2 populaires constitue une base solide pour tester le trafic malveillant. Ces profils représentent des configurations pratiques et fréquemment utilisées qui contournent les défenses, et permettent de mesurer les taux de faux négatifs (FN). Il convient toutefois d’accorder une grande attention à la création d’un ensemble de données représentatif de « trafic malveillant », car la couverture et les éléments testés par les ensembles de données peuvent comporter plusieurs niveaux, comme l’illustre le diagramme suivant :

1. Les outils de simulation de compromission et d’attaque, tels que SafeBreach, sont excellents pour les tests de couverture et les tests répétés. Leurs cas de test C2 comprennent généralement au moins une certaine simulation de l’activité des frameworks C2. Leur avantage réside dans l’étendue des fonctionnalités disponibles, notamment des attaques générales par malware, des interfaces graphiques et des architectures bien conçues, ainsi que des procédures de test et des rapports reproductibles. Ces outils peuvent fournir un large éventail de scénarios, notamment une activité faible et lente, une communication vers une infrastructure IaaS/CSP, du trafic HTTP et non-HTTP, du trafic SSL/HTTPS et l’usurpation de divers agents utilisateurs.
2. Outils de framework C2 (profils publics). Les tests approfondis des frameworks C2 nécessitent un travail ciblé. Une approche consiste à créer un ensemble de données de test fondé sur les profils publics spécifiques des outils de framework C2, par exemple Cobalt Strike. Ces profils malléables publics ont tendance à être largement partagés et utilisés par de nombreux utilisateurs et acteurs malveillants, car ils comprennent des émulations utiles d’applications bénignes telles que gmail. Cette approche fournit généralement des tests plus complets concernant les frameworks C2 concernés.
3. Outils de framework C2 (profils personnalisés). La personnalisation interne des C2 Malleable Profiles peut permettre des tests encore plus réalistes des frameworks C2. Ces configurations personnalisées peuvent être créées lors d’opérations internes d’équipe rouge. Cela exige davantage de travail et d’investissement, car les opérateurs de l’équipe rouge doivent maîtriser les outils de framework C2.
4. Attaques réalistes. Les tests les plus réalistes reposent sur des tests en boîte noire réalisés dans le cadre de tests d’intrusion externes ou de programmes de prime aux bugs. Dans ces scénarios, les exigences de l’exercice sont soigneusement conçues pour exiger ou encourager de véritables exploits POC utilisant des outils de framework C2 précis ou tout comportement de balise C2, avec pour condition d’éviter la détection pendant une certaine période. Les objectifs des exercices ne consistent pas uniquement à tester les vecteurs d’accès initial, ce qui est la norme, mais à se concentrer sur l’activité post-compromission en démontrant la capacité à installer une charge utile de porte dérobée associée à une activité C2 démontrée. Cela enrichit l’ensemble de données de test au-delà des frameworks C2 et permet de tester du code POC de porte dérobée comportant des communications C2 personnalisées. Cela constitue également un excellent test de la résilience de tout outil de détection face à un « attaquant » compétent utilisant des TTP différentes ou personnalisées.

Les tests peuvent faire appel à une ou plusieurs approches, mais des choix explicites doivent être effectués quant à la manière de créer, recueillir et valider les ensembles de données de test, ainsi qu’à la façon de mesurer les résultats attendus. La création et la collecte des ensembles de données de test sont très importantes afin que les tests puissent être automatisés et facilement répétés.

Il est également essentiel de mesurer des métriques complètes pendant les tests : vrais et faux positifs, vrais et faux négatifs. Bien que la collecte de toutes les métriques puisse sembler évidente, il est difficile d’être précis dans leur définition et clair et reproductible dans la méthodologie de mesure, ce qui conduit à des résultats trompeurs.

Objectifs de faux positifs et de faux négatifs

Compte tenu des nouvelles menaces furtives créées par les frameworks C2, les solutions de détection plus récentes ne disposeront pas de taux de FP et de FN largement reconnus. Il est toutefois essentiel de définir des objectifs de FP et de FN. Avec des ensembles de données de test dont la qualité est connue, des références peuvent être établies pour l’environnement actuel et ses utilisateurs ou appareils, permettant ensuite de définir des objectifs raisonnables par rapport à ces références.

Par exemple, supposons qu’une organisation disposant uniquement d’un IPS commence à évaluer de nouvelles solutions de détection C2 et ne sache pas clairement quels taux de FP/FN sont acceptables. Elle peut néanmoins établir des objectifs raisonnables en suivant une méthodologie de test telle que la suivante :

• Créer des données de test de qualité pour le trafic bénin à partir de données de production et pour le trafic malveillant à partir, par exemple, de profils C2 malléables publics pour Cobalt Strike, puis valider manuellement des échantillons de ces ensembles de données.
• Créer une méthodologie de test claire et reproductible en définissant les outils de test et de mesure.
• Mesurer toutes les métriques (TP/TN/FP/FN) pendant les tests.
• Tester les nouvelles solutions et comparer les métriques. Par exemple, l’IPS pourrait être spécifiquement réglé afin d’obtenir de meilleurs taux de TP pour le trafic malveillant, tout en veillant à mesurer et à valider également les taux de FP/TN/FN. L’efficacité des différentes solutions peut alors être correctement évaluée, notamment en ce qui concerne l’impact total sur l’organisation décrit dans la section Impact ci-dessous.
• Tester de nouveaux ensembles de données et les comparer. Il convient de personnaliser les ensembles de données afin qu’ils reflètent des ajustements raisonnables effectués par un attaquant. Plusieurs méthodes sont possibles.
  • Par exemple, lors de tests de Cobalt Strike, ses C2 Malleable Profiles peuvent être facilement modifiés afin d’émuler des applications bénignes d’une manière légèrement différente ou d’émuler des applications bénignes entièrement nouvelles utilisées au sein de l’organisation concernée. Cela peut être réalisé en capturant le trafic HTTP/S sortant au moyen d’un proxy.
  • Tester non pas un seul, mais plusieurs outils de framework C2, car leurs capacités et leurs techniques diffèrent. L’utilisation d’un autre outil de framework C2 constitue également une modification pertinente, puisque la mise en forme de son trafic C2 sera différente.
  • La création d’une charge utile de test personnalisée disposant de ses propres communications C2 codées manuellement constitue une autre méthode de modification des ensembles de données de test, mais elle exige le plus de temps et d’investissement.

Tests de résilience

En effectuant des tests avec de nouveaux ensembles de données sur différentes solutions, nous obtenons également des informations précieuses sur la rigidité ou la résilience des différentes solutions. Dans ce document, nous avons souligné que les approches codées en dur et fondées sur des signatures sont non seulement moins efficaces pour détecter les frameworks C2, mais également rigides, ce qui entraîne des taux élevés de FP/FN et permet un contournement facile grâce à de simples modifications de l’attaque, telles que des changements apportés aux profils malléables.

La résilience de toute solution peut être testée en veillant à ce que les ensembles de données soient modifiés dans des limites raisonnables, c’est-à-dire en restant dans la même catégorie de TTP. Autrement dit, nous pouvons effectuer un test de résilience réaliste en modifiant les communications C2 au sein de l’ensemble de données de trafic malveillant à l’aide de profils C2 malléables et en surveillant les taux de TP/TN/FP/FN. Nous observons ainsi les variations de la couverture et comprenons également les modifications à apporter à la solution de détection afin de maintenir la couverture pour des objectifs particuliers de TP/TN/FP/FN.

Répéter les tests avec des ensembles de données modifiés de cette manière revient à simuler un changement de TTP par un attaquant. Cela permet d’évaluer la résilience et l’efficacité de la nouvelle solution de détection en déterminant si elle est toujours capable de détecter des modifications relevant de la même catégorie de technique de menace, à savoir les communications C2 via HTTP/S.

Impact des faux positifs et des faux négatifs

La mesure des taux de FP/FN est utile et permet d’évaluer les améliorations relatives, mais nous devons également mesurer, ou au moins estimer, l’impact des FP et des FN. Sans cela, il est impossible d’évaluer l’utilité réelle d’une solution de détection. Autrement dit, un taux de FP de 1 % ou une amélioration de 5 % du taux de FP ne fournit aucun contexte tant que nous ne pouvons pas mesurer l’impact de ce 1 % ou de ces +5 % d’une manière pertinente pour les décideurs responsables du budget de sécurité.

Voici deux approches permettant de traduire les taux de TP/TN/FP/FN en un impact plus quantifiable :

1. Impact sur les utilisateurs au fil du temps : examiner le nombre absolu de faux positifs correspondant aux taux de FP et le normaliser sous forme de taux par utilisateur au fil du temps. Il s’agit d’une mesure qualitative, mais elle est souvent plus parlante que des taux en pourcentage ou des nombres absolus. Par exemple, plutôt que 1 % de FP ou 2 437 faux positifs, il peut être plus facile d’évaluer l’impact de 0,1 faux positif par utilisateur et par jour. S’il s’agissait d’une passerelle web sécurisée, une personne de l’organisation pourrait déterminer si un objectif donné de FP est acceptable en fonction de l’impact sur les utilisateurs au fil du temps. Dans le cas présent, les malware reposant sur un framework C2 entraînent des compromissions, et l’impact sur les utilisateurs se caractérise davantage par des interruptions de service ou des pertes de données par utilisateur sur une période donnée. Nous avons N % de probabilité de subir une perte de X $ par utilisateur chaque année. Il s’agit souvent d’estimations approximatives, mais tout point de départ est utile, car il peut être révisé et amélioré au moyen d’itérations régulières. Si l’impact est évalué en termes d’utilisateurs au fil du temps, il devient alors facile d’évaluer les solutions de détection ou de protection, dont la tarification repose souvent sur le nombre d’utilisateurs par an.
2. Impact sur les opérations de sécurité en termes de temps, d’argent et de probabilité de compromission. Outre l’impact sur les utilisateurs finaux, il convient d’évaluer l’impact administratif, en particulier sur les équipes opérationnelles qui consacrent souvent du temps au traitement des alertes de détection. Le temps consacré à répondre à des alertes bruyantes peut être directement converti en coût salarial en équivalents temps plein. Le facteur supplémentaire de fatigue liée aux alertes constitue un impact réel qui peut être estimé en termes d’efficacité, notamment le délai de réponse, et surtout de perte de temps et d’attention au détriment des menaces ayant un impact véritablement plus élevé, qui sont perdues ou ne font pas l’objet d’une enquête. Ce dernier impact devient un facteur de l’impact d’une compromission : les compromissions sont plus susceptibles de se produire lorsque les opérations de sécurité doivent examiner et supprimer un trop grand nombre de faux positifs.

Une évaluation d’impact constitue souvent le seul moyen d’obtenir des informations cruciales, telles que le coût réel de l’efficacité de la détection. Par exemple, une solution de détection excessivement agressive, configurée avec peu de FN mais beaucoup de FP, est inutile et nuisible, car les opérations de sécurité consacrent un temps excessif à répondre à des alertes de faible fidélité au lieu de mener des activités offrant un meilleur effet de levier. De même, une solution de détection excessivement prudente, présentant peu de FP mais beaucoup de FN, expose l’organisation à un risque élevé de compromission potentielle, ce qui peut être inacceptable du point de vue de l’évaluation globale des risques.

L’impact doit être estimé et évalué en même temps que les métriques fondamentales TP/FP/TN/FN.

Tests réalistes

Faire intervenir une équipe rouge composée d’humains, et pas uniquement des outils automatisés de simulation de compromission ou de test d’intrusion. Il est fortement recommandé d’utiliser non seulement des utilisateurs et des environnements de production pour tester les solutions de détection des balises C2, mais également des scénarios adverses réalistes, tels que des tests d’intrusion ou des programmes de prime aux bugs. En ajustant le montant des primes et les exigences afin de démontrer explicitement l’implantation et la réussite d’actions post-exploitation réalisées avec des boîtes à outils de framework C2 populaires, nous pouvons rendre le « trafic malveillant » réel et mesurable. Cela pourrait être étendu à toute activité de balise C2, notamment à du code personnalisé visant à tester la résilience de la solution de détection. Les exigences de test devraient comprendre la démonstration d’une activité quotidienne réussie de balise et de l’exécution de commandes pendant une semaine, sans détection.

Si un test d’intrusion externe ou un programme de prime aux bugs est répété, les différences entre les taux de détection seront mesurables et utiles pour évaluer l’efficacité et le ROI.

Grâce à une approche rigoureuse des tests, l’efficacité sera non seulement mesurée de manière complète, mais des objectifs continus pourront également être définis par rapport à une référence actuelle ou historique. Et bien entendu, si les mêmes tests et mesures sont effectués pour plusieurs solutions, il devient trivial de comparer les performances et de prendre des décisions d’achat ou de mise en œuvre.

Considérations de conception

La recherche et la conception relatives à ces concepts et à l’approche globale sont examinées plus en détail dans : Systèmes et méthodes de sécurité pour détecter une commande et un contrôle malléables (Mulugeta).

Avantages

Détection d’anomalies liées à de nouvelles menaces inconnues

Cette approche atténue efficacement les menaces inconnues en exploitant des modèles d’apprentissage automatique entraînés sur le comportement des applications propre aux utilisateurs d’une organisation. La métrique granulaire du risque utilisateur réduit considérablement les faux positifs.

En revanche, les approches réactives existantes reposent sur l’identification d’une première victime ou d’un patient zéro, un agneau sacrifié pour le bien commun, suivie d’une analyse et de recherches menées par le fournisseur, qui peuvent prendre plusieurs jours, voire plusieurs mois, avant qu’il publie une nouvelle signature ou règle permettant de bloquer la nouvelle menace pour les clients qui n’ont pas encore été attaqués. De par sa conception, cette approche est inefficace pour bloquer les menaces malléables nouvelles et émergentes.

Une approche de détection d’anomalies exploitant des modèles d’apprentissage automatique précis et réglés peut détecter de manière unique les comportements suspects sans nécessiter de cycle d’analyse, de publication et de mise à jour. L’approche conserve sa robustesse même lorsque les tactiques de menace évoluent.

Analyse complète des signaux

La détection d’anomalies dans un ensemble complet de signaux, tels que le temps, le volume, les communications TCP/IP, les empreintes SSL/TLS et les charges utiles des protocoles applicatifs, peut détecter efficacement des communications C2 malléables sophistiquées.

Détection des boîtes à outils adverses

Cette approche peut détecter efficacement l’utilisation des outils de framework C2 et des frameworks C2 les plus récents, ainsi que les activités de balises C2 nouvelles et suspectes, en s’appuyant sur la détection d’anomalies à partir d’un large éventail de signaux réseau propres aux utilisateurs de l’environnement et en les comparant au trafic valide et bénin de cet environnement.

Efficacité de la détection

Les approches actuelles, à savoir les signatures IPS et les blocages d’IP, de domaines ou d’URL, ne détectent pas une part importante des communications C2 avancées présentes dans les malware les plus récents, soit entre 40 % et 80 % selon les scénarios de test.

En utilisant une nouvelle approche reposant sur un modèle d’apprentissage automatique réglé, la détection d’anomalies dans un riche ensemble de signaux et une métrique de risque granulaire, il est possible de détecter plus de 85 à 95 % de ces attaques qui contournent actuellement les défenses.

Il en résulte un taux global de détection des vrais positifs supérieur à 95 %, avec un nombre minimal de faux positifs.

Conclusion

Les boîtes à outils de framework C2 ont fourni aux attaquants des techniques sophistiquées permettant de contourner la détection des communications de commande et contrôle (C2). Des boîtes à outils largement disponibles, telles que Cobalt Strike, Brute Ratel et Mythic, sont notamment accessibles sous forme de code open source ou de code commercial piraté ou dérobé.

Les approches statiques traditionnelles, qui reposent fortement sur des signatures et des indicateurs statiques tels que des listes de blocage d’IP/URL, présentent de graves limitations et peuvent facilement être contournées par ces menaces en constante évolution.

Pour relever ce défi, une approche fondamentalement différente exploitant des modèles d’apprentissage automatique est nécessaire. Ces modèles intègrent un ensemble complet de signaux réseau et sont spécifiquement entraînés au niveau de l’utilisateur et de l’organisation. Ils utilisent également des métriques précises du risque utilisateur afin de réduire les faux positifs et de mesurer les nuances souvent associées aux menaces.

L’efficacité des approches d’apprentissage automatique doit être soigneusement évaluée par les utilisateurs. Des tests rigoureux menés sur un environnement de test robuste comprenant du trafic malveillant et du trafic bénin sont essentiels pour déterminer leur efficacité à détecter et à atténuer ces nouvelles menaces.

Références

1. « Cobalt Strike : une opération internationale des forces de l’ordre s’attaque aux utilisations illégales de cet outil de test d’intrusion “couteau suisse”. » The Record from Recorded Future News, 3 juillet 2024, https://therecord.media/cobalt-strike-law-enforcement-takedown. Consulté le 23 août 2024.
2. Gill, Andy. « Comprendre les profils Cobalt Strike – mise à jour pour Cobalt Strike 4.6. » ZSEC Blog, 13 avril 2022, https://blog.zsec.uk/cobalt-strike-profiles/. Consulté le 23 août 2024.
3. Larson, Selena, et Daniel Blackford. « Cobalt Strike : de l’outil APT favori au crimeware. » Proofpoint, 29 juin 2021, https://www.proofpoint.com/us/blog/threat-insight/cobalt-strike-favorite-tool-apt-crimeware.
4. Mudge, Raphael. « Malleable C2 Profiles : gmail. » Malleable-C2-Profiles normal gmail.profile, rsmudge, 28 février 2018, https://github.com/rsmudge/Malleable-C2-Profiles/blob/master/normal/gmail.profile.
5. Mulugeta, Dagmawi. « Systèmes et méthodes de sécurité pour détecter une commande et un contrôle malléables. » Free Patents Online, 20 août 2024, https://www.freepatentsonline.com/12069081.html.
6. Rahman, Alyssa. « Cobalt Strike | Définition des composants de Cobalt Strike et de BEACON. » Google Cloud, 10 décembre 2021, https://cloud.google.com/blog/topics/threat-intelligence/defining-cobalt-strike-components/.
7. Snort. « SID 1:25050. » Règle Snort : connexion sortante de la variante MALWARE-CNC Win.Trojan.Zeus, https://www.snort.org/rule_docs/1-25050.
8. « L’attaque de la chaîne d’approvisionnement SolarWinds utilise la porte dérobée SUNBURST. » Google Cloud, 13 décembre 2020, https://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor/.