La campaña de robo de credenciales de Snowflake y los límites de la responsabilidad compartida

Resumen

• Límite confirmado de la campaña:Mandiant atribuyó una campaña con motivación económica a UNC5537 y afirmó que todos los incidentes de la campaña que manejó directamente se originaron en credenciales de clientes comprometidas. No encontró evidencia de que el acceso no autorizado a clientes proviniera de una violación del entorno empresarial de Snowflake. Snowflake también afirmó no haber encontrado evidencia de vulnerabilidad, configuración incorrecta o violación de su plataforma que causara la actividad.
• Cadena de control observada:Las cuentas afectadas carecían de autenticación multifactor, conservaban credenciales expuestas en registros históricos de infostealers y no tenían listas de permitidos de red. Luego, los atacantes utilizaron clientes compatibles de Snowflake y operaciones SQL para enumerar datos, prepararlos, comprimirlos y descargarlos. Aproximadamente 165 organizaciones fueron notificadas como potencialmente expuestas; esa no es una cifra de brechas confirmadas, personas ni registros.
• Hallazgo sobre responsabilidad compartida:Los clientes controlaban sus usuarios, roles, rotación de contraseñas, inscripción en MFA, políticas de red, higiene de endpoints y minimización de datos. Snowflake controlaba qué protecciones existían, cómo se presentaban y se establecían por defecto, qué señales entre clientes podía ver la plataforma y con qué rapidez llegaban las advertencias y un comportamiento de referencia más sólido a la base instalada. Esas responsabilidades son concurrentes, no mutuamente excluyentes.
• Hallazgo sobre soberanía:Elegir una región de Snowflake determina dónde se ubican el almacenamiento y la computación de la cuenta; la documentación de Snowflake dice expresamente que no limita el acceso de los usuarios. En esta campaña, una identidad válida podía convertir un conjunto de datos almacenado regionalmente en una copia descargada. La localización de datos sin controles de identidad, salida y evidencia es una decisión de ubicación, no un control de soberanía completo.

No se demostró que la plataforma sufriera una brecha, pero se puso a prueba la relación de servicio

La primera disciplina en este caso es el vocabulario. Una instancia de cliente de Snowflake no es lo mismo que el entorno empresarial propio de Snowflake ni la plataforma de producción compartida. Una persona con credenciales válidas podía acceder a la cuenta de un cliente sin traspasar a otro inquilino, explotar una vulnerabilidad de software, obtener una cuenta de administrador del proveedor ni romper la infraestructura que separaba a los clientes. La evidencia pública respalda el compromiso de cuentas de clientes. No respalda un compromiso técnico generalizado de la plataforma.

Elinforme de la campaña UNC5537 de Mandiantes inusualmente directo en ese punto. En todos los incidentes relacionados con la campaña que gestionó Mandiant, la causa raíz fueron credenciales de clientes comprometidas. Su investigación no encontró evidencia de que el acceso no autorizado a las cuentas de clientes se debiera a una violación del entorno empresarial de Snowflake. Elaviso de investigación y refuerzo de Snowflaketambién separó las cuentas de clientes atacadas de la plataforma de producción y proporcionó consultas e indicadores para que los clientes investigaran sus propios entornos. CISA amplificó esa guía en unaalerta del 3 de junio de 2024.

Ese hallazgo negativo es importante. Calificar el evento como una brecha de la plataforma de Snowflake puede implicar que un defecto en el código o la infraestructura compartida abrió todos los inquilinos, o que Snowflake perdió una credencial maestra que permitió el acceso a los clientes. El registro examinado no establece ninguna de estas cosas. Además, ocultaría las acciones que los clientes debían tomar de inmediato: identificar usuarios con solo contraseña, rotar credenciales, inspeccionar el historial de inicio de sesión y consultas, restringir redes, reducir privilegios de roles y preservar evidencia.

El error opuesto es tratar la ausencia de una brecha en la plataforma como la ausencia de una cuestión de responsabilidad del proveedor. Un servicio en la nube no es simplemente un disco neutral en el que el cliente coloca bits. Snowflake construyó y operó los puntos finales de autenticación que aceptaron las credenciales, las interfaces que utilizaron los atacantes, el motor de consultas que procesó sus comandos, la telemetría que registró las sesiones y los controles del producto que podrían haber requerido un segundo factor o restringir el origen de la red. Snowflake también tenía una visibilidad entre clientes que ningún cliente individual podía poseer. El hecho de que un control decisivo fuera configurable por el cliente determina quién tenía el deber operativo de configurarlo. No responde si los valores predeterminados, las advertencias, la detección y la aplicación del proveedor eran proporcionales a la concentración de datos en su servicio.

ElFormulario 10-Kde Snowflake para el año fiscal 2025 formaliza su posición. Dice que Snowflake es responsable de la seguridad de la plataforma y de la infraestructura de nube subyacente, mientras que los clientes seleccionan y configuran los controles para sus entornos. Atribuye el acceso de mayo de 2024 al incumplimiento por parte de los clientes de obligaciones como la MFA y las políticas de red, al tiempo que registra demandas, investigaciones regulatorias, consultas legislativas, daños reputacionales y la posibilidad de disputas de indemnización. Se trata de evidencia material de la empresa sobre el modelo declarado y la exposición comercial de Snowflake. No es una adjudicación independiente de que toda responsabilidad o reclamación legal recaiga en el lado del cliente.

Por lo tanto, la pregunta útil es más limitada que "¿Quién sufrió la brecha?" y más amplia que "¿A quién le robaron la contraseña?". Es: en cada paso, desde el secreto robado hasta los datos descargados, ¿qué actor podía prevenir, detectar, interrumpir, reconstruir o advertir sobre la acción? La responsabilidad se deriva del control sobre esos pasos.

La campaña unió el viejo robo de endpoints con la autoridad actual en la nube

Mandiant obtuvo por primera vez inteligencia de amenazas en abril de 2024 sobre registros de bases de datos que posteriormente se rastrearon hasta una instancia de Snowflake de una víctima. Esa víctima contrató a Mandiant, que concluyó que el intruso utilizó credenciales robadas previamente por malware infostealer. La cuenta en cuestión no tenía habilitada la MFA. El 22 de mayo, tras identificar inteligencia que apuntaba a una campaña más amplia, Mandiant se puso en contacto con Snowflake y comenzó a notificar a posibles víctimas. Snowflake publicó orientación sobre detección y refuerzo para clientes el 30 de mayo. En el informe de junio, Mandiant y Snowflake habían notificado aproximadamente a 165 organizaciones que estaban potencialmente expuestas.

