Ransomware sur Linux : signes précoces à repérer

On entend encore parfois « Linux, ça ne craint rien ». Et oui, Linux est solide. Mais solide ne veut pas dire immunisé.

Le ransomware sur Linux, ça existe. Et souvent, ça ne ressemble pas aux gros écrans rouges bien bruyants qu’on voit sur Windows. Ça arrive plus silencieusement, plus lentement. Parfois ça commence par une seule machine, un seul service, un seul compte SSH un peu trop « pratique ». Et ensuite… tout s’enchaîne.

Dans cet article, je vais te donner les signes précoces, ceux qu’on peut repérer avant le chiffrement massif. Pas de panique inutile, mais pas de naïveté non plus. L’idée, c’est de te permettre d’attraper le problème tôt.

Petite note au passage : sur Le Blog Tech Pro de Samyn-Antoy ABASSE (monblog-sa-abasse.blogspot.com), je publie régulièrement des checklists Linux et des articles SysAdmin orientés terrain. Si tu veux garder ça sous la main, ajoute le site en favoris, ça évite de chercher au pire moment.

---

Pourquoi Linux est une cible rentable (et donc ciblée)

Parce que Linux est partout là où ça fait mal.

Serveurs web, VPS, NAS, hôtes Proxmox, clusters Docker, Kubernetes, bases de données, serveurs Git, ERP… et parfois même les machines de dev qui ont accès à tout. Les attaquants le savent.

Et puis, sur Linux, le ransomware moderne ne se limite pas à chiffrer. Souvent il :

• vole des données avant (double extorsion) ;
• supprime ou chiffre les sauvegardes accessibles ;
• se propage via SSH, clés réutilisées, Ansible mal protégé, partages NFS, API Docker trop ouvertes ;
• tue les services de backup, de supervision, les agents EDR si possible.

Donc oui, repérer les signaux faibles c’est vital.

Pour t'aider dans cette tâche cruciale et te préparer au mieux à faire face à ces menaces potentielles sur ton système Linux, je te recommande vivement d'explorer certaines ressources utiles disponibles sur mon blog. Par exemple, tu pourrais découvrir des informations précieuses sur les 7 distributions Linux à suivre, ou encore envisager d'obtenir une certification Linux en 2026 pour renforcer tes compétences.

Si tu es intéressé par une carrière dans ce domaine en pleine expansion ou si tu souhaites devenir consultant Linux en freelance, mon blog propose également des conseils utiles à ce sujet. En fin de compte, maîtriser Linux peut booster ta carrière, alors n'hésite pas à explorer ces ressources!

Le premier signal : connexions SSH « bizarres » (et pas forcément nombreuses)

Ce que tu veux repérer :

• connexions SSH à des heures inhabituelles ;
• authentifications réussies depuis des IP jamais vues ;
• usage soudain de comptes rarement utilisés (ou oubliés) ;
• tentatives de login, puis une réussite, puis plus rien pendant des heures.

Commandes utiles

bash

last -a | head -n 30

sudo grep -iE "sshd|accepted|authentication failure|invalid user" /var/log/auth.log | tail -n 200

sudo grep -iE "sshd|accepted|authentication failure|invalid user" /var/log/secure | tail -n 200

À surveiller aussi : un utilisateur qui se connecte en SSH puis enchaîne directement avec sudo su - ou un wget ou curl vers un domaine inconnu. Souvent, ça commence comme ça. Très simple.

Image à insérer : capture d’écran d’un extrait de /var/log/auth.log montrant un « Accepted publickey » depuis une IP étrangère.
![Exemple de log SSH anormal](/wp-content/uploads/2026/06/log-ssh-anormal.png)

---

Des processus inconnus, mais surtout des processus « hors contexte »

Un ransomware ou son loader va lancer des processus qui ne collent pas avec le rôle de la machine.

Sur un serveur Nginx, voir un python qui tourne, pourquoi pas. Mais voir python qui ouvre des connexions sortantes vers des IP random, là… non.

À repérer

• processus lancés depuis /tmp, /var/tmp, /dev/shm ;
• binaires sans chemin clair, ou avec des noms qui imitent le système (kworker, systemd-update, dbus-daemon… mais pas au bon endroit) ;
• processus qui consomment beaucoup de CPU ou d’I/O disque, surtout s’il n’y a pas de charge habituelle ;
• parent process suspect (ex : un sshd qui spawn un truc bizarre, ou cron qui spawn un binaire inconnu).

Acquérir des compétences pour détecter ces anomalies peut nécessiter une formation avancée. Pour ceux intéressés par le développement de leurs compétences en administration système et sécurité informatique, envisager des certifications Linux pourrait être bénéfique.

Commandes utiles

Voici quelques commandes Linux qui pourraient s'avérer précieuses :

bash ps auxf --sort=-%cpu | head -n 30 ps auxf --sort=-%mem | head -n 30 sudo ls -l /proc//exe sudo readlink -f /proc//cwd sudo readlink -f /proc//exe

Et si tu as htop, active l’affichage du chemin complet des commandes. Ça aide énormément.

Image à insérer : capture d’écran htop avec une commande lancée depuis /dev/shm.
![Processus lancé depuis /dev/shm](/wp-content/uploads/2026/06/processus-dev-shm.png)

---

Activité réseau sortante inhabituelle (la vraie alerte pré chiffrement)

Souvent, avant de chiffrer, l’attaquant :

• fait de la reconnaissance interne ;
• exfiltre des données ;
• télécharge des outils (rclone, megacmd, outils maison) ;
• contacte un serveur de commande.

Donc si tu vois une machine Linux serveur qui commence à parler « beaucoup » vers l’extérieur, c’est un signe.

À repérer

• connexions sortantes vers des IP non liées à ton activité ;
• pics de trafic sortant (exfiltration) ;
• DNS vers des domaines nouveaux, bizarres, très longs, aléatoires ;
• connexions vers des ports atypiques.

Commandes utiles

bash ss -tupna | head -n 50 sudo lsof -i -P -n | head -n 50 sudo resolvectl statistics sudo journalctl -u systemd-resolved --since "2 hours ago" | tail -n 200

Si tu as un pare feu type nftables/ufw, regarde aussi les logs. Un serveur qui n’a jamais fait de sortant vers Internet, et qui s’y met, c’est rarement « juste un update ».

Image à insérer : capture d’écran ss -tupna montrant un binaire inconnu connecté à une IP externe.
![Connexions sortantes suspectes](/wp-content/uploads/2026/06/ss-connexions-suspectes.png)

Modifications silencieuses de cron, systemd et des services

Les ransomwares et surtout leurs précurseurs adorent la persistance simple.

Cron

Repère :

• de nouvelles tâches dans /etc/crontab ;
• de nouveaux fichiers dans /etc/cron.* ;
• des crons user dans /var/spool/cron/ ou via crontab -l.

bash sudo cat /etc/crontab sudo ls -la /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly sudo crontab -l sudo ls -la /var/spool/cron/crontabs 2>/dev/null || true

Systemd

Repère :

• un nouveau service qui ressemble au système mais que tu n’as jamais créé ;
• un service qui lance un binaire dans /tmp ;
• un ExecStart= qui pointe vers un script obscur.

bash systemctl list-unit-files --type=service | grep enabled systemctl status systemctl cat

Le truc un peu vicieux : l’attaquant peut déposer un service puis attendre. Donc tu veux surveiller la création récente de fichiers.

bash sudo find /etc/systemd/system -type f -mtime -3 -maxdepth 2 -ls

---

Création massive de fichiers, changements d’extensions, et I/O disque anormale

Le chiffrement, ça se voit souvent au niveau disque avant de se voir « visuellement ».

À repérer

• pic d’écriture disque constant ;
• avalanche de fichiers modifiés très vite ;
• apparition d’extensions nouvelles (.locked, .crypt, .encrypted, ou un suffixe personnalisé) ;
• disparition soudaine de snapshots accessibles.

Commandes utiles

bash

iostat -xm 1

sudo find /home -type f -mmin -10 | head -n 50 sudo find /var/www -type f -mmin -10 | head -n 50

sudo du -xhd1 / | sort -h | tail -n 20

Si tu as iotop, c’est encore mieux :

bash sudo iotop -o

---

Suppression ou sabotage des sauvegardes (c’est très fréquent)

Avant de chiffrer, certains groupes vont :

• supprimer les backups locaux ;
• tenter d’accéder au serveur de sauvegarde ;
• chiffrer le partage NFS/SMB monté sur le serveur ;
• supprimer des snapshots (LVM, ZFS, Btrfs) si les droits le permettent.

Signaux faibles

• montages NFS qui « sautent » puis reviennent ;
• connexions inhabituelles vers le serveur de backup ;
• commandes rm -rf dans l’historique bash de comptes admin (ou suppression de l’historique, encore plus suspect) ;
• logs montrant des suppressions de gros volumes de fichiers.

Commandes :

bash mount | grep -E "nfs|cifs" journalctl --since "6 hours ago" | grep -iE "mount|nfs|cifs|umount" | tail -n 200

