Ransomware C3RB3R en Synology: Orígenes, recuperación y cómo mantenerse a salvo

Ransomware C3RB3R comenzó a aparecer en unidades Synology NAS alrededor del 28 de octubre de 2026 y, en cuestión de un día, era el único tema en r/synology. Los archivos se renombran con una L0CK3D extensión (un cero, no la letra O), cada carpeta recibe una read-me3.txt nota de rescate y un portal Tor exige Bitcoin. La información más rápida y útil no provino de sitios de noticias en inglés. Provino de foros de habla china, donde Synology tiene una gran base de usuarios, y de tres repositorios de GitHub escritos por víctimas que realmente recuperaron sus datos o demostraron que no podían hacerlo. Esta guía recopila lo que se ha confirmado sobre el ransomware C3RB3R hasta ahora: de dónde vino, cómo entra, la única vía de recuperación que ha funcionado y el diseño de copia de seguridad que ejecutamos para que un ataque como este nos cueste una restauración en lugar de un rescate.

Actualización, 31 de octubre de 2026: Synology ya ha determinado el punto de entrada. En un correo electrónico enviado a los clientes el 30 de octubre, confirmó que el ransomware C3RB3R explota únicamente la vulnerabilidad corregida en Synology-SA-24:20, parcheada en diciembre de 2024, y que la campaña no está relacionada con la vulnerabilidad PHP2Shell parcheada el mismo mes. Hemos añadido la propia lista de comprobación de cuatro pasos de Synology, nuestra lectura de por qué se produjeron los ataques cuando lo hicieron y una capa adicional que ejecutamos y por la que la mayoría de los propietarios ya pagan: la protección contra ransomware de Active Insight.

Punto SynoPower Club:Una víctima en un grupo chino de NAS tenía más de 50 TB en un solo equipo y ninguna instantánea. El cifrador fue lo suficientemente lento como para que solo sus fotos de 2024 se vieran afectadas, y dio la casualidad de que tenían una copia fría en una unidad en la nube. Otro perdió cinco años de repositorios privados de GitLab porque el RAID 6 más tres copias de seguridad residían en la misma máquina. El ransomware C3RB3R no venció a su almacenamiento, venció a su diseño de copias de seguridad. Ejecutamos nuestros sitios públicos como Docker dentro de Virtual DSM, creamos una instantánea de todo el sistema invitado desde el host, la replicamos en un segundo NAS y la exportamos a USB y a la nube de forma programada. Si un sistema invitado resulta cifrado esta noche, lo revertimos a la última instantánea y el atacante no obtiene nada.

¿Qué es el ransomware C3RB3R?

El ransomware C3RB3R es una versión para Linux de la familia Cerber, una línea de ransomware que ha existido desde 2016 y que ha atacado dispositivos NAS intermitentemente durante años. 360 le atribuye la ola de octubre de 2026 en Synology. En un equipo DSM infectado, el cifrador del ransomware C3RB3R se ejecuta como un binario x86-64 enlazado estáticamente y empaquetado con UPX llamado libgldElimina su propio archivo tras iniciarse, por lo que el proceso en ejecución muestra (eliminado) junto a su ruta ejecutable.

Lo que usted ve como propietario de un equipo afectado por el ransomware C3RB3R es coherente en todos los informes:

• Archivos renombrados a name.ext.L0CK3DAlgunos informes lo escriben como LOCK3D, pero los análisis de GitHub citan el cero.
• Una nota de rescate llamada read-me3.txt en cada carpeta cifrada, con el encabezado C3RB3R INSTRUCTIONS.
• Una página de Tor titulada C3rb3r Decryptor. La captura de pantalla de una víctima mostraba 0,03696 BTC (unos 2952 USD) si se pagaba en un plazo de cinco días, duplicándose a 0,07392 BTC (unos 5904 USD) después de eso, con un temporizador de cuenta regresiva.
• Persistencia a través de entradas cron que coinciden con /etc/cron.d/synot*, las cuales se vuelven a crear por sí solas y sobrevivieron a una actualización de DSM en al menos un caso.
• Archivos de copia de seguridad en el mismo volumen cifrados junto con todo lo demás, incluidos los destinos de Hyper Backup y los volcados de bases de datos.