Cada término de esa última frase debe protegerse de la inflación. "Aproximadamente" indica una estimación. "Potencialmente expuestas" describe una población notificada, no 165 hallazgos forenses completados. "Organizaciones" no significa cuentas, bases de datos, personas ni registros. Algunas organizaciones pueden gestionar varias cuentas de Snowflake, y una cuenta puede contener datos sobre una población mucho mayor. El informe no proporciona un total de organizaciones confirmadas, personas afectadas, bytes exportados ni pagos de extorsión para toda la campaña.

El historial de credenciales explica por qué un inicio de sesión en la nube en 2024 podía comenzar con una infección de endpoint años antes. Mandiant descubrió que la mayoría de las credenciales utilizadas por UNC5537 estaban presentes en salidas históricas de infostealers, y la infección asociada más temprana se observó en noviembre de 2020. Al menos el 79,7 por ciento de las cuentas aprovechadas por el actor tenían exposición previa de credenciales. Ese porcentaje se aplica a las cuentas utilizadas por el actor en la campaña analizada, no a todos los clientes de Snowflake ni a las 165 organizaciones notificadas.

Tres condiciones convirtieron repetidamente los secretos expuestos en acceso funcional. Las cuentas afectadas no estaban configuradas con MFA. Las contraseñas encontradas en registros de infostealers seguían siendo válidas, a veces durante años. Las instancias de clientes afectadas carecían de listas de permitidos de red que restringieran las conexiones a orígenes de confianza. Ninguna de esas condiciones es un exploit novedoso. Juntas formaban una ruta de autorización duradera: conocer el localizador de la cuenta, el nombre de usuario y la contraseña aún válida; conectarse desde un sistema controlado por el atacante; recibir una sesión; heredar el rol asignado; consultar todo lo que ese rol pudiera leer.

La dimensión del endpoint también estaba más distribuida de lo que sugiere la narrativa convencional del portátil de un empleado. En varias investigaciones, Mandiant encontró la infección anterior de infostealer en sistemas de contratistas que también se utilizaban para actividades personales, como juegos o descargas pirateadas. Un dispositivo de contratista puede estar fuera de la flota de endpoints gestionados por el cliente y, sin embargo, llevar credenciales para varios clientes. También puede tener una cuenta administrativa porque a menudo se contrata a contratistas especializados para construir u operar plataformas de datos. El cliente que creó al usuario sigue siendo responsable de la identidad y sus privilegios, pero la exposición puede ser invisible para las herramientas de endpoint del propio cliente.

Esto es un multiplicador de dependencia en la nube. La credencial se roba de un endpoint, quizás fuera de la flota de Snowflake o del propietario de los datos. La credencial es aceptada por un servicio global. El rol puede alcanzar un almacén consolidado que contiene años de registros de varios sistemas empresariales. El atacante ya no necesita comprometer esos sistemas de origen uno por uno. El valor analítico que hacía útil el almacén para el cliente también hacía valioso el acceso exitoso para un actor de extorsión.

Los atacantes tienen la responsabilidad directa de robar, comprar, probar y utilizar credenciales; entrar en los entornos de los clientes sin autorización; llevarse datos; e intentar su venta o extorsión. Describir los fallos de control que hicieron posibles esos delitos no diluye esa responsabilidad. Explica por qué la misma técnica delictiva tuvo éxito a escala y dónde se puede reducir su repetición.

Las funciones compatibles se convirtieron en una vía de exfiltración

La campaña no se detuvo en la autenticación. Mandiant observó accesos a través de Snowsight, SnowSQL, controladores y herramientas de bases de datos. El actor enumeró usuarios, roles, sesiones, nombres de organizaciones, bases de datos, esquemas y tablas. Utilizó operaciones SQL familiares para seleccionar datos, crear etapas temporales, copiar la salida de consultas en archivos comprimidos y recuperar esos archivos en una máquina local. En varios casos, aparecieron comandos similares en diferentes entornos de clientes.

Esa secuencia hace que el incidente sea legible como funcionalidad ordinaria utilizada bajo una identidad no autorizada:

1. Un nombre de usuario y contraseña válidos de cliente establecieron una sesión.
2. La sesión heredó roles y privilegios sobre objetos asignados por el cliente.
3. El reconocimiento identificó tablas valiosas y etapas disponibles.
4. Las consultas seleccionaron registros que el rol podía leer.
5. El almacenamiento temporal yCOPY INTOconvirtieron los resultados en archivos descargables.
6. GETmovió los archivos a un cliente controlado por el atacante.

Ningún paso de esa cadena requirió que la base de datos funcionara mal. Por eso el cifrado en reposo, aunque necesario, no era el control decisivo. Ladocumentación de cifrado de extremo a extremo de Snowflakedice que los datos del cliente están cifrados en reposo y bajo TLS en tránsito, pero también explica que Snowflake descifra los datos mientras se realizan transformaciones u operaciones de tabla y permite a los usuarios descargar los resultados. El cifrado protege los archivos y el transporte de partes que carecen de autorización o claves. No impide que una identidad aceptada con un rol permitido le pida al servicio que devuelva resultados legibles.

El mismo principio se aplica a las claves gestionadas por el cliente. El control de claves puede abordar escenarios de proveedor, almacenamiento y revocación, pero una cuenta en ejecución debe usar su jerarquía de claves para servir consultas autorizadas. A menos que una política de claves esté vinculada a una decisión separada que rechace la sesión u operación, la base de datos no puede distinguir al propietario de la cuenta de un intruso que ha cumplido la política de autenticación configurada por el propietario.

