VM attaquante

La VM attaquante compile le module, sert les payloads, reçoit la connexion reverse et affiche le dashboard.

Image préconstruite

Archive finale:

• Télécharger: kozaci-attacker.qcow2.tar.zst
• Checksums: page checksums

Après téléchargement, utiliser la page checksums pour vérifier l'archive.

Utilisation:

mkdir -p images
tar --zstd -xf /chemin/vers/kozaci-attacker.qcow2.tar.zst -C images

Le disque extrait doit ensuite être disponible sous:

images/attacker.qcow2

Une fois les deux images extraites (attacker.qcow2 et victim.qcow2), lancer ./scripts/host-setup.sh depuis la racine du dépôt. Le script détecte les disques existants, prépare le réseau et lance les VMs normalement. Sur l'attaquant le script setup-attacker.sh à déjà été lancé. La VM victime peut être lancée après l'attaque. Normalement le serveur Flask est déjà lancé et le module compilé. Il suffit de lancer le dashboard pour voir l'état du rootkit. Si ce n'est pas le cas il suffit de lancer avec ~/start-attacker-panel.sh puis ~/open-attacker-dashboard.sh. puis passer à la VM victime pour déclencher l'attaque.

Une bonne pratique est de lancer le serveur de fichiers host avant de lancer les VMs pour s'assurer d'avoir les dernières versions des scripts et sources servis depuis le dépôt. Si le rootkit a changé, il faudra ensuite relancer ~/build-demo-rootkit.sh côté attaquant pour republier le .ko.

./scripts/serve-host.sh

Ce script régénère served/wlkom-src.tar.gz et sert le dossier served/. Gardez-le ouvert pendant que vous relancez le setup dans la VM concernée avec wget -qO- http://10.0.2.2:8000/setup-attacker.sh | bash ou wget -qO- http://10.0.2.2:8000/setup-victim.sh | bash, elle récupérera alors les dernières versions disponibles sur le host.

Setup initial

Dans la VM attaquante fraîchement installée:

wget -qO- http://10.0.2.2:8000/setup-attacker.sh | bash

Le script:

1. configure wlkom-lab en 192.168.100.1/24
2. configure wlkom-wan en DHCP
3. télécharge wlkom-src.tar.gz depuis le host
4. installe Python, Flask, build tools, gcc-12, Firefox, NetworkManager, Wireshark et tcpdump
5. installe le noyau 5.15.0-171-generic et les headers
6. met les paquets kernel en hold
7. désactive les upgrades automatiques
8. copie les sources dans ~/wlkom-attacker
9. crée les helpers utilisateur
10. prépare le venv Flask
11. compile wlkom.ko si le bon noyau est déjà actif
12. lance le panel et Wireshark si aucun reboot n'est requis.

La VM attaquante est celle qui a le plus de dépendances parce qu'elle compile le module et héberge l'interface. La victime, elle, doit rester plus légère: elle télécharge un .ko déjà prêt.

Fichiers créés

Chemin	Rôle
~/wlkom-attacker/	code attaquant installé
~/wlkom-attacker/rootkit-demo/	sources kernel compilées
~/wlkom-attacker/web_payloads/rootkit-demo/wlkom.ko	payload servi à la victime
~/build-demo-rootkit.sh	compile et publie wlkom.ko
~/start-attacker-panel.sh	lance Flask et le listener 4444
~/kill-attacker-panel.sh	arrête le panel et libère 8080/4444
~/open-attacker-dashboard.sh	démarre puis ouvre le dashboard
~/connect-rootkit.sh	listener manuel chiffré de secours
~/start-wireshark-c2.sh	capture le trafic C2
~/Desktop/WLKOM Dashboard.desktop	raccourci dashboard
~/Desktop/WLKOM Wireshark C2.desktop	raccourci capture
~/.config/autostart/wlkom-attacker-panel.desktop	autostart du panel

Le script ajoute aussi un @reboot dans la crontab utilisateur pour relancer le panel après redémarrage de la VM attaquante.

Compiler le module

~/build-demo-rootkit.sh

Le helper refuse de compiler si:

• uname -r n'est pas 5.15.0-171-generic
• /lib/modules/$(uname -r)/build manque
• make, gcc ou gcc-12 manquent.

Sortie attendue:

Payload: /home/user/wlkom-attacker/web_payloads/rootkit-demo/wlkom.ko
Vermagic: 5.15.0-171-generic ...

Le vermagic est le point à regarder en premier si insmod échoue côté victime. Il doit commencer par le même uname -r que la victime. Voir Références techniques.

Lancer le dashboard

~/start-attacker-panel.sh
~/open-attacker-dashboard.sh

URL:

http://192.168.100.1:8080

Services:

Route ou port	Rôle	Accès
/	dashboard React	attaquant/local
/api/rootkit/*	API de contrôle	attaquant/local
/freecloude	page victime	public réseau privé
/payload/freecloude.py	loader victime et élévation de privilèges	public réseau privé
/payload/freecloude.sh	installateur lancé par le loader	public réseau privé
/payload/rootkit-demo/wlkom.ko	module compilé	public réseau privé
0.0.0.0:4444	listener C2	connexion reverse module

La restriction d'accès est faite côté Flask: seules /freecloude et /payload/* restent accessibles depuis la victime.

Listener kernel

Le backend crée un RootkitController qui écoute sur:

0.0.0.0:4444

Quand wlkom.ko se connecte:

1. le statut passe en detected=true
2. la socket reste dans _pending_sock
3. le dashboard demande le mot de passe
4. le backend dérive la clé FNV-1a/XOR
5. il déchiffre la bannière KOZACITEAM \nPassword:
6. il envoie le mot de passe chiffré
7. la socket devient active si Authenticated. et wlkom> sont reçus.

La socket est dite "pending" avant authentification. Elle existe déjà côté TCP, mais elle n'est pas encore utilisable pour envoyer des commandes. C'est normal: le module se connecte avant que l'utilisateur ait tapé le mot de passe dans le dashboard.

Listener manuel

Si le dashboard gêne un diagnostic:

~/kill-attacker-panel.sh
~/connect-rootkit.sh

Ce listener reproduit la même crypto XOR/FNV-1a et permet de tester la connexion kernel sans React ni Flask API.

Capture C2

~/start-wireshark-c2.sh

Par défaut, le script capture:

host 192.168.100.2 and tcp port 4444

Il ouvre Wireshark si l'interface graphique est disponible, sinon il utilise tcpdump.

Vérifications

uname -r
ip -brief addr
ss -lntp | grep -E ':8080|:4444'
curl -fsS http://192.168.100.1:8080/api/rootkit/status
ls -lh ~/wlkom-attacker/web_payloads/rootkit-demo/wlkom.ko
modinfo -F vermagic ~/wlkom-attacker/web_payloads/rootkit-demo/wlkom.ko

Le vermagic doit commencer par:

5.15.0-171-generic

Si le dashboard ne répond pas ou si le listener 4444 est déjà pris, voir Troubleshooting.