Si l’expertise surpasse la popularité, rien ne l’arrête : Sliver C2 Framework, patron de la post-exploitation

par Gilbert Thierry NLO · Publié 31 juillet 2026 · Mis à jour 31 juillet 2026

Plusieurs fois cité dans des études de compromission, Sliver C2 Framework a su séduire de nombreux groupes de hackers qui s’en servent comme vecteur d’attaque, en dépit de sa cible originelle : les professionnels de la sécurité. Un détournement d’usage qui a su sonner l’alerte auprès de grands éditeurs dont Microsoft, qui s’y est appesanti afin d’adapter au mieux ses outils de détection et de sécurité. Mais, comme il est courant en sécurité, le jeu de ping-pong entre black hackers, éditeurs, constructeurs et autres professionnels de la sécurité, gagne en profondeur chaque jour. Ne pas comprendre Sliver pour un professionnel, c’est passer à côté d’une source malveillante de haute facture. Quel est cet outil qui tend à industrialiser les retombées d’une chaîne d’attaque ? Comment fonctionne-t-il concrètement et qu’est-ce qui fait sa particularité, sont des questions qui valent tout leur pesant d’or. Et pire encore, y en a-t-il de similaires ?

Présentation et utilité de l’outil

Dans une chaîne d’attaque, l’étape de post-exploitation intervient une fois que l’accès au système de la cible a été obtenu via diverses techniques allant de l’ingénierie sociale à l’exploitation d’une vulnérabilité. Le défi majeur pour un attaquant parvenu à ce niveau est de rester sans se faire repérer et, si possible, d’infecter plus de machines.

Des techniques de persistance et d’évasion sont alors utilisées à cet effet autour de la charge utile en elle-même. C’est cette dernière qui porte effectivement l’action du pirate, du hacker ou du groupe de hackers (les dégâts immédiats ou latents qu’il compte bien commettre comme le vol de données, le chiffrement de celles-ci pour demander une rançon, etc.). Mais pour ce faire, il faudra bien que la machine cible et celle de l’attaquant puissent communiquer.

Pour parvenir à contrôler la machine de la victime à distance et, au besoin, interagir avec elle en lui passant des commandes sans être vu, Sliver C2 Framework peut bel et bien entrer en jeu, avec une plus-value notable sur ses prédécesseurs.

Sliver est un framework C2 lancé en 2019 par Bishop Fox avec comme ligne directrice : traiter la génération d’implants comme un pipeline de compilation procédural où chaque binaire reçoit sa propre paire de clés asymétriques intégrée lors de la compilation.

Cette façon de faire projette la sécurité de l’implant au premier plan. Comment peut-il résider en toute sécurité (sa sécurité à lui) au sein d’une machine victime, et permettre à l’attaquant d’attenter à la confidentialité, l’intégrité des données ou la disponibilité d’un système ou d’une infrastructure informatique ?

Comprendre la notion clé d’implant

Les implants Sliver sont des agents ou des charges utiles déployés sur la machine d’une victime. Les points clés suivants permettent de cerner leurs caractéristiques :

Fichier binaire unique : À l’instar du serveur, les implants sont des fichiers binaires uniques, sans dépendances externes, ce qui facilite leur déploiement et les rend plus difficiles à détecter.
Compatibilité multiplateforme : Les implants sont conçus pour fonctionner sous les différents systèmes d’exploitation pour ordinateurs dont Linux, macOS et Windows. Une caractéristique qui rend Sliver C2 très utile au sein de systèmes informatiques hétérogènes.
Évasion dynamique : Le processus de compilation dynamique garantit que chaque implant possède une signature unique. Ceci permet de contourner les mécanismes de détection par signature utilisés par les solutions de sécurité classiques.

Composants et fonctionnement de Slider C2

Composants

Le système C2 fonctionne avec trois composants principaux :

Le serveur