Por lo tanto, el diseño de roles controlaba el radio después del inicio de sesión. Elmodelo de control de acceso actual de Snowflakeadmite controles de acceso basados en roles y discrecionales, propiedad, jerarquía de roles y privilegios sobre objetos. Una credencial asignada solo a una base de datos o vista limitada tiene una consecuencia diferente a una que tengaACCOUNTADMIN, un amplio uso del almacén o acceso de selección a conjuntos de datos sin procesar. Una cuenta de servicio utilizada por una integración no debe heredar el alcance exploratorio de un administrador humano. El rol temporal de un contratista debe expirar con el compromiso en lugar de permanecer inactivo con una contraseña válida.

Las políticas de protección de datos pueden reducir el resultado incluso cuando un rol está comprometido. Ladocumentación de clasificación de datos sensibles de Snowflakeconecta el descubrimiento de columnas personales y sensibles con políticas de enmascaramiento y acceso a filas. Se trata de una descripción de la capacidad actual, no de una prueba de que cada cliente afectado hubiera clasificado o enmascarado sus datos en 2024. Plantea la pregunta de diseño: ¿expuso el cliente tablas históricas completas a identidades que solo necesitaban agregados, particiones recientes, campos tokenizados o vistas aprobadas?

La exportación es en sí misma una función empresarial privilegiada y debe regirse como tal. Un almacén de datos a menudo necesita descargas masivas para canalizaciones legítimas, copias de seguridad, entrenamiento de modelos y sistemas posteriores. Una prohibición general rara vez es realista. Pero crear una etapa, descargar un resultado inusualmente grande o utilizar un cliente y origen de red desconocidos debe ser observable y, para conjuntos de datos de alto riesgo, puede justificar la aprobación, límites de velocidad, restricciones de destino, elevación de corta duración o un rol de exportación independiente. Los comandos de la campaña eran lo suficientemente normales como para ejecutarse, pero lo suficientemente inusuales en contexto como para merecer una decisión de seguridad rápida.

El cliente tenía la configuración; Snowflake tenía la línea base

La MFA es la prueba más clara de responsabilidad compartida porque ambas partes pueden afirmar un hecho cierto. El administrador del cliente podía y debía habilitarla. Snowflake había ofrecido MFA desde 2015 y políticas de red desde 2016. Al mismo tiempo, las cuentas activas en 2024 pudieron autenticarse sin MFA, lo que significa que la línea base efectiva del servicio permitía una ruta de solo contraseña para esas cuentas.

La diferencia entre disponibilidad y aplicación no es semántica. Una función de seguridad puede ser gratuita, estar documentada, ser recomendada y, sin embargo, estar ausente en las sesiones que importan. Los administradores se enfrentan a integraciones antiguas, usuarios de servicio no interactivos, contratistas, cuentas de emergencia, múltiples clientes y el temor al bloqueo. Esas limitaciones explican la fricción en la adopción; no justifican dejar el acceso humano privilegiado dependiendo de una contraseña reutilizable. También proporcionan al proveedor la información necesaria para crear herramientas de migración, separar identidades humanas y de servicio, y hacer explícitas las excepciones.

Después de la campaña, la dirección pública de Snowflake pasó de la recomendación a valores predeterminados más estrictos. Suanuncio de adhesión a Secure by Design de julio de 2024hizo hincapié en los controles de políticas de MFA y las comprobaciones del Trust Center. En septiembre de 2024, Snowflake dijo quela MFA se aplicaría por defectopara los usuarios humanos en las cuentas creadas a partir de octubre de 2024, al tiempo que recomendaba SSO con MFA del proveedor de identidad para humanos y OAuth o autenticación de par de claves para servicios. La distinción entre cuentas nuevas y existentes es importante. Un valor predeterminado seguro protege la creación futura; no elimina automáticamente todas las rutas de contraseña heredadas en la base instalada.

Snowflake introdujo más tarde laProtección de Contraseñas Filtradas, que utiliza fuentes de inteligencia de amenazas para probar contraseñas filtradas reportadas en un proceso que preserva la privacidad y deshabilita una contraseña cuando se confirma que sigue siendo válida. Ese control del lado del proveedor aborda directamente una de las ventajas de UNC5537: credenciales antiguas de infostealers que seguían siendo utilizables. También es una prueba de que la responsabilidad compartida puede evolucionar. Los clientes aún tienen que gestionar identidades y rotaciones, pero el proveedor puede usar inteligencia entre servicios para hacer que una contraseña robada deje de funcionar antes de que cada cliente la descubra de forma independiente.

Ladocumentación actual de políticas de autenticaciónpermite a los administradores controlar los métodos y clientes permitidos y exigir MFA a nivel de cuenta o de usuario. También advierte que las restricciones de tipo de cliente son de máximo esfuerzo y no deben ser el único límite de seguridad. Laguía actual de pares de clavesofrece a los usuarios de servicio una alternativa a las contraseñas estáticas. Estas páginas describen capacidades disponibles para 2026; no deben leerse en retrospectiva como prueba de las características exactas, los valores predeterminados o el estado de aplicación para cada cliente en abril de 2024.

Los estándares ayudan a explicar por qué los valores predeterminados del proveedor deben formar parte del análisis. Laguía actual de autenticación y gestión de autenticadores del NISTtrata las contraseñas como no resistentes a la repetición y define la resistencia al phishing como una propiedad del protocolo que no depende de la vigilancia del usuario. Elcompromiso Secure by Design de CISA de 2024identifica específicamente la MFA por defecto, los recordatorios persistentes en el producto, el soporte básico de SSO y la publicación de métricas de adopción como formas en que los fabricantes de software pueden aumentar de manera mensurable el uso de la MFA. Snowflake firmó ese compromiso voluntario después de la campaña. El compromiso no es un veredicto legal sobre el diseño de Snowflake en 2024, pero rechaza la idea de que ofrecer una casilla de verificación agote el papel del proveedor.

La línea base responsable distingue los tipos de identidad. Los administradores humanos deben utilizar MFA resistente al phishing o una identidad federada fuertemente gobernada. Las cargas de trabajo de servicio deben usar credenciales de carga de trabajo que puedan ser delimitadas, rotadas y atribuidas sin pretender que un robot pueda responder a una notificación push. El acceso de emergencia debe ser poco frecuente, supervisado, limitado en el tiempo y probado. Las identidades de contratistas deben tener un propietario, caducidad, postura de dispositivo aprobada y no reutilizar credenciales entre clientes. Cada excepción debe aparecer en un panel cuyo denominador sean todas las identidades, no solo los empleados activos.