Dónde comenzó: r/synology y los foros chinos

El ransomware C3RB3R apareció por primera vez en inglés en r/synology, donde las víctimas publicaron con aproximadamente un día de diferencia alrededor del 28 y 29 de octubre de 2026. En cuestión de horas, los lectores decían que aparecía un nuevo hilo cada vez que recargaban el subreddit. Vale la pena leer tres de esos hilos completos, porque cada uno aporta una pieza diferente:

• El informe forense. Un propietario de una DS918+ en DSM 7.2.1-69057 Update 5, con la interfaz web accesible desde Internet, apagó el equipo y examinó los discos en modo de solo lectura en un host Proxmox. El registro de autenticación de DSM contenía una solicitud de inicio de sesión cuyo campo de cuenta incluía líneas inyectadas de LD_PRELOAD y LD_DEBUG_OUTPUT además de un comando de shell codificado, y un archivo debajo de /etc/cron.dEso coincide con la técnica publicada de CVE-2024-10441. Una copia de seguridad 3-2-1 significó que el ataque costó una restauración, no un rescate. Léalo aquí: Bueno, finalmente sucedió. Mi primer incidente real de ransomware.
• El usuario exclusivo de Photos. Este propietario creía que DSM estaba actualizado y solo usaba Synology Photos, pero el UPnP del enrutador estaba activado. Después de un restablecimiento de modo 2, las carpetas cubiertas por Snapshot Replication se recuperaron. Las carpetas sin instantáneas no lo hicieron, y la unidad USB local de Hyper Backup se cifró junto con el NAS. Léalo aquí: Impactado por el ransomware c3rb3r esta mañana.
• La discusión sobre QuickConnect. El autor original solo se dio cuenta después de que DSM se degradó y una reinstalación reveló los archivos cifrados. En las respuestas, otro lector con una contraseña segura, 2FA y QuickConnect habilitado dijo que también había sido afectado, y otros señalaron que los usuarios que solo usan aplicaciones pueden desactivar por completo el acceso a DSM en QuickConnect. Léalo aquí: Impactado por el ransomware C3RB3R.

Leyéndolo todo junto, el patrón es claro. El ransomware C3RB3R solo necesitaba una página de inicio de sesión de DSM a la que pudiera acceder, nada más. Las contraseñas y el 2FA no sirvieron de nada, porque el exploit se ejecuta antes de la autenticación. El informe forense lo dejó claro: la solicitud llegó a una aplicación vulnerable, y otra pantalla de contraseña no habría solucionado eso.

El trabajo técnico más profundo se desarrolló en chino. Las víctimas en grupos de WeChat y Xiaohongshu publicaron notas de rescate, compararon cronologías y se remitieron mutuamente a los repositorios de GitHub explicados a continuación. Una comunidad taiwanesa de Synology en Facebook recopiló los mismos enlaces de recuperación para los usuarios locales. Tiene sentido: Synology es una empresa taiwanesa y sus mayores comunidades de usuarios son de habla china, por lo que de allí provino el mayor volumen de casos de ransomware C3RB3R y, por lo tanto, la identificación de patrones más rápida.

La propia Synology publicó un aviso de seguridad el 29 de octubre de 2026, indicando que había identificado a actores de amenazas explotando una vulnerabilidad parcheada en diciembre de 2024 contra versiones desactualizadas de DSM, e instando a todos a actualizar de inmediato.

Cómo se introduce el ransomware C3RB3R

Durante los dos primeros días hubo dos posibles puntos de entrada. Desde entonces, Synology ha confirmado el más antiguo. Su correo electrónico del 30 de octubre indica que los ataques explotan únicamente la vulnerabilidad abordada en Synology-SA-24:20 y que el ransomware C3RB3R no tiene nada que ver con PHP2Shell. La siguiente tabla muestra ambos candidatos tal y como se debatieron, porque aún merece la pena parchear el par 360.

	Synology dice	360 dice
