Source: Blog personnel de Jake Saunders. Contexte: l’auteur reçoit un abus report de son hébergeur Hetzner signalant du scanning réseau sortant; il découvre que son instance Umami (analytics) a été compromis via une faille Next.js récemment divulguée.

L’incident démarre par un email d’abus Hetzner signalant du scanning vers une plage d’IP en Thaïlande. Sur le serveur (hébergé chez Hetzner et orchestré avec Coolify), l’auteur observe une charge CPU anormale et des processus de minage (xmrig) tournant en tant qu’utilisateur UID 1001. L’investigation montre la présence d’un dossier xmrig-6.24.0 à l’emplacement interne de Next.js dans le conteneur Umami, avec une commande pointant vers un pool Monero. ⛏️

La cause identifiée est une exploitation de la vulnérabilité critique Next.js RSC (CVE-2025-66478): une désérialisation non sécurisée du protocole Flight de React Server Components permettant une exécution de code à distance (RCE) via une requête HTTP spécialement forgée sur un endpoint App Router. Le binaire xmrigr est téléchargé/exécuté dans le conteneur Umami (qui utilise Next.js), conduisant à du cryptojacking (Monero) et à du network scanning.

L’analyse de l’isolation montre que le conteneur Umami tournait en tant que user non-root (nextjs / UID 1001), non privilégié et sans volumes montés. Malgré l’affichage des processus dans ps du host (partage de kernel), les artefacts tels que /tmp/.XIN-unix/javae n’existent pas sur l’hôte, indiquant que l’attaque est restée confinée au conteneur et n’a pas persisté via cron/systemd ni accédé au filesystem hôte. L’auteur compare avec un autre cas où un conteneur root a permis persistance et accès étendu, ce qui ne s’est pas produit ici.

Remédiation: arrêt et suppression du conteneur Umami compromis, vérification de la charge CPU redevenue normale, puis durcissement du pare-feu UFW (autorisation entrante limitée à SSH/HTTP/HTTPS). Hetzner clôt le ticket après explication. L’auteur retient notamment que des dépendances peuvent embarquer Next.js même si l’on ne l’utilise pas directement, et que l’isolement par conteneur aide lorsqu’il est correctement configuré.

IOCs et TTPs:

  • IOCs
    • Domaine pool: auto.c3pool.org:443
    • Binaire/dossier: /app/node_modules/next/dist/server/lib/xmrig-6.24.0/xmrig
    • Chemin/nom de processus observé: /tmp/.XIN-unix/javae ; processus xmrig et runnv
    • Wallet Monero: 8Bt9BEG98SbBPNTp1svQtDQs7PMztqzGoNQHo58eaUYdf8apDkbzp8HbLJH89fMzzciFQ7fb4ZiqUbymDZR6S9asKHZR6wn
    • Paramètre pass: WUZHRkYOHh1GW1RZWBxaWENRX0ZBWVtdSRxQWkBWHg==
  • TTPs
    • Initial access: exploitation de CVE-2025-66478 (Next.js RSC/Flight) via requête HTTP malveillante
    • Execution: déploiement et exécution de XMRig pour minage Monero
    • Resource hijacking: surutilisation CPU, cryptomining
    • Discovery/Recon: network scanning sortant
    • Defense evasion/opsec limité: noms/chemins trompeurs (javae, /tmp/.XIN-unix)

Il s’agit d’un rapport d’incident personnel visant à partager la chronologie, l’analyse technique et la remédiation d’une compromission de conteneur via une vulnérabilité Next.js.

🔗 Source originale : https://blog.jakesaunders.dev/my-server-started-mining-monero-this-morning/