El ransomware C3RB3R lleva desde principios de octubre cifrando archivos en NAS Synology que corren versiones viejas de DSM, el sistema operativo de estos equipos de red. Cada archivo tocado termina con la extensión .L0CK3D y cada carpeta recibe una nota llamada read-me3.txt: el rescate arranca en 0,036960 bitcoin, unos US$2.952, y se duplica si pasan cinco días sin pago.
Synology confirmó los ataques el 29 de octubre con un comunicado fechado en Taipéi. La empresa informó que los atacantes explotan una vulnerabilidad corregida en diciembre de 2024 y pidió actualizar DSM de inmediato, con las actualizaciones automáticas activadas. Su equipo PSIRT, el grupo de respuesta a incidentes de seguridad del producto, sigue la campaña y atiende a los afectados desde el Centro de soporte de DSM.
El aviso no nombra al ransomware ni da una cifra de víctimas. Ese hueco lo llenó el equipo antiransomware de 360, firma china de seguridad: sus técnicos recibieron pedidos de ayuda desde principios de octubre y, tras analizar muestras de equipos dañados, las identificaron como C3RB3R, una variante de Cerber, familia con años de historial contra estos equipos.
Dos diagnósticos para una misma puerta de entrada
360 apunta a dos fallos de DSM publicados el 18 de septiembre de 2026: CVE-2026-13639 y CVE-2026-13684, cada uno con nota 9,8 sobre 10. El primero nace de una entropía insuficiente en la lógica de inicio de sesión, que vuelve predecibles las sesiones; el segundo, de una codificación de salida deficiente en SCGI, la interfaz entre el servidor web y los programas internos. Combinados, permiten a un atacante remoto leer o escribir cualquier archivo sin iniciar sesión.
Synology defiende otra ruta. Su comunicado remite al aviso SA-24:20 y a CVE-2024-10441, una ejecución remota de código también con nota 9,8 que Pumpkin Chang y Orange Tsai, de DEVCORE, mostraron en el concurso Pwn2Own 2024. El parche para la rama DSM 6.2 salió el 5 de diciembre de 2024. Y un detalle da fuerza a esta versión: el 25 de octubre apareció en GitHub una explicación pública con prueba de concepto de ese fallo viejo, cuatro días antes de los avisos.
Un correo a clientes del 30 de octubre cerró más la puerta: la campaña usa solo el fallo de SA-24:20 y no guarda relación con PHP2Shell. Un tercer equipo de respuesta, identificado como Solar, complica el cuadro con una víctima que ya corría una versión reciente de la rama 7.4. Su reporte no descarta paquetes añadidos, contenedores ni credenciales robadas, y nadie ha publicado prueba de un fallo de día cero.
El patrón se repite en otras marcas. El ransomware Qilin entró en octubre por una falla de Palo Alto sin corregir: cuando un parche lleva meses publicado y nadie lo aplica, el atacante no necesita inventar nada nuevo. Necesita una lista de equipos viejos y tiempo.
ChaCha8 por archivo y copias que caen con el equipo
La muestra de 360 salta 27 directorios del sistema y varias categorías de archivos. El resto lo recorre carpeta por carpeta: 187 extensiones prioritarias reciben cifrado completo y las demás, cifrado parcial para acortar el trabajo. Cada archivo se cifra con ChaCha8 y una clave propia de 256 bits, envuelta con RSA-2048, un esquema que deja la llave maestra solo en manos del operador.
Junto al archivo cifrado queda una nota con un identificador de seis dígitos y una dirección en la red Tor. En Corea del Sur los casos se empezaron a reportar el 28 de octubre y KISA, la Agencia de Internet y Seguridad de Corea, recibió avisos de usuarios con fotos y documentos bloqueados, sin publicar la escala del daño. Las copias guardadas en el mismo NAS se cifran con todo lo demás, y no existe descifrador público para esta variante.
Versiones de DSM que cierran los fallos de septiembre
Para los dos fallos de 360, las versiones corregidas son DSM 7.4-90075, 7.3.2-86009-4, 7.2.2-72806-9 y 7.2.1-69057-12. La comparación pide leer la compilación completa, dígito final incluido: un equipo en 7.2.2-72806-1 trae el parche de 2024 y le falta el de septiembre. El aviso SA-26:13 agrupa ocho vulnerabilidades y no lista medida temporal alguna: la actualización es la única salida para esa ruta.
PHP2Shell queda como problema aparte, y serio. Sus dos fallos, CVE-2026-109618 y CVE-2026-109619, también con nota 9,8, permiten ejecutar código sin credenciales en paquetes como Web Station, WordPress, Joomla o Mail Station; PHP 7.3 no recibe arreglo por estar fuera de soporte y Mail Station pide actualización manual desde el Centro de paquetes. Synology afirma que por ahí no entra C3RB3R, pero un NAS expuesto necesita ese parche igual.
La revisión que pide Synology toma diez minutos: pasar el Asesor de seguridad, buscar en el Programador de tareas trabajos que el dueño no creó y revisar en Usuario y grupo si apareció una cuenta de administrador desconocida. Si algo de eso aparece, la orden de la empresa es contactar a Soporte y no intentar la limpieza por cuenta propia. Después toca lo que más se pospone: actualizar DSM y cada paquete, sacar la pantalla de inicio de sesión de internet y guardar una copia fuera del equipo con Hyper Backup o Snapshot Replication, comprobando que la tarea termina.
El dato que falta: nadie ha publicado cuántos equipos cayeron, y mientras 360 y Synology discuten la puerta de entrada, los NAS sin actualizar siguen visibles en la red con el rescate fijado en bitcoin.
Fuente: TechAeris
