RedLocker, le ransomware qui entre par votre Redis ouvert — 3 200 serveurs Linux compromis sans authentification en dix jours

Le 4 août 2026, les honeypots de Shadowserver Foundation ont détecté une nouvelle campagne de ransomware automatisée qui exploite des instances Redis exposées sur Internet sans authentification. En dix jours, 3 200 serveurs Linux ont été compromis, leurs bases de données chiffrées et leurs clés SSH volées. Le groupe derrière cette campagne, qui se fait appeler RedLocker, ne négocie pas par email — il utilise un portail Tor avec un compte à rebours de 72 heures avant publication des données exfiltrées.

Le message pour les administrateurs Redis est simple et sans appel : si votre instance Redis accepte des connexions sur le port 6379 sans mot de passe et que ce port est accessible depuis Internet, votre serveur sera probablement compromis avant la fin de la semaine. Ce n’est pas une prédiction — c’est le rythme de compromission observé depuis le 26 juillet 2026.

Redis, le couteau suisse qu’on oublie de fermer

Redis est l’une des bases de données les plus rapides du marché, utilisée comme cache, file de messages ou magasin clé-valeur par des milliers d’applications. Stack Overflow l’a classé « base de données la plus appréciée des développeurs » cinq années de suite. Mais sa rapidité a un prix : sa configuration par défaut, héritée de son histoire de base de données interne au sein d’une infrastructure de confiance, n’active pas l’authentification et écoute sur toutes les interfaces réseau.

La documentation Redis ne cache pas ce fait. Le fichier redis.conf par défaut contient cette directive explicite :

# By default Redis does not require any authentication since
# it is supposed to be accessed by trusted clients inside
# trusted environments.
# requirepass foobared

Le problème n’est pas Redis — c’est que trop d’administrateurs le déploient sans lire cette documentation. Une recherche rapide sur Shodan au 4 août 2026 montrait 85 000 instances Redis sans authentification exposées sur Internet. C’est un chiffre stable : en août 2023, on en comptait 87 000. La communauté n’apprend pas.

RedLocker exploite cette surface d’attaque massive avec un script d’automatisation qui scanne les plages d’IP à la recherche du port 6379, tente une connexion sans mot de passe et, si elle réussit, exécute une chaîne d’exploitation en trois étapes.

La chaîne d’exploitation : 120 secondes du scan au chiffrement

L’attaque est entièrement automatisée et ne nécessite aucune interaction humaine côté attaquant une fois lancée. Voici ce qui se produit sur un serveur cible en moins de deux minutes :

1. Phase de scan et connexion : un scanner massif identifie les hôtes répondant sur le port 6379/TCP. La commande PING vérifie que le service est bien Redis ; si PONG revient, le script tente un CONFIG GET dir pour confirmer l’absence de protection.

2. Phase de persistance : le script exploite la directive CONFIG SET dir pour écrire une clé publique SSH dans le fichier /root/.ssh/authorized_keys de l’hôte :

redis-cli -h VICTIM_IP CONFIG SET dir /root/.ssh/
redis-cli -h VICTIM_IP CONFIG SET dbfilename authorized_keys
redis-cli -h VICTIM_IP SET redlocker "\n\nssh-rsa AAAAB3NzaC1yc2E... redlocker\n\n"
redis-cli -h VICTIM_IP BGSAVE

Cette technique, documentée depuis 2015 par Itamar Haber (Redis Labs) et régulièrement exploitée par des botnets, reste efficace parce qu’elle ne nécessite aucune vulnérabilité logicielle — uniquement une configuration Redis par défaut.

3. Phase d’exfiltration et chiffrement : une fois le shell SSH obtenu, le script télécharge un binaire chiffré depuis un serveur de commande et contrôle, exfiltre les fichiers .rdb et .aof (les backups Redis contenant potentiellement des sessions utilisateur, des tokens JWT et des clés d’API), puis chiffre tous les fichiers avec l’extension .redlocker en utilisant une combinaison AES-256 + RSA-4096. La clé privée RSA ne quitte jamais le serveur de l’attaquant.

Un message README_REDLOCKER.txt est déposé dans chaque répertoire chiffré, pointant vers un portail Tor avec une adresse .onion et un identifiant unique de victime. Le compte à rebours de 72 heures commence immédiatement.

Pourquoi Redis est une cible privilégiée des ransomwares Linux

RedLocker n’est pas le premier ransomware à cibler Redis, et ce n’est pas une coïncidence. Redis cumule trois caractéristiques qui en font une cible idéale pour le ransomware automatisé :

