Las cinco puertas de SafePay: ninguna es de 2026

Seis organismos de tres países publicaron ayer un aviso conjunto sobre el grupo de ransomware SafePay: al menos 600 víctimas desde agosto de 2024. Dentro del documento hay una lista de cinco vulnerabilidades que estos atacantes explotan, y esa lista dice algo que no dice el titular: no hay ningún día cero, ningún sistema operativo y ninguna vulnerabilidad de 2026. Hay tres cortafuegos y dos servidores de copias. La puerta más nueva cumplió dos años hace unas semanas.

Quién firma el aviso

El documento es el AA26-293A, publicado el 20 de octubre de 2026 dentro de la serie #StopRansomware. Lo firman el FBI, CISA y el Servicio Secreto de Estados Unidos junto con la Landeskriminalamt de Renania-Palatinado en Alemania, y la National Crime Agency y la North West Regional Organised Crime Unit en el Reino Unido. Cuando seis organismos de tres países se ponen de acuerdo para firmar lo mismo, el papeleo tarda; que haya salido ahora quiere decir que el material lleva meses acumulándose.

Las cifras: el grupo lleva activo desde agosto de 2024 y el aviso habla de al menos 600 víctimas distintas, repartidas por Norteamérica, Sudamérica, Europa y Australia, en varios sectores de infraestructura crítica. Roban datos, cifran y amenazan con publicar. Y hay un detalle operativo que conviene retener para el final: después del cifrado, alguien llama por teléfono en nombre del grupo.

Conviene leer con precisión cómo introduce el aviso la lista de vulnerabilidades, porque cambia el orden de los factores: dice que estos atacantes usan «perfiles de cuenta obtenidos por phishing para acceder a las redes de las víctimas y explotar los siguientes CVE conocidos de productos de borde». Es decir, las cinco puertas no son el primer paso: son el que convierte el robo de una credencial en un cifrado. Eso no las hace menos importantes, las coloca en su sitio —y, de paso, adelanta la conclusión de este post, que va menos de parches de lo que parece.

Las cinco puertas, con fecha

Esta es la lista del aviso, ordenada por antigüedad. La columna que importa es la última.

Tres aparatos de perímetro y dos veces el mismo servidor de copias. Ni Windows, ni Linux, ni un navegador, ni una aplicación de negocio. Si tu plan de defensa contra el ransomware consiste en un antivirus en cada puesto y la actualización mensual de Windows, ninguna de estas cinco puertas está dentro de tu plan.

Tres de las cinco están en el aparato que deja entrar

Las tres de perímetro no son la misma cosa, y leídas en orden cuentan una secuencia entera. CVE-2020-3259 deja leer memoria del aparato sin autenticarse; lo que sale de ahí son credenciales y trozos de sesión. CISA la metió en su catálogo de fallos explotados en febrero de 2024, asociada a otro grupo de ransomware. CVE-2023-20269 permite probar usuarios y contraseñas contra el perfil de conexión por defecto de la VPN de acceso remoto: no entra sola, pero convierte en útil lo que la anterior sacó. CVE-2024-40766 es la más reciente de las tres y afecta tanto a la interfaz de gestión como al servicio SSLVPN en tres generaciones de cortafuegos.

Y aquí está lo que nos parece la lección más cara de las tres, porque no va de parches: el parche cierra el agujero, no cierra la sesión. El propio fabricante del tercero publicó junto al arreglo una instrucción que casi nadie ejecutó —cambiar las contraseñas de los usuarios locales con acceso SSLVPN después de actualizar— y un año más tarde tuvo que aclarar que la oleada de ataques que se le atribuía no venía de un fallo nuevo, sino del uso de credenciales robadas antes del parche, muchas de ellas arrastradas de una generación de aparato a la siguiente en una migración. Si una vulnerabilidad de divulgación de información ha estado abierta en tu casa, lo que se llevaron no caduca al actualizar el firmware. Caduca cuando rotas las credenciales.

Las otras dos están en el sistema que tenía que salvarte

