Entre las credenciales robadas se encontraba un token de servicio Moveworks que otorgaba acceso remoto a los sistemas Atlassian. Otros compromisos incluyeron una cuenta de Smartsheet con acceso administrativo a la instancia de Atlassian Jira, una cuenta de servicio de Bitbucket con acceso al sistema de administración de código fuente de Cloudflare y un entorno de AWS sin “acceso a la red global ni datos confidenciales ni de clientes”.
“Del 14 al 17 de noviembre, el actor de amenazas hizo un reconocimiento y luego accedió a nuestra wiki interna (que usa Atlassian Confluence) y a nuestra base de datos de errores (Atlassian Jira)”, agregó Cloudflare. “Luego regresaron el 22 de noviembre y establecieron acceso persistente a nuestro servidor Atlassian usando ScriptRunner para Jira, obtuvieron acceso a nuestro sistema de administración de código fuente (que usa Atlassian Bitbucket) e intentaron, sin éxito, acceder a un servidor de consola que tenía acceso al centro de datos que Cloudflare aún no había puesto en producción en São Paulo, Brasil”.
La compañía agregó que el incidente no fue de ninguna manera un error por parte de Atlassian, AWS, Moveworks o Smartsheet, y ocurrió porque no pudo rotar las credenciales robadas asumiendo que no estaban en uso.
Cloudflare dijo que pudo contener y eliminar completamente la infección gracias a la adopción de una arquitectura de confianza cero.
“Debido a nuestros controles de acceso, reglas de firewall y uso de claves de seguridad físicas aplicadas mediante nuestras propias herramientas Zero Trust, la capacidad del actor de amenazas para moverse lateralmente era limitada”, dijo la compañía. “Ningún servicio estuvo implicado y no se realizaron cambios en nuestros sistemas o configuración de red global”.
Reconociendo la intención del ataque de establecer persistencia y temiendo una persistencia pasada por alto, Cloudflare recurrió a un enfoque de remediación integral con pasos proactivos adicionales para futuros ataques.
