There is an english version on this article that you can find here.

Cet article présente un retour d’expérience sur l’installation et les tests de deux sandboxes :

• Drakvuf, maintenue par le CERT polonais
• Cuckoo3, maintenue par le CERT estonien

L’idée de cet article est de proposer un retour d’expérience concret en résumant :

• l’installation de ces deux sandboxes,
• les principales difficultés rencontrées,
• leurs principales fonctionnalités d’analyse,
• ainsi que les avantages et inconvénients de chacune.

Pourquoi ces deux projets ?

#

On pourrait se demander pourquoi avoir choisi Drakvuf et Cuckoo3, plutôt que d’autres projets tels que :

• CAPEv2
• PANDA-RE
• Detux

Les projets retenus sont des solutions récentes, activement maintenues, et proches, dans leur fonctionnement, d’outils comme any.run ou JoeSandbox.

Au fil des recherches, une étude comparative réalisée par l’Université de la Défense de Serbie a été identifiée : A pilot comparative analysis of the Cuckoo and Drakvuf sandboxes: An end-user perspective, cette ci apporte un éclairage intéressant sur le sujet.

• Cette étude date de 2022.
• Elle compare Cuckoo 2.05 et Drakvuf 0.18.

Les versions comparées dans cet article sont :

• Cuckoo3 v0.11.1, sortie le 9 mai 2025, installée sur une machine virtuelle sous Ubuntu 22, hébergée par un ESXi en version 8.0 U3.

  Cuckoo3 est une version entièrement réécrite de Cuckoo, qui était initialement en Python 2.

• Drakvuf v0.20, sortie le 17 novembre 2025, installée sur un serveur bare metal équipé d’un Xeon E5-1650 v2, fonctionnant sous Ubuntu 24.04.3 LTS.

Même si cet article n’a pas vocation à être une mise à jour de l’étude universitaire mentionnée plus haut, je ne m’interdis pas d’en réutiliser certaines parties pour illustrer les évolutions des deux projets.
Cette comparaison m’est permise par la licence utilisée par l’étude : Creative Commons Attribution 4.0 International.
Cet article repose donc sur la même licence, et peut être librement partagé et adapté, sous réserve de respecter les conditions d’attribution prévues par celle-ci.

Passons maintenant aux choses sérieuses.

Vue d’ensemble

#

Drakvuf Sandbox

#

Présentation

#

Drakvuf Sandbox est une sandbox d’analyse comportementale sans agent (agentless) fondée sur l’introspection de machines virtuelles : elle observe l’exécution d’un échantillon depuis l’hyperviseur via DRAKVUF, sans utiliser d’agent sur la VM invitée, ce qui réduit fortement les mécanismes d’évasion.

L’interface Web orchestre le cycle dépôt → exécution contrôlée → restitution et fournit des traces détaillées (arbre des processus, appels système, fichiers, registre, réseau) exploitables pour qualifier rapidement un binaire.

Installation

#

Préambule

#

En introduction, dans le README du dépôt GitHub, voici le commentaire laissé par les développeurs :

Here be dragons 🐉. Maintaining your own sandbox is a difficult task and this project uses technology that is not user-friendly. Be prepared to brush up on your debugging skills as bugs may be reproducible only on your configuration. On the other hand, it’s not purely an R&D project and it is used in production! Source code and issues section on both DRAKVUF Sandbox and DRAKVUF engine projects are your best friend.

Préparez-vous donc à devoir débuguer à de nombreuses reprises.

Il est recommandé, plutôt que d’utiliser une image ISO “brute” de Windows, de préparer un fichier autounattend.xml qui automatisera une bonne partie (sinon l’intégralité) de l’installation de Windows.
D’autant plus que vous pouvez automatiser certaines tâches hors ligne demandées plus tard par la documentation de cette façon !

Pour cela, une fois votre image ISO téléchargée (miroir), rendez-vous sur le site schneegans.de qui permet de générer le fichier XML directement depuis votre navigateur, sans devoir installer plusieurs dizaines de SDK Microsoft.

Ensuite, pour intégrer ce fichier XML dans l’ISO, depuis Windows, vous pouvez utiliser le projet WIMUtil, qui répond parfaitement à ce besoin. (Aucune solution n’a été testée sous Linux dans le cadre de cet article, mais des alternatives existent probablement. 😉.)

cd /tmp

# Télécharger et installer les paquets précompilés Xen depuis le dépôt GitHub
# Adapter la commande ci-dessous
wget https://github.com/tklengyel/drakvuf-builds/releases/xen-files.deb

sudo apt update
sudo apt install ./xen-hypervisor*.deb

sudo reboot

# Détecter si le système est compatible Xen
xen-detect

# Lister les machines virtuelles gérées par Xen
xl list

# Ajouter les binaires Xen au PATH
# Ajouter le chemin des binaires et un alias pratique dans ~/.bashrc
echo "export PATH=$PATH:/usr/sbin" >> ~/.bashrc
echo "alias ll='ls -la'" >> ~/.bashrc

# Recharger le fichier de configuration du shell
source ~/.bashrc

cd /tmp

# Télécharger les paquets Drakvuf depuis le dépôt GitHub
# Adapter la commande ci-dessous
wget https://github.com/tklengyel/drakvuf-builds/releases/drakvuf-files.deb

# Mettre à jour les dépôts et installer le bundle Drakvuf
sudo apt update
sudo apt install ./drakvuf-bundle*.deb

# Vérifier que la commande vmi-win-guid fonctionne correctement
vmi-win-guid

# Vérifier le bon chargement des commandes
drakvuf
injector

# Installation des outils nécessaires
sudo apt update
sudo apt install btop iptables tcpdump dnsmasq qemu-utils bridge-utils libmagic1 python3-venv redis-server

# Création d'un environnement virtuel Python
cd /opt
python3 -m venv venv
. venv/bin/activate

# Installation de Drakvuf Sandbox
pip install wheel
pip install drakvuf-sandbox

# Copier l'ISO de Windows 10 22H2 sur la VM
# Installation de l'image Windows
drakrun install ./Win10_22H2.iso --vcpus 4 --memory 8192

# Se connecter via VNC à la machine virtuelle pour terminer l'installation.

# (Optionnel) Suppression des pilotes audio si un problème survient
sudo sed -i '/^soundhw *=/d' /etc/drakrun/cfg.template