La política de red era un segundo control, no un sustituto de la identidad

El tercer factor recurrente de Mandiant fue la ausencia de listas de permitidos de red. Por lo tanto, una credencial válida podía utilizarse desde una infraestructura que no tenía ninguna razón comercial para acceder al almacén del cliente. Las restricciones de red no repararían una contraseña robada, pero podrían hacer que esa contraseña fuera insuficiente desde un origen no confiable.

Ladocumentación actual de políticas de red de Snowflakehace explícito el valor predeterminado: sin una política, los usuarios pueden conectarse desde cualquier ordenador o dispositivo. Los clientes pueden permitir o bloquear rangos de IP y puntos finales privados, aplicar controles a nivel de cuenta o de usuario y restringir el acceso a etapas internas con configuración adicional. La conectividad privada y los controles de acceso público pueden reforzar aún más las cuentas de alta sensibilidad.

El cliente conoce sus oficinas aprobadas, cargas de trabajo en la nube, VPN, contratistas y puntos finales de integración, por lo que el cliente debe definir la lista de permitidos utilizable. Snowflake no puede inferir todos los orígenes legítimos sin interrumpir el negocio. Sin embargo, el proveedor controla la accesibilidad predeterminada, la sintaxis de la política, la capacidad de simular un cambio, la protección contra bloqueos, el registro y si se advierte al administrador cuando no existe una política de cuenta. Una plataforma puede preservar la elección del cliente mientras convierte el acceso público sin restricciones en una excepción visible y con límite de tiempo en lugar de un estado estable silencioso.

Las reglas de red también tienen límites. Los atacantes pueden obtener una sesión desde un dispositivo de contratista aprobado, enrutarse a través de una VPN corporativa permitida, comprometer una carga de trabajo dentro de la nube permitida o robar un token después de la autenticación. Las grandes empresas pueden tener direcciones de salida cambiantes que dificultan las listas estáticas. La conectividad privada puede excluir herramientas SaaS que no la admiten. Estas son razones para combinar los controles de red con una identidad sólida y detección de comportamiento, no para omitirlos.

La campaña demuestra el valor de los controles independientes. La rotación de contraseñas habría invalidado las credenciales históricas. La MFA habría requerido otro factor. Una política de red habría rechazado orígenes desconocidos. El mínimo privilegio habría reducido los datos visibles. Los controles de exportación podrían haber interrumpido la preparación. La detección podría haber acortado el tiempo de permanencia. Ninguna medida por sí sola es perfecta; el atacante tuvo éxito donde varias estaban ausentes o eran permisivas al mismo tiempo.

Para la responsabilidad, cada control necesita un propietario y una medida de eficacia. "Política de red compatible" es un hecho del producto. "Cada cuenta de producción tiene una política probada que cubre el servicio y las etapas internas" es un resultado operativo. "MFA disponible" es un hecho del producto. "Ningún humano privilegiado puede establecer una sesión solo con una contraseña reutilizable" es un resultado. La responsabilidad compartida solo tiene sentido cuando ambas partes pueden mostrar los resultados en su límite.

El proveedor veía una campaña que cada cliente solo podía ver como un incidente

Un cliente individual podía inspeccionar sus propios inicios de sesión fallidos y exitosos, clientes, direcciones IP, texto de consulta, roles, etapas y movimientos de datos. Snowflake podía correlacionar patrones entre cuentas: la misma infraestructura, clientes inusuales, reconocimiento repetido, comandos de preparación similares, un aumento en los inicios de sesión solo con contraseña o credenciales coincidentes con fuentes de inteligencia de amenazas. Esta asimetría es la responsabilidad no contractual más importante del proveedor. Surge de operar el servicio a escala.

Lavista LOGIN_HISTORY actual de Snowflakeconserva un año de intentos de inicio de sesión e incluye usuario, IP de origen, cliente informado, primer y segundo factor, éxito y detalles de riesgo relacionados, con latencia documentada.QUERY_HISTORYconserva un año de actividad de consultas y conecta una consulta con el evento de autenticación, sesión, usuario, rol, texto, bytes de resultado, filas descargadas y bytes enviados por la red. Los clientes empresariales pueden usarACCESS_HISTORYpara reconstruir las tablas, vistas, columnas, etapas, políticas y objetos modificados a los que se accedió. Esos esquemas proporcionan la materia prima para una investigación de alta calidad.

El historial en bruto no es lo mismo que la detección. Un cliente debe conceder acceso a los analistas, exportar o consultar los datos, comprender el comportamiento normal, escribir alertas, enrutarlas, conservarlas más allá de las ventanas nativas si es necesario y dotar de personal a la respuesta. Una latencia de telemetría de dos horas puede ser aceptable para la revisión retrospectiva, pero demasiado lenta para algunas decisiones de exportación masiva. Un límite de Enterprise Edition en el historial de acceso a nivel de columna también puede afectar a la precisión con la que un cliente puede delimitar la exposición. Estos hechos operativos y de producto deben probarse durante la adquisición, no descubrirse después de un robo.

ElTrust Center actual de Snowflakeverifica la inscripción en MFA, la política de red de la cuenta, los roles privilegiados, los usuarios inactivos, los inicios de sesión de riesgo, las direcciones IP inusuales y las grandes transferencias de datos a través de escáneres de seguridad e inteligencia de amenazas. La documentación actual también indica limitaciones: algunos paquetes deben estar habilitados; algunas detecciones pueden llegar en una hora; y la existencia de una política configurada no prueba que su contenido logre el objetivo previsto. Una vez más, la capacidad actual no es evidencia de lo que un cliente determinado o Snowflake detectaron en la primavera de 2024. Muestra lo que un proveedor puede convertir en producto una vez que se comprende un patrón de fallo entre clientes.

El sistema de advertencia debe operar en dos capas. En la capa de inquilino, los clientes necesitan eventos inmediatos y exportables y controles para bloquear o suspender la actividad. En la capa de proveedor, Snowflake necesita análisis de campaña y un proceso practicado para notificar a los clientes con suficiente evidencia para actuar. Una notificación útil incluye identificadores de cuenta y usuario, marcas de tiempo en UTC, infraestructura de origen, factor de autenticación, IDs de sesión y consulta, comandos, objetos y columnas afectados, acciones de preparación, volumen de transferencia estimado, estado de contención y confianza. "Potencialmente expuesto" es una etiqueta inicial apropiada solo si va seguida de la evidencia necesaria para resolver el potencial.

