El pestillo de la puerta de un baño está ahí para que quien va a entrar sepa que hay alguien dentro. Cualquiera que empuje fuerte entra igual, y eso no es un defecto del pestillo: es exactamente lo que un pestillo hace.
La casilla «Protected» de los backups de Proxmox es un pestillo. En la interfaz sale un candadito, en la documentación se llama protection, y en la cabeza de mucha gente que sabe lo que hace se ha traducido a «inmutable». No lo es, y la diferencia acaba de dejar de ser académica: hay ransomware que la quita con una sola llamada a la API de Proxmox antes de borrar la copia.
Operamos clusters de Proxmox VE con Ceph en producción y gestionamos copias con Proxmox Backup Server y con Veeam, así que esto nos toca de lleno. Lo que sigue es lo que dice el código de Proxmox cuando lo abres, y qué hacemos nosotros con esa información.
El bicho se ha leído el manual
Halcyon publicó el análisis de una variante Linux de Pay2Key: un binario ELF de 64 bits escrito en C++, detectado por primera vez a finales de agosto de 2025. Lo interesante no es el cifrado (ChaCha20 por fichero, con las claves protegidas con Curve25519), que es lo de siempre. Lo interesante es que no trae herramientas propias para tocar la virtualización: usa las de Proxmox.
- 1Se hace el inventario con
pvesh get /cluster/resources. No escanea: pregunta. - 2Apaga las máquinas con
qm stop <vmid> --skiplocky los contenedores conpct stop <ctid> --skiplock. Con los discos quietos, cifrar es más rápido y más limpio. - 3Quita la protección de las copias:
pvesh set /nodes/<nodo>/storage/<storage>/content/<backup> --protected 0. - 4Y entonces las borra:
pvesh delete /nodes/<nodo>/storage/<storage>/content/<backup>.
Halcyon dice que, de todas las familias de ransomware que siguen, ninguna otra había modificado las protecciones de backup integradas de la plataforma. Ese paso 3 es la novedad. Alguien se sentó a leer la API de Proxmox y encontró la puerta que estaba abierta.
Conviene no saltarse un detalle antes de seguir: esas órdenes salen del propio nodo ya comprometido, y quien ha llegado a apagar máquinas con --skiplock tiene privilegios de sobra para que ninguna comprobación de permisos le pare. La API no está siendo burlada, está siendo usada. Lo que viene a continuación no explica cómo entró el bicho, sino por qué la casilla no iba a detenerlo en ningún caso.
Por qué cede el pestillo: quitarlo cuesta lo mismo que borrar
Aquí es donde merece la pena abrir el código en vez de fiarse del titular. En pve-storage, el fichero src/PVE/API2/Storage/Content.pm define las dos operaciones que nos importan sobre un volumen de backup.
El DELETE lo anuncia claro: «necesitas el privilegio Datastore.Allocate en el almacenamiento (o Datastore.AllocateSpace para volúmenes de backup si tienes VM.Backup en la VM)». El PUT que cambia atributos —el que pone y quita el protected— anuncia algo mucho más suave: «necesitas acceso de lectura al volumen».
Leído así parece un agujero: el candado se abriría con permiso de lectura. Pero la comprobación de verdad la hace check_volume_access, en src/PVE/Storage.pm, y para un volumen de tipo backup con VM propietaria pide Datastore.AllocateSpace en el almacenamiento y VM.Backup en la VM dueña de la copia. Que es, letra por letra, lo que el DELETE comprueba en ese mismo caso.
Ni agujero ni candado. La conclusión es la incómoda de verdad: protected no es una frontera de privilegio. Quitar el pestillo no pide ni un permiso más que borrar la copia, así que quien puede borrarla puede desprotegerla siempre. El pestillo no está pensado para pararle a él; está pensado para pararte a ti.
Un matiz que no conviene saltarse, porque va en la dirección contraria a la que uno esperaría: esto vale para el almacenamiento gobernado desde PVE. Dentro del propio Proxmox Backup Server el reparto es distinto —quitar la protección pide Datastore.Modify, o ser el dueño del grupo con Datastore.Backup; borrar pide Datastore.Modify o ser el dueño con Datastore.Prune—, de modo que un token de solo backup puede abrir el pestillo y quedarse ahí, sin poder borrar nada. El pestillo cae; la puerta, no. Que es justo como debería ser, y la razón de que la recomendación que viene ahora funcione.
Y para eso funciona muy bien. Evita que una política de retención se coma la copia buena, evita el borrado a mano un viernes por la tarde, evita el prune mal calculado. Sigue mereciendo la pena tenerlo puesto en todas las copias que te importen.
En almacenamiento de ficheros, el candado es un fichero al lado
Hay un detalle más, y es el que más nos sorprendió al mirarlo. En los almacenamientos basados en ficheros —directorio, NFS, CIFS— la protección no vive en una base de datos ni en metadatos del sistema de ficheros. Vive en un fichero vecino: protection_file_path devuelve literalmente ${path}.protected, y archive_remove se niega a borrar («cannot remove protected archive») mientras ese fichero exista.
O sea: la protección de la copia está guardada en el mismo sitio y con los mismos permisos que la copia. Quien pueda escribir en ese directorio —el propio host, el root del NAS, cualquiera que monte el recurso NFS— no necesita ni la API. Le basta un rm. Guardar la llave dentro de la caja fuerte es una decisión perfectamente razonable si lo que montas es un pestillo. En PBS no funciona así: la protección la guarda y la aplica el servidor, y el cliente solo puede pedirla por la API. Esa diferencia es media respuesta al problema.
Esto no es un fallo de Proxmox
Conviene decirlo, porque el titular fácil sería el contrario. Proxmox no ha prometido en ningún sitio que protected sea inmutabilidad, no hay CVE que reportar aquí y no hay parche que esperar. La casilla hace lo que dice la documentación que hace. El error de lectura ha sido nuestro, de forma bastante generalizada, y lo curioso es que la documentación de Proxmox Backup Server ya trae la respuesta correcta escrita, en un apartado que se llama Ransomware Protection & Recovery y que casi nadie lee hasta el día después.
Lo que sí es una frontera: permisos que el atacante no tiene
Una frontera de verdad no es una casilla en el mismo lado de la puerta. Es un permiso que las credenciales comprometidas no incluyen. Sobre eso sí se puede construir, y esto es lo que hay que conseguir:
- ✓El cluster no puede borrar nada. El privilegio
Datastore.Backupde PBS, en palabras de su documentación, «permite solo crear, pero no borrar ni alterar backups existentes». Un token con eso y nada más escribe copias y no puede borrar las que ya están. - ✓La retención se ejecuta en el PBS, no en el cliente. Es la recomendación de la documentación de Proxmox: no dar permisos de borrado y hacer el prune con trabajos programados en el propio servidor de backup. Si nadie desde fuera puede borrar, no hace falta un pestillo.
- ✓Un token por cluster, y acotado a su namespace. Proxmox llega a poner el ejemplo de la ruta ACL:
/datastore/tank/pve-abc-cluster. Un cluster comprometido no alcanza los datos de otro. - ✓La sincronización no propaga borrados. Un trabajo de sync se puede configurar para no eliminar en destino lo que ha desaparecido en origen. Es la diferencia entre una copia remota y un espejo de la catástrofe.
- ✓Retención larga y un medio distinto. Proxmox avisa de que hay ransomware que se queda dormido días o semanas antes de cifrar: si tu ventana son 14 días, puedes tener catorce copias del problema. La cinta, además, es el único sitio donde «desconectado» significa desconectado de verdad.
Hay además una propiedad del diseño de PBS que juega a favor y que conviene conocer: no reescribe bloques existentes. Un host de Proxmox comprometido, o cualquier cliente comprometido que use el cliente de backup, no puede corromper ni modificar las copias que ya están dentro. Puede pedir que se borren —si le dejas—, pero no puede cifrarlas por debajo.
La verificación ayuda y no basta (lo dice Proxmox, no nosotros)
Los trabajos de verificación comprueban que los datos siguen cuadrando con los SHA-256 registrados, así que si algo empieza a cifrar copias por dentro, empiezan a fallar. Es una señal buenísima y barata. Pero la documentación de Proxmox añade una frase importante: un ransomware suficientemente avanzado podría eludir este mecanismo, y por tanto la verificación es una medida adicional, no suficiente.
Lo mismo con los avisos: si el origen acaba cifrado, es probable que los trabajos de sincronización fallen y salte la notificación de error. Eso es detección por efecto secundario: llega tarde y solo a veces. Conviene tenerla y conviene no apoyarse en ella.
Lo que NO vamos a decirte
- ✗Que desmarques el «Protected». Sigue puesto. Protege de lo que siempre ha protegido: de nosotros. Y eso pasa mucho más a menudo que un ataque dirigido.
- ✗Que esto sea urgente para todo el mundo. Si tus copias ya salen a un PBS con un token sin permiso de borrado y el prune vive en el servidor, este post te confirma que lo tenías bien y no tienes nada que hacer esta semana.
- ✗Que hace falta comprar algo. Todo lo de la lista de arriba son permisos, un namespace y una casilla en un trabajo de sincronización. Se arregla en una tarde. Somos parte interesada —vendemos backup gestionado— y aun así lo que hay que hacer aquí es gratis.
Las cuatro preguntas que hacemos nosotros
Cuando entramos a revisar un entorno Proxmox ajeno, el bloque de backup se despacha con cuatro preguntas. Las cuatro se responden mirando, no preguntando:
- ?¿Con qué credencial escribe el cluster en el destino de backup, y puede esa credencial borrar? Si la respuesta es «con la de root» o «no lo sé», ya sabes por dónde empezar.
- ?¿Quién ejecuta la retención? Si el prune lo lanza el cliente, el cliente borra.
- ?¿Existe una copia que no se pueda alcanzar desde el cluster? Otro PBS que tira en vez de recibir, cinta, otra ubicación. Si todo se alcanza desde el mismo sitio, hay una copia, no dos.
- ?¿Cuándo se restauró por última vez, y a dónde? Restaurar encima del original no es una prueba, es un segundo incidente.
La cuarta es la que más veces se responde con silencio. Ya escribimos sobre el registro de la propiedad de Rumanía, donde el atacante entró con credenciales válidas y borró lo que alcanzaba: el patrón es siempre el mismo, y lo que salva no es la casilla, es la distancia. Y si estás montando el cluster ahora, el resto de decisiones que tomamos en producción están en nuestro checklist de hardening de Proxmox VE 9.2.
En corto
Pay2Key no ha roto nada de Proxmox. Ha leído la documentación y ha usado la API tal como está publicada, que es bastante más incómodo. La lección es dejar de pedirle al protected algo que nunca prometió: un pestillo y una puerta blindada se parecen mucho hasta el día en que empujan. La puerta blindada, en Proxmox, se llama «un permiso que el cluster no tiene».
Fuentes (verificadas una a una): análisis de la variante Linux de Pay2Key, órdenes de Proxmox utilizadas, ChaCha20/Curve25519 y atribución (FBI, CISA y el DC3 la valoraron como operación de información iraní en agosto de 2024) — Halcyon; permisos de PUT y DELETE sobre /nodes/{node}/storage/{storage}/content/{volume}, función check_volume_access, protection_file_path y archive_remove — código fuente de pve-storage (Content.pm y Storage.pm); Datastore.Backup, prune en servidor, tokens por namespace, sincronización sin propagar borrados, no reescritura de bloques y límites de la verificación — documentación de Proxmox Backup Server 4.2.
¿Sabes si tu cluster puede borrar sus propios backups?
En everyWAN operamos Proxmox VE con Ceph en producción y gestionamos copias con PBS y Veeam, con filosofía 3-2-1. Revisamos permisos, retención y distancia de tus copias, y te decimos también cuando ya lo tienes bien. Mira nuestro servicio de ciberseguridad y de disaster recovery.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN