Techniques de détection des botnets permettant d'identifier les systèmes de commande et de contrôle (C2) modernes

Ce guide traite uniquement de la couche de détection : comment les analystes SOC et les ingénieurs en détection identifient l'activité des botnets sur le réseau, et quelles sont les limites de chaque technique. Si vous avez besoin des notions de base — qu'est-ce qu'un botnet, comment le malware se propage, ainsi que les principales familles —, commencez plutôt par consulter la page de référence.

La détection des botnets consiste à identifier les hôtes compromis en analysant le comportement réseau généré par leur trafic de commande et de contrôle (C2) — périodicité des balises, anomalies DNS et empreintes des canaux chiffrés — plutôt qu’en comparant ces éléments à des signatures connues. Étant donné que chaque bot doit communiquer avec son contrôleur pour être opérationnel, le canal de contrôle constitue le point d’observation le plus fiable.

Des signatures au comportement : pourquoi la détection des botnets ne se limite plus aux indicateurs de compromission (IOC)

Comment détecte-t-on les botnets ? Dans la pratique, grâce à l’analyse comportementale du canal de contrôle : périodicité des balises, activité DNS anormale (telle que les requêtes DGA [algorithme de génération de domaines] et le « fast flux »), empreintes de sessions chiffrées et comportement au niveau des flux. La comparaison des signatures et des indicateurs de compromission (IOC) a toujours sa place, mais elle ne permet de détecter que les infrastructures qui ont déjà été identifiées, signalées et répertoriées.

Les listes de réputation d'adresses IP et de noms de domaine constituent le minimum requis. Une liste noire empêche les bots de masse de réutiliser l'infrastructure du mois dernier, tandis qu'un système de détection et de prévention des intrusions (IDS/IPS) basé sur des signatures signale de manière fiable les charges utiles et les protocoles de communication C2 pour lesquels il dispose de définitions. Le problème réside dans la obsolescence : chaque entrée décrit une infrastructure ou un outil qu'un attaquant peut remplacer en quelques minutes ; une liste perd donc de sa valeur dès sa publication.

Le taux de rotation est mesurable. Dans son rapport « Botnet Threat Update » couvrant la période de janvier à juin 2026, Spamhaus a observé que Sliver avait dépassé Cobalt Strike en tant que framework C2 le plus répandu, avec une hausse de 58 % en six mois, tandis que le nombre de serveurs de commande et de contrôle (C&C) de botnets qu’il a recensés a chuté de 30 % pour s’établir à 14 952. Spamhaus a également constaté une hausse de 771 % des domaines C&C .cn, tandis que les enregistrements détournés auprès du registraire REGRU ont chuté de 90 % — les opérateurs se délocalisent en masse dès que la pression s'intensifie. Toute détection reposant sur des signatures spécifiques à un framework poursuit une cible qui évolue plus rapidement que ne le permet le pipeline de signatures. Pour avoir une vision de ce renouvellement du point de vue d'un défenseur, découvrez à quoi ressemble le fonctionnement des balises Sliver dans la pratique.

La détection comportementale inverse la problématique. Au lieu de répertorier les artefacts connus pour être malveillants, on établit une base de référence sur la manière dont les hôtes communiquent normalement — destinations, timing, volumes, protocoles — et on met en évidence les écarts compatibles avec un canal de contrôle. La détection des anomalies réseau fournit cette discipline de référence ; les sections suivantes l’appliquent aux signaux qu’un botnet ne peut s’empêcher de produire. Un bot peut changer de framework, de domaine et de serveur du jour au lendemain. Ce qu’il ne peut pas faire, c’est cesser de se connecter, cesser de résoudre ses points de rendez-vous ou cesser d’envoyer le même client partout — et chacun de ces comportements est observable.

Détection des signaux de commande et de contrôle

Le « beaconing » désigne la fréquence à laquelle un bot effectue des vérifications auprès de ses commandement et contrôle serveur : l'implant se met en veille, se réveille, demande une tâche, puis se remet en veille. Ce rythme est le signal le plus caractéristique d'un botnet sur un réseau, et le détecter relève d'un problème de synchronisation, et non d'un problème lié à la charge utile. MITRE suit le transport sous la forme T1071, protocole de la couche application, car les enregistrements s'effectuent généralement via le protocole HTTPS ou le système DNS standard.

