Credenciales de proveedor de ConnectWise (SkyKick) usadas de forma indebida en ataques a Microsoft 365

Agradecimientos: Un agradecimiento especial a Rich Mozeleski, Andrew Brandt, Andrew Kaiser, Dave Kleinatland y Matt Kiely por sus contribuciones a esta investigación y redacción.

Actualización: 27/10/26 a las 2:30 p. m. hora del Este

En un informe del 21 de octubre, Microsoft atribuyó el abuso de credenciales de ConnectWise a un actor de amenazas que rastrea como Storm-0940, el cual, según indica, usó ARTEX, un framework de IA multiagente de código abierto, en el ataque. Publicamos un seguimiento en el blog que analiza nuestra propia telemetría y cómo se relaciona con estos hallazgos. 

Actualización: 19/10/26 a la 1:30 p. m. hora del Este

Esta actualización cubre tres temas: direcciones IP adicionales que circulan en relación con esta actividad, lo que hemos aprendido sobre el comportamiento del atacante después de obtener acceso, y el arte de los ataques de precisión contra los adversarios.

Direcciones IP adicionales: A medida que la comunidad ha compartido más direcciones, revisamos cada una contra nuestra telemetría. En una revisión de inicios de sesión de aplicaciones en más de 10.000 inquilinos con aplicaciones de ConnectWise (donde podemos ver esos registros), 144.172.64[.]128 y los rangos internos de Microsoft son las únicas direcciones que generaron actividad de inicio de sesión de aplicaciones. No vimos actividad de inicio de sesión de aplicaciones desde ninguna de las otras direcciones mencionadas a continuación, todas dentro del mismo rango de proveedor que 144.172.64[.]128 (AS14956, RouterHosting). Sí vimos intentos de password spray y de inicio de sesión fallidos desde algunas de ellas. Por el momento, no creemos que esos intentos estén relacionados con los inicios de sesión de aplicaciones descritos en esta publicación.

Direcciones IP y sus características a continuación:

Qué sucedió después de obtener acceso: Desde nuestra última actualización, Huntress identificó un segundo inquilino con actividad posterior al compromiso. Huntress no estaba implementado originalmente en este inquilino, pero vimos intentos de inicio de sesión de principal de servicio desde ese inquilino hacia inquilinos protegidos por Huntress (desde la dirección IP *.128). Trabajando de forma proactiva con un socio, logramos implementar Huntress en este segundo inquilino para recopilar telemetría adicional.

En los dos inquilinos con esta actividad, el comportamiento posterior al compromiso fue rápido, programado y notablemente indiscriminado. En ambos inquilinos, las actividades posteriores al compromiso ocurrieron con dos minutos de diferencia entre sí, alrededor de las 03:45 UTC del 15 de octubre. El procedimiento fue el mismo cada vez: la aplicación se otorgó a sí misma el rol de Administrador Global y luego plantó un nuevo secreto en un pequeño número de otras aplicaciones del inquilino para mantener un punto de apoyo persistente. La elección de qué aplicaciones usar como puerta trasera parecía aleatoria en los dos inquilinos que revisamos. En los dos inquilinos comprometidos, el mismo flujo de otorgamiento seleccionó dos conjuntos de aplicaciones completamente diferentes. Cabe destacar que una aplicación existía en AMBOS inquilinos, pero se eligió para plantar el secreto solo en uno de ellos. En uno de los inquilinos, las aplicaciones que recibieron secretos plantados estaban entre las menos privilegiadas del entorno, mientras que aplicaciones mucho más poderosas quedaron intactas. El único criterio consistente que podemos señalar es estructural: las credenciales se plantaron en aplicaciones registradas dentro del inquilino afectado, sin importar lo que esas aplicaciones realmente puedan hacer.

Igual de importante es lo que no vimos: el acceso pudo haberse usado para lecturas del directorio de Microsoft Graph, que no dejan registro de auditoría. En los dos inquilinos que revisamos, tampoco encontramos evidencia de manipulación de buzones o archivos, ni cambios de usuarios o políticas.