Cœur de l’opération, il est contrôlé par l’équipe qui mène l’attaque. C’est lui qui héberge le framework C2, couramment sous Linux bien qu’il soit également possible de le faire via les systèmes d’exploitation Windows ou macOS. Lorsqu’un implant est déployé sur la cible, c’est vers lui qu’il doit se tourner pour recevoir les commandes des hackers ou télécharger une partie plus importante de l’implant. Vous l’aurez compris, à l’instar des payloads sous Metasploit Framework, l’implant est une charge utile qui agit comme un client ou un agent qui peut se déployer de diverses manières, soit de façon complète et autonome, soit de façon étagée.

Le client, agent ou implant

C’est le programme malveillant qui s’exécute sur la machine de la victime. Ce type de programme se présente sous la forme d’un fichier dont le format varie en fonction des besoins du hacker et de l’environnement d’exécution de la cible. Il peut prendre la forme d’un exécutable (.exe), d’une bibliothèque Windows (.dll) ou d’un shellcode censé être interprété par le système d’exploitation hôte de la cible, bien évidemment.

En effet, la génération d’un implant permet d’obtenir en sortie un fichier aux format et caractéristiques variables :

Le fichier exécutable (.exe) :

C’est le format par défaut qui cible l’environnement Windows. Il est facile à générer et se déploie de façon autonome c’est-à-dire sans nécessiter l’appel de librairies externes ; tout est empaqueté. Mais cela a un prix : Sliver produit des binaires Go volumineux (10 à 16 Mo), et le dépôt d’un exécutable complet sur le disque le rend plus repérable par les solutions de sécurité.

Le shellcode :

Il s’agit d’un code machine brut exécutable directement en mémoire (RAM). Pour réussir un déploiement de ce genre, des méthodes typiques de l’injection de processus sont souvent utilisées.

L’injection de processus permet d’adjoindre à un programme en cours d’exécution, un autre le faisant passer ainsi pour un programme connu et auquel le système d’exploitation a foi. Pour ce faire, les attaquants modifient des implants Sliver ou les diffusent via des chargeurs de shellcode personnalisés écrit en C#, PowerShell, C++ ou même Rust.

En d’autres termes, un shellcode peut être obtenu sur modification d’un implant préconçu ou sur conception propre dans un langage approprié de son choix. Il viendra ensuite s’exécuter en mémoire grâce à un chargeur léger, dans l’optique de contourner les solutions de sécurité classiques qui surveillent majoritairement tout ce qui se « dépose » sur le disque dur.

Les fichier dll :

Par défaut utilisés comme de briques logicielles par les systèmes d’exploitation Windows, un fichier dll vu sous l’angle Sliver C2 peut s’avérer particulièrement utile lorsque l’implant doit résider dans un autre processus, facilitant notamment certaines manœuvres telles que le mouvement latéral.

Quel que soit le format de sorti et les paramètres de communication à mettre en œuvre (adresse du serveur et port d’écoute notamment), la détection sur l’hôte, machine de la victime, n’est qu’un aspect pris en compte par les attaquants car au-delà d’une empreinte ou d’un comportement sur l’hôte, le trafic réseau aussi peut générer une signature ou un comportement reconnaissable.

Les écouteurs

Composants du serveur C2, ils écoutent les connexions entrantes des implants. Avec pour but de se fondre dans la communication « normale » du réseau, et ainsi échapper à la détection des solutions de sécurité, ils sont conçus pour utiliser des protocoles courants (HTTPS, DNS, Wireguard, etc.). Néanmoins, cela se fait en tenant compte d’une subtilité importante : l’implant et le serveur s’identifient mutuellement en utilisant la technique mTLS.

mTLS (Mutual Transport Layer Security) est une technique d’authentification pair à pair où le client et le serveur vérifient mutuellement leur identité à l’aide de certificats numériques X.509, avant d’établir une connexion chiffrée via le protocole TLS standard (HTTPS).

Il faut relever que mTLS n’est pas un protocole en lui-même, c’est une technique qui repose sur un protocole, en l’occurrence TLS qui permet de chiffrer les communications sur réseau IP. Dans la phase d’identification, le protocole TLS standard est unidirectionnel, c’est-à-dire qu’il permet usuellement à un client de vérifier l’identité du serveur. Mais avec mTLS, le client vérifie l’identité de son vis-à-vis mais le serveur aussi.