Le détecteur « naïf » repose sur le principe de la périodicité. Il regroupe les flux par paire d’hôtes, calcule les intervalles entre les connexions successives et recherche une distribution trop régulière : un temps d’inactivité fixe de 60 secondes produit des temps d’intervalle entre les arrivées quasi identiques, ce qu’aucun comportement de navigation humain ne génère. Une faible variance sur des dizaines d’observations en fait un candidat sérieux au statut de balise.

Les attaquants le savent, c’est pourquoi tous les frameworks C2 sérieux intègrent une fonctionnalité de « jitter » : chaque intervalle de pause est aléatoire dans une fourchette configurée, ce qui étale la distribution des arrivées jusqu’à ce que les simples seuils de variance cessent de se déclencher. La comparaison naïve des intervalles échoue dans ce cas. Mais le « jitter » aléatoire ne fait que randomiser chaque intervalle individuellement — il ne supprime pas le calendrier sous-jacent.

L'analyse dans le domaine fréquentiel exploite cette faiblesse. En transformant la chronologie des connexions dans le domaine fréquentiel — la transformée de Fourier étant l'outil standard —, une balise récurrente concentre l'énergie en un pic correspondant à sa fréquence de connexion sous-jacente. La gigue élargit ce pic ; elle ne l'efface pas. Tant que la balise se répète, il est possible de déterminer sa fréquence fondamentale, une approche qui a été démontrée publiquement contre un système C2 soumis à la gigue.

‍

Les enregistrements de flux constituent la base concrète de tout ce processus : ils contiennent les horodatages, le nombre d'octets et les durées dont l'analyse a besoin, sans qu'il soit nécessaire de capturer la charge utile. L'analyse du trafic réseau aborde cette méthodologie de manière approfondie.

Identifiez les modes de défaillance avant le déploiement. Les balises « low-and-slow » qui restent inactives pendant des heures peuvent se produire trop rarement pour être résolues dans votre fenêtre d’analyse. Les callbacks déclenchés par des événements liés à l’activité des utilisateurs ne présentent jamais de fréquence stable. Et les entreprises regorgent de périodicités légitimes — NTP, vérifications de mises à jour, agents de télémétrie, sondes de surveillance — ; la périodicité à elle seule sert donc à générer une liste restreinte, et non à rendre un verdict. Vérifiez les candidats en tenant compte de la rareté des destinations, de la cohérence de la taille des sessions et des signaux DNS présentés dans la section suivante avant même qu’un analyste ne voie une alerte.

Détection basée sur le DNS — DGA et « fast flux »

Les bots sont confrontés à un problème de « rendez-vous » : ils doivent retrouver leur contrôleur même après la saisie de leurs noms de domaine. Or, les deux solutions dominantes — les algorithmes de génération de noms de domaine et le « fast flux » — laissent toutes deux des traces partout dans le DNS.

Un DGA génère régulièrement un grand nombre de noms de domaine candidats ; l'opérateur n'en enregistre que quelques-uns, et chaque bot parcourt la liste jusqu'à ce que l'un d'entre eux soit valide. MITRE répertorie cette technique sous le nom de T1568.002, et sa stratégie de détection DET0419 (analyses AN1178–AN1181) formalise les signaux sur lesquels les défenseurs se sont mis d'accord : des noms de domaine présentant une entropie de caractères élevée et une faible similarité lexicale avec le langage naturel, des requêtes répétées vers des domaines inconnus, et — l'indice le plus révélateur — des échecs NXDOMAIN persistants lorsqu'un hôte explore des candidats qui n'ont jamais été enregistrés.

Fast Flux s'attaque au modèle de désactivation sous un autre angle : le nom de domaine reste inchangé tandis que l'infrastructure qui le sous-tend est renouvelée. Le Avis « Five Eyes » de 2025 concernant les variations rapides de flux décrit le « flux simple », dans lequel les enregistrements A alternent entre les hôtes compromis, et le « flux double », dans lequel les serveurs de noms alternent également — selon MITRE, T1568.001 (DET0485). Ses indicateurs sont concrets : des valeurs de durée de vie (TTL) si faibles qu’un domaine peut changer d’adresse IP toutes les 3 à 5 minutes, des dizaines voire des centaines d’adresses IP renouvelées chaque jour, et une géolocalisation incohérente entre les différentes résolutions d’un domaine. L’avis explique également pourquoi le blocage des adresses IP échoue : chaque adresse est retirée avant que la liste noire ne puisse se propager. Le DNS peut également servir de canal C2, suivi sous la forme de T1071.004 (DET0400).

Les signaux DNS à haut rendement, classés selon l'ordre dans lequel la plupart des équipes les vérifient :

1. Des noms de domaine à forte entropie, d'apparence aléatoire et sans signification lexicale
2. Pics prolongés de NXDOMAIN provenant d'un seul hôte interne
3. Domaines nouvellement enregistrés ou inconnus jusqu'à présent faisant l'objet de requêtes répétées
4. Durées de vie (TTL) DNS anormalement courtes — de quelques secondes à quelques minutes
5. Un domaine qui renvoie quotidiennement vers des dizaines ou des centaines d'adresses IP
6. Géolocalisation incohérente entre les adresses IP résolues d'un domaine
7. Rotation des enregistrements de serveurs de noms (NS) parallèlement à celle des enregistrements A
8. Enregistrements de flux indiquant de nombreuses connexions de courte durée vers des adresses IP changeantes

‍

Le DGA et le « fast flux » génèrent des signaux DNS distincts, chacun présentant un faux signal inoffensif différent.

Cette deuxième colonne de risques est structurelle, et l’avis l’indique clairement : distinguer le « fast flux » malveillant du comportement légitime des CDN et des équilibreurs de charge « reste un défi permanent ». Les TTL faibles et les adresses IP tournantes caractérisent tous les principaux CDN. C’est le contexte qui permet de les différencier : les rotations des CDN restent confinées à des plages d’hébergement bien connues, tandis que le « fast flux » passe par un grand nombre d’hôtes compromis, utilisés de force comme proxys et points de relais. Commencez par établir une base de référence pour vos journaux de résolveur ; chaque signal mentionné ci-dessus correspond à une mesure d’écart, et non à une valeur absolue.

Détection d'un canal de commande et de contrôle (C2) chiffré sans décryptage

Lorsque le canal C2 est chiffré — MITRE répertorie cette technique sous le nom de T1573, Canal crypté — L'inspection de la charge utile ne donne aucun résultat, et le déchiffrement à grande échelle est souvent irréalisable : l'interception TLS est coûteuse, et les implants qui fixent des certificats refusent tout simplement de se connecter via ce protocole. La solution pratique consiste à identifier le client sans toucher au texte en clair.

L'empreinte TLS génère un hachage des paramètres proposés par un client lors de la négociation de connexion — versions, suites de chiffrement, extensions —, tous visibles avant le début du chiffrement. Un implant C2 intègre une seule pile TLS, de sorte que sa procédure d’établissement de connexion est identique quel que soit l’endroit où il se pose. C’est JA3 qui a créé l’empreinte digitale d’origine, mais en 2023, Chromium a commencé à randomiser l’ordre des extensions TLS, ce qui a compromis la stabilité de JA3 pour une grande partie du trafic web et a motivé la création de son successeur, JA4, spécifié par FoxIO. JA4 résiste à cette randomisation, et la suite plus complète JA4+ va au-delà du protocole TLS pour établir l’empreinte digitale du trafic TCP lui-même. Zeek a ajouté la prise en charge native de JA4 en janvier 2026, mettant ainsi cette technique à la portée de toute équipe utilisant des outils open source de surveillance réseau.

Or, les sources primaires ne précisent pas certains aspects : ni la spécification JA4 ni le document technique de Zeek ne quantifient les faux positifs, les collisions ou la dérive. Ces deux problèmes sont bien réels. Les empreintes entrent en collision : des milliers d’applications inoffensives partagent des bibliothèques TLS communes ; ainsi, un hachage correspondant à un implant connu peut tout aussi bien correspondre à un outil ordinaire reposant sur la même pile. Les empreintes dérivent également : chaque mise à jour d’un client peut modifier la poignée de main, rendant vos listes de correspondances obsolètes sans que vous vous en rendiez compte. Considérez une empreinte comme un signal de corrélation, jamais comme un verdict.

Voici le principe général de la détection tenant compte des techniques d'évasion. Le chiffrement supprime la charge utile mais préserve la poignée de main et la synchronisation ; ainsi, l'identification par empreinte digitale s'associe à l'analyse des métadonnées issue de la section consacrée aux balises : la durée des sessions, la répartition de la taille des paquets et les ratios d'octets restent tous observables dans le trafic chiffré. L'intérêt de modéliser le comportement C2 plutôt que de le déchiffrer s'applique à l'ensemble de cette pile.

La détection par apprentissage automatique et le problème des faux positifs

Les résultats publiés concernant la détection des botnets par apprentissage automatique semblent spectaculaires. Une étude de 2024 a fait état d’un taux de faux positifs (FPR) de 1,53 % sur le jeu de données IoT-23, tout en identifiant 100 % des communications C2 basées sur les paquets et 94 % de celles basées sur les flux. Un article de 2025 consacré aux classificateurs empilés a fait état d’une précision de 97,94 % sur le jeu de données UNSW-NB15, avec une précision de 99,99 % sur son ensemble d’apprentissage. Lisez attentivement les détails avant d’établir votre budget en vous basant sur des chiffres comme ceux-ci.

Commençons par définir ce que sont ces ensembles de données. IoT-23 est constitué de véritables malware sur du matériel réel — mais dans un laboratoire contrôlé, et non sur un réseau de production. UNSW-NB15 est quant à lui un trafic synthétique généré par un outil de test IXIA. Aucun des deux ne contient le trafic chaotique, instable et non conforme aux politiques d’une entreprise en activité, qui est précisément à l’origine des faux positifs. Les mesures de précision des tests de performance sont adaptées à ces derniers.

Passons maintenant aux chiffres — et précisons d’emblée qu’il s’agit là de notre interprétation, et non d’une affirmation avancée par l’une ou l’autre de ces études. Un taux de faux positifs (FPR) de 1,53 % peut sembler négligeable jusqu’à ce qu’on le multiplie par le taux de base : sur un million de flux par jour, un volume modeste pour une entreprise de taille moyenne, 1,53 % correspond à environ 15 300 fausses alertes quotidiennes. Aucun SOC ne procède à ce tri. Selon la même logique, nous interprétons une précision d’entraînement de 99,99 % comme un signe classique de surapprentissage : le modèle a mémorisé son environnement de test, et les résultats obtenus en laboratoire ne sont pas transposables.

Les résultats des tests de performance mesurent la conformité par rapport à la référence, et non les performances sur le trafic réel de l'entreprise.

Rien de tout cela ne rend le ML inutile — cela fait de l’ingénierie de précision le véritable travail. Il faut limiter les modèles à des questions précises et bien définies, corréler leurs résultats avec la périodicité et les signaux DNS mentionnés plus haut, enrichir les candidats à l’aide de renseignements sur les menaces, et exclure les services périodiques connus pour être inoffensifs avant que le système ne déclenche une alerte. Cette discipline de réglage, c’est l’ingénierie de détection, et c’est ce qui distingue un benchmark d’un détecteur. Cette leçon s’applique indépendamment des fournisseurs : c’est le taux de base, et non le modèle d’un produit en particulier, qui explique pourquoi toutes les catégories de détection sont confrontées à des faux positifs liés aux botnets.

Détection des botnets décentralisés, sans agent et P2P

Les botnets modernes sont de plus en plus souvent constitués d’appareils qui ne sont gérés par aucune équipe de sécurité. Sur le réseau de Cloudflare, la vague d’attaques DDoS d’une ampleur sans précédent de fin 2025 — que Cloudflare attribue au botnet Aisuru-Kimwolf — a été attribuée à un ensemble d’« appareils principalement des téléviseurs Android » estimé entre 1 et 4 millions d’hôtes. En mars 2026, le ministère américain de la Justice et ses partenaires internationaux ont démantelé l’infrastructure à l’origine de quatre botnets qui avaient compromis plus de trois millions d’appareils IoT, comme l’a rapporté Krebs on Security. Personne n’installe endpoint sur un téléviseur : pour les appareils IoT non gérés, la colonne endpoint est vide par nature, et le réseau est le seul endroit où la détection peut avoir lieu.

La télémétrie Endpoint celle au niveau du réseau permettent d'observer deux facettes distinctes d'un botnet, et seule la télémétrie au niveau du réseau couvre les appareils sans agent.

Les botnets utilisant des proxys résidentiels aggravent le problème. En 2026, le groupe de veille sur les menaces de Google (GTIG) a décrit le réseau de proxys NetNut/Popa: au moins deux millions d’appareils enregistrés via des SDK intégrés dans des téléviseurs connectés et des boîtiers de streaming, avec 316 groupes de menaces distincts observés utilisant des nœuds de sortie présumés de NetNut en une seule semaine. Ce trafic provient de l'espace d'adressage habituel des FAI grand public ; les heuristiques de réputation et de géolocalisation le jugent donc inoffensif — bien que les primitives de flux et de géolocalisation mentionnées dans l'avis sur le « fast flux » s'appliquent toujours.

