Es raro que un fabricante de software le pida a sus clientes apagar sus servidores. Kiteworks lo hizo este fin de semana. El jueves 25 de septiembre de 2026, la empresa de transferencia segura de archivos avisó que había recibido de autoridades federales de Estados Unidos información creíble de que un ataque contra sistemas Kiteworks podía ser inminente ese fin de semana, y recomendó apagar los servidores durante una ventana preventiva.
El domingo 27 levantó la recomendación. No hubo, según la propia empresa, evidencia de compromiso.
Parece una historia que terminó bien. Pero deja una pregunta que conviene hacerse en cualquier empresa: si mañana un proveedor crítico te pide apagar algo durante seis horas, ¿sabrías hacerlo?
Qué pasó, en orden
| Fecha (2026) | Qué ocurrió |
|---|---|
| Jueves 25 sep | Kiteworks avisa directamente a sus clientes: inteligencia "creíble" de autoridades de EE. UU. sobre un posible ataque ese fin de semana |
| Sábado 26 sep | Ventana de apagado recomendada: 02:00 a 08:00 UTC (viernes 20:00 a sábado 02:00 en el centro de México) |
| Domingo 27 sep | Kiteworks levanta la recomendación para todos los clientes y dice que restauró los sistemas que hospeda |
El aviso aplicaba a los servidores que administra el cliente: instalados en sitio o en su propia cuenta de AWS o Azure. Los clientes con servicio hospedado por Kiteworks no tenían que hacer nada; la empresa apagó y restauró esos equipos por su cuenta.
Hay una discrepancia entre fuentes: BleepingComputer y TechCrunch reportan la ventana de seis horas que aparece en el correo del director general, Jonathan Yaron; The Hacker News habla de nueve horas. Lo que coincide en todas es que fue preventivo, de un fin de semana y ya se levantó. Kiteworks no dijo qué agencia le compartió la información.
La empresa recomienda estar en la versión 9.5.1, que según su director de seguridad, Frank Balonis, corrige todas las vulnerabilidades conocidas.
Por qué estas plataformas atraen ataques
Kiteworks es el sucesor de Accellion, cuya plataforma de transferencia de archivos (FTA) fue explotada en 2020 y 2021 por la banda de extorsión Clop con varias fallas de día cero. El mismo grupo repitió la receta con GoAnywhere MFT, MOVEit Transfer y Cleo.
La lógica es simple: estas herramientas existen para que la empresa comparta archivos delicados —contratos, estados financieros, expedientes, planos— con gente de fuera. Por eso están publicadas en internet y guardan justo lo que sirve para extorsionar. Un solo hueco da acceso a los archivos de muchas víctimas a la vez.
En una PyME mexicana el equivalente rara vez se llama Kiteworks. Suele ser un servidor de archivos con acceso web, un Nextcloud o un FTP que se abrió "para que el contador suba los papeles", o el portal de un proveedor de nómina. Mismo perfil de riesgo, menos vigilancia.
La lección útil: el apagado preventivo
Ayer escribimos sobre Citrix NetScaler, donde las fallas se explotaron antes del parche. En casos así, la única defensa del primer día es desconectar. Kiteworks lo pidió antes del ataque, lo cual es mejor, pero exige lo mismo del cliente: poder apagar un sistema de un momento a otro, un viernes en la noche, sin romper la operación.
Eso casi nunca está resuelto. Las preguntas que conviene contestar hoy, con calma:
- ¿Qué tenemos expuesto a internet? Servidores de archivos, VPN, correo propio, el ERP publicado, cámaras, el conmutador. Si nadie tiene la lista, ese es el primer pendiente.
- ¿Qué depende de cada uno? Si apagas el servidor de archivos, ¿se detiene la facturación, el envío de estados de cuenta, la recepción de órdenes de compra?
- ¿Quién puede decidir un apagado fuera de horario? Y cómo se le localiza un viernes a las 8 de la noche.
- ¿Quién lo ejecuta? Si el servidor lo administra un proveedor, ¿está en el contrato que responde en fin de semana? Revisa tu contrato de soporte y su SLA.
- ¿Cómo avisamos a clientes y proveedores? Un texto preparado ahorra una hora de redacción nerviosa.
- ¿Cuál es el plan B para lo urgente? Por ejemplo, compartir un archivo puntual desde la nube corporativa con liga que caduca.
- ¿Cómo volvemos? Encender, verificar versión, revisar registros de la ventana y confirmar que todo funciona.
Todo eso cabe en una hoja dentro del plan de continuidad del negocio. Si todavía no tienes uno, la plantilla de plan de recuperación ante desastres es un buen punto de partida.
Qué hacer esta semana
- Haz la lista de servicios expuestos a internet y quién los administra. Una hoja de cálculo basta.
- Suscríbete a los avisos de seguridad de los fabricantes de esos servicios, con un correo que alguien lea (no el del exempleado).
- Define quién autoriza un apagado urgente y déjalo por escrito con teléfonos.
- Pregunta a tus proveedores críticos —nube, ERP, nómina, soporte remoto— cómo te avisarían de algo así y en cuánto tiempo. Si la respuesta es "le mandamos un correo", es momento de acordar algo mejor. Casos como el de ScreenConnect muestran que las herramientas de terceros también son puerta de entrada.
- Cierra lo que no se usa. El FTP que se abrió para una auditoría hace tres años no necesita seguir en internet.
El caso Kiteworks salió bien porque hubo aviso, la empresa actuó rápido y los clientes pudieron apagar. La próxima vez puede no haber aviso previo. Lo que sí depende de ti es tener listo el procedimiento.