Consultivo	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, ejecución remota de código sin autenticación en el demonio del complemento del sistema	CVE-2026-13639 (lógica de inicio de sesión) y CVE-2026-13684 (SCGI), ambos CVSS 9.8
Parcheado	De noviembre a diciembre de 2024	18 de septiembre de 2026
Compilaciones corregidas	DSM 7.2.2-72806 Actualización 1, 7.2.1-69057 Actualización 6, 7.2-64570 Actualización 4, 7.1.1-42962 Actualización 7	DSM 7.4-90075, 7.3.2-86009 Actualización 4, 7.2.2-72806 Actualización 9, 7.2.1-69057 Actualización 12

Las pruebas forenses se inclinan hacia el fallo más antiguo en al menos algunas víctimas. El informe detallado de Reddit hizo coincidir sus propios registros supervivientes con el exploit publicado de CVE-2024-10441, al tiempo que señalaba que Synology no lo había confirmado y que ese mismo equipo también estaba por debajo del nivel de corrección de SA-26:13. El informe de soimy indica que los registros de memoria del huésped infectado apuntan a una inyección de variables de entorno a través del complemento de inicio de sesión de DSM, lo que concuerda con CVE-2024-10441, y días antes del brote apareció en GitHub una prueba de concepto pública que abusa del campo de nombre de usuario del inicio de sesión. Dos de los tres casos de rescate documentados se ejecutaban en hardware no original con un gestor de arranque DS918+, uno de ellos en DSM 7.2-64570 Update 3, que está exactamente a una actualización de la solución para CVE-2024-10441. El hardware clonado no puede recibir actualizaciones oficiales fácilmente, lo que lo convierte en el objetivo más vulnerable del conjunto.

La conclusión práctica no ha cambiado: actualice a una versión que cubra ambos avisos y deje de exponer DSM a Internet. Pero quedaba una pregunta. Si la brecha se parcheó en diciembre de 2024, ¿por qué saltaron tantos equipos con el ransomware C3RB3R en los mismos dos días de octubre de 2026, incluidos algunos cuyos propietarios creían que estaban al día?

Implantado con antelación, detonado a tiempo

Nuestra lectura, y es nuestra interpretación más que algo que Synology haya dicho, es que la intrusión del ransomware C3RB3R y el cifrado son dos eventos independientes. La evidencia apunta en esa dirección:

• La puerta trasera llegó primero. En el caso de Xiaohongshu a continuación, una shell de puerta trasera había estado presente en el NAS durante 37 días y había activado telnet como root antes de que se cifrara un solo archivo.
• Sobrevive a las actualizaciones. Las entradas de cron bajo /etc/cron.d/synot* se recrean a sí mismas, y al menos una víctima descubrió que todavía estaban presentes tras actualizar a la versión más reciente de DSM. La actualización cerró la brecha, pero dejó al intruso dentro.
• Las detonaciones fueron sincronizadas. Los equipos con ransomware C3RB3R que habían sido comprometidos en momentos diferentes, en distintas versiones, comenzaron el cifrado con unas 48 horas de diferencia entre sí.

Ese patrón encaja con un operador que implantó C3RB3R en equipos no parcheados a lo largo de meses y luego eligió cuándo apretar el gatillo de forma remota. El momento que eligieron fue la semana de PHP2Shell, cuando todos los administradores de Synology estaban ocupados parcheando, muchos equipos acababan de ser actualizados y los propietarios se sentían seguros por haberlo hecho. Synology aclara que PHP2Shell no fue la vía de entrada. Fue la cobertura. La lección es que un equipo expuesto sin parchear debe tratarse como comprometido hasta que se revise, que es exactamente lo que le pide hacer el paso uno de la lista de comprobación de Synology.

Primera respuesta al ransomware C3RB3R en 4 pasos

Si encuentra L0CK3D archivos ahora mismo, el orden de las acciones en los próximos diez minutos decidirá si la recuperación es posible. La clave que desbloquea sus archivos existe únicamente dentro del proceso en ejecución del ransomware C3RB3R. Un reinicio, un kill -9 o una reinstalación de DSM la destruirá.