Nuestra respuesta quirúrgica: Quizás te preguntes por qué nuestra respuesta no incluyó deshabilitar masivamente las aplicaciones de ConnectWise/SkyKick en todos los inquilinos. Nuestro enfoque de contención es deliberado, quirúrgico y basado en evidencia, y este incidente requería un bisturí, no un martillo. Priorizamos los inquilinos con inicios de sesión no autorizados confirmados y exitosos, y nuestra recomendación para todos los demás ha sido deshabilitar las aplicaciones afectadas y revisar sus registros.

Cuando comenzó nuestra investigación, rápidamente establecimos una imagen clara de la ventana del ataque. Los inicios de sesión maliciosos de la aplicación se concentraron en la mañana del 15 de octubre UTC, y el último inicio de sesión exitoso confirmado que observamos con esta credencial fue a las 08:44 UTC del 15 de octubre. Después de eso, solo vimos intentos fallidos en los inquilinos donde podemos ver los registros de inicio de sesión. Con evidencia en mano de que no había actividad actual ni repetida (en los inquilinos donde podemos ver los registros de inicio de sesión), simplemente no tenía sentido crear un radio de impacto mayor de lo necesario.

Esta decisión permitió que nuestros expertos y agentes se concentraran de cerca en los entornos con inicios de sesión no autorizados confirmados, compartieran lo que encontramos con socios de la industria y publicaran recomendaciones para la comunidad.

Creemos que son estos momentos quirúrgicos los que más aprecian nuestros socios y en los que más confían cuando las cosas se complican, especialmente cuando una decisión equivocada puede interrumpir sistemas en funcionamiento y la productividad del negocio como daño colateral.

Actualización: 17/10/26 @ 5:15 p. m. hora del Este

**Al 17 de octubre a las 5:15 p. m. hora del Este, ConnectWise ha comunicado que deshabilitó las aplicaciones correspondientes.

Durante investigaciones adicionales, Huntress identificó una segunda ola dirigida de intentos desde 144.172.64[.]128 el 15 de octubre, que apuntaba sin éxito a un alcance limitado de 16 inquilinos protegidos por Huntress. Estos inquilinos pertenecen a los sectores de política pública, seguridad nacional, comercio y minerales críticos. A diferencia de la primera ola de actividad descrita en nuestro blog inicial a continuación, la mayoría de estos inquilinos no dependen de ningún producto de ConnectWise. En los inquilinos sin el service principal correspondiente de ConnectWise, los intentos fallaron porque la aplicación no estaba presente.

Para el nuevo conjunto de objetivos, el primer rastreo apuntó a tokens de Graph de la aplicación SkyKick y ocurrió el 15 de octubre entre las 09:25:04 y las 12:35:50 UTC. Varios inquilinos fueron afectados en ráfagas durante ese período. El segundo rastreo afectó a los mismos inquilinos en la misma fecha, entre las 13:54:39 y las 14:20:24 UTC. Este rastreo parecía manual y apuntó a Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra y las API de administración de Office 365.

Además de la actividad anterior: 

• Huntress ha identificado casi 1.000 inquilinos de Entra con actividad de inicio de sesión desde la dirección IP asociada con la actividad no autorizada (144.172.64[.]128). Más de 300 de ellos tuvieron éxito.

• Si bien muchos de estos inicios de sesión fueron exitosos, la ausencia de un principal de servicio en algunos inquilinos impidió que el actor de amenazas lograra acceder a esos inquilinos. 

• Huntress también ha recibido reportes e indicios externos fuera de nuestra flota que describen actividad similar en otros inquilinos, incluyendo lo que parece ser actividad manual directa. No hemos verificado estos reportes de forma independiente.

Como se mencionó en nuestro blog inicial, el 15 de octubre el actor de amenazas parece haber usado el acceso de la familia de aplicaciones de ConnectWise para agregar una credencial a una aplicación de Huntress en el inquilino de un cliente, y para agregar una credencial a otra aplicación en el mismo inquilino. La credencial en la aplicación de Huntress se usó para iniciar sesión siete veces en rápida sucesión. El 16 de octubre, Huntress identificó y eliminó la credencial no autorizada en nuestra aplicación. No hemos visto que la aplicación haya hecho cambios en el registro de auditoría de ese inquilino, pero Microsoft no registra todo lo que una aplicación lee, por lo que no podemos descartar el acceso a los datos que la aplicación puede leer allí. Huntress está revisando activamente la actividad de credenciales asociada con nuestras aplicaciones en los entornos de los socios, validando el acceso esperado e investigando cambios sospechosos.

Cabe destacar que el acceso que llevó a que se agregara la credencial a Huntress y a otra aplicación provino de un espacio privado de Azure IPv6, no de la dirección IP asociada con los inicios de sesión anteriores (144.172.64[.]128). En este momento, recomendamos a todos los usuarios de ConnectWise auditar todos los inicios de sesión de principales de servicio en las aplicaciones identificadas a continuación, a partir de alrededor de las 01:00 UTC del 15 de octubre hasta las 02:00 UTC del 16 de octubre.

Estamos fortaleciendo nuestras salvaguardas con monitoreo adicional y controles preventivos para ayudar a detectar y responder a actividad inusual aún más rápido. Hemos habilitado App Instance Property Lock en todas las aplicaciones de Huntress y estamos mejorando nuestras capacidades de salud de flota y monitoreo para detectar intentos de modificación.

Huntress continúa investigando este incidente y actualizará este blog con cualquier novedad importante.

Actualización: 17/10/26 @ 10:30 a. m. hora del Este

Después de pasar la noche revisando los registros de Azure, tenemos alta confianza en que el actor de amenazas también ha abusado de las siguientes aplicaciones de Microsoft 365:

• ConnectWise Cloud Management - Exchange Online (b78f6a77-d4e5-46fb-87e5-d1648bd02519).

• ConnectWise Cloud Management - MS Teams (24205314-2b89-4e07-a2a4-579e898a5640).

• ConnectWise Cloud Management - SharePoint Online (b2b55f5b-7758-4719-8d8f-88ae172e6bdb).

Por el momento, no parece que ConnectWise haya deshabilitado estas aplicaciones.

En cuanto a los comportamientos de explotación temprana y posteriores a la explotación, hemos observado lo que podría ser una tendencia hacia la selección alfabética de objetivos (nuestras víctimas más interesantes empiezan con “A”). Aunque todos los inquilinos deben ser examinados con atención, este patrón vale la pena compartirlo para fines de priorización.

Si te has visto afectado con tácticas destacables relacionadas con este incidente de SkyKick, a nuestro equipo de investigación le encantaría saber más para poder tomar medidas que protejan a la comunidad. Escríbenos a [email protected].

Antecedentes

ConnectWise Cloud Backup (anteriormente SkyKick) es un servicio de respaldo y recuperación en la nube creado para que los proveedores de servicios administrados (MSP) protejan los datos de Microsoft 365 o Google Workspace de sus clientes. Para cumplir esa función, a la aplicación se le otorga acceso amplio a los buzones de correo, OneDrive, SharePoint, Teams y los datos de directorio en cada inquilino donde está instalada. 

El 15 de octubre, la identidad de la aplicación inició sesión en inquilinos de Microsoft 365 de clientes desde 144.172.64[.]128, una dirección de un proveedor de hospedaje, y recibió tokens de acceso de Microsoft Graph. Así no se comporta normalmente la aplicación: el tráfico legítimo proviene de un espacio de IP privado de Azure. A partir de las 19:00 UTC del 16 de octubre, Huntress ha confirmado inicios de sesión no autorizados en 162 inquilinos.

La autenticación en sí es certera: proviene de los propios registros de inicio de sesión de Microsoft en cada inquilino. El tipo de credencial fue una aserción de cliente, lo que significa que la credencial reside en el propio inquilino del proveedor. Nada que el cliente haya hecho en su entorno podría haberla producido. 

ConnectWise ha reconocido el incidente en su sitio web y ha confirmado que la IP está asociada con actividad no autorizada. Todyl también ha informado sobre este incidente.

Figura 1: Cómo se ve el intento de inicio de sesión para un administrador de TI en el Centro de administración de Microsoft Entra

Huntress continúa monitoreando esta situación de cerca junto con nuestros socios de seguridad; para todas las actualizaciones, sigue revisando esta publicación del blog.

Qué sucedió

