Cuando una aplicación en la nube de confianza se convierte en una vía de ataque

Ilustración conceptual proporcionada por el propietario del sitio. No muestra cuántos tenants de clientes se vieron afectados ni sugiere ninguna cifra de tenants.

Un incidente de octubre de 2026 relacionado con ConnectWise Cloud Backup puso al descubierto un riesgo de seguridad que va más allá de las cuentas de los empleados. Los atacantes usaron credenciales asociadas a aplicaciones de confianza para autenticarse en entornos de Microsoft 365 de clientes, lo que muestra por qué las identidades de las aplicaciones de terceros forman parte del límite de seguridad de una organización.

La aplicación era de confianza. Su credencial, no.

Las organizaciones autorizan con frecuencia a aplicaciones de terceros a acceder a sus entornos de Microsoft 365. Un servicio de copia de seguridad en la nube, por ejemplo, necesita permiso para obtener información de Exchange Online, SharePoint, OneDrive y otros servicios. Usa ese acceso para crear copias de seguridad y permitir la restauración.

El servicio de copia de seguridad debe funcionar aunque ningún empleado haya iniciado sesión. Por eso la organización autoriza la identidad de la aplicación en lugar de exigir que una persona apruebe cada operación programada.

En octubre de 2026, este esquema pasó a ocupar el centro de un incidente de seguridad relacionado con ConnectWise Cloud Backup, antes SkyKick. ConnectWise confirmó un acceso no autorizado en el que intervinieron identidades de aplicación asociadas a su entorno de copias de seguridad en la nube. Investigadores de seguridad independientes observaron a atacantes que se autenticaban mediante esas identidades en tenants de Microsoft 365 de clientes.

El 15 de octubre, Sophos X-Ops identificó solicitudes de autenticación automatizadas en las que se usaba la identidad de aplicación de ConnectWise Cloud Backup para obtener tokens de acceso de Microsoft Graph. Huntress informó de forma independiente de inicios de sesión no autorizados en 162 tenants de clientes a las 19:00 UTC del 16 de octubre.

Estos hallazgos establecen que se estaban usando identidades de aplicación de confianza sin autorización. No establecen que en los 162 tenants hubiera robo de datos, una vulneración administrativa o un acceso persistente del atacante.

Los investigadores también observaron cambios más graves en permisos de aplicaciones y en credenciales en al menos un tenant. Esos hallazgos requieren un examen aparte, porque la evidencia disponible no establece que toda la actividad relacionada la llevara a cabo el mismo atacante. Fuentes: ConnectWise Trust Center, investigación de Sophos X-Ops e investigación de Huntress.

Cómo accede a Microsoft 365 una aplicación de copia de seguridad

Para entender este incidente hay que separar la identidad de un empleado de la identidad de una aplicación. Cuando un empleado accede a Outlook, Microsoft Entra ID autentica a esa persona según los requisitos de inicio de sesión de la organización. Estos pueden incluir la autenticación multifactor, comprobaciones del dispositivo y políticas de Conditional Access.

Un servicio de copia de seguridad automatizado funciona de otra manera. Necesita acceder a información sin que haya un empleado presente. Microsoft Entra lo permite mediante identidades de aplicación, con las que el software puede autenticarse y solicitar acceso a servicios.

En el caso de una aplicación de terceros que usan muchas organizaciones, Microsoft Entra distingue dos objetos relacionados. El registro de aplicación (application registration) representa la aplicación de software. El editor lo mantiene en su propio tenant, junto con las credenciales que se usan para autenticar la aplicación.

Una entidad de servicio (service principal) representa la presencia de esa aplicación dentro de un tenant de cliente concreto. Proporciona la identidad local a través de la cual se pueden asignar permisos y accesos. Así, una aplicación multitenant puede tener un único registro de aplicación controlado por el editor y entidades de servicio separadas en muchas organizaciones clientes.

Es un diseño habitual en las plataformas de software como servicio. Cada cliente decide si autoriza la aplicación y qué permisos le concede. Normalmente, el proveedor controla la credencial que usa su aplicación para demostrar su identidad.

Microsoft documenta esta relación en su guía sobre objetos de aplicación y entidades de servicio.

Cómo funciona el inicio de sesión de una aplicación

Piensa en un servicio de copia de seguridad que obtiene información de un tenant de cliente. La aplicación se autentica en Microsoft Entra con una credencial admitida, como un secreto de cliente (client secret) o un certificado, y solicita un token de acceso para un recurso concreto.

Microsoft Entra verifica la identidad de la aplicación, evalúa los requisitos de autorización y de políticas aplicables y determina si la solicitud puede aprobarse. Si esas comprobaciones salen bien, Entra emite un token de acceso para el recurso solicitado que refleja los permisos autorizados de la aplicación. La aplicación presenta ese token a Microsoft Graph, que evalúa si la operación solicitada está permitida.

Intervienen dos decisiones de seguridad distintas. La autenticación establece qué identidad hace la solicitud. La autorización determina a qué puede acceder esa identidad o qué puede cambiar.

Una credencial de aplicación válida no da acceso ilimitado a todos los tenants o servicios de Microsoft 365. El acceso depende de la presencia de la aplicación en el tenant de destino, de los permisos que se le han concedido y de las restricciones que se apliquen.

Microsoft Entra admite dos modelos de permisos importantes. Con los permisos delegados, una aplicación actúa en el contexto de un usuario que ha iniciado sesión. Con los permisos de aplicación, el software puede actuar sin que haya un usuario con la sesión iniciada, dentro de los límites de sus permisos autorizados.

La actividad de tokens de ConnectWise correspondía a una autenticación solo de aplicación mediante el modelo de credenciales de cliente (client credentials) de OAuth 2.0. Eso explica por qué el atacante no necesitaba obtener la contraseña de un empleado concreto ni superar el desafío de MFA interactivo habitual de ese empleado.

No significa que la MFA fallara. Tampoco significa que las identidades de aplicación carezcan de controles de seguridad. Significa que el atacante intentaba autenticarse como una identidad de carga de trabajo, no como un usuario humano.

El límite de seguridad falló cuando el atacante obtuvo una credencial capaz de demostrar la identidad de una aplicación que los clientes ya habían autorizado.

Cómo una sola credencial podía llegar a varias organizaciones

ConnectWise Cloud Backup estaba diseñado para funcionar en varios tenants de Microsoft 365. Cada cliente mantenía su propio entorno y concedía acceso a la aplicación mediante su propio proceso de autorización. Sin embargo, la credencial de aplicación controlada por el proveedor podía usarse para autenticar la misma identidad de aplicación en los tenants de clientes que habían dado su consentimiento.

Por tanto, un atacante en posesión de esa credencial podía intentar autenticarse en más de una organización sin tener que vulnerar por separado las cuentas de los empleados de cada una. Sophos observó este mecanismo durante un barrido automatizado de tokens el 15 de octubre.

Las solicitudes procedían de un servidor privado virtual con la dirección 144.172.64[.]128 y se dirigían a tenants de clientes en un orden sistemático. Sophos observó la actividad durante aproximadamente 96 minutos e informó de que no pudo determinar qué hizo finalmente el atacante con los tokens emitidos. Huntress observó de forma independiente autenticaciones no autorizadas desde la misma infraestructura de origen, aunque su investigación abarcó otro conjunto de tenants y de observaciones.

La relevancia técnica está en que el atacante usaba una relación de autorización que ya existía entre cada cliente y la aplicación del proveedor. Los tenants de los clientes no se fusionaron en un único entorno de seguridad. Cada uno conservó sus propios permisos y controles. Pero la misma credencial comprometida del proveedor podía presentarse en cualquier lugar donde esa aplicación estuviera autorizada.

En un servicio de copia de seguridad, los permisos concedidos pueden incluir el acceso a buzones, archivos e información del directorio, y las operaciones necesarias para la restauración. Un atacante que obtuviera un token de acceso podría llegar a ejercer los permisos que representa ese token.

Sin embargo, la evidencia debe interpretarse con cuidado. Una solicitud de autenticación no es lo mismo que un inicio de sesión correcto. Un inicio de sesión correcto no prueba necesariamente que una operación solicitada a Microsoft Graph tuviera éxito. Y un token válido no establece que se descargara o modificara información de los clientes.

Son hallazgos distintos que requieren evidencias distintas. Fuentes: análisis técnico de Sophos X-Ops e investigación del incidente de Huntress.

La investigación también identificó una vía de acceso persistente

Las solicitudes de tokens no autorizadas no fueron los únicos hallazgos preocupantes. Huntress documentó una secuencia aparte de cambios en identidades de aplicación en un tenant de cliente el 15 de octubre.