Los comandos para los pasos 2 y 3 tienen este aspecto. Lea los repositorios antes de ejecutar cualquier comando, ya que los detalles dependen del binario que tenga.

# Paso 2: busque el cifrador (su ejecutable aparece como eliminado)

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

# Congélelo. Nunca use kill -9 aquí.

kill -STOP <PID>	grep State /proc/<PID>/status # debería mostrar T (stopped)	# Busque la persistencia que lo vuelve a ejecutar	ls -l /etc/cron.d/ | grep synot
¿Se pueden descifrar los datos? Los tres casos de rescate en GitHub	No existe un descifrador universal para el ransomware C3RB3R, y cualquiera que venda uno está especulando. Lo que existen son tres estudios de caso detallados que explican exactamente cuándo funciona la recuperación.	Repositorio	Equipo
Resultado	Motivo	Repositorio	soimy/c3rb3r-rescue
DSM en una máquina virtual de Proxmox VE ejecutando GitLab	Recuperado	Una copia de 16 GiB de la RAM del huésped contenía la clave de sesión de 48 bytes. GitLab se restauró con 80 proyectos y 9253 objetos LFS.	El cifrador ya había salido unas 30 horas antes. Los escaneos completos de RAM y swap no encontraron ninguna clave.

El tercer repositorio es el más importante de leer, porque su título es su lección: que nunca se haya reiniciado no significa que sea recuperable. Lo que importa es si el proceso del ransomware C3RB3R sigue activo. Una vez que se cierra, pone a cero su búfer de claves y la clave desaparece. Una clave recuperada en una víctima tampoco sirve en otra, porque cada ejecución genera una nueva clave de sesión.

Por qué la clave solo reside en la memoria

El análisis de Benjamin-zlt detalla el formato de archivo del ransomware C3RB3R y explica tanto por qué esto funciona como por qué normalmente no lo hace.

• Cada archivo obtiene su propia clave ChaCha8 aleatoria. Esa clave se envuelve con una clave maestra de sesión mediante AES-256-CBC y se almacena en un tráiler de 588 bytes al final del archivo.
• La clave maestra de sesión es de 48 bytes: un IV de 16 bytes más una clave AES de 32 bytes. Nunca se escribe en el disco. Un puntero global dentro del proceso en ejecución apunta a ella.
• El tráiler también incluye un blob envuelto con la clave pública del atacante (RSA-2048), por lo que sin el proceso en ejecución, solo el atacante puede recuperar la clave de sesión.
• No todos los archivos están completamente cifrados. En una muestra de 400 archivos, alrededor del 56 % utilizó el modo segmentado, el 31 % solo tenía cifrado el primer 1 MiB y el 13 % estaba cifrado de extremo a extremo. Los archivos parcialmente cifrados siguen sin ser legibles, pero el análisis del pie de página le indica lo que queda.

Por tanto, la debilidad del ransomware C3RB3R es limitada y con un tiempo restringido: el cifrador mantiene la clave maestra en la memoria durante toda la sesión. Congélelo mientras esté en ejecución y podrá extraer la clave. Si pierde esa ventana, solo le quedará el blob de clave pública, diseñado para ser infranqueable.

La historia de una víctima: 50 TB y sin snapshots

Un relato detallado publicado en Xiaohongshu el 29 de octubre de 2026 por el usuario 柯基爱好者 narra la noche de un miembro de su grupo de NAS. Notó la nota del ransomware C3RB3R, confirmó el encabezado C3RB3R INSTRUCTIONS y estuvo a punto de comprar Bitcoin antes de que el grupo lo dirigiera a los casos de GitHub.

A continuación, utilizó un asistente de código de IA a través de SSH para investigar. Este encontró y congeló el cifrador, por lo que nada nuevo fue cifrado después de ese momento. También descubrió que una probable shell de puerta trasera había estado alojada en el NAS durante 37 días y había habilitado telnet como root, lo que significa que la intrusión inicial y el cifrado estuvieron separados por más de un mes. Escribió un script de recolección de pruebas y, correctamente, esperó a que él confirmara antes de ejecutar cualquier cosa como root.

