El teu servidor de còpies és dins del domini que ha de restaurar

El 8 de juny Veeam va publicar la build 12.3.2.4854 de Backup & Replication. Corregia CVE-2026-44963, un 9,4 sobre 10, descrit en una línia: execució de codi al servidor de còpies per part d'«un usuari de domini autenticat». Val la pena llegir-ho dues vegades. No diu administrador. No diu operador de còpies. Diu usuari. I hi ha una conseqüència que no és a l'avís del fabricant, sinó a l'anàlisi que va publicar un mes després una empresa de seguretat aliena: en un servidor en grup de treball, la fallada ni tan sols existeix. Mateix codi, mateixa versió, mateixa màquina. El que canvia és a qui li pregunta el teu servidor de còpies si ets de fiar.

La fallada no és on sembla

La mecànica, segons l'anàlisi tècnica que va publicar SecureLayer7 al juliol, és un clàssic de .NET. El servei Veeam.Backup.Service.exe exposa un extrem de .NET Remoting sobre HTTP al TCP/8000. Tres operacions WCF encadenades acaben lliurant dades a un deserialitzador BinaryFormatter protegit per una llista negra: rebutja les classes perilloses conegudes i confia en tota la resta. Només cal trobar una classe serialitzable que no hi sigui. La cadena documentada passa per subclasses de DataSet, s'aprofita de ReadXmlSchema perquè l'esquema l'escrigui l'atacant i acaba a Process.Start.

Això és el com. El qui és el que importa. Abans de deserialitzar res, el servei comprova que qui fa la crida pertanyi al rol WindowsBuiltInRole.User. En una màquina unida al domini, aquest rol el compleix qualsevol compte del domini: la becària, el comercial, el compte de servei de la impressora. En una màquina en grup de treball només el compleixen els comptes locals, que són els que tu has creat i es compten amb els dits d'una mà.

I aquest qui no és una particularitat d'aquesta fallada: és el patró. A la mateixa nota de Veeam, la frase «execució de codi al servidor de còpies per un usuari de domini autenticat» apareix al març del 2025 (CVE-2025-23120, un 9,9), un altre cop a l'octubre del 2025 i dues vegades més al març del 2026 (CVE-2026-21666 i CVE-2026-21667, tots dos 9,9). El de juny és el sisè de la sèrie en poc més d'un any i, a més, el que puntua més baix. Detall que convé mirar dues vegades: la build que avui figura com a vulnerable, la 12.3.2.4465, era exactament el pedaç del març d'aquells dos. Que la mateixa frase es repeteixi sis vegades no és mala sort del codi. És el que passa quan la frontera d'autorització d'un sistema és la pertinença al domini.

Dos avisos abans de continuar, perquè la resta de l'article s'hi recolza. El primer, i cal dir-ho amb precisió: aquest detall intern —el port, la cadena de classes, el rol que es comprova— prové d'una anàlisi de tercers, no de l'avís de Veeam, que és deliberadament escarit. De fet Veeam sí que marca explícitament algunes de les fallades anteriors com a exclusives de servidors units al domini, i en aquesta no ho fa. Que en grup de treball ni tan sols existeixi ho sosté l'anàlisi externa, no el fabricant. El segon avís: no ens consta que aquest CVE s'estigui explotant allà fora, i no ho insinuarem per fer pressa. L'argument d'aquest post no necessita que l'estiguin explotant.

Ja va passar, a la mateixa peça, fa dos anys