La intervención del proveedor también necesita gobernanza. Bloquear automáticamente una sesión de cliente puede interrumpir la producción y exceder la autoridad contractual del proveedor. No actuar puede permitir la continuación del robo. Por lo tanto, el diseño debe definir de antemano umbrales de riesgo, retenciones temporales, canales de escalado de clientes, contactos de emergencia y un proceso de anulación rápida. Los clientes deben designar a personas que puedan recibir una alerta de alta gravedad a cualquier hora y autorizar la suspensión. El proveedor debe medir el tiempo desde la señal entre cuentas hasta el contacto con el cliente, el tiempo hasta la contención y la proporción de clientes notificados que pueden recuperar un paquete de evidencia completo.

La localidad de los datos no hizo que el acceso fuera local

Snowflake comercializa y documenta el despliegue regional porque los clientes tienen requisitos de latencia, resiliencia, privacidad, regulación y soberanía. Ladocumentación de regiones compatibles de Snowflakedice que cada cuenta se aloja en una región y que los datos permanecen en esa región a menos que los usuarios los copien, muevan o repliquen explícitamente. La misma página contiene el límite crítico: las regiones determinan dónde se almacenan los datos y se aprovisiona la computación; no limitan el acceso de los usuarios a Snowflake.

Esa distinción convierte la cadena UNC5537 en un caso de soberanía. Antes de la intrusión, las tablas de un cliente pueden haberse almacenado y procesado en un país seleccionado o en una ubicación regional en la nube. Después de una autenticación exitosa, el atacante podía consultar la cuenta regional desde otro lugar, preparar los resultados y descargarlos en un cliente. Mandiant observó el patrón técnico de recuperación local desde etapas temporales. El registro público de la campaña no establece el país de origen, el país de destino ni el estado legal de la transferencia para cada víctima, por lo que no se puede respaldar una afirmación universal de transferencia transfronteriza ilegal. Sin embargo, la arquitectura muestra que la localidad de almacenamiento por sí sola no podía hacer cumplir la localidad del usuario.

El uso compartido y la replicación entre regiones crean una ruta de movimiento legítima y separada. Laguía de uso compartido entre regiones de Snowflakeindica a las organizaciones que confirmen las restricciones legales y reglamentarias antes de replicar datos en una región o país diferente. Eso es un movimiento planificado bajo la administración del cliente. La exportación impulsada por credenciales es diferente: puede crear una copia no controlada fuera del entorno seleccionado sin cambiar la ubicación de la cuenta de origen. Un inventario de datos que solo registre la región de origen seguirá diciendo "UE" o "Canadá" incluso después de que un atacante haya extraído una copia.

Por lo tanto, la soberanía de datos tiene al menos cuatro capas:

• Ubicación:dónde se aprovisionan los recursos autoritativos de almacenamiento y computación.
• Acceso:qué identidades humanas y de máquina pueden conectarse, desde qué dispositivos, redes y jurisdicciones.
• Movimiento:qué consultas, descargas, comparticiones, replicaciones, conectores y descargas pueden crear otra copia.
• Evidencia y remedio:si la organización puede demostrar dónde se originó el acceso, qué salió, qué personas o registros regulados estuvieron involucrados y con qué rapidez puede contener y notificar.

El proveedor controla partes importantes de las cuatro capas incluso cuando el cliente elige la política. Ofrece regiones y mantiene los datos de la cuenta en ellas. Autentica las solicitudes y expone los controles de red. Ejecuta comandos de exportación y registra metadatos de consultas. Tiene visibilidad de amenazas entre clientes y puede deshabilitar contraseñas filtradas. El cliente decide su base legal, categorías de datos, roles, orígenes permitidos, enmascaramiento, retención y movimiento aprobado. Un compromiso de alojamiento regional sin estos controles complementarios puede satisfacer un requisito limitado de ubicación del centro de datos, dejando expuesta la autoridad práctica para copiar datos a nivel global.

Esta es también la razón por la que el cifrado y la soberanía no deben confundirse. El cifrado puede proteger un objeto almacenado del operador de la infraestructura o de un lector no autorizado en la capa de almacenamiento. Una aplicación que debe analizar el objeto necesariamente pone los datos a disposición de un contexto de consulta autorizado. Si la garantía de identidad y el alcance del rol son débiles, la localidad criptográfica puede coexistir con la exfiltración operativa.

Las divulgaciones de los clientes muestran consecuencias diferentes, no una brecha uniforme

La campaña se describe a menudo a través de nombres de clientes destacados, pero el registro público de cada cliente tiene su propio alcance, fechas, datos, terminología y confianza. No es seguro transferir los hechos de una empresa a otra ni convertir una afirmación de un foro criminal en una población verificada.

ElFormulario 8-K de Live Nation del 31 de mayo de 2024decía que identificó actividad no autorizada el 20 de mayo en un entorno de base de datos en la nube de un tercero que contenía datos de la empresa, principalmente de Ticketmaster. Decía que el 27 de mayo un actor criminal ofreció a la venta lo que afirmaba ser datos de usuarios de la empresa, y que Live Nation estaba notificando a las fuerzas del orden, reguladores y usuarios según correspondiera. La presentación no nombraba a Snowflake, no proporcionaba un recuento confirmado de personas afectadas ni explicaba la ruta de autenticación.

Lapágina de incidentes de Ticketmaster Canadáofrece un nivel de detalle diferente. Describe el acceso no autorizado a una base de datos aislada en la nube alojada por un proveedor de servicios de datos externo, dice que la base de datos contenía información personal limitada de algunos compradores de entradas norteamericanos y enumera posibles campos como correo electrónico, número de teléfono, información de tarjeta cifrada y otra información proporcionada por los clientes. Dice que las cuentas de clientes de Ticketmaster no se vieron afectadas. Ese último límite es importante: el compromiso de un almacén de datos back-end no es prueba de que el atacante obtuviera el inicio de sesión de Ticketmaster de cada persona ni pudiera realizar transacciones a través de la cuenta de consumidor.