Dès lors, le serveur a les moyens de refuser une connexion du client à moins que ce dernier ne lui présente un certificat valide émis par une autorité de certification (AC) de confiance. Un voleur qui craint d’être volé quoi …

Fonctionnement : modes de communication entre les différents composants

Sliver utilise deux modèles de communication principaux pour interagir avec les implants sur une machine compromise :

Les balises (beacons) : Une balise est un modèle de connexion persistante à long terme. Pour maintenir sa présence sans se faire repérer et permettre une montée en puissance de l’attaque depuis l’infrastructure du hacker, l’implant sur la machine victime communique avec le serveur C2 à intervalles prédéfinis. Une gigue optionnelle peut être ajoutée à l’intervalle de la balise pour rendre la communication plus aléatoire et plus difficile à détecter.
Les sessions : Contrairement aux balises, les sessions sont plus denses sur le plan interactif. Mais attention, les concepts ne s’opposent pas dans la mesure où, une session peut être établie en se servant d’une balise. De ce fait, une session est une connexion interactive à large bande passante offrant une expérience similaire à celle d’un shell. Ce modèle est idéal pour l’exécution de commandes et l’énumération des ressources sur la machine victime.

Atouts conséquents

Au regard de son architecture et de son fonctionnement, Sliver C2 présente les avantages et atouts suivants :

Atout 1 : Adapté aux opérations de longue durée

Grâce aux modes de fonctionnement Beacon (asynchrone) et Session (interactif), il est aussi bien adapté aux opérations de longue durée qu’à l’exploitation interactive.

Atout 2 : Moins sujet à une détection basée sur les signatures

Le maniement du protocole TLS via la technique mTLS usant de certificats de part et d’autre pour une communication chiffrée de confiance en HTTPS, le rend difficile à la détection.

De plus, chaque implant généré par Sliver possède sa propre paire de clés de chiffrement asymétriques, ce qui signifie que la détection traditionnelle basée sur la signature devient mathématiquement impossible : vous ne détectez pas un seul binaire, mais des variations infinies.

Dans le même ordre d’idées, chaque implant contient une clé publique codée en dur, dont seule la clé privée correspondante du serveur permet de déchiffrer les communications. Ainsi, même deux implants générés avec des paramètres identiques possèdent des identités cryptographiques totalement différentes.

Atout 3 : Moins sujet à une détection basée sur la qualité du trafic

Grâce à la flexibilité du protocole C2, Sliver est capable de prendre en charge l’écoute simultanée sur plusieurs protocoles, et les implants peuvent basculer entre eux pour une meilleure résilience.

Faire passer un trafic malicieux pour un trafic normal est particulièrement ingénieux lorsqu’on veut passer sous les radars. Comment ne pas le noter avec l’implémentation DNS C2 par exemple : elle encode les données dans les requêtes DNS et utilise les réponses des enregistrements TXT pour les commandes, apparaissant ainsi comme un trafic DNS légitime.

Parmi les autres protocoles réseau pris en charge nous pouvons citer : WireGuard (tunnel VPN léger) et HTTPS.

Atout 4 : Moins sujet à une détection basée sur le volume du trafic

Les schémas de communication réguliers, où les messages de balise apparaissent à intervalles constants et transmettent souvent des quantités de données similaires, constituent la base de nombreuses techniques de détection.

Plus concrètement, si la plupart des requêtes contiennent un nombre d’octets sensiblement identique, le trafic peut être regroupé en un seul cluster et identifié comme un comportement de balisage. Mais avec Sliver C2, la rotation de l’encodeur permet de produire un taux de compression différent.

Les messages de balise résultants se répartissent ainsi en plusieurs plages de taille distinctes, plutôt qu’en un seul cluster dominant. Ce qui peut permettre de déjouer les algorithmes qui s’attendent à ce que les messages de balise restent similaires.

