Rançongiciel C3RB3R sur Synology : origines, récupération et comment rester en sécurité

Ransomware C3RB3R a commencé à apparaître sur les unités NAS Synology aux alentours du 28 octobre 2026, et en un jour, c'était le seul sujet sur r/synology. Les fichiers sont renommés avec une extension .L0CK3D (un zéro, pas la lettre O), chaque dossier reçoit une read-me3.txt note de rançon, et un portail Tor demande du Bitcoin. Les informations les plus rapides et les plus utiles ne provenaient pas des sites d'actualités anglophones. Elles provenaient de forums sinophones, où Synology possède une énorme base d'utilisateurs, et de trois dépôts GitHub rédigés par des victimes qui ont réellement récupéré leurs données, ou prouvé qu'elles ne le pouvaient pas. Ce guide rassemble ce qui est confirmé sur le ransomware C3RB3R jusqu'à présent : d'où il vient, comment il pénètre, le seul moyen de récupération qui a fonctionné, et la conception de sauvegarde que nous appliquons pour qu'une telle attaque nous coûte une restauration au lieu d'une rançon.

Mise à jour, 31 octobre 2026 : Synology a désormais établi le point d'entrée. Dans un e-mail envoyé à ses clients le 30 octobre, elle a confirmé que le rançongiciel C3RB3R exploite uniquement la vulnérabilité corrigée dans Synology-SA-24:20, patchée en décembre 2024, et que la campagne n'est pas liée à la vulnérabilité PHP2Shell corrigée le même mois. Nous avons ajouté la propre liste de contrôle en quatre étapes de Synology, notre interprétation des raisons pour lesquelles les attaques se sont déclenchées au moment où elles l'ont fait, ainsi qu'une couche supplémentaire que nous utilisons et que la plupart des propriétaires paient déjà : la protection contre les rançongiciels d'Active Insight.

Point SynoPower Club :Une victime dans un groupe NAS chinois avait plus de 50 To sur un seul boîtier et aucun snapshot. Le chiffreur était suffisamment lent pour que seuls ses clichés de 2024 soient touchés, et ceux-ci se trouvaient avoir une copie à froid sur un stockage cloud. Un autre a perdu cinq ans de dépôts GitLab privés, parce que le RAID 6 et trois sauvegardes se trouvaient tous sur la même machine. Le ransomware C3RB3R n'a pas vaincu leur stockage, il a vaincu la conception de leur sauvegarde. Nous exécutons nos sites publics sous forme de conteneurs Docker dans Virtual DSM, effectuons un snapshot de l'ensemble de l'invité depuis l'hôte, le répliquons sur un second NAS et l'exportons sur USB et vers le cloud selon un calendrier. Si un invité est chiffré ce soir, nous le restaurons au dernier snapshot et l'attaquant ne reçoit rien.

Qu'est-ce que le ransomware C3RB3R ?

Le ransomware C3RB3R est une version Linux de la famille Cerber, une ligne de rançongiciels présente depuis 2016 et qui cible par intermittence les appareils NAS depuis des années. 360 lui attribue la vague d'octobre 2026 sur Synology. Sur un boîtier DSM infecté, le chiffreur du ransomware C3RB3R s'exécute sous la forme d'un binaire x86-64 lié statiquement et compressé avec UPX nommé libgldIl supprime son propre fichier après avoir démarré, de sorte que le processus en cours d'exécution affiche (supprimé) à côté du chemin de son exécutable.

Ce que vous voyez en tant que propriétaire d'un boîtier touché par le ransomware C3RB3R est cohérent dans chaque rapport :

• Fichiers renommés en name.ext.L0CK3DCertains rapports l'orthographient LOCK3D, mais les analyses GitHub citent le zéro.
• Une note de rançon nommée read-me3.txt dans chaque dossier chiffré, avec l'en-tête C3RB3R INSTRUCTIONS.
• Une page Tor intitulée C3rb3r Decryptor. Une capture d'écran d'une victime montrait 0,03696 BTC (environ 2 952 $ US) en cas de paiement sous cinq jours, doublant à 0,07392 BTC (environ 5 904 $ US) après cela, avec un compte à rebours.
• Persistance via des entrées cron correspondant à /etc/cron.d/synot*, qui se recréent d'elles-mêmes et ont survécu à une mise à niveau de DSM dans au moins un cas.
• Fichiers de sauvegarde sur le même volume chiffrés en même temps que tout le reste, y compris les cibles Hyper Backup et les dumps de bases de données.

Où cela a commencé : r/synology et les forums chinois

Le ransomware C3RB3R a fait sa première apparition en anglais sur r/synology, où les victimes ont publié à environ un jour d'intervalle autour des 28 et 29 octobre 2026. En quelques heures, les lecteurs ont indiqué qu'un nouveau fil apparaissait à chaque rafraîchissement du subreddit. Trois de ces fils valent la peine d'être lus en entier, car chacun apporte une pièce différente :

• L'analyse d'investigation numérique. Un propriétaire de DS918+ sous DSM 7.2.1-69057 Update 5, dont l'interface web était accessible depuis Internet, a éteint le boîtier et examiné les disques en lecture seule sur un hôte Proxmox. Le journal d'authentification DSM contenait une demande de connexion dont le champ de compte portait des lignes d'injection LD_PRELOAD et LD_DEBUG_OUTPUT ainsi qu'une commande shell encodée et un fichier sous /etc/cron.dCela correspond à la technique CVE-2024-10441 publiée. Une sauvegarde 3-2-1 a permis que l'attaque ne coûte qu'une restauration, et non une rançon. Lisez-le ici : Eh bien, c'est enfin arrivé. Mon premier vrai incident de rançongiciel.
• L'utilisateur de Photos uniquement. Ce propriétaire pensait que DSM était à jour et n'utilisait que Synology Photos, mais le UPnP était activé sur le routeur. Après une réinitialisation de mode 2, les dossiers couverts par Snapshot Replication sont revenus. Les dossiers sans snapshots ne sont pas revenus, et le lecteur USB local Hyper Backup a été chiffré en même temps que le NAS. Lisez-le ici : Touché par le rançongiciel c3rb3r ce matin.
• La discussion sur QuickConnect. L'auteur de la publication originale n'a remarqué l'attaque qu'après la dégradation de DSM et une réinstallation qui a révélé les fichiers chiffrés. Dans les réponses, un autre lecteur disposant d'un mot de passe fort, du 2FA et de QuickConnect activé a déclaré avoir également été touché, et d'autres ont souligné que les utilisateurs uniquement d'applications peuvent désactiver entièrement l'accès DSM dans QuickConnect. Lisez-le ici : Touché par le rançongiciel C3RB3R.

Lus ensemble, la tendance est claire. Le ransomware C3RB3R avait simplement besoin d'une page de connexion DSM accessible. Les mots de passe et le 2FA n'ont pas aidé, car l'exploit s'exécute avant l'authentification. L'analyse d'investigation l'a dit clairement : la requête a atteint une application vulnérable, et une autre invite de mot de passe n'aurait rien changé.

Le travail technique plus approfondi s'est déroulé en chinois. Les victimes dans les groupes WeChat et Xiaohongshu ont publié des demandes de rançon, comparé les chronologies et se sont redirigées mutuellement vers les répertoires GitHub présentés ci-dessous. Une communauté Synology taïwanaise sur Facebook a rassemblé les mêmes liens de récupération pour les utilisateurs locaux. C'est logique : Synology est une entreprise taïwanaise et ses plus grandes communautés d'utilisateurs sont sinophones, c'est donc de là que provenaient le volume le plus important de cas de rançongiciel C3RB3R et, par conséquent, l'identification la plus rapide des schémas d'attaque.

Synology a elle-même publié un avis de sécurité le 29 octobre 2026, indiquant qu'il avait identifié des acteurs de menace exploitant une vulnérabilité corrigée en décembre 2024 contre des versions obsolètes de DSM, et incitant tout le monde à mettre à jour immédiatement.

Comment le ransomware C3RB3R s'infiltre

Pendant les deux premiers jours, il y avait deux points d'entrée potentiels. Synology a depuis confirmé le plus ancien. Son e-mail du 30 octobre indique que les attaques exploitent uniquement la vulnérabilité traitée dans Synology-SA-24:20 et que le rançongiciel C3RB3R n'a rien à voir avec PHP2Shell. Le tableau ci-dessous présente les deux candidats tels qu'ils ont été débattus, car la paire 360 vaut toujours la peine d'être patchée.

	Synology déclare	360 déclare
Consultatif	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, exécution de code à distance non authentifiée dans le démon du plugin système	CVE-2026-13639 (logique de connexion) et CVE-2026-13684 (SCGI), toutes deux CVSS 9.8
Corrigé	De novembre à décembre 2024	18 septembre 2026
Versions corrigées	DSM 7.2.2-72806 Mise à jour 1, 7.2.1-69057 Mise à jour 6, 7.2-64570 Mise à jour 4, 7.1.1-42962 Mise à jour 7	DSM 7.4-90075, 7.3.2-86009 Mise à jour 4, 7.2.2-72806 Mise à jour 9, 7.2.1-69057 Mise à jour 12

Les preuves médico-légales penchent vers la faille la plus ancienne pour au moins certaines victimes. Le rapport Reddit le plus détaillé a associé ses propres journaux survivants à l'exploit CVE-2024-10441 publié, tout en notant que Synology ne l'avait pas confirmé et que la même machine était également en dessous du niveau de correctif SA-26:13. Le rapport soimy indique que les journaux de mémoire de l'invité infecté pointent vers une injection de variables d'environnement via le plugin de connexion DSM, ce qui est cohérent avec CVE-2024-10441, et une preuve de concept publique abusant du champ du nom d'utilisateur de connexion est apparue sur GitHub quelques jours avant l'attaque. Deux des trois cas de récupération documentés fonctionnaient sur du matériel non officiel avec un bootloader DS918+, dont l'un sur DSM 7.2-64570 Update 3, soit exactement une mise à jour avant le correctif CVE-2024-10441. Le matériel cloné ne peut pas recevoir facilement les mises à jour officielles, ce qui en fait la cible la plus vulnérable.

La conclusion pratique n'a pas changé : mettez à jour vers une version couvrant les deux bulletins de sécurité et cessez d'exposer DSM à Internet. Mais une question subsistait. Si la faille a été corrigée en décembre 2024, pourquoi tant de boîtiers se sont-ils déclenchés avec le rançongiciel C3RB3R au cours des deux mêmes jours d'octobre 2026, y compris certains dont les propriétaires pensaient qu'ils étaient à jour ?

Implanté tôt, déclenché au bon moment

Notre lecture, et il s'agit de notre interprétation plutôt que d'une déclaration officielle de Synology, est que l'intrusion du rançongiciel C3RB3R et le chiffrement sont deux événements distincts. Les preuves vont dans ce sens :

• La porte dérobée est arrivée en premier. Dans le cas Xiaohongshu ci-dessous, un shell de porte dérobée résidait sur le NAS depuis 37 jours et avait activé telnet en tant que root avant même qu'un seul fichier ne soit chiffré.
• Elle survit aux mises à jour. Les entrées cron sous /etc/cron.d/synot* se recréent d'elles-mêmes, et au moins une victime les a trouvées toujours en place après la mise à niveau vers la dernière version de DSM. La mise à jour a comblé la faille mais a laissé l'intrus à l'intérieur.
• Les déclenchements étaient synchronisés. Des boîtiers touchés par le rançongiciel C3RB3R qui avaient été compromis à des moments différents, sur des versions différentes, ont commencé à chiffrer à environ 48 heures d'intervalle.

Ce schéma correspond à un opérateur ayant implanté des implants du rançongiciel C3RB3R sur des boîtiers non patchés pendant des mois, puis choisi le moment de déclencher l'attaque à distance. Le moment choisi a été la semaine PHP2Shell, quand chaque administrateur Synology était occupé à appliquer les correctifs, que de nombreux boîtiers venaient d'être mis à jour et que les propriétaires se croyaient en sécurité parce qu'ils l'avaient fait. Synology indique clairement que PHP2Shell n'était pas la voie d'accès. C'était la couverture. La leçon est qu'un boîtier exposé alors qu'il n'était pas patché doit être traité comme compromis jusqu'à vérification, ce qui est exactement ce que la première étape de la liste de contrôle de Synology vous demande de faire.

Première réaction face au ransomware C3RB3R en 4 étapes

Si vous trouvez des extension .L0CK3D fichiers dès maintenant, l'ordre des actions dans les dix prochaines minutes déterminera si une récupération est possible. La clé qui déverrouille vos fichiers n'existe que dans le processus du ransomware C3RB3R en cours d'exécution. Un redémarrage, un kill -9 ou une réinstallation de DSM la détruira.