Et pense à vérifier l’historique, même si ce n’est pas une preuve parfaite :

bash sudo cat /root/.bash_history | tail -n 50

---

Apparition d’outils « classiques » d’exfiltration ou de mouvement latéral

Quelques noms reviennent souvent dans les incidents :

• rclone
• megacmd
• scp et rsync utilisés de façon étrange
• sshpass
• scanners : nmap, masscan
• socat, nc (netcat)

Évidemment, ces outils peuvent être légitimes. C’est le contexte qui compte.

bash command -v rclone megacmd nmap masscan socat nc sshpass 2>/dev/null dpkg -l | grep -E "rclone|nmap|socat|netcat" 2>/dev/null rpm -qa | grep -E "rclone|nmap|socat|netcat" 2>/dev/null

Et regarde les téléchargements récents :

bash sudo find /tmp /var/tmp /dev/shm -type f -mtime -2 -ls 2>/dev/null | head -n 50

---

Logs qui s’arrêtent, qui se vident, ou qui « deviennent calmes »

Un serveur qui n’écrit plus de logs, c’est parfois pire qu’un serveur qui spam.

À repérer

• rsyslog ou journald redémarrés sans raison ;
• rotation de logs anormale ;
• fichiers de logs tronqués ;
• effacement de /var/log/auth.log ou /var/log/secure.

bash systemctl status rsyslog 2>/dev/null || true systemctl status systemd-journald

journalctl --since "2 hours ago" | tail -n 200 sudo ls -lah /var/log | tail -n 50

Tu peux aussi vérifier si des attributs immuables ont été utilisés (plus rare, mais déjà vu) :

bash sudo lsattr /var/log/auth.log 2>/dev/null || true

---

Comptes, clés SSH et sudoers qui changent « sans ticket »

Classique : l’attaquant obtient un accès, puis ajoute une clé SSH persistante.

À surveiller

• ajout de comptes dans /etc/passwd ;
• ajout d’un user dans un groupe admin (sudo, wheel) ;
• modification de /etc/sudoers ou fichiers dans /etc/sudoers.d/ ;
• nouvelles clés dans ~/.ssh/authorized_keys.

Commandes :

bash

sudo tail -n 20 /etc/passwd sudo tail -n 20 /etc/group

sudo ls -la /etc/sudoers.d sudo grep -R . /etc/sudoers.d 2>/dev/null

sudo find /home -maxdepth 3 -type f -path "*/.ssh/authorized_keys" -ls 2>/dev/null sudo ls -la /root/.ssh 2>/dev/null || true

---

Sur Docker et environnements conteneurisés : attention aux signaux « pas Linux classique »

Beaucoup d’attaques Linux modernes passent par :

• un Docker socket exposé (/var/run/docker.sock) ;
• une API Docker ouverte ;
• des conteneurs privilégiés ;
• des secrets en clair dans des variables d’environnement.

Signes précoces :

• création de nouveaux conteneurs inconnus ;
• images tirées depuis des registres suspects ;
• conteneur qui monte la racine de l’hôte (-v /:/host) ;
• exécution de commandes dans plusieurs conteneurs.

bash docker ps docker images | head docker events --since 1h

Image à insérer : capture docker events montrant une image pull inattendue.
![Événements Docker suspects](/wp-content/uploads/2026/06/docker-events-suspects.png)

---

Mini check rapide : si tu suspectes quelque chose, fais ça tout de suite

Sans trop réfléchir, parce que quand le chiffrement démarre, tu n’as plus le luxe.

1. Isoler la machine (réseau sortant et latéral)
   Coupe l’interface, bloque au pare feu, retire du VLAN. Le but : stopper l’exfiltration et la propagation.
2. Capturer l’état

• ps auxf
• ss -tupna
• journalctl --since "2 hours ago"
• copie de /var/log/auth.log ou /var/log/secure

3. Sauver ce qui peut l’être
   Si tu as des snapshots immuables, déclenche-les. Si tu as une sauvegarde offline, ne la reconnecte pas « pour voir ».
4. Ne redémarre pas par réflexe
   Parfois le malware vit en mémoire. Mais parfois un reboot efface des preuves utiles. Décide en fonction de ton plan d’incident, pas à l’instinct.

Pour éviter de telles situations et mieux comprendre comment sécuriser vos environnements, il peut être bénéfique d'apprendre à monétiser ses compétences Linux ou même envisager de devenir expert Linux freelance. En outre, une compréhension approfondie des différences entre Linux et Windows peut également s'avérer utile dans ce domaine. Enfin, une connaissance solide en matière de sécurité est essentielle; pour cela, je recommande fortement de consulter la sécurité Linux expliquée pour obtenir des conseils pratiques et stratégiques.