Les architectures peer-to-peer suppriment totalement le serveur central : il n'y a pas de serveur C2 unique vers lequel rediriger le trafic, et l'analyse des flux ne suffit pas à elle seule à garantir la détection. Les méthodes basées sur les graphes modélisent plutôt la topologie des communications — les détecteurs topologiques publiés ont affiché un score F1 moyen de 99,140 %, bien que ces résultats datent de 2020 et aient été obtenus sur des topologies de référence. Il convient de considérer cela comme une preuve, issue de la recherche, de l'efficacité de l'approche, et non comme une fonctionnalité prête à être déployée.

Les opérations de démantèlement illustrent le même phénomène sous un autre angle. Europol a fait état de la saisie de 1 025 serveurs dans le cadre de l’opération « Endgame » — une opération qui a porté ses fruits précisément parce que ces serveurs disposaient d’un système de contrôle et de commande (C2) centralisé. Les techniques « fast flux », DGA et P2P ont toutes pour but de contourner ce mode de défaillance ; c’est pourquoi la localisation des appareils réquisitionnés pour former un botnet ne peut être confiée uniquement aux opérations de démantèlement.

Correspondance entre la détection des botnets et les cadres MITRE ATT&CK NIST CSF

La cartographie du cadre permet de garantir la traçabilité de ce travail. Actuellement MITRE ATT&CK Il s'agit de la version 19.1 — 15 tactiques, la catégorie « Évasion défensive » ayant été scindée en « Furtivité » (0005) et la déficience de défense (0112) — dont les modules « Stratégies de détection » et « Analyse » ont fait leur apparition dans v18, publiée le 28 octobre 2025. Sur le NIST CSF 2.0 (CSWP 29, publié le 26 février 2024) d'autre part, la surveillance continue du réseau dans le cadre de DE.CM-01 est le point d'ancrage principal, DE.CM-09 couvre la surveillance endpoint des ressources informatiques, et DE.AE-02, DE.AE-03et DE.AE-07 couvrent l'analyse des événements, la corrélation multisource et l'enrichissement des renseignements. Le tableau de correspondance ci-dessous établit un lien entre chaque signal présenté dans ce guide et ces deux cadres — ainsi qu'avec votre contexte plus large détection des menaces programme.

Chaque signal de détection de botnet figurant sur cette page correspond à une MITRE ATT&CK spécifique et à une sous-catégorie « DETECT » du NIST CSF 2.0.

Approches modernes de la détection des botnets

Tout ce qui précède converge vers une seule approche opérationnelle : partir du principe que le système a été compromis, surveiller le réseau et modéliser les comportements — car le botnet que vous devez absolument détecter s'exécute sur un appareil que vous ne gérez pas, via un canal que vous ne pouvez pas déchiffrer, en utilisant une infrastructure que nulle liste noire n'a jamais répertoriée. détection et réponse aux incidents NDR) constituent la couche opérationnelle où ces techniques s'exécutent en continu sous forme de détections corrélées et orchestrées, plutôt que dans le cadre de recherches ponctuelles. Il existe un vaste marché d’outils de détection de botnets qui mettent en œuvre certaines parties de cette pile ; l’évaluation de ce paysage est un exercice distinct de la compréhension des techniques sur lesquelles il repose.

Vectra AI en matière de détection des botnets

Vectra AI la détection des botnets comme un problème de modélisation comportementale plutôt que comme un problème de signatures. Attack Signal Intelligence le comportement des systèmes de commande et de contrôle sur le réseau — cadence des balises, schémas DNS caractéristiques de la génération de domaines, caractéristiques des canaux chiffrés — et établit des corrélations entre ces comportements sur l’ensemble des hôtes afin de distinguer un véritable canal de contrôle d’une périodicité de routine. Comme cette analyse repose sur le réseau, elle s’applique également aux appareils sans agent, pour lesquels il n’existera jamais endpoint .

Conclusion

La détection des botnets s'est orientée vers un domaine que les attaquants ne peuvent pas suivre : les comportements qu'un bot doit adopter pour fonctionner. Les signatures et les listes de blocage continuent de filtrer le bruit de fond, mais les signaux durables sont la périodicité qui résiste à la gigue, le comportement DNS qui résiste au renouvellement des domaines, les empreintes et la synchronisation qui résistent au chiffrement, ainsi que la visibilité réseau qui résiste à l'absence d'agent. Développez ces quatre éléments, associez-les aux MITRE ATT&CK NIST CSF, puis affinez votre approche en tenant compte du taux de base.

‍