Tu servidor de copias está dentro del dominio que tiene que restaurar

El 8 de junio Veeam publicó la build 12.3.2.4854 de Backup & Replication. Corregía CVE-2026-44963, un 9,4 sobre 10, descrito en una línea: ejecución de código en el servidor de copias por parte de «un usuario de dominio autenticado». Merece leerse dos veces. No dice administrador. No dice operador de copias. Dice usuario. Y hay una consecuencia que no está en el aviso del fabricante, sino en el análisis que publicó un mes después una empresa de seguridad ajena: en un servidor en grupo de trabajo, el fallo no llega a existir. Mismo código, misma versión, misma máquina. Lo que cambia es a quién le pregunta tu servidor de copias si eres de fiar.

El fallo no está donde parece

La mecánica, según el análisis técnico que publicó SecureLayer7 en julio, es un clásico de .NET. El servicio Veeam.Backup.Service.exe expone un extremo de .NET Remoting sobre HTTP en el TCP/8000. Tres operaciones WCF encadenadas acaban entregando datos a un deserializador BinaryFormatter protegido por una lista negra: rechaza las clases peligrosas conocidas y confía en todo lo demás. Basta con encontrar una clase serializable que no esté en la lista. La cadena documentada pasa por subclases de DataSet, se apoya en ReadXmlSchema para que el esquema lo escriba el atacante y termina en Process.Start.

Eso es el cómo. El quién es lo que importa. Antes de deserializar nada, el servicio comprueba que quien hace la llamada pertenezca al rol WindowsBuiltInRole.User. En una máquina unida al dominio, ese rol lo cumple cualquier cuenta del dominio: la becaria, el comercial, la cuenta de servicio de la impresora. En una máquina en grupo de trabajo solo lo cumplen las cuentas locales, que son las que tú has creado y se cuentan con los dedos de una mano.

Y ese quién no es una particularidad de este fallo: es el patrón. En la misma nota de Veeam, la frase «ejecución de código en el servidor de copias por un usuario de dominio autenticado» aparece en marzo de 2025 (CVE-2025-23120, un 9,9), otra vez en octubre de 2025 y dos veces más en marzo de 2026 (CVE-2026-21666 y CVE-2026-21667, ambos 9,9). El de junio es el sexto de la serie en poco más de un año, y además el que menos puntúa. Detalle que conviene mirar dos veces: la build que hoy figura como vulnerable, la 12.3.2.4465, era exactamente el parche de marzo de esos dos. Que la misma frase se repita seis veces no es mala suerte del código. Es lo que ocurre cuando la frontera de autorización de un sistema es la pertenencia al dominio.

Dos avisos antes de seguir, porque el resto del artículo se apoya en ellos. El primero, y hay que decirlo con precisión: ese detalle interno —el puerto, la cadena de clases, el rol que se comprueba— procede de un análisis de terceros, no del aviso de Veeam, que es deliberadamente escueto. De hecho Veeam sí marca explícitamente algunos de los fallos anteriores como exclusivos de servidores unidos al dominio, y en este no lo hace. Lo de que en grupo de trabajo no llega a existir lo sostiene el análisis externo, no el fabricante. El segundo aviso: no nos consta que este CVE se esté explotando ahí fuera, y no vamos a insinuarlo para meter prisa. El argumento de este post no necesita que lo estén explotando.

Ya pasó, en la misma pieza, hace dos años

En septiembre de 2024, Veeam corrigió CVE-2024-40711: un 9,8 en la escala de entonces (CVSS v3.1, mientras que el 9,4 de ahora es v4.0, así que no son directamente comparables), también deserialización de datos no confiables y en el mismo servicio, en aquel caso sin autenticar. Publicó la actualización el 4 de septiembre; watchTowr sacó el análisis el día 9 y esperó al 15 para publicar el código de prueba. En octubre, el equipo de Sophos X-Ops ya rastreaba al menos cuatro ataques de ransomware que lo usaban. Akira y Fog primero, Frag después. El patrón que describieron es el que importa: entraban por pasarelas VPN con credenciales robadas y sin segundo factor, desde ahí explotaban el servicio de Veeam, se creaban una cuenta local de administrador y cifraban.

Nadie entró por el servidor de copias. Entraron por otro sitio y fueron a buscarlo, que es distinto y es deliberado: quien controla las copias decide si negocias o no. Lo mismo que vimos en el borrado del registro de la propiedad de Rumanía, donde el atacante tenía credenciales válidas y se llevó por delante todo lo que su sesión alcanzaba, copias incluidas. Y lo mismo que dice la estadística: en el informe de ransomware de este año, el 79% de los ataques empezaba en la identidad, no en una vulnerabilidad. Es decir: cuando alguien llega hasta aquí, casi siempre ya tiene un usuario de dominio cualquiera en la mano.

