Construire une Infra C2 avec Sliver en Lab Isole pour la Recherche Defensive

Chaque fois qu'un analyste SOC ouvre un ticket pour un beacon suspect, il y a de fortes chances que personne dans l'equipe n'ait jamais vu un canal de command-and-control fonctionner de ses propres yeux. Les operateurs Red Team utilisent Sliver, Mythic et Havoc tous les jours, mais la plupart des defenseurs ne connaissent ces frameworks que par des captures dans des rapports Mandiant. Ce vide est dangereux : on ne detecte de facon fiable qu'un comportement que l'on a observe. Ce guide construit un lab Sliver isole et sans internet dont le seul but est de generer une telemetrie realiste, controlee et documentee, pour qu'une Blue Team ecrive et valide des regles de detection contre des indicateurs qu'elle a elle-meme produits. Tout ce qui suit se passe dans un VLAN air-gapped et ne porte aucun risque legal, car le lab ne parle a personne en dehors de 10.50.0.0/16.

Qu'est-ce qu'un C2, et pourquoi Sliver pour un lab defensif

Un framework de command-and-control (C2) est le cote operateur du post-exploitation : un serveur qui recoit les check-ins d'implants (aussi appeles beacons ou agents) sur des hotes compromis, plus un canal de tasking qui renvoie des commandes. Sliver, maintenu par BishopFox, est ecrit en Go et fournit des implants multiplateformes pour Windows, Linux et macOS via mTLS, WireGuard, HTTP(S) et DNS. Pour un lab defensif il bat les alternatives sur trois axes : contrairement a Cobalt Strike il est gratuit et son code est auditable, on peut donc lire exactement ce que fait un implant ; contrairement a Mythic il demande beaucoup moins d'infrastructure. Cette auditabilite compte car on cherche a mapper le comportement vers des detections, et une boite noire n'enseigne rien de generalisable.

Modele de menace : pourquoi les defenseurs doivent faire tourner l'outillage offensif

L'ingenierie de detection echoue quand elle repose sur la theorie. Les editeurs publient des regles generiques, les equipes les importent, et le premier vrai incident revele que la regle a declenche sur un champ que l'operateur ne touche jamais, ou a rate celui qui comptait. Faire tourner l'outillage offensif soi-meme referme cette boucle. On apprend les named pipes par defaut de Sliver, ses patterns de process injection, les appels d'API exacts derriere execute-assembly et la cadence reseau d'un beacon mTLS. On apprend aussi ses boutons d'evasion, si bien que lorsqu'une regle cesse de declencher, on comprend quel bouton l'adversaire a tourne. Le lab n'attaque personne ; c'est une usine a telemetrie dont la sortie est des regles Sigma, des IOCs et des hypotheses de hunting auxquelles on fait confiance car on a genere soi-meme la verite terrain.

Architecture du lab : VLANs, pfSense et isolation totale de l'egress

La topologie est volontairement simple et strictement segmentee. Une VM Debian 12 sert de teamserver avec 4 vCPU et 8 Go de RAM. Elle vit dans le VLAN C2 10.50.10.0/24. Les cibles vivent dans un VLAN victimes separe 10.50.20.0/24. Entre les deux se trouve un pfSense dont le ruleset n'autorise le trafic qu'entre ces deux sous-reseaux et applique aucun NAT sortant : le lab n'a aucune route vers internet, par conception. C'est important pour deux raisons. D'abord, un implant qui ne peut joindre aucune adresse reelle ne peut fuiter vers un tiers si vous faites une erreur. Ensuite, cela oblige a modeliser le reseau comme une entreprise segmentee l'est vraiment. Si vous n'avez pas encore monte de lab de base, Pentest Web depuis Zero: Construire un Lab Sur avec DVWA, Juice Shop et Burp Suite est une fondation solide a reutiliser ici.

Installer le teamserver, etape par etape