Su suerte fue que el ransomware C3RB3R es lento. Con más de 50 TB por procesar, el cifrador solo había llegado a sus fotos de 2024, y estas tenían una copia fría en la nube. Trasladó los datos de trabajo a un NAS más pequeño y dejó en espera el volumen cifrado para más adelante. Su propio resumen fue contundente: no tenía snapshots, y con snapshots esto habría sido fácil de solucionar. Una segunda víctima en X resumió la misma lección desde el otro extremo: RAID 6 más tres conjuntos de copias de seguridad, todos en el mismo equipo y todos cifrados a la vez.

Cómo mantenemos el ransomware C3RB3R alejado de nuestras copias de seguridad

Cada historia de pérdida de datos descrita anteriormente tiene el mismo patrón: las copias de seguridad eran accesibles desde el equipo comprometido. El ransomware C3RB3R cifra todo aquello en lo que el DSM comprometido pueda escribir, por lo que la solución es mantener al menos una copia en algún lugar donde DSM no pueda escribir en absoluto. Así es como lo hacemos para los sitios que alojamos, lo cual se ajusta a la regla 3-2-1-1-0.

Regla	Significado	Cómo lo hacemos
3	Tres copias de los datos	La VM en vivo, una réplica en un segundo NAS y una exportación programada
2	Dos tipos de soporte	Volúmenes NAS más una unidad USB y una unidad en la nube
1	Una copia fuera de las instalaciones	Exportaciones sincronizadas con Google Drive mediante Cloud Sync
1	Una copia fuera de línea o inmutable	Snapshots de la VM desde el host que el invitado no puede tocar, además de la exportación en USB desconectado
0	Cero errores en la restauración	De hecho, restauramos e iniciamos desde las réplicas cuando movemos VM entre hosts

Ejecute Docker dentro de Virtual DSM, no en el host

Nuestros contenedores de WordPress no se ejecutan en el NAS físico. Se ejecutan dentro de un invitado de Virtual DSM, y este invitado está protegido por Virtual Machine Manager en el host. Si el ransomware C3RB3R obtiene acceso root dentro del invitado, solo tendrá el control de ese invitado y de nada más. Las snapshots del invitado residen en el almacenamiento del host, fuera del sistema de archivos del invitado, por lo que el ransomware dentro de la VM no puede verlas y mucho menos cifrarlas o eliminarlas. La recuperación consiste en una restauración de snapshot que tarda solo unos minutos.

VMM Pro añade las partes que convierten esto en una copia de seguridad real: un plan de protección que toma snapshots de la VM y la replica en un segundo NAS del clúster, cubriendo también el fallo de un host. Nuestro clúster consta de un DS1621xs+ y un DS1525+ que se replican mutuamente. Escribimos sobre la exportación programada y Cloud Sync a Google Drive parte por separado, y la comparación de VMM gratuito frente a VMM Pro explica qué componentes necesitan la licencia.

Si ejecuta Docker directamente en DSM, utilice snapshots inmutables

No todo el mundo quiere una capa de máquina virtual. Si sus contenedores se ejecutan en el host, la defensa contra el ransomware C3RB3R son las instantáneas inmutables. Actívelas en Snapshot Replication para la carpeta compartida que contiene los datos de sus contenedores. Necesitan DSM 7.2 o posterior y un volumen Btrfs, y durante el período de bloqueo nadie puede eliminarlas, incluida una cuenta de administrador de la que se haya apoderado el atacante. Dos detalles marcan la diferencia:

• Use montajes bind en una carpeta compartida como por ejemplo /volume1/docker/app. Los volúmenes con nombre de Docker residen bajo /volume1/@docker, que no es una carpeta compartida y no se puede incluir en instantáneas en absoluto.
• Volquee las bases de datos a un archivo antes de la instantánea. Una instantánea de un MariaDB en ejecución es una copia tras un corte de energía. Una programación de mysqldump en la misma carpeta compartida le proporciona un punto de restauración limpio que la instantánea luego bloquea.
• Elija un periodo de bloqueo más largo del que un atacante pueda permanecer en silencio. La víctima anterior tuvo una puerta trasera durante 37 días antes de que comenzara el cifrado. Siete días de instantáneas inmutables no habrían permitido regresar a un estado limpio.