Lahoja de asuntos parlamentarios de octubre de 2025 de la Oficina del Comisionado de Privacidad de Canadáidentifica a Snowflake como el proveedor externo utilizado por Ticketmaster, da una ventana de incidentes del 2 de abril al 18 de mayo de 2024 para Ticketmaster Canadá y dice que estuvo involucrada información personal de millones de personas, incluidos canadienses. También dice que la investigación seguía abierta y que Ticketmaster Canadá, como responsable del tratamiento de datos en virtud de la PIPEDA, era la entidad investigada. Este es un contexto regulatorio útil, pero no una conclusión definitiva que resuelva la adecuación de las salvaguardias, el momento de la notificación o la responsabilidad.

ElFormulario 8-K de AT&T del 12 de julio de 2024ilustra por qué los límites de las fuentes importan incluso cuando los incidentes se discuten juntos. AT&T dijo que un actor accedió ilegalmente a un espacio de trabajo de AT&T en una plataforma en la nube de un tercero y exfiltró archivos del 14 al 25 de abril. Los archivos contenían registros de interacciones de llamadas y mensajes de texto de casi todos los clientes inalámbricos de AT&T y clientes relevantes de operadores de redes móviles virtuales durante períodos específicos en 2022 y un día en 2023. AT&T dijo que los archivos no contenían contenido de llamadas o mensajes, números de Seguro Social, fechas de nacimiento u otra información personal según el término utilizado por AT&T. La presentación en sí no nombra a Snowflake ni a UNC5537. Respalda los hechos del incidente de AT&T, no una atribución de campaña por sí misma.

Estos registros dan lugar a cuatro reglas de disciplina. Primero, usar la presentación de un cliente solo para ese cliente. Segundo, distinguir entre una base de datos, una cuenta organizativa y un inicio de sesión de consumidor. Tercero, distinguir los campos de datos del número de personas que representan. Cuarto, preservar los hechos negativos como "sin contenido de mensajes" o "cuenta de consumidor no afectada" junto con el impacto. La responsabilidad se vuelve menos creíble cuando el análisis amplía las afirmaciones dramáticas y omite las limitantes.

Los clientes seguían siendo responsables de los datos e identidades que delegaban

La parte del cliente en la responsabilidad compartida es sustancial. La organización creaba o aprobaba usuarios de Snowflake, seleccionaba métodos de autenticación, asignaba roles, cargaba datos, conservaba el historial, elegía una región, habilitaba integraciones y decidía qué empleados y contratistas podían consultar el almacén. También mantenía la relación principal con las personas representadas en sus datos y generalmente conservaba las obligaciones de responsable del tratamiento según la legislación de privacidad aplicable.

Un cliente podría haber interrumpido la campaña observada en varios puntos. Podría rotar las contraseñas después de la exposición del endpoint, prohibir las cuentas de servicio solo con contraseña, exigir MFA para humanos, federar el acceso a través de un proveedor de identidad gobernado, restringir las redes, hacer expirar a los usuarios contratistas, reducir las concesiones de roles, clasificar y enmascarar campos sensibles, aislar el privilegio de exportación, supervisar el historial de inicio de sesión y consultas y ensayar las notificaciones al proveedor de la nube. Para conjuntos de datos regulados o de alto impacto, esas son obligaciones operativas básicas, no mejoras opcionales delegadas a la adquisición.

La gobernanza de endpoints y contratistas merece una atención especial. Un usuario con un rol en la nube de alto impacto no debe autenticarse desde un ordenador personal no gestionado. Los contratistas deben usar escritorios virtuales controlados por el cliente o dispositivos con supervisión de endpoint cuando sea factible. Su identidad debe ser única por cliente, vinculada a un patrocinador y expirar automáticamente. La organización debe buscar en las fuentes de exposición de credenciales los patrones de su cuenta de Snowflake y forzar la rotación cuando aparezcan pruebas, sin esperar a un uso indebido confirmado.

El privilegio mínimo debe probarse con respecto a los datos, no al cargo. "Analista" puede sonar no administrativo pero conservar acceso de selección a cada fila de una tabla de clientes, empleados o transacciones. Una revisión de roles debe preguntar qué filas y columnas se pueden devolver, si se necesitan identificadores sin procesar, si los conjuntos de resultados masivos se pueden escribir en etapas y si la identidad puede crear nuevas credenciales o integraciones. Las consultas de muestra bajo el rol son una evidencia más sólida que un nombre de rol de aspecto limpio.

Los clientes también deben tener preparación para la respuesta. Deben poder mapear un usuario de Snowflake a un empleado o contratista, una consulta a los interesados afectados y una exportación a un análisis de jurisdicción y notificación. Los historiales nativos de un año pueden ser insuficientes para una retención legal más prolongada o un descubrimiento tardío, por lo que los clientes de alto riesgo deben transmitir los eventos relevantes a un almacén de seguridad independiente. Las alertas del proveedor necesitan una ruta probada hacia el equipo de seguridad del cliente, la oficina de privacidad, el propietario del negocio y el responsable ejecutivo de la toma de decisiones.

Laguía de la cadena de suministro del Marco de Ciberseguridad del NISTrecomienda definir y comunicar los requisitos de los proveedores según la criticidad. Aplicado aquí, un cliente de Snowflake debe contratar plazos de notificación de incidentes, campos de evidencia, retención, escalado de soporte, procesamiento regional, visibilidad de subprocesadores, notificación de cambios de control y acceso de garantía. También debe mantener un plan de salida o aislamiento para las funciones de datos cuya pérdida o compromiso sería intolerable. La responsabilidad compartida debe redactarse como interfaces comprobables, no como un párrafo que aparece solo después de un incidente.

Snowflake seguía siendo responsable de la reducción del riesgo a nivel de servicio

Snowflake no controlaba el malware en el dispositivo personal de un contratista ni la decisión del cliente de dejar la MFA deshabilitada. Sí controlaba si una contraseña antigua podía seguir siendo el único factor, si los orígenes sin restricciones eran el valor predeterminado silencioso, si las configuraciones de riesgo generaban advertencias persistentes y lo que hacía el proveedor después de observar un patrón entre clientes.

