El aviso que recibieron los clientes de Kiteworks el viernes 25 de septiembre no pedía parchear. Pedía apagar. Y con eso el problema salió del departamento de sistemas: nadie de guardia tiene autoridad para dejar a la empresa sin el canal por el que entra la documentación de clientes durante toda una mañana de sábado.
Kiteworks es una plataforma de transferencia segura de ficheros: el sitio por el que muchas empresas mueven documentación con clientes, aseguradoras, hospitales o administraciones. Su CISO, Frank Balonis, escribió a los clientes que habían recibido «inteligencia de amenazas creíble de las fuerzas del orden que indica que un ataque a los sistemas de Kiteworks puede ser inminente este fin de semana» (traducción nuestra). En una declaración posterior añadió que no le constaba ningún compromiso y que la medida se tomaba «por exceso de precaución». La nota de prensa de la compañía, ese mismo día, lo atribuyó a «autoridades federales de inteligencia».
Seis horas en el correo, nueve en la nota de prensa
Merece la pena detenerse aquí, porque las dos cifras circulan mezcladas. El correo a clientes, que publicó primero el medio alemán Heise, decía literalmente: «recomendamos encarecidamente que apagues tu sistema Kiteworks durante seis horas» (traducción nuestra), con la ventana ajustada a cada huso: de 4:00 a 10:00 del sábado en Europa central, de las 22:00 del viernes a las 4:00 del sábado en Nueva York. La nota de prensa pública que la compañía colgó en su web ese mismo día hablaba de «una ventana de apagado preventivo de nueve horas este fin de semana, en su zona horaria local».
El ajuste por husos horarios explica que las horas absolutas sean distintas en cada país; no explica que la duración cambie. Los investigadores de Sophos, que vieron los reportes ese mismo día, describieron la ventana como «de 02:00 a 08:00 UTC del 26 de septiembre, si no antes»: seis horas otra vez. Tres de las cuatro fuentes dicen seis; la que dice nueve es la pública. No es una cifra inventada por nadie, pero sí es la que llegó a los titulares, y no es la que tuvo que ejecutar quien estaba al otro lado.
El resto del aviso sí es unívoco, y es la parte que importa para tu plan:
- →Alcanzaba a las instalaciones autogestionadas —en local, en AWS y en Azure— y también a las alojadas por la propia compañía, donde el cliente no tenía que hacer nada. Y se pedía apagar aunque el sistema no fuera accesible desde internet, que es tanto como decir que no había forma de acotarlo por exposición.
- →No había CVE, ni parche, ni indicadores de compromiso publicados. La compañía remitía a su versión al día —«todas las vulnerabilidades conocidas están corregidas en la versión actual 9.5.1»—, que es otra forma de decir que no había nada conocido que aplicar.
- →Kiteworks declaró que no tenía indicios de que sus sistemas ni los de sus clientes estuvieran comprometidos, y que el aviso era «preventivo, no una respuesta a una brecha confirmada» (traducción nuestra). El 27 de septiembre levantó la recomendación para todos los clientes.
Un detalle más, que explica por qué el mercado se tomó en serio un correo sin CVE: Kiteworks se llamaba antes Accellion, y la plataforma de transferencia de ficheros de Accellion fue una de las que se llevaron por delante campañas de extorsión masiva. El sector ya sabe cómo termina esa película, y por eso miles de empresas apagaron por un correo de un viernes.
Alguien tiene que firmarlo, y ese alguien no es el de guardia
Un aviso de parchear se resuelve en la ventana de mantenimiento y lo firma quien lleva la plataforma. Con uno de apagar, la cadena se improvisa: el técnico llama al responsable de IT, el responsable de IT busca a dirección, dirección pregunta cuánto riesgo hay de verdad, y la única respuesta honesta disponible es «no lo sabemos, no hay CVE». A esa hora ya se ha perdido media ventana.
Jake Knott, de la firma de seguridad watchTowr, lo resumió en Computer Weekly: «No hay CVE conocido, ni parche, ni detalles técnicos adicionales disponibles; pero nadie pide a toda su base de clientes que desenchufe sistemas de producción durante el fin de semana por una intuición» (traducción nuestra). Las dos mitades de la frase son verdad al mismo tiempo: la información era insuficiente para evaluar y suficiente para preocupar.
Quien sí firmó fue Balonis, y lo puso por escrito el 28 de septiembre, cuando ya había pasado todo: «Decir a los clientes que desconecten sistemas de producción no es una decisión que ningún fabricante tome a la ligera, y sabíamos exactamente lo que les estábamos pidiendo […] Volveríamos a tomar la misma decisión mañana» (traducción nuestra). Es la frase de alguien que tenía la autoridad clara antes de necesitarla. Esa es toda la diferencia, y no se compra: se escribe en frío. No la lista de acciones —eso ya lo tienes en el plan de continuidad que probablemente nadie ha ensayado—, sino las tres líneas anteriores a las acciones: con qué calidad de información aceptamos parar, quién lo autoriza y a quién se avisa. Escritas un martes cualquiera, evitan la discusión del sábado.
En agosto contamos el reverso de esta misma moneda: a tus servidores los puede apagar alguien con quien no has firmado nada, cuando un fallo en el centro de datos de un proveedor de tu proveedor retira máquinas de servicio sin preguntarte. Aquí el botón lo tienes tú y lo pulsas voluntariamente. La incomodidad es la contraria y el vacío de gobierno es el mismo.
Las horas apagado tienen un agujero, y lo rellenan tus usuarios
Esta parte no aparece en ninguna de las notas, y es la que más nos preocuparía si el aviso llegara a un cliente nuestro mañana. Cuando apagas la plataforma por la que se intercambian ficheros, el trabajo que dependía de ella sigue en pie. Si hay una entrega comprometida para el lunes, alguien va a enviar ese fichero igualmente, y lo va a enviar por donde pueda: su cuenta personal de correo, un servicio gratuito de transferencia, un pendrive. Has contenido un riesgo hipotético y has abierto uno real del que además no queda registro en ningún sitio.
Un apagado preventivo bien hecho incluye el canal sustituto, y lo incluye por escrito y con nombre: cuál es, quién lo autoriza, qué límite de tamaño y de sensibilidad tiene, si va cifrado, dónde queda el registro y cuándo se borra lo que se subió ahí. Parece burocracia hasta que la alternativa aparece en la bandeja personal de alguien. Y si la respuesta honesta es «no tenemos otro canal», eso también es un resultado del ejercicio, y cambia la conversación: pasa de seguridad a diseño.
Apagar tiene procedimiento; encender, más
Operamos Proxmox VE con Ceph en producción y llevamos copias con Proxmox Backup Server y Veeam, así que esta parte la decimos desde el teclado. Seguir un aviso como el de Kiteworks significa entrar en el appliance y apagarlo desde dentro, y ahí hay tres cosas que muerden en una parada de fin de semana no ensayada.
- 1La alta disponibilidad hace su trabajo, y su trabajo es el contrario del tuyo. Si paras la máquina desde el propio Proxmox —
qm stopo el botón de la interfaz—, el estado solicitado pasa astoppedy no hay sorpresa. Si la apagas desde dentro del sistema invitado, que es justo lo que pide un aviso de fabricante, el gestor ve un servicio en estadostartedque ha dejado de correr y lo vuelve a levantar. Antes de entrar:ha-manager set vm:100 --state stopped. - 2La copia de esa madrugada se ejecuta igual. Copiar una máquina parada es lo más consistente que hay a nivel de disco; el problema es de aplicación, cuando el servicio se detuvo a medias dentro de una máquina que sigue viva. Y hay un efecto de segundo orden que se olvida: un fin de semana entero de copias de un sistema apagado empuja fuera de retención los puntos buenos. Se decide antes: o se desactiva esa noche, o se etiqueta.
- 3La monitorización va a gritar, y con razón. Sin un mantenimiento declarado en Zabbix (o en lo que uses) antes de parar, la guardia recibe decenas de avisos de un incidente que provocaste tú. Y ojo con el detalle: en Zabbix el mantenimiento suprime el problema, pero las notificaciones solo callan si la acción tiene marcado «Pause operations for suppressed problems».
Y el arranque es donde aparece el inventario real de dependencias. Nadie descubre que la aplicación necesitaba la base de datos treinta segundos antes hasta que levanta los dos servicios a la vez un domingo. Si vas a parar por precaución, el orden de vuelta es tan parte del procedimiento como el de ida, y la manera barata de aprenderlo es con una máquina que no duela.
Qué encontraron dentro de la ventana
El final de la historia es lo que menos se ha contado. Durante el fin de semana, trabajando con las autoridades, Kiteworks encontró y corrigió una vulnerabilidad crítica que antes no se conocía. Según lo publicado el 29 de septiembre, estaba «confinada a una capacidad que está habilitada en menos del 1 % de la base de clientes», no hay evidencia de que se haya explotado nunca con fines maliciosos y, a esa fecha, no tenía CVE asignado.
Es fácil leer ese dato como una crítica: más del 99 % de los clientes paró producción por algo que no les tocaba. Nosotros lo leemos al revés. En el momento de decidir, nadie —ni el fabricante— podía separar al 1 % del resto, porque la granularidad llega siempre después del hallazgo. Lo que el caso demuestra es que las decisiones de continuidad se toman con información incompleta, y que el plan que solo funciona cuando sabes qué está pasando sirve para poco.
Hay además una asimetría que ya medimos en otro caso y que aquí salió bien por poco: parar es rápido, volver no lo es. Hace dos semanas escribimos sobre un intermediario que tardó 101 minutos en desconectar a un proveedor y nueve días en reconectarlo. Kiteworks levantó su recomendación en dos días. La próxima vez que alguien te pida apagar «unas horas», la pregunta útil no es cuántas: es quién decide que ya se puede volver, y con qué comprobación.
La página que le falta a tu plan
Todo esto cabe en una página y sale de una reunión de una hora, siempre que dentro esté la gente que puede decidir. Para cada plataforma de la que dependes de verdad, la hoja tiene que responder a cuatro cosas, y ninguna de ellas es técnica.
Quién. Nombre y suplente, y hasta cuántas horas puede firmar sin subir un nivel. «Lo decidiríamos entre todos» no es una respuesta; el sábado significa que no decide nadie.
Con qué. Qué evidencia basta: ¿un correo del fabricante sin CVE? ¿un aviso de un CERT? ¿solo con indicadores? Escrito antes, porque el criterio improvisado acaba siendo el del que está más nervioso.
Por dónde se trabaja mientras. El canal sustituto autorizado, con su límite y su registro, y quién avisa a los clientes de que durante esas horas el sitio de siempre no responde. Si no lo dices tú, lo interpretan ellos.
Qué se mira al volver. Un apagado contiene, pero no investiga: si había algo dentro, sigue dentro cuando enciendes. Revisar accesos, cuentas nuevas y tareas programadas antes de abrir el servicio al mundo es la mitad del procedimiento que casi nunca se escribe.
Lo que no afirmamos
- ✗No sabemos si el fallo que encontraron es el que temía la inteligencia. Nadie lo ha afirmado públicamente; la propia compañía no ha dado detalles técnicos del fallo. Los dos hechos coinciden en el tiempo y eso no prueba que sean el mismo.
- ✗No hubo brecha confirmada. La compañía declaró que no tenía indicios de compromiso ni en sus sistemas ni en los de sus clientes, y su monitorización durante la ventana no mostró actividad anómala. Este post no habla de un ataque, sino de cómo se decide.
- ✗Tampoco decimos que apagar sea la respuesta correcta por defecto. En la mayoría de los avisos no lo es. Lo que defendemos es que la decisión esté escrita antes de que llegue el correo, y que incluya cómo se trabaja mientras.
Fuentes (verificadas el 30 de septiembre de 2026): la ventana de nueve horas en zona horaria local, el alcance (on-premises, AWS y Azure, más las instancias alojadas), la referencia a la versión 9.5.1 y la declaración de que no hay indicios de compromiso — Kiteworks, «Precautionary Shutdown Advisory», 25 de septiembre de 2026; las seis horas del correo a clientes, las ventanas por huso horario, la petición de apagar también los sistemas no accesibles desde internet y el crédito a Heise como primer medio en publicarlo — BleepingComputer, 25 de septiembre de 2026; la cita del CISO Frank Balonis en el correo, su declaración posterior, la frase de Jake Knott (watchTowr), el periodo de seis horas del sábado 26 y el anterior nombre de la compañía — Computer Weekly, 25 de septiembre de 2026; la ventana de 02:00 a 08:00 UTC del 26 de septiembre y la recomendación del Counter Threat Unit de seguir la guía del fabricante — Sophos; la restauración de los sistemas, la ausencia de actividad anómala durante la ventana y las citas de Balonis del 28 de septiembre — Kiteworks, 28 de septiembre de 2026; el hallazgo y la corrección durante la ventana, el «menos del 1 % de la base de clientes», la ausencia de evidencia de explotación y de CVE asignado, y el levantamiento de la recomendación el 27 de septiembre — The Hacker News, 29 de septiembre de 2026; el comportamiento del gestor de alta disponibilidad — documentación de Proxmox VE.
¿Quién firmaría en tu empresa una parada de seis horas?
Nos sentamos una hora con quien decide y con quien opera, y salimos con esa hoja escrita para tus plataformas críticas. Si hace falta, después la probamos con una de verdad, que es cuando aparecen las dependencias que nadie recordaba. Es disaster recovery y, para la parte de qué se revisa al encender, ciberseguridad.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN