ConnectWise Cloud Backup: la aplicación nunca necesitó MFA

El atacante inició sesión como la aplicación

Sus usuarios superaron el MFA. El atacante inició sesión como la aplicación. Ese es el límite de identidad que hay detrás del incidente de ConnectWise Cloud Backup: se utilizó una credencial de aplicación para solicitar acceso con permisos ya concedidos dentro de los tenants de los clientes. Un control diseñado para poner a prueba el inicio de sesión de una persona nunca fue la puerta de esa ruta.

El aviso de ConnectWise, consultado el 20 de octubre de 2026, confirma el acceso no autorizado a identidades de aplicación y describe la contención. Aun así, el mecanismo original de exposición de la credencial sigue bajo investigación. Este artículo es un análisis de arquitectura basado en fuentes, no una reconstrucción en un tenant real. La pregunta de fondo es qué acceso conserva una integración cuando la credencial de su operador está en manos hostiles. [1][2]

El consentimiento crea una identidad con permisos permanentes

Los permisos de aplicación difieren de los permisos delegados. En el flujo de credenciales de cliente, el software se autentica en su propio nombre, sin ningún usuario conectado. Una aplicación multiinquilino tiene una entidad de servicio en cada tenant donde se usa; el consentimiento y los permisos asignados determinan lo que esa identidad puede hacer allí. Restablecer la contraseña de un usuario no revoca la credencial de la aplicación ni reescribe esas concesiones. [3][4]

Por eso empiezo la revisión de una integración por el conjunto de permisos, no por la etiqueta comercial del proveedor. La copia de seguridad y la restauración son motivos legítimos para un acceso amplio a los datos, pero una capacidad de lectura, una de escritura y el permiso para modificar identidades tienen consecuencias distintas. Registre las concesiones y los roles de directorio exactos de su tenant. No dé por hecho que todos los clientes concedieron los mismos derechos, ni que la palabra «copia de seguridad» limita la aplicación a la lectura.

Conceptual app-only path

Vendor application credential
  -> token request for customer tenant
  -> customer service principal + granted permissions
  -> access token for a resource
  -> resource operation

No user password or MFA prompt is part of this flow.

¿Su directiva cubre este tipo de aplicación?

La documentación de Microsoft sobre el acceso condicional para identidades de carga de trabajo excluye de estas directivas de entidades de servicio a las aplicaciones SaaS de terceros y multiinquilino. Comprar la licencia correspondiente no elimina esa restricción de alcance. La documentación sobre la evaluación continua de acceso para cargas de trabajo también limita la compatibilidad a las entidades de servicio de un solo inquilino registradas en el tenant. El nombre de una función no demuestra que una identidad concreta esté cubierta. [5][6]

La revisión práctica es un ejercicio de correspondencia: para cada integración, identifique el control que evalúa su solicitud de token, el recurso que acepta el token y los permisos que puede ejercer. Donde una directiva no se aplique, registre la brecha y las restricciones compensatorias disponibles. El MFA de los usuarios sigue siendo valioso para el acceso de los usuarios; fingir que también gobierna las credenciales de solo aplicación deja sin examinar una identidad distinta.

Deshabilitar una aplicación solo responde a una parte de la contención

Impedir que se emitan nuevos tokens e invalidar el acceso existente son operaciones diferentes. Microsoft documenta una vida útil predeterminada de los tokens de acceso de 60 a 90 minutos, pero no es una cuenta atrás universal para un incidente. Influyen la configuración de los tokens, el comportamiento de cada recurso y los mecanismos de revocación admitidos. ConnectWise indica expresamente que los tokens emitidos con anterioridad pueden seguir siendo utilizables hasta que caduquen o se invaliden de otro modo. Utilice esa distinción en el plan de respuesta en lugar de suponer que deshabilitar equivale a cerrar todas las sesiones al instante. [1][7]

