El incidente que ConnectWise confirmó el 17 de octubre de 2026 no empezó con un correo de phishing ni con la contraseña débil de un empleado. Empezó con una credencial de aplicación que tenía permiso para entrar, en nombre propio, a los tenants de Microsoft 365 de sus clientes. Nadie escribió una contraseña. Nadie aprobó un MFA. La puerta estaba abierta porque alguien, en algún momento, la dejó abierta a propósito: para que los respaldos funcionaran solos.
Esa es la lección incómoda de la semana. La conversación pública sobre seguridad sigue centrada en el usuario descuidado, cuando los incidentes con mayor alcance se están moviendo a otro lugar: las identidades de máquina, los proveedores y los permisos que se otorgan una vez y se olvidan para siempre.
Lo que pasó, en orden
ConnectWise confirmó que actores desconocidos obtuvieron acceso a identidades de aplicación asociadas a Cloud Backup —el servicio que la compañía adquirió con SkyKick— y a Cloud Management. Con esas credenciales, los atacantes pudieron autenticarse contra Microsoft Entra ID como principales de servicio y alcanzar datos de clientes en Exchange Online, SharePoint, Teams y el directorio.
La respuesta fue contundente y, para los clientes, dolorosa: la empresa desactivó siete conexiones de aplicación, revocó los certificados asociados y suspendió el servicio de respaldo. Los respaldos programados dejaron de correr y el acceso a restauraciones quedó caído. ConnectWise sostiene que los archivos de respaldo existentes permanecen cifrados y aislados, y que hasta ahora no hay evidencia de que hayan sido expuestos.
Las siete conexiones desactivadas cubren prácticamente toda la superficie de colaboración de Microsoft: Cloud Backup, Cloud Management, Teams, Exchange Online, Microsoft Graph, Partner Center y SharePoint Online. No es una lista de conveniencia: es el mapa de todo lo que un proveedor de respaldos necesita tocar para hacer su trabajo. Y ese es exactamente el problema.
El MFA no falló: nunca fue el control
Cuando se conoce un incidente de este tipo, la primera reacción suele ser preguntar si los clientes tenían autenticación multifactor. La pregunta está mal planteada. El MFA protege a las personas cuando inician sesión. Una identidad de aplicación no inicia sesión: se presenta con un secreto o un certificado y recibe un token. No hay teléfono que aprobar, no hay número que marcar, no hay “¿eres tú?”.
En términos prácticos, el atacante no necesitó robar la contraseña de nadie. Le bastó con la credencial de la aplicación para pedir tokens y operar como un servicio legítimo. Desde el punto de vista de Entra ID, el tráfico era válido: aplicación conocida, permiso concedido, token emitido. El fraude, si acaso, estaba en la intención, no en la forma.
“Deshabilitar las conexiones afectadas evita nueva autenticación a través de ellas; no revierte los cambios que ya se hicieron dentro de un tenant.” — ConnectWise, 17 de octubre de 2026.
Esa frase es la más importante de todo el comunicado. Significa que apagar la llave no cierra lo que ya se abrió. Cualquier regla de reenvío creada, cualquier permiso añadido, cualquier consentimiento otorgado durante la ventana de exposición sigue ahí hasta que alguien lo busque y lo elimine. La revocación es el inicio de la investigación, no el final.
La economía de la llave maestra
Hay una razón por la que los atacantes están apuntando a proveedores de servicios gestionados y a plataformas de respaldo: el retorno. Comprometer a un cliente requiere esfuerzo individual. Comprometer a un proveedor que administra a cientos de clientes convierte ese esfuerzo en una operación con economías de escala. Una credencial, muchos tenants.
El modelo de confianza delegada es el que hace posible que las PYMES tengan correo corporativo, respaldos y soporte sin contratar un departamento de TI. También es el que concentra el riesgo. Cuando un proveedor pide permisos de aplicación sobre el tenant completo, está pidiendo algo equivalente a la llave del edificio, no la de una oficina. La mayoría de las veces la necesita de verdad. El problema es que casi nadie la revisa después.
Los indicadores que circularon tras el incidente apuntan a un patrón conocido: autenticaciones de servicio con user-agents de scripting —del tipo python-requests o python-urllib— y salidas hacia direcciones fuera de los rangos habituales de la nube de Microsoft. No son pruebas forenses definitivas, pero son el tipo de señal que un tablero de identidad bien configurado debería poder mostrar sin que nadie tenga que pedirlo.
Lo que sabemos y lo que todavía no
A estas alturas conviene separar hechos de inferencias. Es un hecho que hubo acceso no autorizado a identidades de aplicación, que se desactivaron siete conexiones, que se revocaron certificados y que el servicio de respaldo está suspendido. También es un hecho que la empresa afirma no haber encontrado evidencia de exposición de los archivos de respaldo.
No sabemos cuántos tenants se vieron afectados, durante cuánto tiempo estuvo activo el acceso, ni si hubo exfiltración de correo o documentos. Tampoco sabemos si los clientes afectados recibieron notificación individual o si tendrán que averiguarlo por su cuenta. “Sin evidencia” no es lo mismo que “sin impacto”: es una declaración sobre lo que se ha podido observar, no sobre lo que ocurrió.
Para una empresa, la conclusión práctica no depende de resolver esas incógnitas. Depende de asumir que su proveedor pudo haber sido el vector y de revisar su propio tenant como si lo hubiera sido.
El patrón de la semana: el perímetro se mudó al proveedor
El incidente de ConnectWise no está solo. En los mismos días, el paquete imgdecode de npm apareció con un cargador de shellcode escondido en un complemento nativo de Windows, acumulando cientos de descargas antes de ser retirado; Drupal parcheó dos vulnerabilidades críticas de ejecución remota de código en Field UI y en el módulo Entity List, con la advertencia expresa de que los exploits podrían aparecer en cuestión de horas; y Ledger confirmó que dispositivos vendidos por un revendedor llevaban un chip alterado que vació carteras.
Tres industrias, tres vectores, una misma lógica: el ataque no entra por donde la empresa mira, sino por donde confía. Un paquete que se instala con una línea de comandos. Un módulo que se actualiza cada trimestre. Un proveedor que administra el correo. La superficie de ataque ya no es la red: es la lista de proveedores y dependencias que nadie audita porque “ya funcionaban”.
Qué significa esto para una PYME mexicana
La mayoría de las empresas pequeñas y medianas de la región no compran ConnectWise directamente. Compran a un integrador local, a un despacho contable con área de sistemas o a un proveedor que les administra el correo y el respaldo. El riesgo no desaparece en esa cadena: se hereda. Si el proveedor tiene acceso delegado y el proveedor del proveedor tiene una credencial comprometida, la PYME está expuesta sin haber tomado una sola decisión técnica al respecto.
A eso se suma una costumbre muy nuestra: la operación por WhatsApp. Credenciales que se comparten en un chat, accesos que se piden “de urgencia” y se quedan, respaldos que se configuran una vez y nadie vuelve a mirar. No es negligencia; es la forma en que se resuelve cuando no hay equipo. Pero es precisamente el terreno donde este tipo de incidentes crece.
La buena noticia es que las medidas que más reducen el riesgo no requieren presupuesto nuevo. Requieren inventario, preguntas incómodas y la disciplina de revisar lo que ya está conectado.
Cuatro acciones para esta semana
El cierre que importa
La industria va a discutir durante semanas si ConnectWise reaccionó rápido o tarde, si el alcance fue mayor de lo reconocido y qué responsabilidad le toca al proveedor. Es una discusión necesaria, pero no es la que te va a proteger el lunes.
Lo que sí puedes hacer es cambiar la pregunta. En lugar de “¿mi proveedor es confiable?”, pregunta “¿qué puede hacer mi proveedor si algo sale mal, y cómo me entero?”. Esa diferencia —entre confianza y verificación— es la única que separa a una empresa que delega de una empresa que simplemente no sabe lo que delegó.
La seguridad en la nube ya no se gana en el firewall. Se gana en el inventario de permisos que nadie revisa.
Análisis de ciberseguridad, IA y automatización para empresas que necesitan entender lo que firman.