Que el servidor de copias aparezca dos veces en una lista de cinco no es casualidad estadística, y la pareja es muy elocuente. CVE-2024-40711 es la que sale en los titulares: deserialización insegura, ejecución de código sin credenciales, 9,8 de nota. Afecta a la versión 12.1.2.172 y a todas las anteriores de la rama 12, y se corrigió en la 12.2 (build 12.2.0.334). Pero la que explica por qué van ahí es la otra, la de 2023: CVE-2023-27532 no ejecuta nada, simplemente saca las credenciales (cifradas) guardadas en la base de configuración a quien alcance el servicio desde la red de la infraestructura de copias. Se arregló en marzo de 2023, en las builds 12.0.0.1420 P20230223 y 11.0.1.1261 P20230227.

Dicho de otra manera: el servidor de copias es, por diseño, un llavero. Para hacer su trabajo guarda credenciales del hipervisor, del almacenamiento, del repositorio, del dominio y de la mitad de las máquinas que respalda. No es un objetivo más dentro del parque: es el único sitio donde todas esas llaves están juntas en un solo sitio y con permisos administrativos. Quien lo alcanza no necesita moverse por la red probando cosas, porque ya tiene el inventario y las llaves. Esto lo contamos con más detalle en su momento: el servidor de copias dentro del dominio es una dependencia circular.

No borran la copia: devuelven el NAS a fábrica

Este es el detalle del aviso que más nos ha hecho pensar y que casi no hemos visto citado en la cobertura. La versión que todos repetimos es «el ransomware borra las copias». Lo que describe el aviso es otra cosa: paran el servicio de instantáneas de volumen y restablecen los dispositivos NAS a sus valores de fábrica.

La diferencia no es de matiz. Borrar ficheros deja rastro, tarda y se puede interrumpir: un borrado masivo dispara alertas, y en muchos repositorios la retención o la inmutabilidad lo impiden. Un restablecimiento de fábrica es una operación legítima del panel de administración del aparato, tarda segundos y se lleva por delante las copias, la configuración de los trabajos, las reglas de retención y los propios registros del NAS en el mismo gesto. No estás restaurando desde un repositorio dañado: estás delante de un aparato que ha vuelto al estado en el que salió de la caja, y que ya no sabe que alguna vez fue tu repositorio de copias.

La consecuencia de diseño es incómoda y es la tesis de este post: una copia que se puede destruir desde un panel de administración al que el atacante llega con credenciales válidas no es una copia aparte. Es la misma copia, en otra caja. La regla 3-2-1 no habla de cajas, habla de que una de esas copias esté fuera del alcance de quien controla tu red: inmutable de verdad —con la inmutabilidad en el repositorio, no en una casilla del trabajo— o desconectada, o en un sitio cuyo panel no comparte identidades con tu dominio.

Lo que usan dentro ya estaba instalado

El inventario de herramientas del aviso tampoco tiene nada exótico: ShareFinder.ps1 y SharpShares.exe para encontrar recursos compartidos, WinRAR y 7-Zip para empaquetar, Rclone y FileZilla para sacar los datos, PsExec y WinRM para ejecutar en otras máquinas, AnyDesk y TeamViewer para el acceso remoto, Mimikatz para las credenciales. Dos terceras partes de esa lista están instaladas ahora mismo, con licencia y con motivo, en la mayoría de empresas que conocemos.

Por eso el fichero no es la señal. La señal es el contexto: AnyDesk apareciendo en un servidor donde nunca estuvo, Rclone hablando con un almacenamiento en la nube que no es el vuestro, PsExec saliendo de un puesto que no es el del administrador, a las tres de la madrugada de un sábado. Eso no lo contesta un listado de aplicaciones permitidas; lo contesta algo que mire el comportamiento y alguien que esté despierto para responder, que es la parte que vendemos como EDR/MDR gestionado y la que, honestamente, es más difícil de sostener con el equipo de dentro.

Cuándo NO parchear mañana a primera hora