La dependencia circular que nadie dibuja

Hasta aquí es un problema de seguridad. Ahora viene la parte que convierte esto en un problema de recuperación, que es la que casi nunca se dibuja en los diagramas.

Domingo por la tarde. Algo ha cifrado media empresa y los controladores de dominio están comprometidos, apagados o los dos. Vas a la consola de copias, que es exactamente para lo que existe, y te pide un usuario. La respuesta a la pregunta «¿quién eres?» la da el Active Directory que acabas de perder. El sistema que tiene que devolverte el directorio necesita el directorio para dejarte entrar.

Seamos precisos, porque aquí es fácil exagerar: no es que la máquina no arranque. Las credenciales en caché suelen dejarte iniciar sesión en el servidor. Lo que se rompe es todo lo demás: la resolución de nombres, los tíquets Kerberos hacia el resto de componentes, las cuentas de servicio con las que el servidor de copias habla con los repositorios, los hosts y los agentes. No se descubre al principio de la restauración. Se descubre a la mitad.

Y no es un descubrimiento nuestro: está en la guía de buenas prácticas de seguridad del propio fabricante, con una frase que lo resume —un sistema de protección de datos no debería depender en modo alguno del entorno que se supone que protege—. La misma guía avisa de las dos caras del problema: si el entorno de producción cae con sus controladores de dominio, eso afecta a tu capacidad de restaurar, porque el servidor de copias depende de ellos para autenticar la consola y para resolver nombres; y quien consiga privilegios altos en ese servidor obtiene, de propina, información detallada de la infraestructura que protege.

Es una escalera de evacuación atornillada a la fachada del edificio del que tiene que sacarte. Funciona perfectamente mientras el problema sea una planta. No cuando lo que cede es la estructura.

Lo que cuesta de verdad sacarlo del dominio

Aquí es donde la mayoría de artículos escriben «pásalo a grupo de trabajo» y se van a comer. La recomendación del fabricante tiene en realidad dos escalones, y ninguno es gratis:

• Entornos pequeños: grupo de trabajo. Es lo más rápido de montar y aísla de verdad. A cambio, cada sistema se configura por separado —usuarios, permisos, política de seguridad local—, no hay Kerberos, y todo tiene que quedar documentado, porque lo que en el dominio te daban las políticas de grupo aquí te lo tienes que dar tú. En un parque con varios servidores de copias y varios operadores, esto se vuelve pesado deprisa.
• Entornos grandes: un dominio de gestión en un bosque de Active Directory separado. Mantienes gestión centralizada, políticas de grupo y cumplimiento, y ganas algo operativo que el grupo de trabajo no te da: desactivar una cuenta de un clic en mitad de un incidente. A cambio es infraestructura nueva —controladores, respaldo, ciclo de vida— que hay que montar y mantener.

Y hay una consecuencia que no aparece en ninguna de las dos descripciones y que es la que más trabajo da el primer día: al salir del dominio, todas las conexiones hacia producción pasan a hacerse con credenciales explícitas guardadas en el propio servidor de copias —hosts de virtualización, repositorios, comparticiones, agentes, bases de datos—. Eso hay que inventariarlo antes de tocar nada, porque lo que se rompe si te olvidas de una no es la consola: es el trabajo de las tres de la madrugada.

La lista con la que revisamos un servidor de copias

• La build exacta, no «la 12». Están afectadas la 12.3.2.4465 y todas las anteriores de la rama 12; lo corrige la 12.3.2.4854; ninguna build 13.x está afectada, por cambios de arquitectura.
• ¿Está unido al dominio? Es la primera pregunta que hacemos, y decide el resto.
• Quién llega al TCP/8000. Ese puerto no tiene por qué ser alcanzable desde toda la red de usuarios, y desde luego no desde internet. Es la diferencia entre «cualquier usuario del dominio» y «cualquier usuario del dominio que además esté en el segmento correcto».
• Cuentas y segundo factor. Cuántas cuentas pueden entrar en la consola, quién las conoce y si hay MFA. En los ataques de 2024 la puerta de entrada fue una VPN sin segundo factor; el servidor de copias solo fue la parada siguiente.
• Inmutabilidad del repositorio. Es lo único que sigue en pie cuando todo lo anterior ha fallado.
• Un camino de acceso que no dependa del directorio. Cómo entras en la consola el día que el dominio no responde: escrito, con las credenciales en un sitio que tampoco dependa del dominio, y probado por alguien que no seas tú.
• Un ensayo de restauración con el dominio fuera de juego. No el de recuperar un fichero borrado: el de levantar un controlador de dominio cuando no queda ningún controlador de dominio.

Antes de tocar la topología

Tres situaciones en las que no empezaríamos por sacar el servidor del dominio:

• Si el repositorio todavía es mutable. Sacar el servidor del dominio y dejar las copias donde un administrador comprometido puede borrarlas es mover el problema de sitio, no resolverlo.
• Si nadie va a documentar nada. Un grupo de trabajo mal llevado acaba en una contraseña en un cajón y en un servidor sin parchear porque «ese no está en las políticas». Eso es peor que el punto de partida.
• Si tu servidor de copias no es Windows ni habla con Active Directory. Proxmox Backup Server, por ejemplo, autentica por defecto contra su propio ámbito, así que no hereda esta dependencia; integrarlo con LDAP o AD es opcional, y es justo ahí donde la heredaría. Operamos los dos, Veeam y PBS, y no somos revendedores de ninguno: esto no es «cámbiate de producto», es «mira de quién depende el tuyo».

El parche no cambia quién puede llamar

Actualizar es obligatorio y no lo discutimos: si tienes una build de la rama 12 anterior a la 12.3.2.4854, ese es el trabajo de esta semana. Pero conviene leer bien lo que dice el fabricante. La rama 13 no está afectada por este fallo porque cambió la arquitectura de esa parte, no porque haya dejado de existir la pregunta de fondo: ¿de quién se fía tu servidor de copias para saber quién eres? Los fallos de deserialización en .NET llevan una década apareciendo, y una lista negra siempre va por detrás de la creatividad ajena.

El parche cierra un agujero. La topología de confianza decide cuánta gente puede asomarse al siguiente. Son dos trabajos distintos y solemos hacer solo el primero, igual que parchear no es limpiar: cerrar la puerta no cambia quién tenía llave.

La pregunta que discrimina

No hace falta una auditoría para saber en qué lado estás. Basta con una pregunta, y conviene hacerla en voz alta en la próxima reunión: el lunes por la mañana, con el directorio caído, ¿cómo entras en la consola de copias?

Si la respuesta es «con mi usuario de siempre», ya sabes de qué depende tu plan de recuperación. Si la respuesta es «no lo hemos probado nunca», es la misma respuesta con mejores modales.

Si quieres que miremos cómo está montada la tuya —de quién depende la consola, si el repositorio aguanta a un administrador comprometido y qué pasa exactamente el día que falta el directorio—, eso es parte de lo que hacemos en disaster recovery y en copias gestionadas.

Fuentes (verificadas): los datos de CVE-2026-44963 (puntuación 9,4 en CVSS v4.0; ejecución de código en el servidor de copias por un usuario de dominio autenticado; afecta a la build 12.3.2.4465 y anteriores de la rama 12; corregido en la 12.3.2.4854, publicada el 8 de junio de 2026; ninguna build 13.x afectada por cambios de arquitectura) proceden de la KB4696 de Veeam y de la cobertura de The Hacker News del 9 de junio de 2026, que atribuye el hallazgo a Sina Kheirkhah (watchTowr). La serie de fallos anteriores con la misma descripción («ejecución de código en el servidor de copias por un usuario de dominio autenticado») está en esa misma KB4696: CVE-2025-23120 (9,9, marzo de 2025), otro en octubre de 2025 y CVE-2026-21666 y CVE-2026-21667 (ambos 9,9, corregidos en la build 12.3.2.4465 del 12 de marzo de 2026, que es la que ahora consta como vulnerable). En esa KB, Veeam marca explícitamente algunos de esos fallos como exclusivos de servidores unidos al dominio, pero NO lo hace en el de junio: la inmunidad del grupo de trabajo la sostiene el análisis externo, no el fabricante. El detalle interno —extremo de .NET Remoting en TCP/8000, tres operaciones WCF, deserializador BinaryFormatter con lista negra, cadena vía subclases de DataSet y ReadXmlSchema, y comprobación del rol WindowsBuiltInRole.User— procede del análisis técnico de SecureLayer7 publicado el 6 de julio de 2026: es trabajo de terceros, no del aviso del fabricante, y así lo hemos escrito. La recomendación de grupo de trabajo o dominio de gestión en un bosque separado, sus contrapartidas y la frase sobre no depender del entorno que se protege están en la guía de buenas prácticas de seguridad de Veeam. Los hechos de 2024 (CVE-2024-40711, 9,8; actualización del 4 de septiembre; análisis de watchTowr el 9 y código de prueba el 15; ataques de Akira y Fog rastreados por Sophos X-Ops en octubre a través de VPN sin segundo factor; Frag después) proceden de BleepingComputer y del blog de Sophos. El 79% de ataques originados en la identidad es del informe The State of Ransomware 2026 de Sophos, que analizamos en su día. No nos consta explotación pública de CVE-2026-44963 a fecha de publicación de este artículo. Fotografía de la imagen social: escalera de evacuación en Róterdam, de Marek Ślusarczyk (Tupungato), Wikimedia Commons, licencia CC BY 3.0.