Aproximadamente entre las 03:44 y las 03:49 UTC, una aplicación relacionada llamada ConnectWise Cloud Management – MS Teams se asignó a sí misma el rol de directorio Global Administrator. En ese mismo periodo modificó otras dos identidades de aplicación y les añadió nuevos secretos de cliente.

Una de esas identidades pertenecía a una aplicación de gestión de un MSP (proveedor de servicios gestionados). La otra pertenecía a la aplicación Huntress Security Platform dentro de ese tenant. Después, Huntress identificó una autenticación correcta con una credencial no autorizada asociada a su aplicación.

Estas observaciones muestran por qué los cambios en las credenciales de aplicaciones importan en una investigación de identidades en la nube.

Cómo una segunda credencial crea una vía de acceso aparte

Un secreto de cliente permite que una aplicación se autentique como su identidad registrada. Si un atacante tiene autorización suficiente para añadir un nuevo secreto a otra aplicación, puede que logre autenticarse con la identidad de esa aplicación y sus permisos existentes. Eso crea una vía de acceso separada de la credencial comprometida original.

Por ejemplo, deshabilitar la identidad de ConnectWise Cloud Backup no eliminaría automáticamente un secreto no autorizado añadido a una aplicación de gestión sin relación con ella. Hay que investigar la segunda aplicación y eliminar o invalidar sus credenciales no autorizadas mediante el proceso de respuesta adecuado.

Sin embargo, poseer la credencial de una aplicación no otorga automáticamente la autoridad para modificar otra aplicación ni para asignar un rol privilegiado. Esas acciones requieren permisos o privilegios aparte. Esta distinción es especialmente importante porque en el incidente intervinieron varias identidades de aplicación de ConnectWise con relaciones de autorización diferentes.

Lo que los investigadores pudieron establecer y lo que no

El orden temporal de la actividad observada importa. Huntress registró las asignaciones de Global Administrator y la creación de credenciales adicionales antes de la actividad de autenticación posterior desde la dirección IP pública identificada.

Los eventos anteriores correspondían a tráfico registrado desde un espacio de direcciones privadas alojado por Microsoft. Huntress no pudo establecer que la actividad anterior y el barrido de tokens posterior desde la IP pública los hubiera llevado a cabo el mismo operador. También observó otra actividad de asignación de roles de aplicación que se parecía a la automatización legítima de ConnectWise, y que requería más investigación en lugar de atribuirse automáticamente al atacante.

El 21 de octubre, ConnectWise afirmó que, según la evidencia de que disponía, incluida información de inteligencia de amenazas compartida por Microsoft, parece que un grupo alineado con el Estado chino fue el responsable del ataque a ConnectWise Cloud Backup y que ese grupo usó un framework de IA agéntica de libre acceso. Esa es la valoración del proveedor. Sophos no nombró a ningún actor, y Huntress no había vinculado las fases anterior y posterior de la actividad al mismo operador. Fuente: ConnectWise Trust Center.

Por tanto, la evidencia respalda una conclusión precisa:

Hubo autenticaciones de aplicación no autorizadas en varios tenants de clientes, y en al menos un tenant se documentó una secuencia aparte y preocupante de persistencia mediante credenciales. No se estableció la relación completa entre esas actividades.

Sería inexacto describirlas como una única secuencia de ataque, reconstruida de forma concluyente, que afectara a todos los clientes. Fuente: Huntress, investigación sobre la credencial de proveedor de ConnectWise/SkyKick.

Por qué la contención del proveedor no completó la corrección en los clientes

ConnectWise respondió deshabilitando las identidades de aplicación afectadas, revocando credenciales y suspendiendo los servicios en la nube relacionados mientras investigaba. Según su guía del 18 de octubre, la empresa deshabilitó siete identidades de aplicación de ConnectWise a las 07:00 UTC del 17 de octubre.

Esa acción impidió nuevas autenticaciones a través de las conexiones afectadas. No revirtió automáticamente los cambios hechos antes dentro de los tenants de Microsoft 365 de los clientes. Los tokens emitidos previamente podían seguir siendo válidos hasta su caducidad o su invalidación efectiva. Y, lo que es más importante, las credenciales, permisos o asignaciones privilegiadas adicionales establecidos en otras identidades requerían su propia investigación.