Ce que je recommande (simplement) pour détecter plus tôt, la prochaine fois

Tu n’as pas besoin d’un SOC complet pour déjà améliorer les choses.

• Active et centralise les logs (même basique) : rsyslog vers une autre machine.
• Mets des alertes sur : nouveaux services systemd, modifications sudoers, nouveaux cron, pics de trafic sortant.
• Restreins SSH : pas de mot de passe, clés, fail2ban, IP allowlist si possible.
• Segmente réseau : le serveur web ne doit pas parler au serveur de backup librement.
• Backups : au moins une copie offline ou immuable.

Et si tu veux, je peux publier une checklist téléchargeable version « routine hebdo » sur Le Blog Tech Pro de Samyn-Antoy ABASSE. Dis moi juste ton contexte (VPS, PME, homelab, prod Docker), je l’adapte.

---

Conclusion

Les ransomwares sur Linux ne te préviennent pas gentiment. Ils testent, ils observent, ils s’installent. Et quand ça chiffre, c’est déjà tard.

Mais les signes précoces existent : connexions SSH anormales, processus hors contexte, trafic sortant étrange, persistance via cron ou systemd, I/O disque qui s’emballe, backups qui se font saboter, logs qui disparaissent, clés SSH ajoutées en douce.

Garde cette page sous la main. Et surtout, la prochaine fois que tu vois un « petit truc bizarre » sur un serveur Linux, ne le mets pas de côté. C’est souvent là que tout se joue.

Si tu cherches à approfondir tes connaissances sur les certifications Linux pour mieux gérer ces situations ou si tu te demandes quel OS choisir entre Linux et Windows, n'hésite pas à consulter ces ressources utiles.

Questions fréquemment posées

Le ransomware existe-t-il vraiment sur Linux ?

Oui, le ransomware sur Linux existe bel et bien. Même si Linux est souvent perçu comme solide et sécurisé, il n'est pas immunisé contre ces attaques. Les ransomwares sur Linux peuvent être plus discrets et se propager lentement, commençant parfois par une seule machine ou un compte SSH vulnérable.

Pourquoi Linux est-il une cible rentable pour les attaquants ?

Linux est largement utilisé dans des environnements critiques tels que serveurs web, VPS, NAS, clusters Docker, Kubernetes, bases de données et ERP. Cette omniprésence dans des infrastructures sensibles en fait une cible privilégiée pour les attaquants qui cherchent à maximiser leurs gains via le vol de données, la suppression de sauvegardes ou la propagation via SSH et autres services.

Quels sont les premiers signes d'une attaque ransomware sur un système Linux ?

Les premiers signaux incluent des connexions SSH inhabituelles : connexions à des heures étranges, authentifications réussies depuis des IP inconnues, utilisation soudaine de comptes rarement utilisés, ou tentatives de login suivies d'une réussite puis d'une absence d'activité. Il faut aussi surveiller les processus inconnus ou hors contexte qui ne correspondent pas au rôle habituel de la machine.

Comment détecter des connexions SSH suspectes sur Linux ?

Pour repérer ces connexions suspectes, il est utile d'analyser les logs avec des commandes comme 'last -a | head -n 30' ou 'sudo grep -iE "sshd|accepted|authentication failure|invalid user" /var/log/auth.log | tail -n 200'. Surveillez aussi les utilisateurs qui se connectent en SSH puis lancent immédiatement des commandes comme 'sudo su -', 'wget' ou 'curl' vers des domaines inconnus.

Quels comportements de processus indiquent une possible infection par ransomware ?

Des processus lancés depuis des répertoires temporaires comme '/tmp', '/var/tmp' ou '/dev/shm', ainsi que des binaires sans chemin clair ou avec des noms imitant ceux du système (par exemple 'kworker') peuvent indiquer une infection. De plus, un processus qui ouvre des connexions sortantes vers des IP aléatoires alors qu'il ne devrait pas est un signe d'alerte.

Comment se préparer efficacement contre les ransomwares sur Linux ?

Il est essentiel de repérer les signaux faibles dès le début pour agir rapidement. Maintenez une bonne hygiène de sécurité : sécurisez vos accès SSH (évitez les clés réutilisées), protégez vos outils d'automatisation comme Ansible, limitez les partages NFS et restreignez l'accès aux API Docker. Par ailleurs, consultez régulièrement des ressources spécialisées comme le Blog Tech Pro de Samyn-Antoy ABASSE pour accéder à des checklists et conseils orientés terrain.