Hay un tercer estado: el acceso creado a través de otra identidad. Huntress informa de credenciales no autorizadas añadidas a otras aplicaciones en los tenants afectados. Deshabilitar la aplicación original de ConnectWise no elimina esas credenciales. Por eso mi modelo de cierre tiene tres filas separadas: nueva emisión bloqueada, acceso emitido previamente contabilizado y acceso derivado no autorizado eliminado. Esperar noventa minutos no demuestra la tercera fila. [2]

Containment question                 Evidence to request
New tokens still issued?             Application state + sign-in outcomes
Existing token still accepted?       Resource behavior + expiry/invalidation
New independent access established?  Credential, grant and role-change review

Elapsed time alone is not a closure record.

Un inicio de sesión correcto demuestra un acceso, no todas las acciones posibles

Un inicio de sesión correcto de una entidad de servicio demuestra algo más limitado que la lectura de todos los buzones. La investigación publicada por Todyl describe actividad de inicio de sesión sin los cambios de persistencia que buscó en los tenants revisados. Huntress describe cambios posteriores al compromiso en otros. Son conjuntos de observaciones distintos, no razones para proyectar el peor resultado observado sobre todos los clientes. El permiso establece la capacidad; la evidencia a nivel de operación establece el uso observado. [2][8]

El atajo contrario también es peligroso. Una vista vacía de inicios de sesión de usuario no cubre los inicios de sesión de entidades de servicio, que Microsoft registra por separado. Y la ausencia de entradas de auditoría tampoco demuestra que se habría registrado toda posible lectura de datos. Mantenga la afirmación acotada: qué telemetría estaba disponible, qué identidades y recursos cubría y qué operaciones puede mostrar realmente. «Desconocido» es una conclusión útil cuando preserva el siguiente paso de la investigación. [2][9]

Siga los cambios desde la aplicación original hasta otras identidades

Busque por ID de aplicación y después correlacione los inicios de sesión de entidades de servicio con los eventos de auditoría dentro de la ventana del incidente. El ID de Cloud Backup que figura abajo es un primer punto de anclaje, no el inventario completo de aplicaciones afectadas; utilice la lista vigente del proveedor para la familia de aplicaciones más amplia. Conserve el iniciador, el destino, el resultado y los identificadores de correlación. Siga tanto los cambios en los que una aplicación de la lista es el actor como los cambios que se hicieron sobre ella. [1]

Revise las credenciales, concesiones de consentimiento y asignaciones de roles desconocidas frente a los registros de responsables aprobados antes de clasificarlas como maliciosas. Las fechas de validez de una credencial no bastan para saber cuándo se añadió. Registre qué se eliminó, por qué y qué otra identidad habilitaba. Así se obtiene una cadena que otro revisor puede seguir, en lugar de una captura de pantalla que muestra una aplicación empresarial deshabilitada. [1]

Initial application ID: 506e08f9-6e9a-4da4-942b-a099a03644ae
Product label: ConnectWise Cloud Backup / formerly SkyKick

Investigation record:
  tenant + application ID + local service principal ID
  event time + initiator + target + outcome + correlation ID
  credential or permission change + approved owner record
  containment action + remaining access + evidence limits

Pregunte qué sobrevive al botón de deshabilitar

La pregunta de aceptación de una integración de terceros debería redactarse antes de un incidente: si su credencial se filtra mañana, ¿qué acción del lado del cliente detiene el nuevo acceso, qué ocurre con los tokens ya emitidos y cómo encontraríamos los permisos o credenciales creados en otros lugares? Exija responsables con nombre para esas respuestas. Una integración sin responsable actual conserva cualquier acceso que no se haya eliminado.

Las mismas preguntas definen un encargo útil de verificación de la corrección después de un incidente. Comprobaría la evidencia de cada estado de contención y rastrearía los cambios en otras identidades antes de tratar la aplicación original como todo el problema. Restablecer el servicio de copias de seguridad y demostrar que el acceso al tenant está bajo control son decisiones relacionadas que necesitan evidencias distintas.