También hay una diferencia entre que un proveedor deshabilite la conexión de una aplicación y que un cliente verifique el estado de la aplicación empresarial correspondiente en su propio tenant. Son dos controles administrativos distintos.

Esto significa que la respuesta al incidente tiene dos partes conectadas. ConnectWise debe proteger sus propias credenciales de aplicación, investigar sus servicios y confirmar cuándo pueden restablecerse con seguridad las conexiones afectadas. Los administradores de los clientes y los proveedores de servicios gestionados deben determinar si hubo actividad no autorizada dentro de los tenants de los que son responsables.

Qué deben investigar los administradores

La investigación debe centrarse en la evidencia relevante para las identidades de aplicación afectadas, en lugar de cambiar de forma indiscriminada credenciales no relacionadas.

Los registros de inicio de sesión de entidades de servicio pueden mostrar autenticaciones en las que intervienen identidades de carga de trabajo. Estos eventos son distintos de la actividad de inicio de sesión habitual de los empleados y puede que no se vean en los informes que los administradores revisan de forma rutinaria.

Los registros de auditoría de Microsoft Entra pueden identificar cambios en credenciales de aplicaciones, permisos, entidades de servicio y asignaciones de roles de directorio. Los investigadores deben examinar qué identidad inició un cambio, qué identidad se modificó y si después se usó una credencial inesperada.

ConnectWise recomienda revisar la actividad relevante a partir del 13 de octubre de 2026 y ampliar la investigación cuando la evidencia disponible indique que hace falta. Sophos y Huntress también proporcionan indicadores específicos del incidente, como direcciones de origen, identidades de aplicación y el software cliente observado.

Esos indicadores deben interpretarse en contexto. Una dirección IP sospechosa puede apoyar una investigación, pero la ausencia de esa dirección no prueba que un tenant no se viera afectado. Del mismo modo, las direcciones de red privadas alojadas por Microsoft pueden aparecer en actividad legítima y no identifican por sí solas a un atacante.

Otra limitación importante tiene que ver con la visibilidad. Los registros de inicio de sesión de Microsoft Entra pueden establecer que una aplicación se autenticó. Los registros de auditoría pueden mostrar cambios de identidad y de permisos. No registran necesariamente toda la información que una aplicación leyó después a través de Microsoft Graph.

Cuando hay registros de actividad de Graph adicionales disponibles, pueden ayudar a los investigadores a establecer las operaciones posteriores que se realizaron. Su disponibilidad y su cobertura dependen de la configuración, las licencias y las medidas de registro del tenant. En consecuencia, la ausencia de un evento observado de acceso a datos no siempre permite establecer que no hubo acceso.

Los administradores deben conservar la evidencia relevante, verificar el estado de las aplicaciones y seguir la guía vigente del proveedor al deshabilitar o volver a conectar las aplicaciones afectadas. Eliminar de inmediato los objetos de aplicación puede borrar contexto útil para la investigación. La guía de respuesta al incidente recomienda deshabilitar las conexiones afectadas y conservar lo necesario para entender su actividad.

Cambiar las contraseñas de los empleados o revocar las sesiones de usuario no bastaría por sí solo para resolver las credenciales no autorizadas asociadas a identidades de aplicación. Fuentes: ConnectWise Trust Center y guía de corrección, investigación de Sophos X-Ops y hallazgos técnicos de Huntress.

El efecto en las copias de seguridad de los clientes

La investigación de seguridad también provocó una interrupción operativa. ConnectWise suspendió Cloud Backup y los servicios relacionados mientras protegía su entorno y validaba las conexiones de aplicación afectadas. Las operaciones de copia de seguridad programadas, el acceso a los archivos de copia de seguridad y las funciones de restauración quedaron interrumpidos durante la suspensión.

ConnectWise informó de que los archivos de copia de seguridad existentes de Cloud Backup seguían cifrados y aislados, sin indicios en ese momento de que se hubieran vulnerado. Ese hallazgo se refiere a las copias de seguridad almacenadas por el proveedor. No establece que el entorno de Microsoft 365 en producción de cada cliente quedara a salvo de la autenticación de aplicación no autorizada.

Un atacante podría llegar a usar los permisos de Microsoft Graph concedidos a una aplicación de copia de seguridad para acceder a información de un tenant en producción sin vulnerar el archivo separado donde se guardan los datos ya copiados. Por eso hay que mantener separadas las dos cuestiones: la seguridad de los archivos de copia de seguridad existentes y el acceso no autorizado a los entornos reales de los clientes.