# Une fois l'installation initiale de la VM terminée, exécutez la commande suivante pour générer les différents profils
drakrun postinstall

# Modifier le fichier de configuration pour activer Internet
nano /etc/drakrun/config.toml
# --> Changer la valeur de net_enable de "false" à "true"

# (Optionnel) Suppression de l'exécution du fichier PowerShell lors du démarrage de la VM d'analyse si celui-ci pose problème par la suite
# --> Changer la valeur de no_post_restore de "false" à "true"

# Démarrer la modification de la VM master
drakrun modify-vm0 begin
# Effectuer les modifications souhaitées

# Valider les changements
drakrun modify-vm0 commit

# Annuler les modifications effectuées
drakrun modify-vm0 rollback

cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
ngen.exe executeQueuedItems
cd C:\Windows\Microsoft.NET\Framework64\v4.0.30319
ngen.exe executeQueuedItems

# Démarrer la machine virtuelle d'analyse
drakrun vm-start

# Tester l'exécution de Drakvuf
drakrun drakvuf-cmdline

# Exemple d'exécution manuelle de Drakvuf avec les profils JSON
drakvuf -o json -F -k 0x1aa002 -r /var/lib/drakrun/profiles/kernel.json -d vm-1 \
  --json-ntdll /var/lib/drakrun/profiles/native_ntdll_profile.json \
  --json-wow /var/lib/drakrun/profiles/wow64_ntdll_profile.json \
  --json-win32k /var/lib/drakrun/profiles/native_win32k_profile.json \
  --json-kernel32 /var/lib/drakrun/profiles/native_kernel32_profile.json \
  --json-wow-kernel32 /var/lib/drakrun/profiles/wow64_kernel32_profile.json \
  --json-tcpip /var/lib/drakrun/profiles/native_tcpip_profile.json \
  --json-sspicli /var/lib/drakrun/profiles/native_sspicli_profile.json \
  --json-kernelbase /var/lib/drakrun/profiles/native_kernelbase_profile.json \
  --json-iphlpapi /var/lib/drakrun/profiles/native_iphlpapi_profile.json \
  --json-mpr /var/lib/drakrun/profiles/native_mpr_profile.json \
  --json-clr /var/lib/drakrun/profiles/native_clr_profile.json

# Exemple d'exécution automatisée avec le profil par défaut
$(drakrun drakvuf-cmdline) -a procmon

# Lancer le worker Drakrun sur la VM 1
drakrun worker --vm-id 1

Pour la suite de l’installation (création de services, lancement de l’interface Web), la documentation du projet peut être suivie pour compléter l’installation. Aucune difficulté particulière n’ayant été rencontrée à cette étape, aucun complément spécifique n’est ajouté ici.

Difficultés rencontrées

#

Lors de la création de la VM master, des problèmes liés aux pilotes audio ont été rencontrés.

Pour rappel, ce problème a été résolu en supprimant l’implémentation du son depuis le fichier cfg.template avec la commande suivante :

sudo sed -i '/^soundhw *=/d' /etc/drakrun/cfg.template

Un second problème observé concernait d’importantes lenteurs, ainsi que des problèmes de stabilité de l’injection de l’agent drakcore.
Ces 3 points ont été corrigés lors du passage en version 0.20.

Utilisation

#

Une fois une partie des problèmes corrigés, on peut accéder pour la première fois à l’interface Web via l’adresse IP de la machine sur le port 5000 (si ce port n’a pas été modifié lors de la configuration).

Voici ce à quoi ressemble l’interface Web après quelques utilisations.

Par défaut, vous n’aurez évidemment pas de rapports d’analyse préexistants.

L’interface Web est très fonctionnelle (dans le bon sens du terme) : il n’y a aucune fonctionnalité inutile.

Après l’installation, cet onglet est vide ; nous y reviendrons prochainement.

• Choix de la durée d’analyse entre 1 et 15 minutes
• Choix des plugins parmi une liste assez importante permettant d’interagir avec la VM d’analyse pendant l’exécution du binaire
• Possibilité de définir le nom du binaire
• Possibilité de lancer le sample avec une commande de lancement personnalisée

Par défaut, Internet (si configuré) et les captures d’écran sont activés. Il est possible de les désactiver en cochant une case.

L’onglet “API Docs” renvoie vers la documentation Swagger, qui permet de tester les différents endpoints en situation réelle.

Je ne sais pas si le projet est pensé “API-first”, mais il semble pouvoir fonctionner en totale autonomie via l’API (soumission des binaires, récupération des rapports, etc.).

Enfin, l’onglet “RQ Dashboard” permet d’accéder aux informations des différents workers stockés dans le cache Redis.

Tout ça, c’est bien beau, mais à quoi ressemble un rapport d’analyse ?

Eh bien, à ça :

Les rapports sont composés de trois catégories principales :

• Le process tree

• Les informations sur le binaire, avec la possibilité de récupérer certaines captures (liées aux plugins sélectionnés lors du lancement de l’analyse) :

  • Captures PCAP
  • Clés TLS
  • Dumps mémoire
    • À noter ici qu’il s’agit d’une archive zip contenant des fichiers de vidages mémoire de plusieurs processus et non de d’un dump mémoire de toute la VM.

• La suite du rapport, composée de quatre onglets principaux :

  • Summary report

    Ici, on retrouve le processus créé, ainsi que les domaines appelés, les requêtes HTTP, les "Cracked URLs", les connexions, les fichiers modifiés et ceux supprimés, ainsi que les TTPs.

  • General logs
    

    

    Ici se trouvent les différents logs d’exécution de l’analyse, regroupés par plugins.

  • Process info

    Pour chacun des processus du process tree, il est possible d’avoir des détails avancés sur celui-ci.

    Cette fonctionnalité n’a pas pu être testée dans l’environnement utilisé pour cet article.

  

  • Screenshots
    Comme proposé par beaucoup d’autres sandboxes commerciales aujourd’hui, Drakvuf prend des captures d’écran au cours de la détonation, sans doute parce que cela nécessite moins d’espace de stockage qu’une vidéo de la détonation complète, pour une plus-value qui reste très intéressante.
    

    