La responsabilidad del proveedor en este caso tiene seis partes.

Línea base segura.El acceso humano privilegiado no debe depender únicamente de una contraseña reutilizable. Las identidades de servicio deben tener un tipo separado y métodos sin contraseña compatibles. Los nuevos valores predeterminados deben llegar a las cuentas de alto riesgo existentes mediante la aplicación por fases, excepciones explícitas y ayuda a la migración, en lugar de proteger solo a los nuevos inquilinos.

Visibilidad de la configuración.El proveedor debe mostrar a los administradores de seguridad un denominador completo: humanos sin MFA, usuarios de servicio heredados con contraseñas, cuentas inactivas, usuarios sin restricciones de red, roles privilegiados y cuentas que permiten el acceso público. Los hallazgos deben ser visibles a nivel de organización y exportables para auditoría.

Detección entre clientes.La infraestructura reutilizada, las credenciales filtradas, los clientes inusuales, las secuencias de reconocimiento, la creación de etapas temporales y las grandes exportaciones pueden formar una señal de campaña. El proveedor debe detectar en la capa de servicio, contactar a las posibles víctimas y definir cuándo la actividad de alta confianza desencadena un bloqueo temporal.

Telemetría procesable.Los clientes necesitan evidencia de autenticación, consultas, objetos, etapas y transferencias con suficiente retención y una latencia lo suficientemente baja como para contener un robo activo. La evidencia de mayor fidelidad no debe dejar de estar disponible precisamente donde el servicio almacena los datos de mayor impacto.

Advertencia y coordinación.Una alerta al cliente debe moverse a través de una ruta de emergencia conocida y llevar evidencia, no solo un consejo para revisar los registros. El proveedor debe realizar un seguimiento del acuse de recibo, la contención y la exposición recurrente, y debe apoyar las solicitudes de las fuerzas del orden y los reguladores sin convertir las observaciones inciertas en recuentos confirmados de víctimas.

Verificación posterior al incidente.Las funciones y los valores predeterminados anunciados necesitan medidas de adopción y eficacia. Los cambios posteriores de Snowflake hacia la MFA por defecto, la desactivación de contraseñas filtradas, los hallazgos del Trust Center y los tipos de identidad más sólidos abordan la ruta observada. La cuestión de responsabilidad pendiente es la cobertura: ¿qué usuarios y clientes están realmente protegidos, qué excepciones persisten y con qué frecuencia un control detiene un intento real o simulado?

Esta asignación no convierte a Snowflake en el responsable del tratamiento de cada conjunto de datos de los clientes, ni hace al proveedor responsable de cada configuración del cliente. Reconoce que una empresa en la nube se beneficia de concentrar datos y operar un límite de seguridad. La escala crea deberes que solo el proveedor puede cumplir, especialmente la correlación entre inquilinos y la ingeniería de la línea base.

Los litigios posteriores ponen a prueba el mismo límite sin resolverlo aún

Snowflake y las empresas afectadas se enfrentaron a litigios civiles consolidados después de los incidentes. En unaorden del tribunal federal del 29 de octubre de 2025, el Distrito de Montana sostuvo que los demandantes de instituciones financieras habían alegado suficientemente ciertas teorías de negligencia contra Snowflake y Ticketmaster para sobrevivir a las mociones de desestimación. El tribunal consideró que la MFA por defecto alegada y la previsibilidad eran relevantes para el deber, el incumplimiento y la causalidad en esa etapa procesal.

Esa orden no es una constatación de que Snowflake o Ticketmaster fueran negligentes. En una moción de desestimación, el tribunal comprueba si las alegaciones bien fundamentadas exponen una reclamación plausible; no resuelve las pruebas controvertidas, no determina el mecanismo final del incidente para cada demandante ni asigna daños. Snowflake refutó las alegaciones y argumentó que los fallos de los clientes al implementar la MFA, las políticas de red y otras salvaguardias causaron el daño. La orden es significativa porque muestra que describir la MFA como una configuración del cliente no puso fin automáticamente a toda reclamación de deber del proveedor. No es un sustituto del registro final de los méritos.

La investigación de privacidad canadiense tuvo una asignación diferente. La OPC dijo que Ticketmaster Canadá seguía siendo el responsable del tratamiento y la entidad investigada, mientras que la oficina se puso en contacto con Snowflake para obtener información. Esto refleja un principio de privacidad común: externalizar el almacenamiento no externaliza el deber del responsable de proteger y notificar. No significa que el proveedor de servicios no tenga deberes contractuales, técnicos o legales propios.

El propio 10-K de Snowflake reconoció numerosas demandas, investigaciones regulatorias y consultas legislativas, pero no informó de una asignación universal definitiva de responsabilidad. A la fecha de publicación, las fuentes públicas revisadas aquí no respaldan la afirmación de que Snowflake haya sido exonerada legalmente, de que todos los clientes tuvieran la culpa legal o de que un tribunal o regulador final haya adoptado la asignación operativa de este artículo.

La responsabilidad operativa puede evaluarse antes de la responsabilidad final. ¿Era previsible el acceso solo con contraseña? Sí. ¿Podía el cliente exigir MFA y políticas de red? Sí. ¿Podía Snowflake diseñar valores predeterminados y detectar la actividad entre clientes? Sí. ¿Explotaron los criminales intencionadamente la ruta resultante? Sí. Esas proposiciones pueden coexistir. Las leyes de responsabilidad civil, contractual, de privacidad y de valores pueden asignar consecuencias de manera diferente según la jurisdicción y el demandante, pero la ingeniería no debe esperar a que gane un eslogan.

Una prueba medible de responsabilidad compartida

La respuesta más contundente no es otro diagrama con "cliente" en un lado y "proveedor" en el otro. Es un conjunto de controles cuya cobertura y comportamiento ante fallos se pueden demostrar.

Los consejos de administración deben recibir resultados en lugar de inventarios de funciones. Las medidas útiles incluyen el porcentaje de usuarios humanos protegidos por MFA resistente al phishing, el número de usuarios de servicio capaces de usar contraseña, la antigüedad de cada excepción de emergencia, el porcentaje de cuentas con políticas de red probadas, el número de identidades de contratistas privilegiados caducadas, el tiempo medio para alertar sobre orígenes desconocidos, el tiempo para suspender una sesión de alta confianza y el tiempo para producir un paquete de exposición a nivel de campo.

