ShadowV2 représente une nouvelle vague de menaces natives du cloud qui transforment des instances de conteneurs mal configurées en infrastructures d'attaque louables. La campagne cible les points d'extrémité Docker d'Amazon Web Services (AWS) exposés à l'internet public, en déployant une boîte à outils en plusieurs étapes qui combine un cadre de commande basé sur Python et un cheval de Troie d'accès à distance basé sur Go. Les techniques observées comprennent la réinitialisation rapide HTTP/2, des tentatives automatisées de contournement du mode Cloudflare Under Attack et des charges utiles DDoS modulaires adaptées aux opérations DDoS-for-Hire. Cette analyse dissèque la chaîne d'infection, l'architecture C2, les techniques d'évasion et les atténuations pratiques pour les organisations qui exécutent Docker sur AWS, DigitalOcean ou les clusters Kubernetes.
Botnet ShadowV2 : Un Docker AWS mal configuré alimente un DDoS pour le compte d'autrui
ShadowV2 cible les API Docker exposées sur Internet et les démons hôtes mal configurés fonctionnant sur les instances EC2 d'Amazon Web Services (AWS). Les scanners identifient les points d'extrémité de Docker Engine qui acceptent des requêtes non authentifiées, puis exécutent une compromission en plusieurs étapes. Les attaquants génèrent un conteneur Ubuntu générique, installent des utilitaires dans cet environnement de construction éphémère, capturent une image, puis exécutent un conteneur réel qui exécute un binaire ELF basé sur Go. Cette technique favorise la construction et l'exécution sur place afin de réduire les artefacts détectables sur le système de fichiers de l'hôte.
La compromission initiale s'appuie sur des erreurs de configuration courantes du cloud plutôt que sur des failles inconnues. Les attaquants analysent de larges plages d'adresses IP sur AWS et DigitalOcean, à la recherche d'API Docker accessibles via TCP. Une fois découvert, le module de diffusion Python ordonne au démon d'extraire ou de construire des images de conteneurs et d'exécuter des commandes privilégiées. La charge utile basée sur Go s'enregistre ensuite auprès d'un serveur de commande et de contrôle et rejoint le botnet ShadowV2 pour des campagnes DDoS coordonnées.
Chaîne d'infection Docker ShadowV2 et ciblage AWS
La chaîne d'infection observée en 2025 démontre des étapes d'orchestration claires adaptées aux environnements conteneurisés. Le diffuseur utilise des appels d'API Docker non authentifiés pour exécuter des conteneurs de construction éphémères et pour lancer un runtime léger hébergeant le RAT Go. Le RAT envoie périodiquement des messages de battement de cœur à un domaine C2 caché derrière Cloudflare et attend de nouvelles coordonnées d'attaque.
- Scan : les bots recensent les API de Docker Engine faisant face à Internet dans les plages d'IP d'AWS et de DigitalOcean.
- Déploiement : un conteneur générique Ubuntu est créé pour installer les outils d'exécution dans l'environnement de la victime.
- Image : une image du conteneur préparé est créée et instanciée en tant que conteneur réel pour exécuter la charge utile basée sur Go.
- S'inscrire : le RAT Go établit une communication HTTP avec le C2 et obtient des tâches telles que la réinitialisation rapide HTTP/2 et les paramètres d'inondation HTTP.
- Attaque : le nœud infecté participe à l'amplification du trafic ou à des inondations HTTP ciblées sous le contrôle de l'opérateur.
Cette approche permet aux opérateurs de centraliser la logique malveillante dans des conteneurs éphémères et de réduire les empreintes médico-légales sur les volumes hôtes. Cette tactique rend également plus difficile pour les propriétaires d'infrastructures la détection de la compromission par de simples vérifications de l'intégrité des fichiers, car une grande partie de l'activité se produit dans les couches de conteneurs.
| Stade | Technique | Objectifs |
|---|---|---|
| Découverte | Analyse de l'API Docker à l'échelle de l'Internet à l'aide de divers agents utilisateurs | AWS, DigitalOcean, nœuds Kubernetes exposés |
| Déploiement | Conteneur de construction Ubuntu sur place puis instanciation de l'image | Docker Engine sur les instances EC2 |
| Commandement | RAT basé sur Go avec HTTP C2 | L'infrastructure C2 derrière Cloudflare |
ShadowV2 occupe une niche pratique pour les criminels : la possibilité de convertir l'informatique en nuage en une ressource DDoS évolutive. La dépendance à l'égard des mauvaises configurations plutôt qu'à l'égard d'une exploitation avancée suggère qu'une fraction importante des incidents pourrait être évitée grâce à un renforcement de base. Les opérateurs qui utilisent Docker sur AWS devraient vérifier les ports exposés et limiter l'API du moteur Docker à localhost ou à des sous-réseaux VPC de confiance. Cette section montre que l'hygiène de base du cloud permet souvent d'éviter l'enrôlement complet d'un réseau de zombies, ce qui constitue un avantage décisif pour les défenseurs.
Commande et contrôle du botnet ShadowV2 : Python C2 et Go RAT sur une infrastructure en nuage
L'architecture C2 de ShadowV2 associe des cadres web Python modernes à une protection résiliente de la périphérie du nuage. Le plan de contrôle observé utilise un backend Python FastAPI qui s'appuie sur Pydantic pour la validation des données et fournit un panneau de connexion orienté vers l'opérateur. L'hébergement derrière Cloudflare cache l'origine réelle, ce qui complique l'attribution. Le backend expose des API pour gérer les utilisateurs, configurer les types d'attaques disponibles et orchestrer les points d'extrémité infectés qui participeront à des campagnes spécifiques.
Le RAT basé sur Go, installé sur des conteneurs Docker compromis, communique par HTTP pour interroger le C2 afin d'obtenir des commandes et de transmettre des données télémétriques. Le RAT peut exécuter des commandes natives, lancer des modules DDoS et signaler les caractéristiques du système. Le propagateur Python et le RAT Go créent ensemble un écosystème modulaire dans lequel de nouveaux vecteurs d'attaque peuvent être intégrés sans que le code de l'agent ne soit modifié en profondeur.
Caractéristiques du ShadowV2 C2 et interface opérateur
Les capacités API observées comprennent la gestion des utilisateurs de type RBAC, les modèles d'attaque, les pools de déploiement et les listes d'exclusion. La présence d'une API structurée implique que les auteurs ont envisagé une interface qui prenne en charge plusieurs opérateurs ou locataires payants - une caractéristique des services DDoS à louer. Le tableau de bord de l'opérateur hébergé indique une intention d'industrialiser la vente et la gestion des attaques, en exposant des fonctionnalités normalement associées à des offres légitimes de plateforme en tant que service.
- Orchestration pilotée par API permettant des attaques planifiées et à la demande.
- Tableau de bord de l'opérateur offrant la configuration de l'attaque et la gestion de l'exclusion des cibles.
- L'ingestion de données télémétriques provenant d'hôtes infectés pour les contrôles de santé et la sélection de pools.
- Cloudfront/CDN edge hiding for C2 domains to frustrate takedown.
L'architecture de ShadowV2 tient compte de l'échelle et de la facilité de maintenance. En tirant parti de FastAPI et des services de périphérie dans le nuage, les opérateurs peuvent évoluer rapidement et répondre aux mesures défensives. La conception C2 permet également l'intégration de nouveaux modules, tels que les proxys SOCKS ou les outils de scraping, en accord avec la banalisation croissante de la cybercriminalité en tant que service.
| Composant C2 | Rôle | Outils observés |
|---|---|---|
| API de backend | Plan de contrôle de l'opérateur | FastAPI, Pydantic, Cloudflare edge |
| Agent | Exécution et rapports | RAT basé sur Go, polling HTTP |
| Épandeur | Vecteur de compromis initial | Diffuseur Python, abus de l'API Docker |
En pratique, les défenseurs ont besoin de la télémétrie des couches d'orchestration des conteneurs et des journaux de sortie du réseau pour détecter des modèles suspects d'interrogation et de battement de cœur. Le recoupement des horodatages de l'activité de l'API Docker avec les opérations de construction de conteneurs révèle souvent la création d'images non autorisées. La détection la plus efficace combine les journaux de flux des fournisseurs de cloud, l'audit au niveau de l'hôte et les outils qui valident l'exposition à l'API Docker. Il en résulte une conclusion opérationnelle claire : surveiller les interactions du plan de contrôle de manière agressive pour interrompre le cycle de vie C2.
Évasion du botnet ShadowV2 et UAM de Cloudflare : Tentatives de contournement automatisées et réinitialisation rapide HTTP/2
ShadowV2 démontre diverses techniques d'évasion qui visent à contourner les défenses web telles que le mode d'attaque (Under Attack Mode, UAM) de Cloudflare. Une méthode notable exploite l'automatisation ChromeDP pour résoudre les défis JavaScript présentés par Cloudflare, en obtenant des cookies d'autorisation à réutiliser dans des requêtes ultérieures. La campagne met également en œuvre des attaques HTTP/2 Rapid Reset pour exploiter la sémantique du protocole plutôt que des inondations purement volumétriques, qui peuvent être plus efficaces contre certaines piles de serveurs et certaines mesures d'atténuation.
Cependant, les heuristiques anti-automatisation de Cloudflare et l'évolution des défis sont conçus pour détecter le trafic des navigateurs sans tête. La tentative d'automatisation présente des inconvénients : bien qu'elle permette parfois d'obtenir un cookie d'effacement, l'approche est fragile et détectable. L'utilisation par ShadowV2 de ChromeDP et de techniques de réinitialisation rapide témoigne d'une tentative stratégique de combiner des attaques furtives à faible empreinte avec des rafales de trafic à fort volume lorsque l'occasion se présente.
Tactiques d'évasion de ShadowV2 et réponses du CDN
Les CDN dans le nuage comme Cloudflare et Akamai jouent un double rôle. Ils masquent les origines de C2 backend, ce qui complique les démantèlements, et ils agissent comme des défenseurs de première ligne pour les cibles potentielles. Les tentatives de ShadowV2 pour résoudre les défis via ChromeDP mettent en évidence la course aux armements entre l'automatisation sans tête et les mécanismes de défi. Les mesures d'atténuation d'Akamai et de Cloudflare impliquent généralement la limitation du débit, le durcissement des défis et l'évaluation de la réputation IP, ce qui oblige les attaquants à s'appuyer sur une infrastructure piratée plutôt que sur des sondages bruts à la périphérie.
- L'automatisation tente de résoudre les problèmes liés à JavaScript à l'aide d'outils de navigation sans tête.
- Les attaques au niveau du protocole, comme la réinitialisation rapide HTTP/2, permettent de contourner certains mécanismes heuristiques de limitation du débit.
- Utilisation de Cloudflare pour masquer les serveurs C2 et compliquer l'identification de l'origine.
- Repli sur les inondations HTTP volumétriques lorsque les méthodes furtives ne produisent pas d'effet.
Du point de vue du défenseur, l'analyse de la cohérence de la poignée de main TLS, des comportements de flux HTTP/2 et des schémas d'émission de cookies peut révéler des solutions de défi automatisées. Associés aux journaux d'Akamai ou de Cloudflare, ces signaux permettent aux équipes de sécurité de bloquer ou d'interrompre les sessions suspectes avant qu'elles ne prennent de l'ampleur. L'idée est qu'une détection efficace exploite à la fois la télémétrie de la couche applicative et les analyses fournies par le CDN pour repérer les tentatives de contournement de l'UAM.
| Evasion | Technique ShadowV2 | Atténuation |
|---|---|---|
| Dérivation de l'UAM | Automatisation de ChromeDP pour obtenir un cookie d'autorisation | Heuristique des défis comportementaux et empreintes digitales des appareils |
| Abus de protocole | HTTP/2 Inondations par réinitialisation rapide | Gestion des flux HTTP/2 et limites par connexion |
| C2 dissimulation | Fronting de Cloudflare pour les domaines C2 | Corrélation des journaux de bord et signalement des abus |
Le mélange de furtivité et de volume de ShadowV2 le rend adaptable. L'implication défensive est claire : les paramètres CDN et les pare-feu d'application web doivent être configurés avec des heuristiques en couches et un partage automatique des informations pour détecter les activités sophistiquées de DDoS pour le compte d'autrui. L'observation de l'interaction entre l'émission de défis, les schémas d'utilisation des cookies et les comportements HTTP/2 atypiques est essentielle pour perturber ces campagnes à grande échelle.
Le botnet ShadowV2 comme DDoS à louer : API Marketplace, risques Kubernetes et mauvaises configurations du cloud
ShadowV2 a été observé en train de proposer des API orientées vers les opérateurs qui gèrent les comptes d'utilisateurs, attribuent des privilèges d'attaque et spécifient les pools de systèmes infectés qui exécuteront les ordres. Ce modèle commercial ressemble à des plateformes SaaS légitimes, mais il répond à la demande illégale de campagnes DDoS. L'approche basée sur les API permet aux opérateurs de demander par programme des attaques contre des cibles spécifiques et d'en exclure d'autres, ce qui démontre un niveau de contrôle opérationnel que l'on retrouve normalement dans les opérations de cybercriminalité en tant que service parvenues à maturité.
Les erreurs de configuration vont au-delà des démons Docker isolés. Les clusters Kubernetes, les droplets DigitalOcean et même les runners de conteneurs auto-hébergés peuvent être mal configurés pour exposer les plans de contrôle. Pour des organisations telles que l'hypothétique société d'hébergement "Atlas Web Services", un seul nœud mal configuré a permis une propagation dans un cluster qui a ensuite été exploité par ShadowV2 pour une campagne volumétrique coordonnée. L'incident souligne comment de petites lacunes dans le contrôle d'accès peuvent entraîner des risques à l'échelle de la plateforme.
Fonctionnalités de la place de marché ShadowV2 et surface d'attaque native dans le nuage
L'interface de l'opérateur prend en charge la sélection des types d'attaques, la programmation et les modèles d'achat qui s'alignent sur les principes économiques du DDoS-for-Hire. Cela révèle un canal de vente bien pensé où les attaquants monétisent l'accès aux pools de botnets. Le modèle de plateforme réduit les frictions pour les acheteurs tout en permettant aux développeurs de mettre à jour les modules d'attaque de manière centralisée. Il en résulte une chaîne d'approvisionnement dynamique où les mauvaises configurations des nuages servent de matière première aux marchés illicites.
- Les points de terminaison de l'API pour la gestion des utilisateurs et des attaques permettent l'orchestration programmatique des campagnes.
- Les mauvaises configurations de Kubernetes (serveur API exposé, kubelets non authentifiés) élargissent la surface d'attaque.
- Les erreurs de configuration des fournisseurs de services en nuage sur AWS et DigitalOcean entraînent une propagation latérale rapide.
- Les interfaces de type service abaissent la barre pour les clients criminels qui recherchent des offres de DDoS à louer.
Les mesures pratiques pour réduire les risques comprennent l'application du moindre privilège sur les API de conteneurs, l'activation de TLS mutuel et l'accès basé sur les rôles sur Kubernetes, et l'assurance que les sockets des démons Docker ne sont pas liés à des interfaces publiques. Les mesures correctives prises par Atlas Web Services après l'incident comprenaient des ACL au niveau du réseau, le renforcement de l'hôte et le passage à des services de conteneurs gérés avec une isolation par défaut plus stricte. Les enseignements tirés montrent que la discipline opérationnelle et les modèles standardisés réduisent considérablement l'exposition.
| Fonctionnalité du marché | Risque | Contrôle recommandé |
|---|---|---|
| Orchestration de l'API | Attaques automatisées à grande échelle | Audit et limitation de l'accès à l'API ; détection des anomalies |
| Exposition à l'API des conteneurs | Première implantation via Docker Engine | Lier l'API Docker à localhost ; utiliser le proxy de socket |
| Mauvaise configuration de Kubernetes | Mouvement latéral de la grappe | RBAC, politiques de réseau et plans de contrôle privés |
L'essor des plateformes DDoS à louer telles que ShadowV2 tire parti de la banalisation de l'informatique en nuage et de l'inégalité des mesures de sécurité entre les fournisseurs. La sécurisation des domaines natifs de l'informatique en nuage nécessite l'automatisation, la validation continue de la configuration et la modélisation des menaces qui inclut à la fois les dépendances des services et l'économie des places de marché illicites. L'idée : fermer les vecteurs d'attaque faciles oblige les adversaires à déployer plus d'efforts, ce qui augmente leurs coûts opérationnels et réduit l'incidence de la croissance opportuniste des réseaux de zombies.
Notre avis : Le botnet ShadowV2 et les risques liés à AWS Docker vont de l'avant
ShadowV2 rappelle que la commodité de l'informatique dématérialisée s'accompagne souvent d'une dette de sécurité. La campagne convertit des points d'extrémité Docker et d'orchestration de conteneurs mal configurés sur Amazon Web Services et d'autres fournisseurs en une structure d'attaque louable. L'utilisation d'un outil C2 basé sur Python et d'un RAT Go, combinée à des services périphériques comme Cloudflare pour masquer l'infrastructure, signale une professionnalisation croissante des opérations DDoS-as-a-service. Les organisations devraient considérer les plans de contrôle de conteneurs exposés comme des vulnérabilités critiques.
Les mesures concrètes recommandées consistent à s'assurer que les API de Docker Engine ne sont pas accessibles depuis l'internet public, à déployer des contrôles de moindre privilège pour les moteurs d'exécution des conteneurs et à activer la télémétrie des hôtes et du réseau pour détecter les comportements suspects en matière de construction et d'interrogation. Les offres Kubernetes gérées et les modèles d'orchestration renforcés réduisent la marge d'erreur humaine. En outre, l'intégration de la télémétrie CDN et WAF (de Cloudflare, Akamai et autres fournisseurs similaires) dans les processus de réponse aux incidents améliore la capacité à détecter et à décélérer les attaques à un stade précoce.
- Vérifier les règles du pare-feu du cloud pour s'assurer que les API Docker et les kubelets sont privés.
- Mise en œuvre d'une analyse continue de la configuration et d'une détection des dérives pour les modèles de conteneurs.
- Corréler les journaux de bord du CDN avec la télémétrie de l'hôte afin d'identifier les sondages C2 et les abus.
- Sensibiliser les équipes de la plateforme aux valeurs par défaut sécurisées lors du provisionnement des ressources AWS, DigitalOcean ou Kubernetes.
Les contrôles recommandés vont des modifications de l'infrastructure aux pratiques opérationnelles. L'utilisation d'une infrastructure automatisée en tant que code avec des portes de politique renforcées prévient l'exposition accidentelle. La journalisation prête pour l'analyse judiciaire, les registres de conteneurs immuables et l'absence de montage de socket Docker sur l'hôte pour les services tiers réduisent le rayon de choc d'une compromission. La combinaison de mesures de prévention et de détection est la seule voie réaliste pour réduire l'impact commercial de l'enrôlement d'un botnet.
| Contrôle | Pourquoi c'est utile | Action rapide |
|---|---|---|
| Liaisons API Docker privées | Bloque les commandes à distance non authentifiées | Reconfigurer le démon pour qu'il écoute sur localhost ou un socket sécurisé |
| Orchestration gérée | Réduit le risque de mauvaise configuration | Migrer vers un Kubernetes géré avec des valeurs par défaut renforcées |
| Corrélation logarithmique des bords | Détecte l'activité C2 précoce | Transférer les logs Cloudflare/Akamai dans SIEM |
Pour en savoir plus sur les risques adjacents et les tactiques défensives, consultez les ressources qui couvrent les impacts de l'IdO, les outils de cybersécurité pilotés par l'IA et l'hygiène des logiciels malveillants. Des sujets tels que la façon dont l'Internet des objets modifie la surface d'attaque ou la façon dont l'IA informe la détection des menaces sont directement pertinents pour comprendre l'écosystème dans lequel ShadowV2 opère. Des exemples et des examens techniques peuvent être trouvés dans des briefings dédiés et des exercices d'incidents pour améliorer la préparation.
- Vue d'ensemble de DualMedia sur l'IdO et la cybersécurité : Impact de l'IdO sur la cybersécurité
- Revue technique de l'IA dans la cybersécurité : Les progrès de l'IA dans la cybersécurité
- Ressources pratiques pour les wargames : Wargame sur la cybersécurité en Irlande
- Contexte de compromission des appareils intelligents : Les pirates informatiques contrôlent-ils les appareils intelligents ?
- Principes de base et suppression des logiciels malveillants : Qu'est-ce qu'un logiciel malveillant et comment le supprimer ?
- Actualités et conseils sur la sécurité de l'IdO : Actualités sur la sécurité de l'IdO
L'évolution de ShadowV2 montre que les défenseurs doivent suivre le rythme de l'industrialisation des outils criminels. Donner la priorité à l'hygiène des API de conteneurs, intégrer des informations sur les CDN et traiter la mauvaise configuration des nuages comme une vulnérabilité critique sont les actions immédiates qui réduisent matériellement le risque. Enfin, l'augmentation du coût opérationnel pour les adversaires grâce à un contrôle cohérent et automatisé réduit le marché des services DDoS à louer et améliore la résilience collective.