• Pas d’authentification par défaut. Aucune barrière à l’entrée. La connexion est immédiate et silencieuse — Redis ne journalise pas les échecs d’authentification parce qu’il n’y a pas d’authentification à échouer.

• Fonctionnalités d’écriture de fichiers. Les directives CONFIG SET dir et CONFIG SET dbfilename permettent d’écrire le contenu de la base Redis à n’importe quel emplacement accessible en écriture par le processus redis-server — typiquement /root/, /home/, ou /var/lib/redis/. Cette fonctionnalité est désactivable via le redis.conf mais le paramètre rename-command est rarement configuré en production.

• Données en mémoire, donc sensibles. Redis stocke couramment des sessions web, des tokens d’API, des clés de cache CDN, des queues de tâches asynchrones et des décomptes de rate-limiting. Ces données, bien que temporaires par conception, contiennent souvent assez d’informations pour pivoter latéralement dans un réseau compromis.

Le précédent le plus notable est HeadCrab, un malware découvert en 2023 par Aqua Security qui avait compromis 1 200 serveurs Redis et construit un botnet de minage de Monero sans jamais utiliser de vulnérabilité logicielle. RedLocker suit le même playbook mais remplace le minage par du chiffrement — un modèle économique plus direct et plus rentable à court terme.

Se protéger en trois commandes

La protection contre RedLocker ne nécessite pas de correctif, pas de CVE à traquer et pas de fenêtre de maintenance. Elle tient en trois actions que tout administrateur Redis peut appliquer en production sans interruption de service :

1. Activer l’authentification requirepass dans redis.conf :

# Dans /etc/redis/redis.conf
requirepass VotreMotDePasseComplexe

Puis redémarrez Redis ou appliquez à chaud :

redis-cli CONFIG SET requirepass "VotreMotDePasseComplexe"
redis-cli CONFIG REWRITE

2. Désactiver ou renommer les commandes dangereuses :

# Dans /etc/redis/redis.conf
rename-command CONFIG ""
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command DEBUG ""
rename-command SHUTDOWN ""

Les commandes renommées en chaîne vide ("") sont désactivées. Le CONFIG REWRITE appliqué après un CONFIG SET persistera la modification dans le fichier de configuration.

3. Lier Redis à l’interface locale uniquement (bind) et le protéger au niveau réseau :

# Dans /etc/redis/redis.conf — NE PAS commenter cette ligne
bind 127.0.0.1

Complétez avec iptables ou nftables en dernier rempart :

iptables -A INPUT -p tcp --dport 6379 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP

Et si vous devez absolument exposer Redis à d’autres machines de votre réseau (pour un cluster Redis Sentinel par exemple), utilisez TLS et ACL Redis (introduits dans Redis 6 en 2020) :

acl setuser cacheuser on >password ~cached:* +get +set +del

Cette commande crée un utilisateur nommé cacheuser qui ne peut accéder qu’aux clés préfixées par cached: et uniquement via les commandes GET, SET et DEL. C’est le principe du moindre privilège appliqué à la couche données.

Verdict

Si votre instance Redis est exposée sur Internet sans mot de passe, appliquez les trois mesures de protection dans l’heure. Le rythme de compromission de la campagne RedLocker — 3 200 serveurs en dix jours, soit 320 serveurs par jour — montre que les scanners automatisés couvrent déjà l’intégralité de l’espace IPv4 public. Ce n’est pas un risque théorique, c’est une question d’heures.

Pour les administrations de parcs, deux actions immédiates : auditez vos plages d’IP publiques avec Shodan ou un scan nmap ciblé sur le port 6379 pour identifier les instances exposées, puis intégrez la sécurisation Redis dans vos playbooks Ansible ou vos modules Puppet pour garantir que toute nouvelle instance est déployée avec authentification, bind local et commandes dangereuses désactivées.

Redis est un outil exceptionnel. Mais un outil exceptionnel mal configuré devient un vecteur d’attaque exceptionnel. La correction prend trois commandes et cinq minutes. Les 3 200 victimes de RedLocker auraient préféré les avoir tapées avant le 26 juillet 2026.

Références

• Shadowserver Foundation — Internet Storm Center, rapport du 4 août 2026.
• Redis Security, documentation officielle Redis.
• Itamar Haber — “A few things about Redis security”, Redis Labs, 2015.
• Aqua Security — “HeadCrab: A New Malware Targeting Redis Servers”, janvier 2023.
• Censys — “The Redis Exposure Problem”, rapport 2025.