ConnectWise suspende su backup cloud por robo de credenciales

Un único secreto de API robado, perteneciente a una herramienta de backup en la que casi ningún cliente piensa, ha dejado fuera de servicio tres servicios cloud de ConnectWise y ha obligado a cientos de tenants de Microsoft 365 a una revisión urgente de registros. ConnectWise confirmó el acceso no autorizado a su entorno de Cloud Backup el 17 de octubre y desde entonces ha suspendido Cloud Backup, SaaS Security y Cloud Management, sin fecha prevista de restauración. Huntress ha confirmado inicios de sesión no autorizados en 162 tenants, y Microsoft afirma que los atacantes «probablemente abusaron de los permisos que los clientes habían concedido previamente a la aplicación, incluidos permisos muy elevados como Directory.ReadWrite.All».

Aquí no se explotó ningún día cero. Nadie encadenó fallos de corrupción de memoria. Un atacante cruzó una puerta que los propios clientes habían dejado abierta, una puerta que ConnectWise construyó y que ni siquiera chirría al abrirse, porque la autenticación basada en aplicaciones no genera ningún aviso de MFA y, en el lugar equivocado, tampoco deja rastro. Es el tipo de incidente menos vistoso que he gestionado, y el que me mantiene en el trabajo.

Días 0 a 2: las pulverizaciones de contraseñas que no encajaron

La cronología, reconstruida por The Record a partir de la telemetría de Huntress, empieza el 13 y el 14 de octubre, cuando los respondedores de Huntress detectaron ataques de pulverización de contraseñas contra cuatro bufetes de abogados. Por sí solo, eso es un martes cualquiera. Las pulverizaciones contra bufetes son ruido de fondo.

El día 2, el 15 de octubre, es cuando la cosa se pone interesante. Alrededor de 50 sistemas monitorizados por Huntress vieron a los atacantes usar las aplicaciones Cloud Management de ConnectWise para asignarse roles de directorio o administrativos. Esa misma mañana, la aplicación Cloud Backup se autenticó desde la dirección IP 144.172.64[.]128 entre las 06:13 y las 08:34 UTC; una dirección de un proveedor de hosting, no del espacio IP privado de Azure desde el que la aplicación suele operar, según CSO Online. Los eventos estaban en los registros de inicio de sesión de Microsoft. Eran detectables, en principio, en el mismo momento en que ocurrieron: una entidad de servicio conectando desde una dirección que nunca había usado.

El mecanismo fue sencillo en lo que importa. La credencial comprometida es un secreto de API vinculado a la aplicación Cloud Backup en el propio tenant de ConnectWise. Permite a la aplicación obtener tokens de acceso a Microsoft Graph en los tenants de los clientes sin que ningún usuario inicie sesión: sin contraseña ni desafío de MFA. El secreto vivía en el entorno del proveedor, lo que significa que nada de lo que hiciera o dejara de hacer cada cliente causó esto. También significa que los clientes no podían haberlo evitado. Lo que sí podían haber hecho es detectarlo.

Cinco minutos hasta Global Admin

En un tenant de un socio de Huntress, la cadena de ataque se completó por entero. Una segunda aplicación de ConnectWise, Cloud Management para Microsoft Teams, con ID de aplicación 24205314-2b89-4e07-a2a4-579e898a5640, se asignó a sí misma el rol de Administrador global y después añadió nuevas credenciales a otras dos aplicaciones de ese tenant, una de ellas una aplicación de un solo tenant de Huntress, exclusiva de ese socio. Según Huntress, toda la secuencia duró unos cinco minutos, y la firma indica que no ha establecido si las fases distintas las ejecutó el mismo operador.

Esa secuencia de cinco minutos es la parte del incidente que conviene memorizar, porque es la vía de escalada de manual para el acceso OAuth delegado. Acceso inicial: la credencial de proveedor robada. Persistencia: nuevas credenciales añadidas a otras aplicaciones, cada una independiente de la clave original del proveedor. Escalada de privilegios: autoasignación del rol de Administrador global mediante una aplicación a la que los propios clientes habían concedido permisos de directorio. Huntress explicó por qué esto se agrava: una aplicación capaz de asignar roles de directorio puede añadir credenciales a otras apps, crear nuevas, restablecer contraseñas y métodos de autenticación, y modificar las políticas de acceso condicional. «Cada uno de esos pasos da al atacante otra vía de regreso que no depende de la credencial original del proveedor, por eso rotar la credencial del proveedor es necesario, pero no suficiente», escribió la firma.

La advertencia práctica de Huntress, recogida por The Register, es la frase más importante de este incidente: desactivar las aplicaciones de M365, incluidas las aplicaciones de ConnectWise abusadas, no eliminará las credenciales que ya se hayan añadido. Los defensores deben revisar las credenciales de todas sus aplicaciones de M365. La contención en el extremo del proveedor revoca la llave de la puerta principal, pero no hace nada con las copias que el atacante ya ha fabricado.

Días 3 a 6: contención, silencio y la segunda oleada