Fun fact : lors de mes tests, l’IP de ma machine DRAKVUF s’est retrouvée bloquée par mon IDS Suricata pour avoir fait sonner les règles ET ATTACK_RESPONSE PowerShell NoProfile Command Received In Powershell Stagers et ET HUNTING PowerShell NonInteractive Command Common In Powershell Stagers (lors de l’analyse d’un binaire qui appelait un script PowerShell, dont des bribes se sont retrouvées écrites dans le rapport). Vous pourriez alors me dire que cela ne serait pas arrivé si j’avais configuré plus tôt le certificat SSL de mon serveur… et vous auriez raison !

Avantages et inconvénients

#

Avantages :

• Documentation maintenue et à jour
• API documentée et complète
• Support de Windows 7 / 10 (22H2)
• Moteur Drakvuf
• Plugins nombreux associés au moteur Drakvuf (parmi lesquels les principaux : apimon, filetracer, memdump, procmon, socketmon et tlsmon ; liste non exhaustive)
• Accès VNC à la VM depuis l’interface Web, ce qui permet, dans le temps imparti, de naviguer à travers les répertoires une fois le sample exécuté
• Process tree détaillé, possibilité d’obtenir des détails sur chacun des processus, de manière individuelle (ne fonctionne pas dans mon cas)
• Possibilité de déchiffrer le trafic de la capture réseau de l’analyse
• Prise en charge des archives chiffrées (depuis la version 0.20)

Inconvénients :

• Ne prend pas en charge les versions récentes de Windows 10, ni aucune version de Windows 11 (probablement lié à l’injection de l’agent drakcore)
• Ne prend pas en charge Linux non plus
• Impossibilité d’analyser des liens (contournement possible en téléversant un fichier vide et en exécutant une commande personnalisée)
• Impossibilité d’interrompre une analyse une fois lancée
• Nested Virtualization (virtualisation imbriquée) assez aléatoire (sur VMware ESXi en tout cas)
• Impossibilité de détonner des menaces récentes de type clickfix ou filefix ou en tout cas pas nativement.

Lors des analyses, la navigation dans la VM via VNC peut s’avérer assez lente, mais ce n’est pas réellement un défaut : c’est une conséquence du fonctionnement intrinsèque du modèle d’introspection sur lequel repose la sandbox Drakvuf.

Cuckoo3

#

Présentation

#

Cuckoo3 est une réécriture moderne et open source (Python 3) du projet Cuckoo originel.

Il s’agit d’une sandbox d’analyse dynamique de malwares : elle exécute des fichiers ou des URL suspects dans des VM Windows isolées et journalise leur comportement afin de produire des rapports. Le projet fournit également une API et une interface Web.

Installation

#

Un accès VPN a été configuré à la place du routage Internet de base, afin de pouvoir sortir sur Internet avec plusieurs adresses IP sans exposer l’IP du serveur.

L’exemple ci-dessous s’appuie sur Proton VPN, mais la configuration est similaire pour tout fichier de connexion OpenVPN.

La documentation d’installation officielle est disponible sur le GitHub du projet.

Même si l’installation de ce projet est nettement plus simple que celle de la sandbox Drakvuf, il reste indispensable de savoir débuguer pour exploiter tout le potentiel de la plateforme.

curl -sSf https://cuckoo-hatch.cert.ee/static/install/quickstart | sudo bash

Le script est interactif (quelques questions au début), puis l’installation dure entre 30 et 40 minutes.

Ensuite, ajoutez une tâche cron pour créer le bridge réseau au démarrage de la machine (crontab -e) :

@reboot /home/cuckoo/vmcloak/bin/vmcloak-qemubridge br0 192.168.30.1/24

Créez ensuite des services systemd pour pérenniser l’installation.

Service : /etc/systemd/system/cuckoo3.service

[Unit]
Description=Cuckoo3 Sandbox
After=network.target cuckoo3-rooter.service
Requires=cuckoo3-rooter.service

[Service]
Type=simple
User=cuckoo
WorkingDirectory=/home/cuckoo
Environment="PATH=/home/cuckoo/cuckoo3/venv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
ExecStart=/home/cuckoo/cuckoo3/venv/bin/cuckoo --quiet
Restart=on-failure

[Install]
WantedBy=multi-user.target

Générez la commande du rooter :

cd /home/cuckoo/cuckoo3
source venv/bin/activate
cuckoorooter -d --group cuckoo --print-command /tmp/cuckoo3-rooter.sock

Copiez-collez la commande affichée par --print-command dans ExecStart= du service cuckoo3-rooter.service.

Service : /etc/systemd/system/cuckoo3-rooter.service

[Unit]
Description=Cuckoo3 Rooter
After=network.target

[Service]
Type=simple
User=root
# Coller ici la commande générée précédemment
ExecStart=
Restart=on-failure

[Install]
WantedBy=multi-user.target

Rechargez ensuite systemd et activez les services :

sudo systemctl daemon-reload
sudo systemctl enable --now cuckoo3-rooter.service cuckoo3.service

internet:
  # Pas d’accès direct Internet, uniquement via VPN.
  enabled: False
  interface: null
  routing_table: main

vpn:
  # On n'utilise pas de VPN déjà monté (preconfigured), seulement le pool.
  preconfigured:
    enabled: False
    vpns: {}

  vpnpool:
    # On laisse le service rooter démarrer / arrêter les VPN Proton automatiquement.
    enabled: True
    routing_tables:
      start_range: 100
      end_range: 200

    providers:
      protonvpn:
        max_connections: 3

        vpns:
          - type: openvpn
            config_path: /home/cuckoo/proton/ca.protonvpn.udp.ovpn
            up_script: /home/cuckoo/.cuckoocwd/rooter/scripts/openvpnroutes.sh
            country: ca

          - type: openvpn
            config_path: /home/cuckoo/proton/ch.protonvpn.udp.ovpn
            up_script: /home/cuckoo/.cuckoocwd/rooter/scripts/openvpnroutes.sh
            country: ch

          - type: openvpn
            config_path: /home/cuckoo/proton/fr.protonvpn.udp.ovpn
            up_script: /home/cuckoo/.cuckoocwd/rooter/scripts/openvpnroutes.sh
            country: fr

# Crée le fichier /home/cuckoo/protonvpn/auth.txt contenant :
#   <username>
#   <password>
cd /home/cuckoo/protonvpn
sed -i 's|^auth-user-pass.*|auth-user-pass /home/cuckoo/protonvpn/auth.txt|' *.ovpn

# À exécuter en root
sudo chown root:root /home/cuckoo/protonvpn/auth.txt
sudo chmod 600 /home/cuckoo/protonvpn/auth.txt

