Comprendre un C2 aujourd’hui : du beaconing discret à la persistance

 Introduction – Le C2 comme colonne vertébrale d’une attaque

Une compromission initiale sans persistance n'est qu'un succès éphémère. Comme le dit l'adage en Red Team : « Une attaque sans C2 est un shell muet. » Le framework de Command & Control (C2) constitue le système nerveux central de toute opération offensive. C'est le point de bascule qui transforme un exploit ponctuel en un contrôle durable et stratégique.

L'évolution des infrastructures C2 reflète la course aux armements entre attaquants et défenseurs. Nous sommes passés du simple reverse shell via Netcat, bruyant et fragile, à des frameworks modulaires sophistiqués orientés OPSEC (Operations Security). Dans ce paysage, Sliver C2 s'est imposé comme une alternative open-source de premier plan, capable de rivaliser avec des solutions commerciales comme Cobalt Strike.

 Rappels techniques sur l’architecture C2

Pour comprendre Sliver, il faut maîtriser les composants fondamentaux d'une infrastructure C2 moderne :

• L'Implant (ou Agent) : Le binaire s'exécutant sur la cible.

• Le Serveur C2 : Le point de ralliement (Mothership) qui centralise les données et distribue les ordres.

• Le Channel : Le tunnel de communication (HTTP, DNS, mTLS).

• Tasking & Exfiltration : Le mécanisme asynchrone d'envoi de commandes et de récupération de données.

Contrairement au modèle "Push" (connexion directe), le C2 moderne privilégie le Pull (Beaconing) : l'implant "appelle" le serveur à intervalles réguliers. Pour rester furtif, on utilise le Jitter (variation aléatoire du temps de sommeil) afin de briser la régularité statistique qui trahirait l'agent auprès des outils d'analyse de trafic.

 Sliver C2 – Présentation technique de l’outil

Développé par Bishop Fox, Sliver est un framework multiplateforme écrit en Go. Sa philosophie repose sur trois piliers : minimalisme opérationnel, furtivité et extensibilité.

Alors que Cobalt Strike est souvent la cible prioritaire des signatures EDR, Sliver offre une flexibilité unique. Il se distingue de frameworks comme Mythic (très orienté web/API) par sa capacité à générer des implants autonomes extrêmement robustes, gérant nativement des protocoles avancés comme WireGuard ou le mTLS, le rendant idéal pour les simulations d'APT (Advanced Persistent Threats).

 Architecture interne de Sliver

L'architecture de Sliver est conçue pour la résilience. Elle repose sur un modèle serveur-client-implant :

1. Le Serveur : Gère la base de données des sessions, les auditeurs (listeners) et la génération des implants.

2. L'Interface Client : Permet à plusieurs opérateurs de collaborer sur la même infrastructure (mode multijoueur).

3. L'Implant : Compilé dynamiquement en Go, il intègre son propre moteur de gestion de tâches.

Le flux de communication suit un cycle strict : l'implant effectue un Initial Check-in (échange de clés), récupère les tâches en attente (Task Fetch), puis renvoie les résultats (Result Push). En cas de perte de connectivité, l'implant entre en mode survie, tentant de se reconnecter via des points de terminaison secondaires prédéfinis.

 Chaîne d’attaque C2 – De l’implant à l’opérateur

Une opération type se décompose ainsi :

• Phase 1 (Déploiement) : L'agent est livré via une méthode d'accès initial (ex: DLL Side-loading sur une application signée).

• Phase 2 (Enregistrement) : L'implant génère un ID unique basé sur les métadonnées de la machine (Hostname, UID) et s'enregistre via un handshake chiffré.