Nuestra capa adicional: Active Insight toma una instantánea cuando comienza el cifrado

Esta es la capa que la mayoría de las guías pasan por alto. Active Insight, el servicio de monitorización en la nube de Synology, puede vigilar la actividad de los archivos en sus carpetas compartidas y, una vez que determina que se trata de un ransomware, reacciona por sí mismo. Synology lo documenta en su guía de seguridad de NAS: cuando se detecta un evento de ransomware, Active Insight envía una notificación del evento y toma automáticamente una instantánea de la carpeta compartida; en los modelos compatibles, dicha instantánea es inmutable.

Por qué esto es especialmente importante para el ransomware C3RB3R: el cifrador del ransomware C3RB3R es lento. La víctima con más de 50 TB apenas iba por sus fotos de 2024 cuando se dio cuenta. Una instantánea tomada cuando aparece por primera vez el patrón de cifrado congela todo lo que aún no se ha tocado, lo que puede ser la mayor parte del volumen. Tampoco le importa cómo entró el ransomware C3RB3R, porque supervisa lo que sucede con los archivos, no la página de inicio de sesión. En nuestro DS1621xs+, la página de Actividad de archivos muestra la protección contra ransomware como Protegido.

Lea las limitaciones antes de confiar en esta función. Proceden de la documentación de Actividad de archivos:

• La monitorización de la actividad de archivos está desactivada por defecto. Registre el NAS para Active Insight en el Panel de control y, a continuación, habilite la monitorización para cada host en el portal de Active Insight.
• Requiere Snapshot Replication, DSM 7.2 o posterior, Active Insight 3.0.2 o posterior, al menos 1 GB de memoria y una licencia de Active Insight asignada a ese NAS.
• Como máximo una instantánea automática por carpeta compartida al día. Es una red de seguridad que se toma tras la detección, no un sustituto de las instantáneas inmutables programadas.
• No cubierto: Carpetas de grabación de Surveillance Station y carpetas compartidas en unidades USB externas.
• La inmutabilidad depende del modelo. En un modelo sin instantáneas inmutables, un atacante con acceso root aún puede eliminar la instantánea automática, así que compagínela con la programación inmutable mencionada anteriormente.

¿Desea la misma configuración? SynoPower Club vende licencias originales para ambos componentes: una licencia de Virtual DSM (VDSM) para ejecutar sus servicios de Docker en un invitado aislado, y una Licencia VMM Pro para planes de protección, replicación entre NAS y migración en vivo. Las claves se envían por correo electrónico.

Dónde encontrar más recursos oficiales

El ransomware C3RB3R en Synology lleva dos días público en el momento de escribir esto, y aún no hay cobertura en vídeo oficial, por lo que esta sección enumera fuentes primarias en lugar de guías paso a paso.

• El aviso de seguridad de Synology del 29 de octubre de 2026, que indica a los usuarios con versiones desactualizadas de DSM que actualicen inmediatamente y activen las actualizaciones automáticas, seguido el 30 de octubre por un correo electrónico a los clientes que confirma SA-24:20 como la única vulnerabilidad involucrada.
• Synology-SA-24:20 y Synology-SA-26:13 son las tablas de versiones. Verifique su compilación en Panel de control, luego en Actualizar y restaurar, comparándola con ambas.
• DSM en una máquina virtual de Proxmox VE ejecutando GitLab es el mejor índice de todos los casos conocidos, incluidos los no cubiertos aquí, y la explicación más clara de cuándo el análisis forense de memoria no tiene sentido.
• Los tres hilos de r/synology enlazados arriba, especialmente el informe forense, que incluye los comandos de investigación de disco de solo lectura paso a paso: Bueno, finalmente sucedió.

Lista de comprobación de la propia Synology (30 de octubre de 2026)

El correo electrónico de Synology a los clientes termina con cuatro pasos. Son breves y cada uno de ellos es importante frente al ransomware C3RB3R:

1. Compruebe si hay intrusos. El ransomware C3RB3R deja una persistencia programada, por lo que debe ejecutar un análisis de Consejero de seguridad y, a continuación, buscar en el Programador de tareas scripts que no haya creado y en Usuario y grupo cuentas de administrador que no haya añadido. Si algo parece incorrecto, póngase en contacto con el soporte de Synology.
2. Actualice todo. Instale el DSM más reciente en Panel de control, Actualización y restauración, y luego actualice todos los paquetes en el Centro de paquetes.
3. Active las actualizaciones automáticas en Actualización y restauración, para que las futuras correcciones de seguridad se apliquen tan pronto como se publiquen.
4. Mantenga una copia de seguridad externa. Utilice Hyper Backup y Snapshot Replication para mantener una copia en una ubicación diferente y compruebe periódicamente que las tareas de copia de seguridad se completan realmente.

El primer paso es el que la gente suele omitir. Si su equipo era accesible desde Internet antes de la solución de diciembre de 2024, es posible que el ransomware C3RB3R ya haya afianzado su presencia, y actualizar hoy no le dirá si alguien ya está dentro.

Una herramienta gratuita que realiza la comprobación por usted

Si se siente cómodo con una terminal, el primer paso ahora puede ser un solo comando. synology-nas-cli es una herramienta de línea de comandos de código abierto bajo la licencia MIT, lanzada el 30 de octubre de 2026 por el desarrollador independiente Akari Sora. Inicia sesión en DSM a través de su API web y audita el equipo frente a esta campaña. El proyecto está en GitHub: akari-sora/synology-nas-cli.

Leímos su código antes de enlazarlo. Utiliza únicamente la biblioteca estándar de Python y no se comunica con nada excepto con su NAS, el servidor de descargas de Synology, PyPI y el conjunto de herramientas de rescate soimy. No envía telemetría y la auditoría básica es solo de lectura. Esto es lo que comprueba:

• Nivel de parche. Su compilación de DSM frente a Synology-SA-26:13, que también cubre la solución anterior SA-24:20, y sus paquetes instalados frente a SA-26:14.
• Exposición. QuickConnect, reenvío de puertos UPnP en el enrutador, el cortafuegos de DSM, AutoBlock, SMB1 y la cuenta de administrador integrada.
• Rastros del ransomware C3RB3R. Las cadenas de inicio de sesión inyectadas en el registro de conexiones, /etc/cron.d/synot* entradas, los libgld y qnetd binarios, cuentas de root adicionales, claves SSH y notas de rescate en sus carpetas compartidas.
• Instantáneas. Carpetas compartidas que no tienen una programación de instantáneas activa.

También puede solucionar la mayor parte de lo que encuentre. Si los archivos se están cifrando en este momento, su comando contain congela el cifrador con SIGSTOP, el mismo paso que la segunda fase de nuestra lista de primera respuesta. Luego, su comando rescue ejecuta el conjunto de herramientas soimy para capturar la memoria y buscar la clave.

nas incident                 # auditoría de solo lectura

nas incident --deep # buscar también el implante (un script root de solo lectura)

• nas incident fix --dry-run # listar cada cambio que haría, sin cambiar nada. Lea estas notas antes de permitir que cambie nada:.
• Es completamente nuevo. El proyecto tiene pocos días, proviene de un solo desarrollador, no está afiliado a Synology y ha tenido poca revisión externa. Comience con la auditoría de solo lectura y la prueba simulada (dry run).
• La corrección del cortafuegos puede dejarle sin acceso. Cambia el cortafuegos de DSM para denegar todo excepto las redes que liste. Ejecútelo desde un ordenador en la misma LAN y sepa dónde está el botón RESET.
• Desactiva QuickConnect. Esa es la configuración más segura, pero si su familia accede a Synology Photos o a Surveillance Station a través de QuickConnect, configure primero una VPN o Tailscale.
• El escaneo profundo, contain y rescue se ejecutan como root. Funcionan a través de una tarea temporal del Programador de tareas, porque es la única forma de leer registros exclusivos de root y congelar procesos.
• El README sugiere delegarlo a un agente de IA. Si lo hace, mantenga la contraseña en un gestor de contraseñas en lugar de en el chat y confirme la corrección usted mismo.

