Après un piratage, mon serveur Hetzner s’est mis à miner du Monero

• Une utilisation anormale du CPU a été détectée sur un serveur Hetzner personnel ; l’enquête a révélé qu’un programme de minage de cryptomonnaie Monero (xmrig) était en cours d’exécution
• La cause était l’attaque d’un conteneur de l’outil d’analyse Umami incluant une vulnérabilité d’exécution de code à distance dans Next.js (CVE-2025-66478)
• Heureusement, comme ce conteneur s’exécutait avec un utilisateur non root et sans montage hôte ni élévation de privilèges, l’intrusion est restée confinée à l’intérieur du conteneur
• L’attaquant a exploité une désérialisation non sécurisée des composants serveur Next.js pour exécuter une charge utile malveillante et installer le mineur
• Ce cas illustre l’importance de la gestion des dépendances et des paramètres de sécurité des conteneurs ; l’auteur a renforcé ses mesures de sécurité en activant le pare-feu, en durcissant SSH et en appliquant des mises à jour régulières

---

Piratage et réponse initiale

• Réception d’un e-mail d’alerte de Hetzner indiquant que le serveur scannait des réseaux externes
  • Le message précisait que le serveur pourrait être bloqué sans intervention dans les 4 heures
• Après connexion en SSH, découverte d’un processus utilisant 819 % du CPU dans /tmp/.XIN-unix/javae, ainsi que de plusieurs processus xmrig
• Il a été confirmé que le minage de cryptomonnaie durait depuis environ 10 jours

Enquête sur le vecteur d’intrusion

• Tous les processus malveillants s’exécutaient avec l’utilisateur UID 1001, ce qui correspondait au conteneur Umami
• Un binaire de mineur a été trouvé dans le répertoire /app/node_modules/next/dist/server/lib/xmrig-6.24.0/
• La commande d’exécution contenait l’adresse du pool de minage auto.c3pool.org:443 ainsi qu’une clé utilisateur

Vulnérabilité Next.js et méthode d’attaque

• La cause était la vulnérabilité de désérialisation des React Server Components de Next.js (CVE-2025-66478)
  • Si un attaquant envoie une requête HTTP manipulée, du code arbitraire peut être exécuté sur le serveur
  • Cela permet ensuite d’installer et d’exécuter un mineur de cryptomonnaie
• L’auteur pensait « ne pas utiliser Next.js directement », avant de se rendre compte plus tard que Umami repose sur Next.js

Vérification de l’isolation du conteneur

• Confirmation que /tmp/.XIN-unix/javae n’existait pas sur le système de fichiers hôte
  • Il s’agissait simplement du fait que la sortie de docker ps affiche les processus du conteneur ; l’isolation réelle était bien maintenue
• Résultat de docker inspect
  • Utilisateur : nextjs
  • Privileged : false
  • Mounts : aucun
• Le code malveillant ne pouvait donc pas accéder à l’hôte, enregistrer une tâche cron, créer un service système ou installer un rootkit

Restauration et renforcement de la sécurité

• Après arrêt et suppression du conteneur Umami infecté, l’utilisation du CPU est revenue à la normale
• Activation du pare-feu UFW pour n’autoriser que SSH, HTTP et HTTPS
• Après transmission des résultats de l’enquête à Hetzner, le ticket a été clôturé en moins d’une heure

Leçons et points d’amélioration

• Dire « je n’utilise pas X » n’inclut pas forcément les dépendances
  • Il faut vérifier sur quelle stack technologique reposent les outils utilisés
• Preuve de l’efficacité de l’isolation des conteneurs
  • Utilisateur non root, mode non privilégié et absence de volumes inutiles ont empêché l’extension des dégâts
• Nécessité d’une défense en profondeur (Defense in Depth)
  • Pare-feu, fail2ban, monitoring et mises à jour régulières sont indispensables
• Insistance sur l’importance de rédiger soi-même le Dockerfile et de réduire au minimum les privilèges du conteneur

Mesures prises après l’incident

• Redéploiement d’Umami avec la dernière version et audit de tous les conteneurs tiers
  • Vérification de l’utilisateur d’exécution, des montages, du calendrier de mise à jour et de la nécessité de chaque conteneur
• Passage à l’authentification par clé SSH, désactivation de la connexion par mot de passe, configuration de fail2ban
• Renforcement du monitoring avec Grafana et Node Exporter, application immédiate des mises à jour de sécurité

Conclusion

• À cause de la vulnérabilité Next.js d’Umami, le serveur a été exploité pendant 10 jours pour miner du Monero, mais
  l’isolation du conteneur et l’exécution en non root ont permis de limiter les dégâts
• Cette expérience a fait prendre conscience à l’auteur de l’importance de l’identification des dépendances, de la configuration de sécurité et de la gestion des mises à jour
• L’incident a été résolu en environ 2 heures et reste un cas concret validant l’efficacité réelle de la sécurité des conteneurs