• Phase 3 (Beaconing) : L'implant "dort" 90% du temps. À chaque réveil, il vérifie si l'opérateur a injecté une commande (ex: ls, whoami, ou chargement d'un binaire en mémoire).

• Phase 4 (Exfiltration) : Les résultats sont fragmentés et chiffrés avant d'être envoyés pour éviter la détection par inspection de paquets.

 Communication et furtivité : Le cœur du sujet

Le génie de Sliver réside dans son mimétisme. Il peut encapsuler son trafic dans du HTTPS parfaitement légitime avec des headers et des User-Agents personnalisables.

• Chiffrement : Utilisation systématique de la cryptographie asymétrique pour l'échange de clés initial, suivi d'un chiffrement symétrique pour le flux de données.

• Évasion EDR : Sliver utilise des techniques de Direct Syscalls pour contourner le hooking des API Windows par les outils de sécurité. En évitant les fonctions suspectes comme CreateRemoteThread, il passe sous le radar des analyses comportementales.

 OPSEC et bonnes pratiques côté attaquant

Un ingénieur Red Team ne connecte jamais un implant directement à son serveur. L'infrastructure doit utiliser des Redirecteurs (proxies inverses type Nginx ou serveurs Cloud de confiance).

• Séparation : Le backend réel est masqué derrière plusieurs IP jetables.

• Gestion des logs : Un bon C2 doit limiter les traces sur le disque de la cible (privilégier l'exécution en mémoire / Fileless).

• Erreur classique : Utiliser des certificats TLS par défaut ou des domaines non catégorisés, immédiatement bloqués par les proxys d'entreprise.

 Détection et traces : La vue du défenseur (Blue Team)

Malgré sa sophistication, Sliver n'est pas invisible car un SOC peut le détecter via :

1. Analyse réseau : Identification du pattern de beaconing (même avec du jitter).

2. Indicateurs hôtes : Détection de l'injection de code via l'analyse de la mémoire (Memory Scanning) pour repérer les payloads de type "Reflective DLL".

3. Analyse de processus : Un processus comme notepad.exe établissant des connexions réseau persistantes est une anomalie majeure.

 Sliver dans une simulation réelle

Imaginons un scénario d'intrusion dans une infrastructure critique. L'objectif est d'accéder au contrôleur de domaine. Sliver permet ici de charger des extensions comme BeRoot ou Mimikatz directement en mémoire (via BOFs), de pivoter à travers le réseau interne en utilisant des tunnels SMB, tout en gardant une empreinte disque quasi nulle. Sa force est sa capacité à maintenir l'accès même si une partie de l'infrastructure de redirection est découverte et coupée.

 Comparaison critique

Caractéristique	Sliver C2	Cobalt Strike	Mythic
Coût	Gratuit (Open Source)	Très onéreux	Gratuit
Langage	Go	Java / C	Python / Go
Détection	Moins de signatures	Très surveillé	Modulaire
Courbe d'apprentissage	Moyenne	Faible	Élevée

Quand l'utiliser ? Pour des opérations de Red Team où la discrétion face à des EDR de nouvelle génération est primordiale.

 Implications pour la cybersécurité moderne

Le C2 n'est plus un simple outil, c'est une surface d'attaque. Le blocage des payloads est devenu insuffisant ; la défense doit désormais se concentrer sur le Threat Hunting comportemental. L'avenir des attaques C2 s'oriente vers l'IA, capable d'ajuster dynamiquement le trafic pour qu'il soit statistiquement indiscernable du trafic utilisateur normal.

Mise en pratique – Observation d’un C2 Sliver du point de vue SOC

Cette section décrit le déploiement minimal d’un C2 Sliver dans un lab afin d’identifier les signaux exploitables côté défense. L’objectif n’est pas l’attaque, mais l’analyse des comportements réseau et hôte générés par un framework C2 moderne.

Topologie observée

• Serveur C2 (Linux) : Sliver Server + listener HTTPS

• Hôte compromis (Windows) : Implant Sliver

• Réseau : isolé (NAT / Host-Only)

[ Sliver Server ]
        |
     HTTPS chiffré
        |
[ Processus Windows ]

Initialisation et communication

Le serveur Sliver est démarré et expose un listener HTTPS.

Un implant Windows est généré avec un intervalle de beaconing et un jitter configurés.

Côté SOC, cela se traduit par :

• connexions HTTPS sortantes intermittentes

• trafic chiffré sans payload exploitable

• timing pseudo-aléatoire mais stable dans le temps

Comportement réseau observable

Même chiffré, le trafic présente des caractéristiques détectables :

• Beaconing périodique avec jitter

• Sessions HTTPS longues et répétitives

• User-Agent atypique ou personnalisé

• Destination IP stable, parfois sans résolution DNS

 Les patterns temporels restent un point d’ancrage majeur pour la détection.

Comportement hôte

Sur la machine Windows :

• un processus légitime peut initier des connexions réseau persistantes

• absence d’écriture disque significative

• exécution majoritairement en mémoire

• création de threads ou appels système directs (Direct Syscalls)

Ces signaux sont visibles via :

• EDR (process + network correlation)

• ETW / Sysmon

• analyse mémoire

Cycle de vie de la session

L’implant :

1. effectue un check-in initial

2. entre en veille prolongée

3. récupère des tâches lors du beacon

4. renvoie les résultats chiffrés

Pour un SOC, cela se traduit par un bruit très faible, mais persistant, souvent ignoré au profit d’alertes plus bruyantes.

Résilience et continuité

En cas de coupure réseau :

• l’implant conserve son état

• reprend automatiquement la communication

• ne nécessite aucune interaction utilisateur

Cette persistance silencieuse est typique des opérations APT et doit être traitée comme telle.

Ce que Sliver impose aux équipes SOC

Sliver démontre que :

• le chiffrement n’est plus un indicateur

• les IOC statiques sont insuffisants

• la détection repose sur la corrélation comportementale

• le Threat Hunting devient indispensable

Un C2 moderne ne se bloque pas, il se comprend.

 Conclusion

Comprendre Sliver, c'est comprendre la philosophie des attaquants modernes : la persistance par l'invisibilité. Pour un ingénieur en cybersécurité, maîtriser ces frameworks est essentiel, non pas pour attaquer, mais pour construire des systèmes capables de détecter l'indétectable.

Sliver C2 illustre parfaitement la mutation des attaques modernes : moins de bruit, plus de contrôle, et une obsession quasi scientifique de la discrétion. À travers son architecture, ses mécanismes de communication et son approche OPSEC, il démontre que le véritable champ de bataille ne se situe plus dans l’exploit initial, mais dans la capacité à maintenir un accès fiable sans déclencher d’alerte. Pour les défenseurs comme pour les Red Teams, comprendre Sliver revient à comprendre comment pensent les attaquants d’aujourd’hui… et surtout ceux de demain.