Les commandes correspondant aux étapes 2 et 3 ressemblent à ceci. Lisez les dépôts avant d'exécuter quoi que ce soit, car les détails dépendent du binaire que vous possédez.

# Étape 2 : trouver le chiffreur (son exécutable apparaît comme supprimé)

ls -l /proc/*/exe 2>/dev/null | grep deleted

# Le geler. N'utilisez jamais kill -9 ici.

kill -STOP <PID>	grep State /proc/<PID>/status # devrait afficher T (stopped)	# Rechercher la persistance qui le réactive	ls -l /etc/cron.d/ | grep synot
Pouvez-vous le déchiffrer ? Les trois cas de récupération GitHub	Il n'existe pas de déchiffreur universel pour le ransomware C3RB3R, et quiconque en vend un émet une supposition. Ce qui existe, ce sont trois études de cas rigoureuses qui vous indiquent exactement quand la récupération fonctionne.	Dépôt	Machine
Résultat	Pourquoi	Dépôt	soimy/c3rb3r-rescue
DSM dans une machine virtuelle Proxmox VE exécutant GitLab	Récupéré	Une copie de 16 Gio de la RAM de l'invité contenait la clé de session de 48 octets. GitLab a été restauré avec 80 projets et 9 253 objets LFS.	Le chiffreur avait déjà quitté environ 30 heures plus tôt. Les analyses complètes de la RAM et du swap n'ont trouvé aucune clé.

Le troisième dépôt est le plus important à lire, car son titre contient sa leçon : « jamais redémarré » ne signifie pas « récupérable ». Ce qui compte, c'est de savoir si le processus du ransomware C3RB3R est toujours actif. Une fois qu'il s'arrête, il efface son tampon de clé, et la clé disparaît. Une clé récupérée chez une victime est également inutile pour une autre, car chaque exécution génère une nouvelle clé de session.

Pourquoi la clé ne vit que dans la mémoire

L'analyse de Benjamin-zlt détaille le format de fichier du ransomware C3RB3R et explique à la fois pourquoi cela fonctionne et pourquoi cela échoue généralement.

• Chaque fichier obtient sa propre clé ChaCha8 aléatoire. Cette clé est chiffrée avec une clé maître de session utilisant AES-256-CBC et stockée dans un en-tête de fin (trailer) de 588 octets à la fin du fichier.
• La clé maître de session fait 48 octets : un IV de 16 octets plus une clé AES de 32 octets. Elle n'est jamais écrite sur le disque. Un pointeur global au sein du processus en cours d'exécution pointe vers elle.
• Le trailer contient également un blob chiffré avec la clé publique de l'attaquant (RSA-2048), donc sans le processus en cours d'exécution, seul l'attaquant peut récupérer la clé de session.
• Tous les fichiers ne sont pas entièrement chiffrés. Sur un échantillon de 400 fichiers, environ 56 % utilisaient le mode segmenté, 31 % n'avaient que le premier 1 Mio de chiffré, et 13 % étaient chiffrés de bout en bout. Les fichiers partiellement chiffrés ne sont toujours pas lisibles, mais l'analyse du pied de page vous indique ce qu'il reste.

La faiblesse du ransomware C3RB3R est donc étroite et limitée dans le temps : le chiffreur conserve la clé maître en mémoire pendant toute la session. Gelez-le pendant qu'il s'exécute et vous pourrez en extraire la clé. Si vous manquez cette fenêtre, il ne vous reste que le blob de clé publique, conçu pour être inviolable.

L'histoire d'une victime : 50 To et aucun snapshot

Un récit détaillé publié sur Xiaohongshu le 29 octobre 2026 par l'utilisateur 柯基爱好者 suit un membre de leur groupe NAS durant la nuit. Il a remarqué la note du ransomware C3RB3R, a confirmé l'en-tête C3RB3R INSTRUCTIONS et était sur le point d'acheter du Bitcoin avant que le groupe ne lui signale les cas sur GitHub.

Il a ensuite utilisé un assistant de codage IA via SSH pour enquêter. Celui-ci a trouvé et gelé le chiffreur, de sorte que rien d'autre n'a été chiffré par la suite. Il a également découvert qu'un shell porte dérobée probable résidait sur le NAS depuis 37 jours et avait activé telnet en tant que root, ce qui signifie que l'intrusion initiale et le chiffrement étaient séparés de plus d'un mois. Il a écrit un script de collecte de preuves et a, à juste titre, attendu sa confirmation avant d'exécuter quoi que ce soit en tant que root.

Sa chance a été que le ransomware C3RB3R soit lent. Avec plus de 50 To à parcourir, le chiffreur n'avait atteint que ses photos de 2024, et celles-ci avaient une copie froide sur un stockage cloud. Il a déplacé les données de travail vers un NAS plus petit et a mis le volume chiffré de côté pour plus tard. Son propre résumé était sans appel : il n'avait aucun snapshot, et avec des snapshots, cela aurait été facile à corriger. Une deuxième victime sur X a résumé la même leçon sous un autre angle : du RAID 6 plus trois jeux de sauvegardes, tous sur le même boîtier, tous chiffrés ensemble.

Comment nous gardons le ransomware C3RB3R à l'écart de nos sauvegardes

Chaque histoire de perte de données ci-dessus présente le même schéma : les sauvegardes étaient accessibles depuis la machine compromise. Le ransomware C3RB3R chiffre tout ce sur quoi le DSM compromis peut écrire, la solution consiste donc à conserver au moins une copie dans un endroit où le DSM ne peut absolument pas écrire. Voici comment nous procédons pour les sites que nous hébergeons, ce qui correspond à la règle 3-2-1-1-0.

Règle	Signification	Comment nous le faisons
3	Trois copies des données	La VM en production, une réplique sur un second NAS et une exportation planifiée
2	Deux types de supports	Des volumes NAS plus un lecteur USB et un stockage cloud
1	Une copie hors site	Exportations synchronisées vers Google Drive avec Cloud Sync
1	Une copie hors ligne ou immuable	Snapshots VM côté hôte auxquels l'invité ne peut pas toucher, plus l'exportation USB déconnectée
0	Zéro erreur lors de la restauration	Nous restaurons et démarrons réellement à partir des répliques lorsque nous déplaçons des VM entre hôtes

Exécutez Docker dans Virtual DSM, pas sur l'hôte

Nos conteneurs WordPress ne s'exécutent pas sur le NAS physique. Ils s'exécutent dans un invité Virtual DSM, et cet invité est protégé par Virtual Machine Manager sur l'hôte. Si le ransomware C3RB3R obtient les accès root dans l'invité, il contrôle cet invité et rien d'autre. Les snapshots de l'invité résident sur le stockage de l'hôte, en dehors du système de fichiers de l'invité, de sorte que le ransomware dans la VM ne peut pas les voir, et encore moins les chiffrer ou les supprimer. La récupération se fait par une restauration de snapshot qui ne prend que quelques minutes.

VMM Pro ajoute les fonctionnalités qui en font une véritable sauvegarde : un plan de protection qui effectue des snapshots de la VM et la réplique sur un second NAS du cluster, couvrant ainsi le cas où un hôte tomberait en panne. Notre cluster est composé d'un DS1621xs+ et d'un DS1525+ se répliquant l'un l'autre. Nous avons rédigé la partie concernant l'exportation planifiée et Cloud Sync vers Google Drive séparément, et la comparaison entre VMM gratuit et VMM Pro explique quelles fonctionnalités nécessitent la licence.

Si vous exécutez Docker directement sur DSM, utilisez des snapshots immuables

Tout le monde ne veut pas forcément d'une couche VM. Si vos conteneurs s'exécutent sur l'hôte, la défense contre le ransomware C3RB3R réside dans les snapshots immuables. Activez-les dans Snapshot Replication pour le dossier partagé qui contient les données de vos conteneurs. Ils nécessitent DSM 7.2 ou ultérieur et un volume Btrfs, et pendant la période de verrouillage, personne ne peut les supprimer, y compris un compte administrateur dont l'attaquant a pris le contrôle. Deux détails font toute la différence :

• Utilisez des bind mounts dans un dossier partagé tel que /volume1/docker/app. Les volumes nommés Docker résident sous /volume1/@docker, qui n'est pas un dossier partagé et ne peut pas du tout faire l'objet de snapshots.
• Exportez les bases de données dans un fichier avant le snapshot. Un snapshot d'une base MariaDB en cours d'exécution équivaut à une copie après coupure de courant. Un export planifié mysqldump dans le même dossier partagé vous donne un point de restauration propre que le snapshot verrouille ensuite.
• Choisissez une période de verrouillage plus longue que le temps pendant lequel un attaquant peut attendre patiemment. La victime ci-dessus avait une porte dérobée depuis 37 jours avant le début du chiffrement. Sept jours de snapshots immuables n'auraient pas permis de remonter jusqu'à un état propre.

Notre couche supplémentaire : Active Insight prend un snapshot lorsque le chiffrement commence

Voici la couche que la plupart des guides oublient. Active Insight, le service de surveillance cloud de Synology, peut observer l'activité des fichiers sur vos dossiers partagés, et une fois qu'il estime faire face à un rançongiciel, il réagit de lui-même. Synology le documente dans son guide de sécurité du NAS: lorsqu'un événement de rançongiciel est détecté, Active Insight envoie une notification d'événement et prend automatiquement un snapshot du dossier partagé, et sur les modèles qui le prennent en charge, ce snapshot est immuable.

Pourquoi cela importe particulièrement pour le rançongiciel C3RB3R : le moteur de chiffrement du rançongiciel C3RB3R est lent. La victime avec plus de 50 To n'en était qu'à ses photos de 2024 lorsqu'elle s'en est rendu compte. Un snapshot pris dès l'apparition initiale du schéma de chiffrement gèle tout ce qui n'a pas encore été touché, ce qui peut représenter la majeure partie du volume. Il se moque également de savoir comment le rançongiciel C3RB3R est entré, car il surveille ce qui arrive aux fichiers, et non la page de connexion. Sur notre DS1621xs+, la page Activité des fichiers affiche la protection contre les rançongiciels comme Protégé.

Lisez les limites avant de vous y fier. Elles proviennent de la documentation sur l'activité des fichiers:

• La surveillance de l'activité des fichiers est désactivée par défaut. Enregistrez le NAS pour Active Insight dans le Panneau de configuration, puis activez la surveillance pour chaque hôte dans le portail Active Insight.
• Il nécessite Snapshot Replication, DSM 7.2 ou version ultérieure, Active Insight 3.0.2 ou version ultérieure, au moins 1 Go de mémoire et une licence Active Insight attribuée à ce NAS.
• Au maximum un snapshot automatique par dossier partagé et par jour. Il s'agit d'un filet de sécurité pris après détection, et non d'un remplacement des snapshots immuables programmés.
• Non couvert : Les dossiers d'enregistrement de Surveillance Station et les dossiers partagés sur les disques USB externes.
• L'immuabilité dépend du modèle. Sur un modèle sans snapshots immuables, un attaquant disposant des accès root peut toujours supprimer le snapshot automatique, associez-le donc à la planification d'immuabilité ci-dessus.

Vous souhaitez la même configuration ? SynoPower Club vend des licences officielles pour ces deux composants : une licence Virtual DSM (VDSM) pour exécuter vos services Docker dans un invité isolé, et une Licence VMM Pro pour les plans de protection, la réplication inter-NAS et la migration en direct. Les clés sont livrées par e-mail.

Où trouver plus de ressources officielles

Le rançongiciel C3RB3R sur Synology a été rendu public il y a deux jours au moment où nous écrivons ces lignes, et il n'y a pas encore de couverture vidéo officielle, donc cette section répertorie les sources primaires plutôt que des tutoriels.

• Le bulletin de sécurité Synology du 29 octobre 2026, qui demande aux utilisateurs de versions obsolètes de DSM de mettre à jour immédiatement et d'activer les mises à jour automatiques, suivi le 30 octobre d'un e-mail aux clients confirmant que SA-24:20 est la seule vulnérabilité impliquée.
• Synology-SA-24:20 et Synology-SA-26:13 sont les tableaux de versions. Vérifiez votre build dans Panneau de configuration, puis Mise à jour et restauration, par rapport aux deux.
• DSM dans une machine virtuelle Proxmox VE exécutant GitLab est le meilleur index de tous les cas connus, y compris ceux non couverts ici, et l'explication la plus claire sur le moment où l'analyse de la mémoire devient inutile.
• Les trois threads r/synology liés ci-dessus, en particulier le rapport d'analyse légale, qui inclut étape par étape les commandes d'investigation de disque en lecture seule : Eh bien, c'est finalement arrivé.

Liste de contrôle propre à Synology (30 octobre 2026)

L’e-mail de Synology aux clients se termine par quatre étapes. Elles sont courtes, et chacune d’elles compte contre le rançongiciel C3RB3R :

1. Vérifiez la présence d'intrus. Le rançongiciel C3RB3R laisse une persistance planifiée, lancez donc une analyse avec Conseiller de sécurité, puis recherchez dans le Planificateur de tâches les scripts que vous n'avez pas créés et dans Utilisateur et groupe les comptes administrateur que vous n'avez pas ajoutés. Si quelque chose semble anormal, contactez l'Assistance Synology.
2. Mettez tout à jour. Installez la dernière version de DSM dans Panneau de configuration, Mise à jour et restauration, puis mettez à jour chaque paquet dans le Centre de paquets.
3. Activez les mises à jour automatiques dans Mise à jour et restauration, afin que les futurs correctifs de sécurité soient appliqués dès leur publication.
4. Conservez une sauvegarde hors site. Utilisez Hyper Backup et Snapshot Replication pour conserver une copie dans un emplacement distinct, et vérifiez régulièrement que les tâches de sauvegarde s'exécutent correctement.

La première étape est celle que les gens négligent. Si votre NAS était accessible depuis Internet avant le correctif de décembre 2024, le rançongiciel C3RB3R y a peut-être déjà pris pied, et faire la mise à jour aujourd'hui ne vous indique pas si quelqu'un est déjà à l'intérieur.

Un outil gratuit qui exécute la vérification pour vous

Si vous êtes à l'aise avec un terminal, la première étape peut désormais se faire en une seule commande. synology-nas-cli est un outil en ligne de commande open source sous licence MIT, publié le 30 octobre 2026 par le développeur indépendant Akari Sora. Il se connecte à DSM via son API web et vérifie le boîtier par rapport à cette campagne. Le projet est disponible sur GitHub : akari-sora/synology-nas-cli.

Nous avons lu son code avant de le mettre en lien. Il utilise uniquement la bibliothèque standard Python et ne communique avec rien d'autre que votre NAS, le serveur de téléchargement Synology, PyPI et le kit d'outils de secours soimy. Il n'envoie aucune télémesure et l'audit de base est uniquement en lecture seule. Voici ce qu'il vérifie :

• Niveau de correctif. Votre version de DSM par rapport à Synology-SA-26:13, qui couvre également le correctif de l'ancien SA-24:20, et vos paquets installés par rapport à SA-26:14.
• Exposition. QuickConnect, le transfert de port UPnP sur le routeur, le pare-feu DSM, AutoBlock, SMB1 et le compte administrateur intégré.
• Traces du rançongiciel C3RB3R. Les chaînes de connexion injectées dans le journal de connexion, /etc/cron.d/synot* les entrées, les libgld et qnetd binaires, les comptes root supplémentaires, les clés SSH et les demandes de rançon sur vos partages.
• Instantanés. Dossiers partagés n'ayant aucune planification de snapshot fonctionnelle.

Il peut également corriger la majeure partie de ce qu'il trouve. Si des fichiers sont en cours de chiffrement en ce moment même, sa commande contain gèle le chiffreur avec SIGSTOP, la même action que l'étape deux de notre liste d'intervention d'urgence. Sa commande rescue pilote ensuite le kit d'outils soimy pour capturer la mémoire et rechercher la clé.

nas incident                 # audit en lecture seule

Lisez ces remarques avant de le laisser modifier quoi que ce soit :

• Il est tout nouveau. Le projet a quelques jours, provient d'un développeur unique, n'est pas affilié à Synology et a reçu peu de révisions externes. Commencez par l'audit en lecture seule et la simulation (dry run).
• La correction du pare-feu peut vous bloquer l'accès. Il bascule le pare-feu DSM pour tout refuser à l'exception des réseaux que vous indiquez. Exécutez-le depuis un ordinateur situé sur le même réseau local (LAN) et sachez où se trouve le bouton RESET.
• Il désactive QuickConnect. C'est le paramètre le plus sûr, mais si votre famille accède à Synology Photos ou Surveillance Station via QuickConnect, configurez d'abord un VPN ou Tailscale.
• L'analyse approfondie (deep scan), le confinement (contain) et le secours (rescue) s'exécutent en tant que root. Ils fonctionnent via une tâche temporaire du Planificateur de tâches, car c'est le seul moyen de lire les journaux réservés à root et de geler les processus.
• Le fichier README suggère de le confier à un agent d'IA. Si vous le faites, conservez le mot de passe dans un gestionnaire de mots de passe plutôt que dans le chat, et confirmez la correction vous-même.
• La récupération de la mémoire ne fonctionne que tant que le chiffreur est actif. La même règle que pour les trois cas GitHub s'applique.

Pour le reste du renforcement de la sécurité, nos guides sur héberger un site web public sur un NAS Synology et sur ce que Threat Prevention peut et ne peut pas voir couvrent le côté réseau, et le guide de correctif PHP2Shell couvre l'autre problème critique survenu la même semaine.

Limites du rançongiciel C3RB3R et remarques sur la sécurité

La mise à jour ne supprime pas une infection existante. Au moins une victime a constaté que la persistance cron était toujours en place après la mise à niveau vers le dernier DSM. Si vous étiez exposé alors que le système n'était pas corrigé, vérifiez /etc/cron.d, le Planificateur de tâches, les scripts de démarrage et les services activés tels que telnet, puis réinitialisez tous vos identifiants.

Être à jour ne signifie pas être sain. Une victime sur Reddit pensait que DSM était à jour, et une autre a été touchée malgré l'activation de la 2FA et d'un mot de passe fort. Un NAS compromis avant d'être corrigé peut conserver l'implant à travers chaque mise à jour ultérieure. Traitez toute page de connexion DSM accessible depuis Internet comme une cible, y compris celles publiées via UPnP que vous n'avez jamais configurées intentionnellement. Utilisez un VPN ou Tailscale pour l'accès à distance et désactivez l'UPnP sur le routeur.

Le RAID et les sauvegardes locales ne sont pas des protections suffisantes contre le rançongiciel C3RB3R. Tout ce sur quoi le DSM compromis peut écrire sera chiffré, y compris les cibles Hyper Backup sur le même appareil et les partages réseau montés.

Ne payez pas avant d'avoir lu les témoignages de victimes. Payer les opérateurs du rançongiciel C3RB3R finance la prochaine vague et ne garantit rien. Si le programme de chiffrement est toujours en cours d'exécution, la méthode de la mémoire libre est votre meilleure chance. Si ce n'est pas le cas, les seules options réalistes sont vos propres copies externes hors de l'appareil.

Faites attention à ce que vous collez dans un assistant IA. Les outils d'IA ont aidé plusieurs victimes ici, mais ne leur transmettez pas de mots de passe, de clés récupérées, de vidages mémoire complets ou de données d'entreprise. Laissez-les proposer des commandes et exécutez vous-même tout ce qui nécessite les droits root.

Le matériel cloné comporte des risques supplémentaires. Plusieurs victimes répertoriées exécutaient DSM sur du matériel non officiel, où les mises à jour officielles sont difficiles voire impossibles à appliquer. Si tel est votre cas, considérez que vous n'avez pas de correctif et isolez complètement l'appareil d'Internet.

Références

• Bulletin de sécurité Synology sur les attaques de rançongiciels DSM, 29 octobre 2026.
• Synology-SA-24:20 DSM (Pwn2Own 2024), CVE-2024-10441 et les builds DSM corrigés.
• Synology-SA-26:13 DSM, CVE-2026-13639 et CVE-2026-13684, publiés le 18 septembre 2026.
• Sauvetage "bare-metal" du rançongiciel C3RB3R par Benjamin-zlt, le format de fichier, la disposition des clés et le flux de travail SIGSTOP.
• synology-nas-cli par Akari Sora, un outil d'audit et de réponse open source pour cette campagne.
• IT-Connect sur la campagne C3RB3R, résumant l'attribution 360 et la chronologie.
• Centre de connaissances Synology : renforcer la sécurité de votre NAS Synology, y compris la manière dont Active Insight prend un instantané d'un dossier partagé lorsqu'il détecte un rançongiciel.

Questions fréquemment posées

Faites en sorte que la prochaine attaque du rançongiciel C3RB3R ne vous coûte qu'une restauration, pas une rançon. Exécutez vos services Docker dans Virtual DSM et protégez l'ensemble du système invité grâce aux plans de protection VMM Pro, répliqués sur un second NAS. SynoPower Club vend des licences officielles pour les deux, avec livraison des clés par e-mail.