Pour tester si les fichiers OVPN sont correctement configurés, on peut exécuter cette commande :

sudo openvpn --config /home/cuckoo/proton/fr.protonvpn.udp.ovpn

Redémarrez ensuite les services :

sudo systemctl restart cuckoo3-rooter.service
sudo systemctl restart cuckoo3.service

Commandes pour vérifier le bon fonctionnement et débuguer en cas de besoin :

sudo systemctl status cuckoo3.service
sudo systemctl status cuckoo3-rooter.service

sudo journalctl -eu cuckoo3 -n 50
sudo journalctl -eu cuckoo3-rooter -n 50

Une fois les services créés, vous pouvez redémarrer la machine pour contrôler que tout se passe comme prévu.

Running OpenVPN starting command. command=['/usr/sbin/openvpn', '--config', '/home/cuckoo/proton/fr.protonvpn.udp.ovpn', ... '--iproute', '/sbin/ip', ...]
...
error=Failed to start VPN ... VPN exited during startup. Exit code: 1. See logs /home/cuckoo/.cuckoocwd/log/rooter/protonvpn-fr.protonvpn.udp.ovpn.log.

if iproute_path:
    command.extend(["--iproute", str(iproute_path)])

pip install --force-reinstall "git+https://github.com/LM-CT/httpreplay.git@main"

Utilisation

#

Une fois la machine redémarrée, vous pouvez accéder à l’interface Web (en HTTP par défaut, via l’adresse IP de la machine).
La page par défaut est celle des statistiques.

Il n’y a pour le moment pas grand-chose à observer.
Vous pouvez donc vous rendre dans Submit et envoyer votre premier binaire.

Si vous n’avez pas de binaire à analyser, vous pouvez vous rendre sur MalwareBazaar

Une fois ce fake captcha ce test de QI achevé, vous pourrez télécharger les binaires malveillants de votre choix.

Gardez à l’esprit que l’environnement n’a pas accès à Internet pour le moment.
Si vous manquez d’inspiration, ce binaire est utilisé dans la suite de cet article. Il permet de tester un certain nombre de fonctionnalités proposées par Cuckoo3. Évitez naturellement de l’exécuter sur votre hôte 😉

Vous pouvez maintenant sélectionner votre binaire.
Si vous téléversez une archive chiffrée (ce qui est recommandé), vous pouvez renseigner le mot de passe sur l’écran de sélection.

Vous pouvez ensuite configurer l’analyse :

Vous pouvez choisir la durée d’analyse, la priorité (si plusieurs analyses sont lancées simultanément), ainsi que l’activation ou non du réseau (si celui-ci a été configuré en amont).

Une fois l’analyse lancée, comptez une minute de plus pour la création du rapport.

Vous pouvez ensuite vous rendre dans Analyses et attendre que votre détonation soit terminée.

Cliquez ensuite sur la tâche pour accéder au rapport.

Dans le cas de ce binaire, le rapport est assez fourni. La détection du type de malware (sur la Behavioral map) ne se fait pas lors de chaque détonation, par exemple.

Le rapport se décompose en plusieurs parties :

Le Summary

• Le Summary, lui-même composé :
  • d’informations sur l’analyse (le score, l’ID de l’analyse, les hash, etc.) ;
  • d’informations sur le fichier lui-même (dans Target, on retrouve le nom, le poids, le type, les hash, etc.) ;
  • d’informations sur la soumission du fichier (si le fichier était dans une archive, on retrouve ses informations ici) ;
  • et des différents paramètres de la détonation (durée, priorité, présence ou non d’Internet, commande utilisée pour le lancement, etc.).

Il y a ensuite une matrice MITRE des différentes TTP observées lors de la détonation du binaire :

Puis la Behavioral map, si le type de menace a pu être établi.

Passons maintenant à la partie PE File de l’analyse, dans laquelle nous pouvons retrouver le timestamp du fichier, l’Imphash, les sections, les ressources, les signatures, les imports et les exports.

Task Report

• Enfin, vous pouvez accéder à la section Task Report en allant dans la partie Windows 10. Vous y retrouvez toujours des informations sur la tâche, mais aussi les Signatures associées aux TTP MITRE vues précédemment, les différents processus présentés sous la forme d’un process tree et des screenshots de l’attaque.

Les sections Settings et Machine ne sont pas détaillées ici, car elles apportent relativement peu d’éléments dans le cadre de ce rapport. Sachez simplement que l’on y retrouve des informations sur la connectivité (ou son absence), ainsi que des détails sur le master de la VM, ici celui par défaut proposé par l’équipe de développement du projet.

Par ailleurs, la partie Network permet de récupérer des informations intéressantes.
En plus de pouvoir télécharger le PCAP de l’analyse, il est possible de visualiser les appels DNS et les connexions UDP directement depuis la page de l’analyse.

Avantages et inconvénients

#

Avantages :

• Documentation maintenue et à jour
• Installation basique (sans prise en charge réseau) rapide et “simple” (plus que l’installation de Drakvuf, en tout cas)
• API documentée
• Support de Windows 7 / 10 (build 1703)
• Supporte très bien la virtualisation imbriquée (sur un ESXi en tout cas)
• Analyses de binaires assez rapides
• Consommation de ressources lors des détonations assez raisonnable
• Possibilité de lancer plusieurs détonations simultanées par défaut (au nombre de 3, à partir d’une même snapshot de la VM fournie par défaut)
• Installation automatique d’un “pack logiciel” cohérent lors de l’installation de la VM (lecteur PDF, dépendances .NET, etc.)
• Possibilité de soumettre une archive chiffrée et d’indiquer le mot de passe lors de la soumission de celle-ci
• Possibilité de soumettre des liens (URL) pour analyse

Inconvénients :

• Version de Windows 10 un peu datée aujourd’hui
• Pas de prise en charge des binaires Linux
• Impossibilité d’interagir avec la VM, ni même de voir en temps réel ce qui se passe visuellement lors de l’analyse (seules les captures d’écran automatisées peuvent en donner un aperçu)
• Impossibilité de détonner des menaces récentes de type clickfix ou filefix, ou en tout cas pas nativement.

Tests comparatifs des sandboxes

#

Protocole de test

#

Depuis une machine virtuelle sous Windows 11 24H2, 5 binaires malveillants ont été téléchargés depuis MalwareBazaar, ainsi qu’un scénario supplémentaire de type ClickFix.

