UNC5537 y los clientes de Snowflake: las cuentas no tenían segundo factor
Ticketmaster, Santander y otros clientes de Snowflake perdieron datos en 2024 porque sus propias cuentas se abrieron con contraseñas robadas en otra parte. La campaña es UNC5537. El control es MFA más una política de red.
En mayo y junio de 2024 un grupo que Mandiant llamó UNC5537 usó credenciales robadas de clientes para entrar en cuentas de Snowflake que no exigían autenticación de múltiples factores y que a menudo no tenían política de red. El texto de inteligencia de amenazas de Google, publicado el 10 de junio de 2024, es el registro público. Snowflake dijo que su plataforma no había sido vulnerada por un fallo.
Los datos que salieron eran de los clientes: tickets de soporte, registros de cuentas y, en algunos casos, conjuntos grandes de identidad. El login era válido. Por eso un escáner que buscaba un CVE en el almacén no encontró nada, y el incidente igual ocurrió.
Por qué los logins eran válidos
Mandiant describió credenciales robadas por malware de robo en máquinas de contratistas y empleados, y luego repetidas contra cuentas de Snowflake que aceptaban solo una contraseña. Circuló una lista de esas cuentas. El atacante no necesitaba un fallo nuevo en el almacén. Necesitaba una contraseña que siguiera sirviendo y una cuenta sin segundo factor.
La guía de Snowflake ese mes pidió a los clientes exigir MFA, poner una política de red en la cuenta y buscar conexiones desde los indicadores publicados. Esos tres pasos son la respuesta al incidente y la prevención. Son la misma lista.
Qué salió, en público
La matriz de Ticketmaster y Santander estuvieron entre las organizaciones que confirmaron datos sacados de entornos alojados en Snowflake. AT&T ató después una revelación grande de registros de llamadas a un almacén de datos en la nube en la misma familia de hechos. La tabla exacta de tu cuenta no está en esos titulares. El historial de login sí.
Un portátil de contratista con una contraseña guardada entra en el alcance. También una cuenta de servicio creada para un tablero y nunca dotada de MFA porque la integración 'no podía preguntar'. Las cuentas de servicio son cómo esta campaña se quedó en silencio: no hay un humano que apruebe un aviso.
Qué dijo Mandiant que no era
No un día cero de Snowflake. No un servicio de autenticación roto dentro de la plataforma. Los clientes que ya exigían MFA no fueron, según el reporte, los logins con éxito de la campaña. Esa frase es la que hay que probar contra la configuración de tu cuenta, no contra un comunicado.
Culpar al almacén y culpar al usuario quedan incompletos los dos. El almacén permitía una cuenta de solo contraseña. El cliente dejó una. Cualquiera de los dos lados podía hacer fallar el login. Solo el cliente puede ver su lista de usuarios esta noche.
MFA, política de red, y después los usuarios
Activa MFA para cada humano y rechaza las cuentas de servicio de solo contraseña. Usa par de claves u OAuth para los trabajos, con alcance al almacén que necesitan. Añade una política de red para que un login desde una red inesperada falle aunque tenga la contraseña. Rota credenciales que hayan aparecido en un volcado de infostealer. La versión de parche no es una release de Snowflake. Mandiant y Snowflake dijeron el 10 de junio de 2024 que no hubo una vulnerabilidad de la plataforma. El control de ese aviso es el MFA en la cuenta del cliente.
Lee el historial de login de mayo y junio de 2024, y de cualquier repetición posterior, buscando nombres de cliente que tú no ejecutas. Si una sesión entró, trata como revelados los datos que esa cuenta podía consultar y avisa a las personas que están ahí. Un agente o un notebook que se conecta con una contraseña compartida hereda el mismo hueco. Dale una credencial que no se pueda teclear en un navegador.
Inteligencia de amenazas de Mandiant y Google Cloud sobre UNC5537, 10 de junio de 2024.
https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion
Preguntas frecuentes
¿Hackearon la plataforma de Snowflake?
El reporte de Mandiant de junio de 2024 y los comunicados de Snowflake describieron credenciales robadas de clientes contra cuentas sin MFA, no una vulnerabilidad del servicio Snowflake. Revisa igual el MFA y la política de red de tu cuenta.
¿El MFA cierra el camino de esta campaña?
Para la repetición de contraseñas que usó UNC5537, sí: una cuenta que exige un segundo factor no se abre solo con la contraseña robada. Acompáñalo de una política de red y de credenciales de trabajo que no sean una contraseña compartida.
¿Qué clientes se nombraron?
Las confirmaciones públicas incluyeron a Ticketmaster y Santander. Tu exposición es tu historial de login y los permisos de cualquier cuenta que aceptara una contraseña sin MFA, no aparecer en esa lista de titulares.