Les équipes de sécurité peuvent ne pas détecter immédiatement le moment où un pirate s'introduit dans le système, mais elles finissent par repérer le trafic qui s'ensuit.
Un système compromis commence à établir une connexion avec une entité à laquelle il ne devrait pas s'adresser. La connexion est établie, puis interrompue, avant d'être réessayée. C'est là le rôle de l'infrastructure de commande et de contrôle.
Dans un article précédent, j'ai expliqué comment les pirates utilisent Brute Ratel pour maintenir des canaux de commande clandestins au sein d'environnements compromis. Des outils tels que Brute Ratel modulent délibérément leur trafic afin de se fondre dans l'activité Web légitime et d'échapper aux méthodes de détection traditionnelles.
Un autre outil conçu selon la même philosophie est Sliver, un framework open source de commande et de contrôle qui introduit des couches supplémentaires de randomisation dans le trafic des balises afin de rendre la détection encore plus difficile.
De l'accès initial au commandement et au contrôle
Les pirates informatiques déploient rarement directement une infrastructure de commande et de contrôle. Ils ont d'abord besoin d'un point d'entrée.
Dans de nombreuses intrusions, cette prise de pied commence par une vulnérabilité dans un service accessible depuis Internet. Un exemple récent est React2Shell (CVE-2025-55182), une faille critique affectant les composants serveur React utilisés dans des frameworks tels que Next.js. L'exploitation de cette vulnérabilité permet à un attaquant d'exécuter du code sur un serveur vulnérable à l'aide d'une requête HTTP spécialement conçue.
Une fois l'exécution du code réussie, les pirates agissent rapidement pour s'assurer une présence durable et prendre le contrôle à distance.
C'est là que les cadres d'analyse post-exploitation entrent en jeu.
Au lieu de créer malware sur mesure, les pirates s'appuient souvent sur des outils open source éprouvés qui offrent une panoplie complète de fonctionnalités pour gérer les hôtes compromis. Ces frameworks prennent en charge les aspects les plus complexes des opérations d'intrusion : communications sécurisées, exécution de tâches sur les systèmes infectés, transfert de fichiers et coordination des activités entre plusieurs machines compromises.
Sliver fait partie de ces outils.
Qu'est-ce que Sliver et pourquoi les pirates l'utilisent-ils ?
Sliver s'est rapidement imposé comme l'un des frameworks open source les plus utilisés pour les opérations post-exploitation. Initialement conçu pour la simulation d'attaques et les opérations de type « red team », ce projet offre une plateforme éprouvée permettant de gérer les systèmes compromis et de coordonner les activités d'intrusion.
Plusieurs facteurs expliquent son adoption croissante :
- Sliver est entièrement open source et fait l'objet d'une maintenance active, ce qui facilite la tâche des pirates par rapport aux frameworks commerciaux. Les opérateurs peuvent facilement générer des implants personnalisés, modifier les profils de communication et intégrer le framework dans des workflows d'intrusion automatisés.
- Ce cadre a été conçu dans un souci de flexibilité opérationnelle. Sliver prend en charge plusieurs systèmes d'exploitation, protocoles de communication et mécanismes de transport, ce qui permet aux opérateurs d'adapter le canal de commande à l'environnement visé. Les transports HTTP et HTTPS sont particulièrement courants, car ils s'intègrent naturellement au trafic normal de l'entreprise.
- Sliver intègre des techniques de dissimulation du trafic destinées à rendre le trafic de commande difficile à identifier. Le framework peut introduire des variations de synchronisation entre les requêtes de balise, modifier la taille et la structure des données transmises, et alterner les mécanismes de codage afin de modifier l'apparence du trafic réseau.
Ces choix de conception rendent Sliver particulièrement attrayant pour les pirates à la recherche d'une plateforme de commande et de contrôle performante sans avoir à développer malware sur mesure. Parallèlement, ils compliquent la tâche des équipes de sécurité chargées de détecter les canaux de commande dissimulés dans le trafic chiffré.
Pourquoi les signaux de balise sont généralement plus faciles à détecter
Les structures traditionnelles de type « commandement et contrôle » ont tendance à générer des schémas de réseau prévisibles.
Si un implant se connecte toutes les 60 secondes et envoie à chaque fois à peu près la même quantité de données, le schéma de trafic qui en résulte devient facile à identifier.
Les outils de sécurité peuvent détecter ces schémas en analysant :
- synchronisation cohérente entre les connexions
- communication répétée vers la même destination
- des tailles de données utiles similaires pour toutes les requêtes
Pour éviter d'être détectés, les infrastructures plus sophistiquées introduisent un élément aléatoire dans ces schémas. Elles peuvent faire varier l'intervalle entre les connexions ou modifier la taille des données transmises à chaque requête. Ces techniques donnent lieu à ce que l'on appelle un « balisage furtif », dans lequel le schéma de communication subsiste mais devient plus difficile à reconnaître.
De nombreux outils modernes de post-exploitation prennent en charge ces techniques dès leur installation.
Sliver va encore plus loin dans cette idée.
Qu'est-ce qui rend Sliver plus difficile à détecter ?
La plupart des infrastructures de commande et de contrôle s'appuient sur deux techniques de contournement fondamentales.
Le premier est la variation de temps, qui se caractérise par le fait que l'implant ajuste de manière aléatoire le délai entre les requêtes de balise. Au lieu d'envoyer une requête toutes les 60 secondes, il peut le faire après 48 secondes, puis 72 secondes, puis 63 secondes.
Le deuxième facteur est la fluctuation des données, qui se caractérise par des tailles légèrement différentes pour chaque requête. Une petite quantité de données aléatoires peut être ajoutée au message de balise afin que le trafic réseau ne semble pas identique à chaque fois.
Sliver propose une approche plus sophistiquée appelée « jitter procédural des données ».
Plutôt que de modifier un seul élément de la requête, Sliver modifie plusieurs paramètres simultanément. Chaque requête de balise peut utiliser un chemin HTTP différent, une méthode d'encodage différente et une valeur aléatoire qui modifie la structure de la requête.
Le framework prend en charge plusieurs types d'encodage, notamment Base64, l'encodage hexadécimal, la compression gzip, et même des encodages qui transforment les données binaires en texte anglais ou en fichiers PNG valides. Chaque méthode d'encodage modifie l'efficacité de la compression des données transmises, ce qui se traduit par des tailles de données utiles variables d'une requête à l'autre.
Au lieu de générer un seul groupe de messages de balise similaires, Sliver produit plusieurs schémas distincts dans le trafic réseau.
Pour les systèmes de détection qui s'attendent à ce que les messages de balise se ressemblent, cette variabilité rompt le schéma.
Tout porte à croire que les pirates utilisent déjà Sliver
Sliver n'est pas seulement un outil destiné à l'équipe rouge.
Des chercheurs en sécurité ont mis en évidence des campagnes dans lesquelles des pirates ont déployé des implants Sliver après avoir accédé à des infrastructures exposées.
On peut citer, à titre d'exemple, les recherches menées par CtrlAltIntel, qui ont mis au jour une campagne visant des appliances FortiWeb connectées à Internet. Après avoir exploité les systèmes exposés, les pirates ont déployé des implants Sliver déguisés en utilitaires de mise à jour du système. Les appareils compromis ont alors commencé à envoyer des signaux vers une infrastructure contrôlée par les pirates, permettant ainsi aux opérateurs de garder le contrôle à distance des serveurs affectés.
L'enquête a mis au jour des dizaines de machines compromises communiquant avec le serveur de commande, ce qui montre à quelle vitesse les frameworks open source de post-exploitation, tels que Sliver, peuvent passer du statut d'outils utilisés par les équipes de simulation d'attaques à celui d'outils utilisés dans le cadre d'intrusions réelles. Ces cas reflètent une tendance plus générale en matière d'intrusions.
Les frameworks open source de post-exploitation permettent aux pirates d'agir rapidement sans avoir à développer malware sur mesure. Ces outils offrent des fonctionnalités de commande et de contrôle éprouvées tout en se fondant dans le trafic réseau légitime.
Pour les défenseurs, cela fait de l'identification du canal de commande une étape cruciale dans la détection d'une intrusion en cours.
Pourquoi les méthodes de détection traditionnelles peinent à donner satisfaction
De nombreuses techniques de détection des systèmes de commande et de contrôle reposent sur l'identification de schémas de communication réguliers, dans lesquels les messages de balise sont émis à intervalles réguliers et transmettent souvent des volumes de données similaires.
Si la plupart des requêtes contiennent à peu près le même nombre d'octets, le profil de trafic peut être regroupé en un seul cluster et identifié comme un comportement de balisage.
Le mécanisme de rotation des encodeurs de Sliver remet en cause cette hypothèse, car chaque méthode d'encodage produit un taux de compression différent ; les messages de balise qui en résultent se répartissent ainsi sur plusieurs fourchettes de taille distinctes, plutôt que de former un seul groupe dominant. Ce schéma multibande permet de déjouer les algorithmes qui partent du principe que les messages de balise restent similaires.
Dans le trafic chiffré, où il est impossible d'inspecter le contenu, ces variations rendent la détection nettement plus difficile.
Les pirates modifient également souvent les implants Sliver ou les diffusent via des chargeurs de shellcode personnalisés conçus pour contourner les antivirus et les systèmes endpoint . Ces techniques permettent à la charge utile de s'exécuter entièrement en mémoire, ce qui réduit le risque de détection sur l'hôte. Cependant, une fois que l'implant a établi son canal de commande, les communications de balisage continuent de générer des schémas observables sur le réseau.
Détection de Sliver par l'analyse comportementale
Même lorsque les charges utiles sont chiffrées et illisibles, le trafic de commande et de contrôle laisse tout de même apparaître des schémas comportementaux.
La Vectra AI analyse ces schémas pour identifier les infrastructures de commande et de contrôle telles que Sliver, même lorsque les attaquants tentent de dissimuler leur trafic à l'aide de jitter, de rotation d'encodeurs ou d'autres techniques de contournement.
Plutôt que de s'appuyer sur l'analyse des signatures ou du contenu des paquets, la plateforme utilise des modèles d'apprentissage profond entraînés à partir de vastes volumes de données télémétriques réelles issues du réseau. Ces modèles analysent les séquences d'activité réseau, telles que la longueur des paquets, les intervalles de temps et le sens de la communication entre les hôtes, afin de détecter des schémas comportementaux caractéristiques des activités de balisage.
Étant donné que les pirates doivent maintenir la communication avec les systèmes qu'ils ont compromis, ce canal de commande reste l'un des moyens les plus fiables pour détecter une intrusion en cours.
Même lorsque les signaux de Sliver se fondent dans le trafic Web habituel, ces signaux comportementaux continuent de se démarquer.
Pour découvrir comment la Vectra AI détecte les activités de commandement et de contrôle telles que Sliver dans des environnements réels, regardez la démonstration en libre-service.