La reacción natural a un aviso así es decir «parcheamos el cortafuegos mañana». Nosotros, que vivimos de esto, vamos a decir lo contrario, y es la razón por la que estas cinco puertas llevan años abiertas en tanta gente: actualizar un cortafuegos en horario de oficina es, en sí mismo, un incidente. Corta todas las sesiones VPN, deja fuera a quien esté teletrabajando, y si la actualización sale regular pierdes el acceso remoto al aparato que da el acceso remoto. Lo mismo con el servidor de copias: subir una rama mayor un viernes con los trabajos corriendo es cómo se rompen las cadenas de respaldo.

Lo que no vale es salir de esa conversación sin fecha. La diferencia entre una empresa que no parchea y una que parchea despacio es que la segunda sale de la reunión con cuatro cosas escritas: ventana concreta, quién está delante del aparato, cómo se vuelve atrás y quién confirma al día siguiente que el servicio hace lo que hacía. Lo que sí se puede hacer esta misma tarde y no necesita ventana es todo lo demás —quitar la gestión de la cara de internet, exigir doble factor, rotar credenciales locales, mirar quién alcanza el servidor de copias—, y es justo lo que la mayoría deja para cuando llegue el parche.

Las ocho comprobaciones

Esto es lo que recorremos nosotros cuando sale un aviso de este tipo. Las cinco primeras se contestan en una tarde; las tres últimas son las que deciden cómo acaba el mal día.

1. Qué versión corre el cortafuegos, y desde cuándo. La versión exacta al lado de la versión corregida del aviso del fabricante, y la fecha de la última actualización. Si esa fecha tiene más de un año, el resto de la lista importa el doble.
2. ¿Contesta la interfaz de gestión desde internet? Compruébalo desde fuera, con una conexión que no sea la de la oficina, no sobre el papel de la configuración. La gestión expuesta es lo que convierte un fallo de control de acceso en una entrada.
3. ¿Se rotaron las credenciales locales DESPUÉS del último parche? Y muy en particular: si cambiasteis de generación de aparato y migrasteis los usuarios locales, esas contraseñas vienen de antes del arreglo. Esta es la casilla que explica buena parte de los incidentes recientes.
4. Doble factor en VPN y en correo web, con la lista de excepciones delante. Siempre hay excepciones —el proveedor, el comercial del móvil viejo, la cuenta de servicio—. No pasa nada por tenerlas; pasa por no saber cuántas son. Escríbelas y ponles fecha de caducidad.
5. La build exacta del servidor de copias y quién llega a él. No «la 12», la build. Y después: desde qué redes se alcanza su servicio, qué cuentas pueden iniciar sesión en él y si es miembro del mismo dominio que está respaldando.
6. El panel del NAS o del repositorio. ¿Se administra con cuentas del dominio? ¿Tiene segundo factor? ¿Puede alguien, desde ese panel, destruir la retención en un clic? Si las respuestas son sí, no y sí, tu segunda copia es la primera copia con otro nombre.
7. Una copia que no dependa de ningún panel alcanzable. Inmutable en el repositorio o desconectada. La pregunta de control no es «¿tenemos copias inmutables?», es «¿quién, con qué credenciales, puede dejar de tenerlas?».
8. Restaurar algo de verdad, y cronometrarlo. No comprobar que el trabajo salió en verde: levantar un servicio y mirar el reloj. Nuestro último simulacro de recuperación completa fue de 14 minutos; es un dato nuestro y una prueba, no una promesa para tu caso. El valor no está en el número, está en que sabemos cuál es.

Y si suena el teléfono

Volvamos al detalle del principio, porque es el que no está en ningún plan técnico: después de cifrar, llaman. No llaman al administrador de sistemas —ése ya sabe lo que pasa—, llaman a quien conteste. Y quien contesta suele ser alguien de administración o de recepción, un miércoles por la mañana, sin un guion y sin saber que esa llamada es parte del ataque. Un plan de continuidad que no incluye dos líneas sobre quién habla, quién no habla y a quién se avisa primero está incompleto por el lado barato.

Y conviene recordar el orden correcto: recuperar los datos no es haber echado al atacante. Si entraron por una credencial de VPN que sigue siendo válida, restaurar te devuelve el servicio y les devuelve el objetivo. Le dedicamos un post entero a esa distinción: recuperar rápido no es echar al atacante.