ConnectWise reconoció por primera vez «intentos de acceso no autorizado» el viernes 16 de octubre y confirmó el acceso al día siguiente. El 17 de octubre desactivó siete identidades de aplicación y después revocó los certificados utilizados en las conexiones de aplicaciones afectadas para todos los usuarios, cortando su propio acceso a través de esas conexiones e invalidando cada credencial compartida previamente usada por Cloud Backup. La interrupción afecta a Cloud Backup (antes producto de SkyKick) y a las plataformas integradas SaaS Security y Cloud Management. A las 16:00 UTC del 18 de octubre, los clientes seguían sin poder hacer copias de seguridad, acceder a los archivos ni restaurar datos, según informó The Register. Jason Ferguson, vicepresidente de operaciones de seguridad de ConnectWise, escribió en Reddit que los archivos existentes «siguen cifrados, aislados y conservados, sin evidencia de acceso no autorizado».

El recuento de Huntress se situaba en 162 tenants con inicios de sesión no autorizados a las 19:00 UTC del 16 de octubre. La firma también observó una segunda oleada, en gran parte fallida, dirigida a tenants «de los sectores de políticas públicas, seguridad nacional, comercio y minerales críticos». Esos intentos fracasaron sobre todo por una razón instructiva: los tenants atacados no usaban productos de ConnectWise, así que la entidad de servicio abusada no estaba presente. Mientras tanto, el aviso de ConnectWise del 19 de octubre añadió dos direcciones IP más, 144.172.64[.]99 y 144.172.64[.]60, identificadas mediante monitorización de terceros, y afirmó que no ha detectado actividad de amenaza exitosa desde la contención. Sigue sin fecha de restauración, no ha dicho cuántos clientes resultaron afectados y declinó hablar de la atribución.

Hay dos cuestiones en la columna de lo desconocido, y la honestidad exige mantenerlas ahí. No se ha revelado cómo se comprometió la credencial en primer lugar. Y no está demostrado que los datos de copia de seguridad se hayan tocado: el portavoz de ConnectWise asegura que no hay indicios de que los archivos hayan sido comprometidos, lo que no equivale a una prueba de ausencia. La advertencia de la propia Huntress es clave aquí: un atacante que use estas credenciales puede llegar a lugares donde no quedará ningún rastro.

La brecha de visibilidad que nadie tuvo en cuenta

ConnectWise ha sido directo sobre el problema estructural: no tiene visibilidad de los entornos de socios y clientes y no puede determinar si un tenant concreto fue vulnerado. Eso es arquitectónicamente correcto: es un proveedor de plataforma, y sus clientes MSP son dueños de la relación con el cliente final. También es todo el modelo de riesgo en una frase. El proveedor tenía una credencial que podía tocar cada tenant que había dado su consentimiento, pero solo los propios tenants pueden ver qué tocó. La responsabilidad de detección recaía en la parte que menos información tenía sobre el compromiso y, en muchos casos, la madurez de registro más baja.

Para los MSP, la aritmética es peor, como señaló Huntress: un punto de apoyo en un cliente puede convertirse en acceso a todos ellos, que es el riesgo de concentración sobre el que funciona este mercado. ConnectWise ya había pasado por esto: un ataque de un Estado-nación contra su software de monitorización remota afectó a clientes el año pasado, y delincuentes han explotado antes vulnerabilidades de sus productos para desplegar ransomware. El patrón no es que ConnectWise sea especialmente descuidada. Es que las herramientas MSP son, por diseño, una arteria privilegiada hacia miles de redes downstream, y el consentimiento por defecto de la industria (amplio, duradero y solo para aplicaciones) trata esa arteria como fontanería y no como superficie de ataque.

Lo que los registros podrían haberle dicho

¿Cuándo podría haberse detectado esto? Tres puntos destacan. Primero, las 06:13 UTC del 15 de octubre: la primera autenticación desde una IP fuera del rango habitual de Azure de la aplicación. Una regla de alerta sobre inicios de sesión de entidades de servicio desde direcciones desconocidas se habría activado antes de la primera asignación de roles. Segundo, el momento en que Cloud Management para Teams se concedió a sí mismo el rol de Administrador global: un evento de asignación de rol de directorio, registrado y de lo más anómalo que pueden mostrar los eventos de auditoría. Tercero, las adiciones de credenciales en las otras dos aplicaciones: cinco minutos de actividad, cada paso en el registro de auditoría, y cada uno un evento que habría hecho saltar el busca si alguien vigilaba esos registros para esa aplicación.

• Alerte sobre autenticaciones de entidades de servicio desde IP fuera de los rangos conocidos del proveedor: las direcciones 144.172.64.x fueron la primera señal pública.
• Alerte sobre cualquier aplicación que se asigne a sí misma roles de directorio, sin excepciones. El software de backup nunca necesita convertirse en Administrador global a las 6 de la mañana.
• Trate los consentimientos OAuth como credenciales permanentes: inventaríelos, reduzca sus permisos y revíselos periódicamente, no después de un incidente.
• Recuerde que revocar la conexión con el proveedor cierra la puerta principal; las credenciales ya añadidas a otras apps siguen siendo válidas hasta que las elimine usted mismo.

He hecho la versión posterior al incidente de esta revisión más veces de las que me interesa contar, y la conclusión es siempre la misma: el tenant tenía los registros, nadie tenía las alertas y la aplicación tenía más privilegios de los que la tarea justificaba. La contención de ConnectWise parece competente. Pero la contención era trabajo del proveedor; la auditoría es tuya. Consulta tus registros de inicio de sesión desde el 13 de octubre, enumera cada credencial de cada aplicación empresarial y responde a la pregunta que este incidente plantea de verdad: ¿qué aplicaciones de terceros de tu tenant podrían hacer esto, y te enterarías en cinco minutos si lo hicieran?