Afin de s’affranchir des difficultés potentielles liées à l’extraction et de réaliser ces tests dans de bonnes conditions, les binaires sont extraits en amont avant leur soumission aux sandboxes.

Les binaires ont été prétestés : pour ceux dont la chaîne d’infection repose sur plusieurs stages (dont certains nécessitent un accès en ligne), le fonctionnement a été vérifié en amont des tests le jour de l’analyse, afin de s’assurer qu’ils sont fonctionnels.

Les deux sandboxes disposent d’une connexion Internet lors de l’exécution des binaires.
Drakvuf utilise une IP de sortie OVH, tandis que Cuckoo3 sort via une IP ProtonVPN.

Pour ces tests, la durée d’exécution est fixée à 10 minutes pour Drakvuf et 5 minutes pour Cuckoo3.

Pour chaque détonation, les rapports générés par les deux sandboxes sont comparés selon les dimensions suivantes :

• Process tree (clarté / complétude)
• Fichiers / registre (visibilité, granularité)
• Réseau (richesse des informations, URLs, domaines, protocoles)
• TTP / MITRE / signatures (quantité et pertinence)
• Verdict / classification (lorsqu’il existe)
• Stabilité / erreurs éventuelles

Analyses

#

Ransom.Satan - exe

Date de l’analyse : 20/12/2025
Type : application/x-dosexec
Famille : Ransomware
Sha256 : 1a0a2fd546e3c05e15b2db3b531cb8e8755641f5f1c17910ce2fb7bbce2a05b7
Info malware : MalwareBazaar
Particularité : communication Tor (via proxy .pw)

Comparaison Drakvuf / Cuckoo3

#

Aspect	Drakvuf	Cuckoo3
Process tree	Arbre clair et complet	Arbre clair et complet
Fichiers / registre	Liste détaillée des fichiers édités et supprimés	NA
Réseau	Informations réseau détaillées (DNS, IP, URLs)	Informations réseau détaillées (DNS, IP, URLs)
MITRE / TTP / signatures	17 TTP remontées	11 TTP et 16 signatures
Verdict / classification	Fonctionnalité non présente	Classé comme Ransomware

Observations

#

• Le chiffrement des données n’a démarré dans aucune des deux détonations.
• Divergences notables :
  • L’injection de processus est remontée dans les TTP du rapport de Cuckoo3, mais n’apparaît pas dans celles observées par Drakvuf.
• Dans les deux cas, la communication vers l’infrastructure Tor via une passerelle .onion.pw est correctement observée dans la partie réseau.
• Le type de menace est correctement identifié comme ransomware par la sandbox.

Captures Drakvuf

#

La requête vers le site sur le réseau Tor via la passerelle .pw est bien détectée.

Captures Cuckoo3

#

---

Ransomware.Petya - exe

Date de l’analyse : 20/12/2025
Type : application/x-dosexec
Famille : Ransomware
Sha256 : 26b4699a7b9eeb16e76305d843d4ab05e94d43f3201436927e13b3ebafa90739
Info malware : MalwareBazaar
Particularité : BSOD / redémarrage (faux CHKDSK)

Comparaison Drakvuf / Cuckoo3

#

Aspect	Drakvuf	Cuckoo3
Comportement système	BSOD déclenché, redémarrage non achevé	Le redémarrage n’a pas été initié lors de l’exécution du binaire, et aucun BSOD n’a été observé
Process tree	Aucun processus enfant observé	Aucun processus enfant observé
Réseau	Aucun trafic réseau significatif observé	Aucun trafic réseau significatif observé
MITRE / TTP / signatures	TTP limitées, focalisées sur le comportement système	4 TTP et 3 signatures
Verdict / classification	NA	Non explicitement classé dans le rapport

Observations

#

• Dans les deux cas, la machine n’a pas achevé le redémarrage. Le faux CHKDSK n’a donc pas été entièrement observé à l’écran, bien que le message soit présent dans le binaire :

  WARNING: DO NOT TURN OFF YOUR PC! IF YOU ABORT THIS PROCESS, YOU COULD
  DESTROY ALL OF YOUR DATA! PLEASE ENSURE THAT YOUR POWER CABLE IS PLUGGED
  CHKDSK is repairing sector

  • Drakvuf : le BSOD est déclenché, indiquant un impact fort sur la stabilité du système.
  • Cuckoo3 : la VM reste dans un état incohérent et ne redémarre pas correctement après l’exécution.