• ¿Qué sabemos? La credencial de la aplicación está en manos hostiles. Se usó para obtener tokens de Microsoft Graph en inquilinos de clientes desde 144.172.64[.]128 el 15 de octubre, entre las 06:13 y las 08:34 UTC. El actor se movió por los inquilinos en orden de GUID, con pocos segundos de diferencia, lo que apunta a un script que trabaja a partir de una lista de objetivos.

• ¿Quién se ve afectado? Cualquier organización que tenga instalada la aplicación. La credencial funciona contra todos los inquilinos en los que la aplicación tiene consentimiento, por lo que el actor no está limitado a los inquilinos que hemos confirmado hasta ahora.

• ¿Cómo funciona? El atacante se autentica en la aplicación usando sus propias herramientas, de la misma manera que lo hace el servicio de respaldo, y obtiene tokens con los permisos existentes de la aplicación. 

• ¿Cuáles son las posibles repercusiones? Dado que el respaldo y la restauración necesitan tanto leer como escribir datos, esos permisos son amplios. Un atacante que tenga esos tokens puede leer los mismos buzones de correo, archivos y datos de directorio que puede leer el servicio de respaldo.

Observaciones de Huntress

Esta es la cronología de lo que Huntress ha visto desde la misma infraestructura:

• 13 al 14 de octubre: ataque de pulverización de contraseñas contra cuatro inquilinos de bufetes de abogados desde 144.172.64[.]128. Solicitudes de token OAuth2 realizadas con scripts (User-Agent curl/7.88.1) desde infraestructura de centro de datos. Dos cuentas quedaron bloqueadas por bloqueo inteligente. No vimos inicios de sesión de usuario exitosos desde esta IP en la telemetría de Huntress.

• 15 de octubre, desde las 01:58 UTC: en aproximadamente 50 inquilinos monitoreados por Huntress, las entidades de servicio de las apps de Cloud Management de ConnectWise (Exchange Online, Microsoft Teams y Microsoft Graph) se asignaron a sí mismas roles de directorio, en su mayoría Administrador de Exchange. El User-Agent en estos eventos (kiota-dotnet) es el que usan las propias apps de ConnectWise, lo que apunta a automatización del proveedor, pero no hemos confirmado eso con ConnectWise.

• 15 de octubre, de 03:44 a 03:49 UTC, un inquilino de cliente: la app Cloud Management de ConnectWise para Microsoft Teams (ID de aplicación 24205314-2b89-4e07-a2a4-579e898a5640) se agregó a sí misma al rol de Administrador Global y luego ejecutó un script de Python (User-Agent Python-urllib/3.12) que modificó otras dos aplicaciones en el inquilino: una aplicación de gestión para MSP y la propia aplicación de Huntress (Huntress Security Platform), agregando nuevos secretos de cliente a ambas. Un intento posterior de agregar un certificado falló. Los nuevos secretos se configuraron para expirar en 2028.

• 15 de octubre, de 06:13 a 08:34 UTC: la app se autenticó desde 144.172.64[.]128 en 17 de los primeros 290~ inquilinos que Huntress revisó, en 17 cuentas de socios distintas.

• Entre el 13 y el 14 de octubre: la misma dirección también intentó un inicio de sesión mediante script usando IDs de aplicación cliente pertenecientes a otras herramientas.

En el inquilino donde vimos persistencia, toda la secuencia tomó alrededor de cinco minutos. La app Cloud Management de ConnectWise para Microsoft Teams se agregó a sí misma al rol de Administrador Global a las 03:44 UTC y nuevamente a las 03:48. En la misma ventana hizo nueve cambios a otras dos aplicaciones, una aplicación de gestión para MSP y la propia aplicación de Huntress. Seis de los cambios tuvieron éxito y tres fallaron. Un fallo fue una credencial de certificado que Microsoft rechazó por una discrepancia de huella digital, y los secretos de cliente que se agregaron después tuvieron éxito.

Un secreto de cliente y un certificado son dos formas en que una aplicación puede demostrar su identidad ante Entra, y cualquiera de los dos le da al titular el mismo acceso: iniciar sesión como esa aplicación, desde cualquier lugar, usando los permisos que ya tiene otorgados. Los inicios de sesión solo de aplicación no involucran ningún usuario, ningún dispositivo ni ninguna solicitud de MFA. La persona que crea un secreto ve su valor en el momento de la creación, así que el atacante tiene credenciales funcionales para ambas aplicaciones hasta que alguien las elimine. Agregar credenciales a una aplicación existente es una técnica de persistencia conocida (MITRE ATT&CK T1098.001, Account Manipulation: Additional Cloud Credentials).

Las dos aplicaciones que recibieron nuevos secretos son herramientas confiables y con privilegios. Agregar una credencial a una aplicación de gestión para MSP puede extender el acceso más allá de un solo inquilino, porque esas aplicaciones suelen estar autorizadas en los inquilinos de los clientes del MSP. Una credencial en la aplicación de una herramienta de seguridad le da al titular todo lo que esa herramienta tenga permitido hacer.

El cambio de Administrador Global y las adiciones de credenciales ocurrieron alrededor de dos horas y media antes de las primeras autenticaciones de app desde 144.172.64[.]128 a las 06:13 UTC. No tenemos una dirección de origen para la actividad anterior, así que no hemos vinculado las dos fases al mismo operador. Los User-Agents nos ayudaron a distinguir la actividad del proveedor de la actividad del atacante. Las aplicaciones Cloud Management y Partner Center de ConnectWise que revisamos hacen sus llamadas a Graph con un User-Agent de SDK de .NET (kiota-dotnet). Los cambios de aplicación en ese inquilino provinieron de un User-Agent de Python, y el ataque de pulverización de contraseñas usó curl/7.88.1. Ninguno de estos es exclusivo de este actor, y Python y curl son comunes en la administración ordinaria, así que la combinación de actor, operación y User-Agent es la señal útil, no ninguno por sí solo.

El registro de auditoría de Microsoft registra las asignaciones de roles y los cambios de aplicación junto con la aplicación que actuó, pero para acciones solo de aplicación no incluye IP de origen, y no registra los detalles de la credencial que se agregó ni qué leyó una aplicación a través de Microsoft Graph. Confirmar exactamente qué se agregó en un inquilino requiere el registro de auditoría de Entra o una consulta de Graph para ese inquilino, por eso pedimos a los socios que revisen las credenciales directamente.

Qué no hemos confirmado

• Impacto. En el único registro de auditoría de inquilino que revisamos en detalle, el actor no muestra acceso a correo ni a archivos. Eso no significa que no se haya tomado ningún dato. Las lecturas de directorio a través de Microsoft Graph no dejan rastro de auditoría, así que el estado actual es "tokens emitidos, nada visible tomado".

• Exposición de aplicaciones secundarias. ConnectWise tiene múltiples aplicaciones con permisos de muy alto nivel. En un inquilino de cliente, Huntress confirmó que se usó una segunda aplicación de ConnectWise, ConnectWise Cloud Management para Microsoft Teams, para otorgarse a sí misma el rol de Administrador Global y agregar credenciales a otras aplicaciones. No podemos verificar que las demás aplicaciones de ConnectWise sean seguras.

Qué hacer a continuación

Deshabilita la aplicación ahora, incluso si no ves nada inusual.

• En el centro de administración de Microsoft Entra, ve a aplicaciones Empresariales y busca el ID de aplicación 506e08f9-6e9a-4da4-942b-a099a03644ae (también puedes buscar "SkyKick" o "ConnectWise Cloud Backup").

• Abre Propiedades y configura "Enabled for users to sign-in" en No.

• No elimines la aplicación. Eliminarla quita el consentimiento, y tendrás que volver a otorgarlo para restaurar el servicio.

• Verifica si hay otras aplicaciones de ConnectWise y SkyKick en tu inquilino (busca "SkyKick" y "ConnectWise"). Si no puedes confirmar que alguna es segura, desactívala también, sin eliminarla, hasta que ConnectWise confirme que lo es.

• IDs de aplicación a buscar: 

  • ConnectWise Cloud Backup
    506e08f9-6e9a-4da4-942b-a099a03644ae 

  • ConnectWise Cloud Management
    2399d300-6fca-4e6a-a686-399fefe75b83

  • ConnectWise Cloud Management - MS Teams
    24205314-2b89-4e07-a2a4-579e898a5640 

  • ConnectWise Cloud Management - Exchange Online
    b78f6a77-d4e5-46fb-87e5-d1648bd02519

  • ConnectWise Cloud Management - MS Graph
    0de14c77-b9b0-4137-9360-34878a929827

  • ConnectWise Cloud Management - Partner Center
    412dcf96-176d-4b3a-a1b0-4981ad66971e 

  • ConnectWise Cloud Management - SharePoint Online
    b2b55f5b-7758-4719-8d8f-88ae172e6bdb

  • En inquilinos más antiguos, las apps de Cloud Management pueden aparecer como "SkyKick Cloud Manager".