Lo que de verdad falló aquí

No fue la sofisticación del atacante. Las cinco puertas tenían parche —todas, desde hace entre dos y más de seis años— y los tres fabricantes publicaron su aviso a tiempo. Lo que falló es un hueco de proceso que vemos en casi todas las empresas por las que pasamos: hay cadencia para Windows porque existe el martes de parches y existe una herramienta que lo hace; hay cadencia para Microsoft 365 porque no la decides tú. Para el cortafuegos y el servidor de copias no hay cadencia: hay «cuando haya ventana». Y son exactamente los dos aparatos que nombra el aviso, justamente porque son los dos que no se pueden reiniciar en horario de oficina.

No somos resellers de ninguna marca de cortafuegos ni de copias, así que podemos decirlo sin conflicto: esto no se arregla comprando nada. Se arregla con un mantenimiento que tenga escrito qué aparatos hay, qué versión corren, quién es el dueño de cada uno y cuándo le toca ventana —incluidos los dos que nadie quiere tocar— y con la parte de continuidad que decide, antes del mal día, qué copia no puede destruir nadie desde ningún panel. Lo que sí vendemos es hacerlo nosotros cuando el equipo de dentro está a otra cosa.

La pregunta con la que cerramos no es si estás parcheado, porque esa se contesta con un «creo que sí». Es ésta: si alguien entra hoy con las credenciales de tu administrador de copias, ¿qué copia te queda mañana? Si para responder tienes que preguntarle a alguien, ya tienes media respuesta.

Fuentes y método: la fecha del aviso, los organismos firmantes, la cifra de «al menos 600 víctimas», el periodo desde agosto de 2024, la lista de los cinco CVE explotados, el inventario de herramientas (ShareFinder.ps1, SharpShares.exe, WinRAR, 7-Zip, Rclone, FileZilla, PsExec, WinRM, AnyDesk, TeamViewer, Mimikatz), la parada del servicio de instantáneas de volumen, el restablecimiento de los NAS a valores de fábrica, la llamada telefónica a la víctima y las mitigaciones recomendadas salen del aviso conjunto AA26-293A, #StopRansomware: SafePay Ransomware, publicado por CISA el 20 de octubre de 2026 y consultado ese mismo día. Las versiones corregidas de Veeam Backup & Replication proceden de los boletines del fabricante KB4424 (CVE-2023-27532: builds 12.0.0.1420 P20230223 y 11.0.1.1261 P20230227) y KB4649 (CVE-2024-40711: afecta a 12.1.2.172 y anteriores de la rama 12, corregido en la build 12.2.0.334). Los detalles de CVE-2024-40766 —alcance en Gen 5, 6 y 7, gestión y SSLVPN, aviso SNWLID-2024-0015— y la recomendación de cambiar las contraseñas de los usuarios locales tras actualizar, del aviso de SonicWall sobre la actividad reciente contra SSLVPN, que es también donde el fabricante aclara que la oleada posterior se apoyaba en credenciales comprometidas antes del parche; la lectura de que el parche no rota las credenciales está desarrollada en el diario del SANS Internet Storm Center sobre ese mismo CVE, citado como fuente secundaria. CVE-2020-3259 y CVE-2023-20269 están descritos según los avisos de seguridad de Cisco para ASA y FTD; las versiones corregidas van por rama y hay que mirarlas en el aviso correspondiente, por eso no las reproducimos aquí. No tenemos telemetría propia sobre SafePay ni hemos atendido ningún incidente de este grupo: todo lo atribuido al atacante procede del aviso. El dato de los 14 minutos es nuestro, de un simulacro interno de recuperación completa, y se da como prueba realizada, no como compromiso de servicio. Lo que es nuestro aquí es la lectura —que las cinco puertas son todas anteriores a 2025, que tres están en el perímetro y dos en el llavero de las copias, que un restablecimiento de fábrica no es un borrado, y que el hueco está en la cadencia de parcheo de los dos aparatos que no se pueden reiniciar en horario de oficina— y las ocho comprobaciones, que son de cosecha propia. Las traducciones de los términos citados son nuestras.