Snowflake debe publicar el progreso agregado cuando pueda hacerlo sin exponer a los clientes. El compromiso de CISA contempla explícitamente estadísticas de adopción por usuario y tipo de MFA. Una declaración de que la MFA está disponible es menos informativa que la distribución de los inicios de sesión solo con contraseña a lo largo del tiempo. Una declaración de que el Trust Center está habilitado es menos informativa que cuántos hallazgos críticos permanecen abiertos más allá de un período definido. Una declaración de que se notificó a los clientes sospechosos es menos informativa que la latencia de notificación y la integridad del paquete de evidencia.

Los clientes deben exigirse el mismo rigor a sí mismos. Un proveedor no puede salvar a una organización que crea roles amplios, ignore los hallazgos, mantenga antiguos usuarios contratistas y no tenga a nadie que responda al contacto de emergencia. El propósito de unos valores predeterminados más estrictos no es transferir la propiedad de la seguridad del cliente a Snowflake. Es hacer que las omisiones predecibles sean menos propensas a convertirse en un robo masivo de datos.

Lo que el registro público aún no establece

La evidencia es lo suficientemente sólida como para reconstruir un patrón de campaña, pero no todos los incidentes de las víctimas.

El registro público no identifica a todas las organizaciones notificadas, no confirma que las 165 sufrieran acceso no autorizado ni proporciona un total definitivo de personas, tablas, registros o bytes descargados afectados en toda la campaña. No muestra qué víctimas pagaron las demandas de extorsión ni si se produjo la eliminación prometida.

No publica el tipo de usuario, la jerarquía de roles, el historial de MFA, la configuración de red, el propietario del endpoint, la secuencia de sesiones, las columnas accedidas ni el volumen de exportación de cada organización. Los hallazgos sobre dispositivos de contratistas de varias investigaciones no deben asignarse a todas las víctimas. La estadística del 79,7 por ciento de exposición de credenciales no debe convertirse en un porcentaje de víctimas.

No establece una vulnerabilidad de software, escape entre inquilinos, compromiso de la plataforma de producción de Snowflake, robo de una credencial maestra del proveedor ni acceso a todos los clientes de Snowflake. El uso observado de clientes y comandos compatibles es evidencia de abuso de credenciales, no prueba de que se explotara el código del producto.

No prueba que los datos regionales cruzaran una frontera nacional en todos los incidentes. La arquitectura permitía el acceso remoto y la descarga local; el análisis legal de transferencia requeriría hechos de origen, destino, interesado, contractuales y de jurisdicción para cada cliente.

No permite que los posibles campos de Ticketmaster, el alcance de los detalles de llamadas de AT&T ni ningún recuento de foros criminales se generalicen a otros clientes. La presentación de Live Nation no nombraba a Snowflake. La presentación de AT&T no nombraba a Snowflake ni a UNC5537. La asociación externa puede ser relevante para una investigación posterior, pero las presentaciones deben citarse por lo que realmente establecen.

Por último, la documentación actual de Snowflake no prueba el funcionamiento de los controles en abril y mayo de 2024. La MFA predeterminada posterior, la protección de contraseñas filtradas, la detección del Trust Center, las políticas de autenticación y los cambios de identidad pueden reducir la repetición, pero la evidencia pública de adopción, cobertura de excepciones, rendimiento de detección y efectividad independiente sigue siendo más limitada que las descripciones de las funciones.

La responsabilidad compartida debe sobrevivir al momento en que se ignora una recomendación

La campaña de Snowflake no se entiende mejor como un concurso entre dos historias absolutas. Una historia dice que la plataforma fue pirateada y el proveedor solo fracasó. La evidencia no lo respalda. La otra dice que los clientes perdieron las contraseñas y, por lo tanto, la cuestión del proveedor está cerrada. Eso es técnicamente incompleto.

UNC5537 encontró una unión escalable entre el compromiso del endpoint y la concentración en la nube. Las contraseñas históricas seguían siendo válidas. Las identidades humanas y de servicio no siempre estaban separadas. Las barreras de MFA y red estaban ausentes. Las funciones de consulta y preparación compatibles movían los datos rápidamente. El proveedor podía ver un patrón entre los inquilinos, mientras que cada cliente solo veía su propia cuenta. Una región de almacenamiento elegida podía mantener los datos de origen en su lugar incluso cuando una sesión autenticada creaba una copia no controlada en otro lugar.

Los clientes tenían el deber más claro de gobernar a sus usuarios, roles, endpoints, contratistas y datos. Snowflake tenía el deber más claro de asegurar y observar el límite del servicio, hacer que las protecciones de alto valor fueran fáciles y cada vez más inevitables, detectar el comportamiento de campaña y proporcionar evidencia. Los atacantes tenían la responsabilidad directa de los actos delictivos. Los reguladores y los tribunales deben evaluar los deberes legales sobre la base de los hechos y la ley aplicable a cada organización. Estas asignaciones se superponen porque los controles se superponen.

La dirección del producto posterior a la campaña reconoce implícitamente la brecha entre la capacidad y el resultado. La MFA predeterminada para nuevos usuarios humanos, la desactivación de contraseñas filtradas, una política de autenticación más sólida, la migración de usuarios de servicio y los hallazgos del Trust Center acercan la seguridad a la línea base del proveedor. No borran la responsabilidad del cliente. Hacen que el sistema compartido dependa menos de que cada administrador encuentre y habilite cada opción correcta antes de que se pruebe una contraseña robada.

Esa es la prueba duradera de responsabilidad para una plataforma de datos en la nube. Supongamos que un cliente pasará por alto una advertencia, un dispositivo de contratista se infectará, una credencial seguirá siendo válida y un atacante utilizará funciones normales del producto. Luego preguntar si el valor predeterminado bloquea el inicio de sesión, otra barrera rechaza el origen, el rol revela poco, la exportación desencadena la intervención y la evidencia llega al cliente a tiempo. La responsabilidad compartida solo es creíble cuando el servicio sigue siendo defendible después del error predecible de una de las partes, y cuando ambas partes pueden demostrar lo que hicieron antes y después del mismo.