Dans un trafic chiffré grâce au protocole HTTPS sus-évoqué, l’inspection de la charge utile n’est pas possible, et ces variations rendent la détection beaucoup plus difficile pour tout équipement de sécurité de cœur du réseau.

Atout 5 : Opensource et bien fourni comparé à des solutions propriétaires beaucoup plus onéreuses

Les outils de sécurité coûtent chers, très chers lorsqu’on n’a pas les compétences techniques et/ou qu’on s’éloigne de l’opensource. Dans le domaine de la post exploitation, plusieurs obstacles majeurs pouvaient se dresser face à des professionnels de sécurité naturellement pressés par les menaces environnantes toujours plus nombreuses :

L’obstacle financier : Pendant des décennies, les équipes rouges et les testeurs d’intrusion ont utilisé Cobalt Strike comme plateforme de commande et de contrôle de référence, malgré son prix supérieur à 5 000 $ et ses restrictions de licence.
Les limites techniques : Les alternatives libres comme Metasploit se sont concentrées sur l’exploitation plutôt que sur l’émulation d’adversaires après exploitation, et des outils comme Empire ont progressivement perdu en maintenance. Aussi, les frameworks C2 traditionnels généraient des implants statiques que les fournisseurs d’antivirus pouvaient identifier une seule fois et bloquer partout.

Prérequis et Installation

La posture d’un hacker éthique ou d’une organisation qui souhaite utiliser le framework Sliver C2 pour rehausser sa propre sécurité est celle qui nous intéresse. Sur cette base, il est avant tout important de comprendre les concepts d’équipes rouges (attaquants) et équipes bleues (défenseurs).

Dans la même dynamique, des autorisations et des mesures de sécurités préalables (sauvegardes, création d’un environnement de tests ou de laboratoire), pourraient être nécessaires avant toute installation, planification et mise en œuvre.

L’installation de Sliver peut se faire directement en ligne de commande sur divers systèmes Linux compatibles Debian notamment, via la commande apt get, ou manuellement en clonant la source du dépôt Github dont l’adresse est la suivante : GitHub – BishopFox/sliver: Adversary Emulation Framework · GitHub.

D’autres indicateurs techniques quant à la compilation ou la nécessité d’interpréteurs pourraient également y être mentionnés.

Outils similaires et alternatives

Mythic

Sur le terrain de l’open source dans la catégorie C2, Mythic fait figure de géant tout comme Sliver C2, mais leurs philosophies sont différentes. D’un côté, Mythic conçu par @its_a_feature_, repose sur une architecture ultra-modulaire conteneurisé sous Docker. Son véritable atout maître réside dans son interface web collaborative hors pair et sa capacité à orchestrer une armada d’agents spécialisés (comme Apollo ou Poseidon) taillés sur mesure pour casser du Windows, du macOS ou du Linux. En contrepartie, cette puissance exige une infrastructure lourde et une prise en main initiale parfois exigeante. Alors que Sliver lui, joue la carte de l’agilité et de la rusticité tactique.

AdaptixC2

Pensé dès le départ pour la vitesse et l’évasion pure, AdaptixC2 fait le pari d’un noyau serveur écrit en Go associé à une interface graphique native fluide (développée en Qt/C++), tranchant ainsi radicalement avec les interfaces Web lourdes de ses concurrents. Sa force de frappe réside dans la légèreté de ses implants, sa gestion très poussée des techniques d’in-memory execution (BOF, reflective DLL injection) et un profil d’évasion EDR taillé pour les environnements Windows hautement surveillés, le tout avec un footprint mémoire dérisoire.

Cependant, face aux ténors du secteur, AdaptixC2 accuse les limites de son niveau de maturité : Face à Mythic, il souffre d’un écosystème d’agents et d’extensibilité beaucoup plus restraint (Mythic régit une armada d’agents Linux/macOS/Windows maintenus par la communauté), ainsi qu’une gestion du travail d’équipe multi-opérateurs moins centralisée. Face à Sliver, s’il rivalise sur la discrétion des implants et l’agilité, il n’embarque pas encore la même variété de canaux d’évasion réseau natifs (mTLS, WireGuard, DNS tunneling).