• En inquilinos más antiguos, las apps de Cloud Management pueden aparecer como "SkyKick Cloud Manager".

• Si una aplicación de ConnectWise o SkyKick tiene un rol de directorio en tu inquilino, especialmente Global Administrator o Administrador de autenticación privilegiada, revísalo, y después de desactivar la app, elimina cualquier rol que no hayas otorgado intencionalmente.

• Si usas Huntress, incluye la aplicación Huntress Security Platform en la revisión de credenciales mencionada arriba.

• Revisa las credenciales (secretos de cliente y certificados) en todas tus aplicaciones Empresariales y registros de aplicaciones, especialmente herramientas de administración y seguridad, para detectar cualquier adición desde el 13 de octubre que no hayas creado. Elimina cualquier cosa inesperada.

• Revisa los registros de auditoría de Entra en busca de aplicaciones de ConnectWise o SkyKick que se agreguen a sí mismas a un rol de directorio, y si esa aplicación modifica otras aplicaciones.

• En esos eventos de auditoría, verifica el user agent. Las apps de ConnectWise Cloud Management y Partner Center que revisamos hacen sus llamadas de Graph con un user agent de .NET SDK (kiota-dotnet). Los cambios de aplicación que vimos en ese inquilino provinieron de un user agent de Python (Python-urllib/3.12), que difiere de las apps del proveedor que revisamos.

• No vuelvas a activar ninguna aplicación de ConnectWise hasta que ConnectWise confirme que todas las credenciales se han restablecido.

Figura 2: Recomendaciones de mitigación

Desactivar la app pausa las copias de seguridad automatizadas hasta que se vuelva a activar. Tus correos, archivos, mensajes de Teams y los inicios de sesión de los usuarios siguen funcionando, y las copias de seguridad existentes que tiene ConnectWise no se eliminan. Considera si una brecha en los puntos de recuperación es relevante para ti.

Si quieres revisar tus registros: 

• En el centro de administración de Entra, ve a Monitoring > Sign-in logs, abre la pestaña Service principal sign-ins y filtra por Application ID 506e08f9-6e9a-4da4-942b-a099a03644ae. La pestaña predeterminada User sign-ins no mostrará estos datos.

• En la columna de dirección IP, busca cualquier dirección fuera de los rangos de Microsoft/Azure. La salida normal de la aplicación es Azure private IPv6. Busca específicamente 144.172.64[.]128.

• Un resultado limpio no descarta el acceso. Deshabilita la aplicación de todos modos.

Revisa también el acceso condicional: Si alguna política excluye esta aplicación, por ejemplo de un bloqueo basado en ubicación, la infraestructura del atacante no quedará bloqueada ahí. Revisa esas exclusiones una vez que la aplicación esté deshabilitada.

Por qué esto importa

El servicio de respaldo necesita un acceso amplio para hacer su trabajo, y un atacante que use sus credenciales heredará ese nivel de acceso en cada inquilino donde la aplicación esté instalada. Según los permisos en el inquilino, eso puede incluir buzones de correo, archivos de OneDrive y SharePoint, datos de Teams e información de directorio, gran parte de la cual pertenece a tus clientes. Parte de ese acceso, como las lecturas de directorio a través de Microsoft Graph, no deja rastro de auditoría, por lo que sugerimos actuar ahora en lugar de esperar pruebas de acceso. El impacto potencial total depende de los permisos en juego en cada inquilino.

Qué podría pasar

Lo que un atacante puede hacer con una credencial como esta depende de los permisos ya otorgados a la aplicación en cada inquilino. Un servicio de respaldo normalmente tiene acceso de lectura a correo, archivos, Teams y datos de directorio para poder copiarlos, y acceso de escritura para poder restaurarlos. Un atacante que posea tokens de esa aplicación hereda el mismo acceso: leer correo y archivos en masa, descargar el contenido de buzones y OneDrive, enumerar usuarios, grupos y aplicaciones y, donde existan permisos de escritura, cambiar o eliminar datos. Como el acceso es solo de la aplicación, no depende de que un usuario haya iniciado sesión, y las protecciones de inicio de sesión que aplican a las personas no aplican aquí.

El riesgo mayor es lo que pasa cuando ese acceso se usa para obtener más. Si una aplicación puede asignar roles de directorio, como vimos en un inquilino, puede convertirse a sí misma en Global Administrator, y un administrador puede añadir credenciales a otras aplicaciones, crear nuevas aplicaciones y otorgarles permisos, restablecer contraseñas y métodos de autenticación para los usuarios, y cambiar las políticas de acceso condicional. Cada uno de esos pasos le da al atacante otra forma de volver a entrar que no depende de la credencial original del proveedor, por lo que rotar la credencial del proveedor es necesario, pero no suficiente.

En entornos de proveedores de servicios administrados, el efecto puede multiplicarse. Los MSP usan aplicaciones de gestión y acceso delegado para administrar muchos inquilinos de clientes, así que un punto de apoyo persistente en un inquilino de MSP puede convertirse en un camino hacia sus clientes. No hemos visto que esto suceda, y el registro de auditoría muestra cambios, no lecturas, pero es la razón por la que les pedimos a los MSP que revisen primero las credenciales de sus herramientas de gestión y seguridad.

En términos de ATT&CK, la actividad que observamos corresponde a cuentas de nube válidas (T1078.004) por el uso de la credencial del proveedor, roles de nube adicionales (T1098.003) por los roles de administrador autoasignados, y credenciales de nube adicionales (T1098.001) por los secretos añadidos a otras aplicaciones.

Cómo detectar esto en tus propios registros

Estos eventos aparecen en el registro de auditoría de Entra como Add member to role, Update application y Add service principal credentials. Los campos que importan son la aplicación que inicia la acción, el objetivo, el resultado y el user agent. Un service principal que se agrega a sí mismo a un rol de directorio, o que modifica otras aplicaciones, es algo inusual en la mayoría de los inquilinos y vale la pena investigarlo por sí solo.

Cómo reducir la exposición

Varios controles de Entra limitan el daño si se roba una credencial de aplicación. Las políticas de administración de aplicaciones pueden restringir o bloquear los secretos de cliente en los registros de aplicaciones y limitar la vida útil de las credenciales. Limitar quién tiene los roles de Application Administrator y Cloud Application Administrator reduce quién puede agregar credenciales a las aplicaciones. El acceso condicional para identidades de carga de trabajo, que requiere licenciamiento adicional, puede restringir desde dónde se permite el inicio de sesión de una aplicación, y Microsoft Entra ID Protection puede marcar service principals riesgosos. Ninguna de estas medidas reemplaza la revisión de credenciales, pero hacen que un secreto plantado sea más difícil de usar o más fácil de detectar.

¿Qué está haciendo Huntress?

Huntress ha estado trabajando con socios para abordar los pasos mencionados anteriormente. También hemos estado:

• Revisando los inquilinos donde podemos ver los registros de inicio de sesión a través de Microsoft Graph, y registrando cada IP pública desde la que la app ha iniciado sesión. 

  • Ese trabajo sigue en curso y nos dirá quién más se ha visto afectado y si hay otras IP de atacantes involucradas. 

  • No podemos revisar los inquilinos que no cuentan con el licenciamiento de Entra necesario.

• Deshabilitando la aplicación en los inquilinos donde encontramos actividad desde 144.172.64[.]128, y en los inquilinos donde una aplicación de ConnectWise o SkyKick se asignó a sí misma un rol de directorio, para luego notificar al socio afectado.

• Revisando cada inquilino que podemos ver para conocer el estado actual: service principals de ConnectWise y SkyKick que tienen roles privilegiados, y credenciales agregadas a cualquier aplicación desde el 13 de octubre, incluyendo nuestra propia aplicación.

•  Analizando cómo podemos agregar visibilidad a los inicios de sesión de aplicaciones. 

Seguiremos actualizando este blog a medida que sepamos más.

Indicadores de compromiso (IOC)