El setembre del 2024, Veeam va corregir CVE-2024-40711: un 9,8 en l'escala d'aleshores (CVSS v3.1, mentre que el 9,4 d'ara és v4.0, així que no són directament comparables), també deserialització de dades no fiables i al mateix servei, en aquell cas sense autenticar. Va publicar l'actualització el 4 de setembre; watchTowr en va treure l'anàlisi el dia 9 i va esperar al 15 per publicar el codi de prova. A l'octubre, l'equip de Sophos X-Ops ja rastrejava almenys quatre atacs de ransomware que el feien servir. Akira i Fog primer, Frag després. El patró que van descriure és el que importa: entraven per passarel·les VPN amb credencials robades i sense segon factor, des d'allà explotaven el servei de Veeam, es creaven un compte local d'administrador i xifraven.

Ningú no va entrar pel servidor de còpies. Van entrar per un altre lloc i van anar a buscar-lo, que és diferent i és deliberat: qui controla les còpies decideix si negocies o no. El mateix que vam veure a l'esborrat del registre de la propietat de Romania, on l'atacant tenia credencials vàlides i es va endur tot el que la seva sessió abastava, còpies incloses. I el mateix que diu l'estadística: a l'informe de ransomware d'enguany, el 79% dels atacs començava en la identitat, no en una vulnerabilitat. És a dir: quan algú arriba fins aquí, gairebé sempre ja té un usuari de domini qualsevol a la mà.

La dependència circular que ningú no dibuixa

Fins aquí és un problema de seguretat. Ara ve la part que converteix això en un problema de recuperació, que és la que gairebé mai no es dibuixa als diagrames.

Diumenge a la tarda. Alguna cosa ha xifrat mitja empresa i els controladors de domini estan compromesos, apagats o totes dues coses. Vas a la consola de còpies, que és exactament per a això que existeix, i et demana un usuari. La resposta a la pregunta «qui ets?» la dona l'Active Directory que acabes de perdre. El sistema que t'ha de tornar el directori necessita el directori per deixar-te entrar.

Siguem precisos, perquè aquí és fàcil exagerar: no és que la màquina no arrenqui. Les credencials en memòria cau solen deixar-te iniciar sessió al servidor. El que es trenca és tota la resta: la resolució de noms, els tiquets Kerberos cap a la resta de components, els comptes de servei amb què el servidor de còpies parla amb els repositoris, els hosts i els agents. No es descobreix al principi de la restauració. Es descobreix a la meitat.

I no és cap descobriment nostre: és a la guia de bones pràctiques de seguretat del mateix fabricant, amb una frase que ho resumeix —un sistema de protecció de dades no hauria de dependre de cap manera de l'entorn que se suposa que protegeix—. La mateixa guia avisa de les dues cares del problema: si l'entorn de producció cau amb els seus controladors de domini, això afecta la teva capacitat de restaurar, perquè el servidor de còpies en depèn per autenticar la consola i per resoldre noms; i qui aconsegueixi privilegis alts en aquest servidor obté, de propina, informació detallada de la infraestructura que protegeix.

És una escala d'evacuació cargolada a la façana de l'edifici del qual t'ha de treure. Funciona perfectament mentre el problema sigui una planta. No quan el que cedeix és l'estructura.

El que costa de debò treure'l del domini

Aquí és on la majoria d'articles escriuen «passa'l a grup de treball» i se'n van a dinar. La recomanació del fabricant té en realitat dos graons, i cap dels dos és de franc:

• Entorns petits: grup de treball. És el més ràpid de muntar i aïlla de debò. A canvi, cada sistema es configura per separat —usuaris, permisos, política de seguretat local—, no hi ha Kerberos, i tot ha de quedar documentat, perquè el que al domini et donaven les polítiques de grup, aquí t'ho has de donar tu. En un parc amb diversos servidors de còpies i diversos operadors, això es torna feixuc de pressa.
• Entorns grans: un domini de gestió en un bosc d'Active Directory separat. Mantens gestió centralitzada, polítiques de grup i compliment, i guanyes una cosa operativa que el grup de treball no et dona: desactivar un compte amb un clic enmig d'un incident. A canvi és infraestructura nova —controladors, còpies, cicle de vida— que cal muntar i mantenir.

I hi ha una conseqüència que no apareix en cap de les dues descripcions i que és la que més feina dona el primer dia: en sortir del domini, totes les connexions cap a producció passen a fer-se amb credencials explícites desades al mateix servidor de còpies —hosts de virtualització, repositoris, comparticions, agents, bases de dades—. Això s'ha d'inventariar abans de tocar res, perquè el que es trenca si te'n descuides una no és la consola: és la feina de les tres de la matinada.

La llista amb què revisem un servidor de còpies

• La build exacta, no «la 12». Estan afectades la 12.3.2.4465 i totes les anteriors de la branca 12; ho corregeix la 12.3.2.4854; cap build 13.x no està afectada, per canvis d'arquitectura.
• Està unit al domini? És la primera pregunta que fem, i decideix la resta.
• Qui arriba al TCP/8000. Aquest port no ha de ser abastable des de tota la xarxa d'usuaris, i molt menys des d'internet. És la diferència entre «qualsevol usuari del domini» i «qualsevol usuari del domini que a més sigui al segment correcte».
• Comptes i segon factor. Quants comptes poden entrar a la consola, qui els coneix i si hi ha MFA. Als atacs del 2024 la porta d'entrada va ser una VPN sense segon factor; el servidor de còpies només va ser la parada següent.
• Immutabilitat del repositori. És l'única cosa que continua dempeus quan tota la resta ha fallat.
• Un camí d'accés que no depengui del directori. Com entres a la consola el dia que el domini no respon: escrit, amb les credencials en un lloc que tampoc no depengui del domini, i provat per algú que no siguis tu.
• Un assaig de restauració amb el domini fora de joc. No el de recuperar un fitxer esborrat: el d'aixecar un controlador de domini quan no en queda cap.

Abans de tocar la topologia

Tres situacions en què no començaríem per treure el servidor del domini:

• Si el repositori encara és mutable. Treure el servidor del domini i deixar les còpies on un administrador compromès les pot esborrar és moure el problema de lloc, no resoldre'l.
• Si ningú no documentarà res. Un grup de treball mal portat acaba en una contrasenya en un calaix i en un servidor sense pedaçar perquè «aquell no és a les polítiques». Això és pitjor que el punt de partida.
• Si el teu servidor de còpies no és Windows ni parla amb Active Directory. Proxmox Backup Server, per exemple, autentica per defecte contra el seu propi àmbit, així que no hereta aquesta dependència; integrar-lo amb LDAP o AD és opcional, i és just aquí on l'heretaria. Operem tots dos, Veeam i PBS, i no som revenedors de cap: això no és «canvia de producte», és «mira de qui depèn el teu».

El pedaç no canvia qui pot fer la crida

Actualitzar és obligatori i no ho discutim: si tens una build de la branca 12 anterior a la 12.3.2.4854, aquesta és la feina d'aquesta setmana. Però convé llegir bé què diu el fabricant. La branca 13 no està afectada per aquesta fallada perquè va canviar l'arquitectura d'aquella part, no perquè hagi deixat d'existir la pregunta de fons: de qui es fia el teu servidor de còpies per saber qui ets? Les fallades de deserialització a .NET fa una dècada que apareixen, i una llista negra sempre va per darrere de la creativitat aliena.

El pedaç tanca un forat. La topologia de confiança decideix quanta gent pot abocar-se al següent. Són dues feines diferents i solem fer només la primera, igual que pedaçar no és netejar: tancar la porta no canvia qui tenia clau.

La pregunta que discrimina

No cal una auditoria per saber a quin costat ets. N'hi ha prou amb una pregunta, i convé fer-la en veu alta a la propera reunió: dilluns al matí, amb el directori caigut, com entres a la consola de còpies?

Si la resposta és «amb el meu usuari de sempre», ja saps de què depèn el teu pla de recuperació. Si la resposta és «no ho hem provat mai», és la mateixa resposta amb millors maneres.

Si vols que mirem com està muntada la teva —de qui depèn la consola, si el repositori aguanta un administrador compromès i què passa exactament el dia que falta el directori—, això és part del que fem a disaster recovery i a còpies gestionades.

Fonts (verificades): les dades de CVE-2026-44963 (puntuació 9,4 en CVSS v4.0; execució de codi al servidor de còpies per un usuari de domini autenticat; afecta la build 12.3.2.4465 i anteriors de la branca 12; corregit a la 12.3.2.4854, publicada el 8 de juny de 2026; cap build 13.x afectada per canvis d'arquitectura) provenen de la KB4696 de Veeam i de la cobertura de The Hacker News del 9 de juny de 2026, que atribueix la troballa a Sina Kheirkhah (watchTowr). La sèrie de fallades anteriors amb la mateixa descripció («execució de codi al servidor de còpies per un usuari de domini autenticat») és a la mateixa KB4696: CVE-2025-23120 (9,9, març del 2025), una altra a l'octubre del 2025 i CVE-2026-21666 i CVE-2026-21667 (tots dos 9,9, corregits a la build 12.3.2.4465 del 12 de març del 2026, que és la que ara consta com a vulnerable). En aquella KB, Veeam marca explícitament algunes d'aquelles fallades com a exclusives de servidors units al domini, però NO ho fa amb la de juny: la immunitat del grup de treball la sosté l'anàlisi externa, no el fabricant. El detall intern —extrem de .NET Remoting al TCP/8000, tres operacions WCF, deserialitzador BinaryFormatter amb llista negra, cadena via subclasses de DataSet i ReadXmlSchema, i comprovació del rol WindowsBuiltInRole.User— prové de l'anàlisi tècnica de SecureLayer7 publicada el 6 de juliol de 2026: és feina de tercers, no de l'avís del fabricant, i així ho hem escrit. La recomanació de grup de treball o domini de gestió en un bosc separat, les seves contrapartides i la frase sobre no dependre de l'entorn que es protegeix són a la guia de bones pràctiques de seguretat de Veeam. Els fets del 2024 (CVE-2024-40711, 9,8; actualització del 4 de setembre; anàlisi de watchTowr el 9 i codi de prova el 15; atacs d'Akira i Fog rastrejats per Sophos X-Ops a l'octubre a través de VPN sense segon factor; Frag després) provenen de BleepingComputer i del blog de Sophos. El 79% d'atacs originats en la identitat és de l'informe The State of Ransomware 2026 de Sophos, que vam analitzar al seu dia. No ens consta explotació pública de CVE-2026-44963 a data de publicació d'aquest article. Fotografia de la imatge social: escala d'evacuació a Rotterdam, de Marek Ślusarczyk (Tupungato), Wikimedia Commons, llicència CC BY 3.0.