Le chemin rapide est curl https://sliver.sh/install | sudo bash, mais dans un environnement isole on ne canalise jamais un script distant vers root. A la place, telechargez le binaire de release signe sur une machine connectee, verifiez-le avec cosign verify-blob contre la cle publiee par BishopFox, calculez son SHA-256 et transportez-le via une cle USB dediee. Sur la VM Debian, placez le binaire dans /usr/local/bin/sliver-server, creez un compte de service non-root sliver et lancez le serveur sous systemd avec une unit durcie (NoNewPrivileges, ProtectSystem=strict, un WorkingDirectory prive). Demarrez la console avec sliver-server et generez une config operateur avec new-operator --name analyst --lhost 10.50.10.5. Limiter le profil operateur a l'adresse du VLAN C2 empeche un implant egare d'atteindre une interface de gestion qu'il ne devrait pas.

Generer des implants et regler les profils

Generez un premier implant avec generate --mtls 10.50.10.5:8443 --os windows --arch amd64 --skip-symbols --save ./payloads. Le flag --skip-symbols retire les tables de symboles Go, reduit le binaire d'environ 40% et ralentit le reverse engineering rapide, tout en laissant assez pour debugger votre propre lab. Deposez cet implant non obfusque sur une VM Windows 11 21H2 avec Defender temps reel actif et il meurt typiquement en environ 12 secondes. Ce n'est pas un echec ; c'est une mesure. Vous avez desormais un signal propre de ce que Defender attrape et une baseline a comparer quand vous ajouterez de l'evasion deliberement. Pour etudier la chaine de livraison qui precede le beacon, associez-le a Initial Access Simule: Macros, LNK et ISO dans un Lab Windows 11 Isole.

Du check-in du beacon aux regles de detection

Le benefice pedagogique commence a l'instant ou le beacon se connecte. Chaque commande operateur produit une empreinte distincte : getsystem touche la duplication de token, execute-assembly spawn un processus sacrificiel et charge le CLR, sideload mappe une DLL unbacked. Instrumentez les hotes victimes avec Sysmon en config SwiftOnSecurity, expediez les evenements via un Elastic Agent vers un cluster local et correlez contre des regles Sigma. Sur trois sprints cibles, une petite equipe peut cartographier des dizaines de nouvelles detections, des noms de named pipe par defaut de Sliver jusqu'aux spawns rundll32 sans command line. Tout ce pipeline pour transformer un IOC en regle maintenable est documente dans Threat Hunting avec Sigma et Elastic: De l'Indicateur a la Regle de Detection, qui se marie directement aux evenements que ce lab emet.

Mouvement lateral dans un mini Active Directory

Le mouvement lateral, c'est la ou le lab se rentabilise. Montez un mini-AD avec deux domain controllers, quatre workstations et un file server, reproduisant la topologie d'un client de taille moyenne. Avec l'implant Sliver initial sur un poste a faibles privileges, utilisez Rubeus pour du Kerberoasting, puis pivotez via un tunnel WireGuard pour atteindre le domain controller sans jamais le toucher directement depuis le teamserver. Les techniques de Pentest Active Directory : Kerberoasting Pas a Pas dans un Lab GOAD et Pivoting avec Chisel et Ligolo-ng : Reseaux Segmentes en Lab de Pentest sont la meme logique avec un outillage different. Chaque saut laisse des traces : 4624 type 3, tickets 4769 en RC4 faible, connexions WMI anormales. Chacune devient du materiel d'entrainement avec un echantillon known-good et un known-bad.

Durcir les detections et fermer la boucle

Un lab sans boucle de retour est une demo. Apres chaque run, traitez chaque detection ecrite comme une hypothese et tentez de la contourner. Activez les fonctions d'evasion de Sliver une par une (reshaping du trafic, jitter, transports alternatifs) et observez quelles regles survivent. Les regles qui ne matchent qu'un string par defaut sont fragiles ; les regles ancrees sur le comportement (une region memoire unbacked qui execute, une chaine parent-enfant qui ne devrait jamais exister) survivent au tuning. Versionnez vos regles Sigma dans git, taggez chacune avec la technique ATT&CK couverte et notez le profil exact d'implant qui a genere les evenements source pour qu'un collegue reproduise le signal. Cette reproductibilite fait la difference entre une regle en laquelle on a confiance en production et une regle dont on espere qu'elle fonctionne.

Pieges et OPSEC du lab

L'OPSEC du lab compte plus qu'on ne croit. Meme air-gapped, des snapshots de VM contenant des implants actifs ont deja fuite vers des repos publics parce que quelqu'un les a uploades par erreur. La regle est simple : les VMs du lab vivent sur un datastore chiffre LUKS, les snapshots ne quittent jamais l'hote, et tout artefact qui doit sortir (regle Sigma, IOC, video demo) passe d'abord par une revue manuelle. Cela rejoint la discipline de OPSEC pour Chercheurs en Securite: Modele de Menace Personnel et Hygiene des Metadonnees : Nettoyer EXIF, PDF et Office avant Publication. La blessure classique auto-infligee, c'est de publier un PDF de rapport dont les metadonnees livrent a l'adversaire le username, le hostname et le chemin du fichier sur le portable perso du chercheur.

Checklist de deploiement

Avant de declarer le lab pret, confirmez chaque point : pfSense impose des regles inter-sous-reseaux uniquement avec zero NAT sortant ; le binaire du teamserver a ete verifie par cosign et tourne sous une unit systemd non-root durcie ; les configs operateur sont limitees au VLAN C2 ; les cibles Windows font tourner Sysmon (config SwiftOnSecurity) vers un cluster Elastic local ; le mini-AD reproduit une topologie realiste ; chaque regle Sigma est versionnee avec un tag ATT&CK et un profil source reproductible ; les snapshots vivent sur LUKS et ne quittent jamais l'hote ; et chaque artefact exporte est passe par une revue de metadonnees. Si une ligne reste non cochee, la telemetrie collectee n'est pas encore une verite terrain fiable.

FAQ : Faire tourner un framework C2 dans un lab est-il legal ?

Oui, a condition que le serveur C2 et chaque implant restent dans une infrastructure que vous possedez et controlez, sans route vers des systemes tiers. L'exposition legale de l'outillage offensif vient du fait de toucher des machines que vous n'etes pas autorise a toucher. Un VLAN air-gapped avec zero NAT sortant supprime entierement cette exposition : l'implant n'a litteralement nulle part ou aller. Gardez un scope ecrit pour le lab, etiquetez les VMs et n'attachez jamais un vrai credential de production ni de vraies donnees client a l'environnement.

FAQ : Sliver, Mythic ou Cobalt Strike pour un lab defensif ?

Pour un lab defensif de telemetrie, Sliver est en general le meilleur point de depart : gratuit, open source et auditable, on peut donc retracer chaque comportement jusqu'a la source et generaliser ses detections. Mythic brille quand on veut modeliser un ecosysteme d'agents varie mais coute plus d'installation. Cobalt Strike represente une grande part des intrusions reelles, si bien que les equipes matures finissent par l'ajouter pour elargir la couverture, mais son licensing et sa nature fermee en font un mauvais premier outil d'apprentissage. Commencez par Sliver, comprenez les fondamentaux, puis elargissez.

Conclusion

Si vous defendez une organisation et n'avez jamais vu un beacon Sliver sur un ecran que vous controlez, votre detection reste theorique. Bloquez une journee entiere, montez le lab avec pfSense plus Debian plus deux cibles Windows, generez un implant non obfusque, laissez-le executer des commandes pendant trente minutes et ouvrez Sysmon. Vous repartirez avec plus de matiere de hunting concrete que plusieurs formations payantes cumulees, et avec zero risque legal car tout se passe dans le VLAN 10.50.0.0/16 qui ne parle a personne dehors. Le but n'est pas de devenir attaquant ; c'est de rendre votre defense empirique plutot qu'aspirationnelle.