Para completar el panorama de fortalecimiento de la seguridad, nuestras guías sobre cómo ejecutar un sitio web público en un NAS Synology y sobre lo que Threat Prevention puede y no puede ver cubren la parte de la red, y la guía de parches de PHP2Shell cubre el otro problema crítico que surgió la misma semana.

Límites y notas de seguridad del ransomware C3RB3R

Actualizar no elimina una infección existente. Al menos una víctima descubrió que la persistencia en cron seguía activa tras actualizar al último DSM. Si estuvo expuesto mientras no tenía el parche instalado, verifique /etc/cron.d, el Programador de tareas, los scripts de inicio y los servicios habilitados como telnet, y luego cambie todas las credenciales.

Estar actualizado no es lo mismo que estar limpio. Una víctima en Reddit creía que su DSM estaba actualizado y otra sufrió el ataque a pesar de tener 2FA y una contraseña segura activadas. Un equipo vulnerado antes de ser parcheado puede conservar la infección a través de todas las actualizaciones posteriores. Trate cualquier página de inicio de sesión de DSM accesible desde Internet como un objetivo, incluidas las publicadas por UPnP que nunca configuró deliberadamente. Utilice una VPN o Tailscale para el acceso remoto y desactive UPnP en el enrutador.

RAID y las copias de seguridad locales no son copias de seguridad frente al ransomware C3RB3R. Cualquier elemento en el que el DSM comprometido pueda escribir será cifrado, incluidos los destinos de Hyper Backup en el mismo equipo y las carpetas compartidas de red montadas.

No pague antes de leer los casos. Pagar a los operadores del ransomware C3RB3R financia la siguiente ola y no garantiza nada. Si el cifrador aún se está ejecutando, la vía de la memoria libre es su mejor oportunidad. Si no es así, la única alternativa real son sus propias copias externas fuera del equipo.

Tenga cuidado con lo que pega en un asistente de IA. Las herramientas de IA ayudaron a varias víctimas aquí, pero no les facilite contraseñas, claves recuperadas, volcados de memoria completos ni datos de la empresa. Deje que sugieran comandos y ejecute usted mismo cualquier cosa que requiera permisos de root.

El hardware no oficial o clonado conlleva un riesgo adicional. Varias víctimas documentadas ejecutaban DSM en hardware no oficial, donde las actualizaciones oficiales son difíciles o imposibles de aplicar. Si esta es su configuración, asuma que no tiene los parches e impida por completo su acceso a Internet.

Referencias

• Aviso de seguridad de Synology sobre ataques de ransomware en DSM, 29 de octubre de 2026.
• Synology-SA-24:20 DSM (Pwn2Own 2024), CVE-2024-10441 y las compilaciones corregidas de DSM.
• Synology-SA-26:13 DSM, CVE-2026-13639 y CVE-2026-13684, publicado el 18 de septiembre de 2026.
• Rescate de hardware físico frente al ransomware C3RB3R de Benjamin-zlt, el formato de archivo, la disposición de claves y el flujo de trabajo de SIGSTOP.
• El rescate de memoria solo funciona mientras el cifrador esté activo., Se aplica la misma regla que en los tres casos de GitHub.
• IT-Connect sobre la campaña de C3RB3R, resumiendo la atribución 360 y la cronología.
• Centro de conocimiento de Synology: cómo mejorar la seguridad de su Synology NAS, incluido cómo Active Insight toma una instantánea de una carpeta compartida cuando detecta ransomware.

Preguntas frecuentes

Haga que el próximo ataque de ransomware C3RB3R solo le cueste una restauración, no un rescate. Ejecute sus servicios Docker dentro de Virtual DSM y proteja todo el sistema invitado con planes de protección de VMM Pro, replicados en un segundo NAS. SynoPower Club vende licencias originales para ambos, con claves entregadas por correo electrónico.