PoshC2 & Empire (BC-Security)

PoshC2 et PowerShell Empire (repris par BC Security) incarnent la transition historique des attaques axées sur le scripting sous Windows, présentant un contraste saisissant entre spécialisation et couteau suisse de post-exploitation.

PoshC2 excelle par son approche industrielle et pragmatique orientée Windows/C# : il génère automatiquement une armada d’implants pré-configurés, intègre de base des règles de réécriture Proxy/Apache pour durcir l’OPSEC, et consomme très peu de ressources en s’appuyant sur une interface CLI/Python épurée et multi-opérateurs, mais paie cette efficacité par un focus très centré sur l’écosystème Active Directory et une rigidité des charges utiles qui demandent un effort manuel de sleep obfuscation pour franchir les EDR stricts.

De son côté, Empire (associé à son interface graphique Starkiller) demeure la référence absolue pour l’abondance de ses modules post-exploitation natifs et sa capacité historique à exécuter des tactiques Living off the Land (via PowerShell, Python et IronPython), tout en offrant une interface intuitive pour orchestrer des pivots complexes ; toutefois, cet héritage fait aussi sa faiblesse : l’empreinte PowerShell d’origine est aujourd’hui lourdement surveillée par AMSI, ETW et les solutions EDR modernes, nécessitant un travail conséquent d’obfuscation en amont et rendant ses payloads plus bruyants par défaut sur les endpoints récents.

HAVOC C2

Conçu par @C2Matrix / Paul Ungur, Havoc C2 s’impose dans le paysage Red Team comme l’héritier direct de l’ergonomie de Cobalt Strike tout en proposant une architecture moderne pensée pour la furtivité.

Son véritable tour de force réside dans son agent natif (Demon) écrit en C et assembleur, qui intègre par défaut des techniques d’évasion avancées (Ekko/Zloader sleep obfuscation, masquage de pile d’appels, contournement d’ETW/AMSI et Indirect Syscalls), associé à un serveur performant en Go et une interface graphique fluide développée en Qt/C++.

Cette combinaison offre aux opérateurs un confort visuel réactif et des implants d’une discrétion redoutable face aux EDR modernes sous Windows, le tout avec un footprint cloud très raisonnable comparé à la lourdeur Docker de Mythic.

En contrepartie, Havoc souffre encore de sa jeunesse : son écosystème de modules de post-exploitation reste plus restreint que ceux de PowerShell Empire ou de Mythic, la stabilité de certaines fonctionnalités en cours de développement peut faire défaut lors d’engagements critiques, et son focus quasi-exclusif sur l’écosystème Windows laisse de côté la gestion native d’environnements multi-OS comme macOS ou Linux.

Au regard de tout ce qui précède, la maxime selon laquelle arriver au sommet c’est bien, mais s’y maintenir c’est encore mieux, s’arrime parfaitement au paysage des outils de commande et de contrôle. Du haut de ses atouts, de sa disponibilité et de son agilité comparé à d’autres, Sliver C2 est sans aucun doute un ténor dans sa catégorie. Il est vrai qu’il peut aider à causer des dégâts importants, mais c’est sans compter sur l’évolution des contre-mesures, tant au niveau de l’hôte que du réseau. C’est ainsi dire que Sliver C2 Framework est certes puissant, mais face à une configuration sécuritaire même minime, la préparation et l’exécution d’une attaque sortent brutalement du champ des néophytes ou des script kiddies. Toute équipe de sécurité gagnerait à coup sûr à en maîtriser les tenants et aboutissants, pour être sûre de pouvoir contrer d’autres types de hackers ou groupes de hackers dotés d’une expertise beaucoup plus aiguisée.

Si l’expertise surpasse la popularité, rien ne l’arrête : Sliver C2 Framework, patron de la post-exploitation