ConnectWise empezó a restablecer el servicio por fases el 21 de octubre, pero eso no confirmaba que todos los servicios se hubieran recuperado ni que todos los tenants de clientes afectados hubieran completado la investigación. Se indicó a los administradores que mantuvieran deshabilitadas las conexiones de aplicación afectadas hasta que se publicara una guía formal de restauración y reconexión. Fuente: ConnectWise Trust Center.

Lo que demuestra este incidente

El incidente de ConnectWise no establece que las aplicaciones de terceros para Microsoft 365 sean inseguras por naturaleza. Las plataformas de copia de seguridad y de gestión en la nube necesitan acceder a los entornos de los clientes para prestar sus servicios. Las identidades de aplicación multitenant y la autenticación solo de aplicación son partes normales de esa arquitectura.

El riesgo aparece cuando un atacante obtiene la credencial que sirve para demostrar la identidad de una aplicación que los clientes ya han autorizado.

En este caso, los investigadores confirmaron autenticaciones de aplicación no autorizadas en varios tenants de clientes. Huntress también documentó cambios privilegiados en aplicaciones y credenciales no autorizadas en un tenant concreto, aunque reconoció de forma explícita los límites a la hora de atribuir las distintas fases de la actividad.

Esos hallazgos explican por qué sustituir la credencial original del proveedor era necesario, pero no bastaba para establecer que el entorno de cada cliente fuera seguro. Las organizaciones también tenían que determinar si el acceso se había ampliado mediante otras identidades, permisos o credenciales.

El límite de seguridad de una organización de Microsoft 365 incluye las aplicaciones de terceros que autoriza, no solo a las personas que inician sesión en sus sistemas.

Proteger las cuentas de usuario sigue siendo esencial. Entender y supervisar las identidades de aplicación es una responsabilidad aparte, sobre todo cuando una sola credencial controlada por el proveedor puede gozar de confianza en muchos tenants de clientes.

Para profundizar

Investigación revisada el 21 de octubre de 2026. Las investigaciones del incidente pueden aportar nuevos hallazgos. Las cifras de tenants reflejan observaciones fechadas, no el número final de organizaciones en las que se haya confirmado un robo de datos o una vulneración persistente.

Avisos y guías de los proveedores

• ConnectWise Trust Center, Cloud Backup incident advisories, declaraciones oficiales sobre el incidente, medidas de contención, servicios afectados e instrucciones de restauración.
• ConnectWise Cloud Backup Technical Investigation and Remediation Guide, octubre de 2026, identificadores de aplicación, alcance de la investigación, conservación de evidencias y guía de corrección para clientes.

Investigaciones independientes

• Sophos X-Ops, ConnectWise Cloud Backup application abused in cross-tenant token sweep, análisis independiente de la autenticación automatizada de aplicaciones y de las solicitudes de tokens de Microsoft Graph.
• Huntress, ConnectWise/SkyKick vendor credentials abused in Microsoft 365 attacks, observaciones de autenticaciones no autorizadas, cambios privilegiados en aplicaciones, persistencia mediante credenciales y límites de la atribución.
• Kudelski Security, ConnectWise Cloud Backup vendor credential abuse, análisis independiente del incidente y contexto técnico.

Documentación de Microsoft

• Microsoft, Application objects and service principals, explica los registros de aplicación, las entidades de servicio en los tenants de clientes y la autorización multitenant.
• Microsoft, Service-principal sign-ins, explica los registros de autenticación de identidades de carga de trabajo.
• Microsoft, Application authorization and resource access, explica las decisiones de acceso de las aplicaciones y los límites de autorización.

Las organizaciones que investiguen una posible exposición deben seguir la guía de seguridad vigente de ConnectWise y de Microsoft adecuada a sus entornos.

Lecturas relacionadas en TechiesJournal

• El límite de credenciales de MCP: por qué un servidor MCP no debería decidir adónde van tus credenciales de OAuth (en inglés), para ver desde otro ángulo dónde se debe confiar en las credenciales de aplicación y dónde no.
• Ataques a la cadena de suministro de CI/CD: cómo llegan los atacantes a tu pipeline (en inglés), para ver otra forma en que una conexión de confianza puede convertirse en un punto de entrada.