Architecture

Cette section explique comment les composants Kozaci s'assemblent: host QEMU/KVM, réseau privé, setup des VMs, dashboard attaquant, module kernel, persistance et reconnexion après reboot.

La bonne manière de lire l'architecture est de suivre les responsabilités:

• Le host prépare les VMs et le réseau.
• L'attaquant compile, sert les payloads, écoute le C2 et affiche l'interface.
• La victime charge le module, puis le module initie la connexion reverse.
• Le backend est le traducteur entre l'interface web et le protocole kernel.

RéseauBridge privé, IPs fixes, NAT QEMU, ports HTTP et canal reverse TCP.Cycle de vieDu setup host au reboot victime, avec auth, commandes et persistance.ChiffrementFNV-1a, XOR, offsets TX/RX, exemple Wireshark et limites.

Vue courte

Le host construit un réseau privé 192.168.100.0/24. L'attaquant écoute en HTTP 8080 pour le dashboard, la page victime et les payloads, puis en TCP 4444 pour la session kernel. La victime récupère freecloude.py. Ce loader élève les privilèges, télécharge freecloude.sh, puis le .sh vérifie wlkom.ko, prépare la persistance et charge le module. Le module initie ensuite une connexion reverse chiffrée vers l'attaquant.

La persistance repose sur les mécanismes Linux standards:

modules-load.d -> demande le chargement de wlkom au boot
modprobe.d     -> redonne attacker_ip, command_port et password

Le rootkit ne crée pas lui-même ces fichiers. L'installateur freecloude.sh, lancé par freecloude.py, les écrit après avoir vérifié que le module téléchargé correspond au noyau courant. Si le chargement runtime échoue ensuite, il retire cette persistance préparée.

Pour les notions noyau derrière ce schéma, la page de référence est Références techniques.