• Aucune des deux sandboxes n’a identifié les URLs .onion en analyse statique, et aucun hit réseau vers ces domaines n’a été observé :

  • http[://]petya5koahtsf7sv[.]onion/
  • http[://]petya37h5tbhyvki[.]onion/

• La ransom note, bien présente en dur dans le binaire, n’a été créée sur aucune des deux machines :

  You became victim of the PETYA RANSOMWARE!
  The harddisks of your computer have been encrypted with an military grade
  encryption algorithm. There is no way to restore your data without a special
  key. You can purchase this key on the darknet page shown in step 2.
  [...]

Captures Drakvuf

#

Captures Cuckoo3

#

---

Vidar - exe

Date de l’analyse : 20/12/2025
Type : application/x-dosexec
Famille : Infostealer (Vidar)
Sha256 : 0c123691f58f567a62eb1202a285e07bf635a040a1b35427438c0bcef491a20d
Info malware : MalwareBazaar
Particularité : binaire décompressé UPX (entrée UPX unpacked, tag upx-dec)

Comparaison Drakvuf / Cuckoo3

#

Aspect	Drakvuf	Cuckoo3
Process tree	Aucun processus enfant observé	Aucun processus enfant observé
Fichiers / registre	Peu d’interactions entre le binaire et le système de fichiers	NA
Réseau	Aucune communication C2 observée	Aucune communication C2 observée
MITRE / TTP / signatures	18 TTP	4 TTP et 6 signatures
Verdict / classification	NA	Non explicitement classé dans le rapport

Observations

#

• La connexion C2 ne s’est pas établie, possiblement car le serveur a été suspendu par l’hébergeur.
• Un surprenant pop-up laisse penser que ce binaire était un test, ou que le threat actor n’a pas payé la licence de son packer :

• Il aurait été intéressant de détonner également la version unpackée pour vérifier si le message persiste et si le comportement reste identique.

Captures Drakvuf

#

Captures Cuckoo3

#

---

AgentTesla - exe

Date de l’analyse : 23/12/2025
Type : application/x-dosexec
Famille : AgentTesla
Sha256 : 24fe87b1951171c60a79a85bd1edc5da865222b2065c8cd30de6d5dacabb5f85
Info malware : MalwareBazaar
Particularité : présence d’un endpoint d’exfiltration SMTP indiqué dans l’entrée (mail.en-oc.com:587)

Comparaison Drakvuf / Cuckoo3

#

Aspect	Drakvuf	Cuckoo3
Process tree	NA (rapport en erreur)	Aucun processus enfant observé
Fichiers / registre	NA	NA
Réseau	NA	Aucune communication C2 observée
MITRE / TTP / signatures	NA	5 TTP et 10 signatures
Verdict / classification	NA	Le binaire a été catégorisé comme Stealer plutôt que comme Trojan

Observations

#

• Le format du binaire n’a pas permis son exécution sur Drakvuf, même après plusieurs essais.
• Le binaire n’est pas parvenu à contacter son C2.
• Aucune trace de tentative d’exfiltration SMTP n’a été observée vers mail.en-oc.com:587.

Captures Drakvuf

#

Captures Cuckoo3

#

---

QuasarRAT - exe

Date de l’analyse : 23/12/2025
Type : application/x-dosexec
Famille : RAT (QuasarRAT)
Sha256 : e04c0a63203c01287f3caeb0713dbdaf55cf31a3fbaf5fdefd9e1047beb9436b
Info malware : MalwareBazaar
Particularité : Remote Administration Tool, C2 exposé dans l’entrée (178.22.24.175:4782)

Comparaison Drakvuf / Cuckoo3

#

Aspect	Drakvuf	Cuckoo3
Process tree	Un processus enfant observé	6 processus enfants observés
Fichiers / registre	Pas de remontées pertinentes	NA
Réseau	Pas de communication observée vers le C2 déclaré	Pas de communication observée vers le C2 déclaré, bien que le binaire ait déroulé plusieurs de ses stages
MITRE / TTP / signatures	15 TTP	9 signatures
Verdict / classification	NA	Pas de catégorie définie

Observations

#

• Le binaire n’est pas parvenu à contacter son C2.
• L’analyse de Cuckoo3 est plus complète, la chaîne d’exécution a pu aller plus loin.

Captures Drakvuf

#

Captures Cuckoo3

#

Matrice MITRE non présente dans le rapport ; voici les signatures indiquées à la place :

---

ClickFix

Date de l’analyse : 23/12/2025
Type : URL (campagne web / faux CAPTCHA)
Famille : CAPTCHA scam (ClickFix), avec mention de DonutLoader dans l’analyse
Sha256 : n/a (analyse d’URL)
Info malware : JoeSandbox
Particularité : page “ClickFix” (faux CAPTCHA) observée sur www.tripmate.co.il + infrastructure associée (ex. getfix.win, noverfault.org)

Notes

#

L’interaction n’étant pas possible sur Cuckoo3, et Drakvuf n’ayant pas été pensé pour l’analyse de ce type de menace (flot d’exécution déclenché par clic utilisateur sur une page web), j’ai dû détourner une fonctionnalité présente sur les deux sandboxes pour simuler l’exécution d’un scénario ClickFix.

Pour cela, j’ai sélectionné un fichier arbitraire sur ma machine, puis utilisé :

• la fonctionnalité “Launch command” sur Cuckoo3 ;
• la fonctionnalité “Start command” sur Drakvuf.

Ces deux fonctionnalités sont normalement prévues pour lancer le binaire uploadé avec des arguments précis.
Dans ce cas, j’ai simplement récupéré (depuis une VM de test et non directement depuis les sandboxes) la commande PowerShell que le faux CAPTCHA demande d’exécuter, et c’est cette commande que j’ai utilisée avec les deux mécanismes de lancement mentionnés plus tôt.

Concrètement :

• le fichier sélectionné initialement depuis l’interface web n’est pas exécuté ;
• seule la commande fournie par le faux CAPTCHA est lancée dans la VM via les options “Launch/Start command”.

Cela permet de tester un scénario ClickFix dans ces sandboxes bien qu’elles ne supportent pas nativement ce type de menace (déclenchée par interaction utilisateur sur une page web plutôt que par exécution directe d’un binaire).

Comparaison Drakvuf / Cuckoo3

#

Aspect	Drakvuf	Cuckoo3
Process tree	Seul le premier PowerShell est observé dans l’arbre des processus	4 processus enfants sont observés
Réseau	NA	Rien de significatif n’est observé dans la partie réseau
MITRE / TTP / signatures	12 TTP	7 TTP et 9 signatures
Verdict / classification	NA	Pas de catégorie définie

Observations

#

• Une fois le script exécuté, celui-ci semble récupérer les ressources nécessaires à la compilation du stage final.
• Bien que ces étapes se soient déroulées sur Cuckoo3, je n’ai observé aucune communication C2 sur l’une ou l’autre des deux sandboxes.

Captures Drakvuf

#

Captures Cuckoo3

#

---

Astuce pour trouver des fake CAPTCHA et des ClickFix récents à des fins d’analyse : JoeSandbox - Any.Run (chercher “clickfix”)

Il est important de garder à l’esprit que ces deux solutions sont encore en test, en bêta, et ne sont pas vouées à être utilisées telles quelles en production. Les observations ci-dessous n’ont pas vocation à critiquer les projets, mais à analyser les comportements que j’ai observés lors de mon utilisation de celles-ci.

À la lecture des détonations ci-dessus, on pourrait avoir l’impression que les fonctionnalités réseau de Drakvuf ne sont pas pleinement opérationnelles. Ce comportement ne reflète toutefois pas les observations globales effectuées lors des tests. À plusieurs reprises, l’exécution de plusieurs stages d’un même binaire a été observée, y compris ceux nécessitant une connectivité réseau fonctionnelle. Dans l’environnement de test utilisé pour cet article, les détonations faisant appel au réseau se déroulent correctement dans environ 25 % des cas.

Les TTP observées par Drakvuf sont celles de l’ensemble des processus, mais le fait de savoir quel processus a déclenché chaque TTP est particulièrement intéressant. Ce point est également valable pour les différents éléments du rapport (interactions réseau, fichiers touchés, etc.). La quantité d’informations apportée par les logs de chacun des plugins sélectionnés au démarrage de la détonation permet une analyse manuelle plus fine de ce qui s’est passé après l’exécution.

Il ne faut cependant pas s’imaginer que l’interaction permise par Drakvuf est au même niveau que celle proposée par certains services en ligne tels que JoeSandbox ou Any.Run. Même si l’approche peut paraître similaire (une fenêtre avec une intégration VNC de la machine durant l’analyse), le modèle agentless de Drakvuf introduit une certaine latence lors de l’exécution. C’est aussi cette approche qui permet d’obtenir des logs aussi détaillés. Les informations fournies pour chaque processus exécuté sont également très utiles en post-analyse.

Enfin, certains formats de fichiers ne peuvent pas être détonnés dans Drakvuf (HTA, LNK, VBS). À la date de rédaction, les fichiers qui s’exécutent sans problème sont principalement les exécutables, les DLL et les scripts .bat. Ces deux listes ne sont pas exhaustives.

Pour Cuckoo3, il est intéressant de noter que le score associé à l’analyse est celui de la signature ayant le score le plus élevé. J’ai toutefois remarqué, lors de mes analyses, que le fonctionnement même de la VM durant l’exécution fait qu’il n’est pas possible d’obtenir un score inférieur à 6, y compris lorsque le binaire est légitime.

Même constat pour l’analyse de sites (non représentée dans les analyses ci-dessus, car la fonctionnalité n’existe pas sur Drakvuf) : en l’état, cette fonctionnalité ne s’est pas révélée particulièrement pertinente. Elle permet d’obtenir une prévisualisation de la page et une analyse des flux réseau, mais sans aller beaucoup plus loin. Sur ce point, des services comme urlscan.io ou Farelo sont bien plus pertinents et généreux en détails sur le site analysé. Peut-être que cette fonctionnalité sera développée dans de prochaines versions. À noter également que le score associé à l’analyse d’un site n’est pas très représentatif : dès lors que la signature Checks computer location settings est déclenchée, le score ne peut pas être inférieur à 7, même lorsque le site est légitime. Le système de classification peut être pratique, bien que celui-ci ne soit pas sans faille. Il est cependant regrettable que les classifications, lorsqu’elles sont présentes dans le rapport, ne soient pas visibles dans une colonne dédiée depuis la liste des analyses.

Les informations fournies pour chaque appel HTTP sont très complètes et permettent d’en comprendre rapidement le contenu. Les autres appels réseau (Host, UDP, DNS, Domain et TCP) sont également bien représentés et pratiques à exploiter.

Les deux sandboxes proposent de récupérer le PCAP de l’analyse, ce qui peut être pertinent pour produire un contre-rapport et pousser l’analyse plus loin. Drakvuf propose en plus la récupération des clés TLS (permettant de déchiffrer l’intégralité du trafic web chiffré) et des dumps mémoire des processus.

Enfin, les captures d’écran permettent de conserver une trace visuelle des analyses, surtout dans le cas de Cuckoo3 où, sans les screenshots, il n’y aurait aucun moyen de savoir comment l’analyse s’est visuellement déroulée.

En résumé, sous forme d’un tableau :

Les deux projets sont encore en bêta et n’ont pas vocation, en l’état, à être déployés tels quels en production. Les constats ci-dessous reflètent uniquement les comportements observés pendant les détonations présentées dans l’article.

Synthèse

#

Malgré certaines difficultés liées à l’installation et à la configuration des deux projets, je tiens à remercier les équipes qui travaillent dessus. Je n’imagine pas le temps qu’il a fallu pour rendre ces projets utilisables.

Bien que n’étant pas aussi complètes que les solutions payantes et en ligne du marché, ces sandboxes peuvent tout à fait répondre aux besoins d’entreprises soucieuses de ne pas partager leurs binaires à l’extérieur (à condition d’avoir suffisamment d’administrateurs en capacité de débuguer et de maintenir le projet en interne).

Les deux projets reposent sur des philosophies différentes : l’un adopte une approche plus automatisée lors des détonations (Cuckoo3), et le second est plus “semi-automatisé” (en laissant la possibilité à l’utilisateur d’interagir avec la sandbox lors des détonations).
Aucune de ces approches n’est meilleure en soi : elles répondent à des besoins légèrement différents.

Comme indiqué en introduction, c’est sur la version 0.19 de la sandbox Drakvuf que l’essentiel des tests a été réalisé. La version 0.20 étant récemment sortie (en date du 17 novembre), la comparaison ci-dessus a été faite sur cette nouvelle version.

Comparaison des produits

#

Les approches des deux solutions sont assez différentes.

DRAKVUF s’appuie sur l’hyperviseur Xen et sur les extensions de virtualisation matérielle d’Intel (VT-x / EPT), ainsi que sur le mécanisme altp2m de Xen. En pratique, certaines pages mémoire de la VM invitée sont marquées dans les Extended Page Tables de façon à provoquer un VM-exit dès que le malware exécute du code dessus. À ce moment-là, l’exécution bascule dans l’hyperviseur et DRAKVUF reconstruit l’événement (appel d’API, syscall, accès mémoire critique, etc.) en lisant la mémoire et les registres de la machine invitée via la VMI. Toute l’observation repose donc sur l’introspection côté hyperviseur, sans driver ni DLL de monitoring installés dans le Windows invité : c’est une approche agentless.

Pour enrichir cette observation brute, DRAKVUF s’appuie sur une série de plugins qui décodent différents aspects du comportement : traçage de processus et de threads, surveillance des opérations sur les fichiers et le registre, suivi du réseau ou détection d’injections de code. Techniquement, ces plugins ne hookent pas les API depuis l’intérieur du système, mais posent des breakpoints et des événements mémoire sur les routines kernel et les bibliothèques système intéressantes. À chaque déclenchement, l’hyperviseur récupère le contexte et reconstruit l’appel observé. Fonctionnellement, on obtient un traçage API/syscall très proche de celui d’une sandbox classique, mais toute la logique reste en dehors de la VM, dans Xen et dans le démon DRAKVUF.

Par-dessus ce moteur d’introspection, la DRAKVUF Sandbox ajoute le composant drakrun, qui orchestre les machines virtuelles dédiées à l’analyse : création de la base, gestion des snapshots, configuration réseau, lancement des détonations et collecte des résultats. L’injection des binaires dans l’invité est confiée à un outil dédié, l’injector, qui utilise les primitives de DRAKVUF pour détourner un thread d’un processus stable à l’intérieur de la VM (typiquement un thread d’explorer.exe) et lui faire exécuter des actions pilotées depuis l’hôte : copier un fichier dans le profil utilisateur, lancer un exécutable, exécuter une commande de préparation, etc. Ce thread reste un thread “légitime” du point de vue de Windows, mais son flux est temporairement contrôlé via l’hyperviseur, ce qui permet d’automatiser l’analyse sans installer d’agent permanent. Une fois le sample lancé, l’analyse proprement dite reste agentless : seuls subsistent les hooks VMI posés via EPT/altp2m et les plugins qui traitent les événements.

Du point de vue du malware, la surface de détection est donc limitée aux artefacts inhérents à la virtualisation Xen : périphériques virtuels caractéristiques, configuration matérielle un peu atypique, et éventuellement des timings légèrement dégradés dus aux VM-exits fréquents et au coût de l’introspection. En revanche, il n’y a pas de service d’“agent” qui écoute sur un port, pas de DLL de monitoring injectée en permanence, ni de processus au nom suspect dans la VM. Cette architecture rend DRAKVUF particulièrement intéressante face à des échantillons dotés de capacités anti-sandbox avancées, qui cherchent explicitement les artefacts de solutions comme Cuckoo3, tout en offrant une excellente visibilité sur les appels API et les syscalls, aussi bien en userland qu’au niveau noyau.

Cuckoo3 adopte une philosophie presque inverse. Là où DRAKVUF observe le comportement depuis l’hyperviseur en reconstruisant les événements à partir de la mémoire, Cuckoo3 repose sur un couple “agent / monitor” installé à l’intérieur de la machine invitée. Un agent tourne dans le système analysé pour recevoir les ordres du serveur Cuckoo3, déposer les fichiers à tester, lancer les exécutables ou ouvrir les URL, puis renvoyer des informations de statut. La collecte fine du comportement est assurée par un monitor dédié (DLL et stager fournis avec Cuckoo3), injecté dans les processus ciblés ; ce monitor hooke directement les API de Windows, suit la création de processus fils, intercepte les opérations sur les fichiers, le registre et le réseau, puis renvoie un flux d’événements comportementaux au serveur d’analyse. Toute la chaîne de collecte est donc in-guest : elle vit dans le contexte même où s’exécute le malware.

Ce choix architectural a des conséquences fonctionnelles importantes. D’un côté, comme le monitor s’exécute dans le même espace d’adressage que le malware et hooke les API au moment où elles sont réellement appelées, Cuckoo3 peut capturer des informations très riches et de haut niveau, y compris les paramètres exacts des appels, certaines chaînes manipulées ou des artefacts d’interface utilisateur, le tout avec un coût de mise au point relativement faible. De l’autre, cette instrumentation laisse des traces visibles dans le système invité : un agent qui écoute sur un port, une DLL injectée et des hooks en mémoire que des malwares un peu méfiants peuvent rechercher explicitement. Cuckoo3 reste néanmoins très attractif en pratique, car il gère nativement une grande variété de formats (exécutables, documents, archives, scripts, URL), s’intègre bien dans un environnement SOC grâce à ses API et à ses modules de reporting, et bénéficie d’un écosystème important de signatures et de modules de post-traitement.

En résumé, DRAKVUF (via drakrun) et Cuckoo3 analysent tous deux le comportement dynamique d’un binaire malveillant, mais ils ne le font ni au même niveau ni avec les mêmes compromis. DRAKVUF privilégie une observation très furtive et très bas niveau depuis l’hyperviseur, en s’appuyant sur EPT et altp2m pour déclencher des VM-exits et sur des plugins d’introspection pour reconstruire ce que fait le malware sans jamais toucher au système invité. Cuckoo3, à l’inverse, assume pleinement une instrumentation en profondeur depuis l’intérieur de la VM, avec un agent et un monitor hookant les API, pour proposer une plateforme d’analyse généraliste, extensible et simple à intégrer dans des workflows de réponse à incident. Dans un contexte opérationnel, les deux approches sont moins concurrentes que complémentaires : Cuckoo3 traite efficacement le gros du flux avec une visibilité très riche côté applicatif, tandis que DRAKVUF apporte une couche d’observation plus discrète et plus robuste face aux échantillons les plus hostiles à la sandbox.

Et après ?

#

Si vous avez tenu jusqu’ici, vous avez sans doute compris que Drakvuf et Cuckoo3 ne sont qu’une petite partie de l’écosystème. D’autres briques méritent clairement un coup d’œil. Côté gestion de machines virtuelles, on peut par exemple citer mofos de Synacktiv, un framework de manipulation de VM basé sur Libvirt/QEMU/KVM, très inspiré de Qubes OS, qui permet de monter rapidement des environnements compartimentés avec gestion du réseau, du presse-papiers et des fenêtres applicatives.
Dans un registre plus orienté cyber range, Ludus permet d’automatiser la création de lab complets (AD, postes Windows, Linux, etc.) sur Proxmox, en s’appuyant sur Packer et Ansible pour déployer des environnements de test clés en main pour red, blue ou purple team.
Et si vous cherchez une sandbox dans la lignée de Cuckoo, CAPE (Config And Payload Extraction) en reprend l’architecture tout en ajoutant du dépackaging dynamique, de la classification via règles YARA sur les payloads déchiffrés et un moteur d’extraction de configuration nettement plus poussé, pensé pour automatiser une bonne partie du travail habituellement fait en rétro.
Enfin, si vous cherchez une analyse récente et complète des sandboxes sur un plan plus académique, je ne peux que vous conseiller ce papier : A Classification of Malware Sandboxes and Their Features.

Rien n’empêche non plus de combiner tout ça pour monter votre propre lab sur mesure : hyperviseur maison (Proxmox, KVM, ESXi), un peu d’Ansible ou de Terraform pour l’orchestration, et quelques briques réseau (proxy, DNS, IDS/IPS) pour recoller le tout. Mais ça, ce sera peut être l’objet d’un prochain article, dédié à la construction d’un petit lab modulaire “from scratch” en partant de ces différents outils. 🙂

Cet article est publié sous licence Creative Commons Attribution 4.0 International.
Vous êtes libre de le partager et de l’adapter, à condition de créditer l’auteur et de mentionner les éventuelles modifications.
Crédit photo d’illustration : Jobert Enamno