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 motivaciones financieras a UNC5537 y señaló que todos los incidentes de la campaña que manejó directamente se debieron a credenciales de clientes comprometidas. No encontró evidencia de que el acceso no autorizado a los clientes surgiera de una vulneración del entorno empresarial de Snowflake. Snowflake también indicó que no encontró evidencia de una vulnerabilidad, mala configuración o brecha en su plataforma que causara la actividad.
• Cadena de control observada:Las cuentas comprometidas carecían de autenticación multifactor, conservaban credenciales expuestas en registros históricos de infostealer y no tenían listas de permitidos de red. 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; no es un recuento de brechas confirmadas, personas o registros.
• Hallazgo sobre responsabilidad compartida:Los clientes controlaban sus usuarios, roles, rotación de contraseñas, habilitación de MFA, políticas de red, higiene de endpoints y minimización de datos. Snowflake controlaba qué protecciones existían, cómo se presentaban y configuran por defecto, qué señales entre clientes podía ver la plataforma y con qué rapidez las advertencias y un comportamiento base más sólido llegaban a la base instalada. Estas responsabilidades son concurrentes, no mutuamente excluyentes.
• Hallazgo sobre soberanía:Elegir una región de Snowflake determina dónde se almacenan los datos de la cuenta y se aprovisiona la computación; 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 localidad de los datos sin controles de identidad, egreso y evidencia es una decisión de colocación, no un control de soberanía completo.

No se demostró que la plataforma estuviera vulnerada, 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 era lo mismo que el entorno empresarial propio de Snowflake ni que la plataforma de producción compartida. Una persona con credenciales válidas podía acceder a la cuenta de un cliente sin cruzar 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 a nivel de plataforma.

El informe de la campaña UNC5537 de Mandiant es inusualmente directo al respecto. Para cada incidente asociado con la campaña que Mandiant manejó personalmente, la causa raíz fueron credenciales de cliente comprometidas. Su investigación no encontró evidencia de que el acceso no autorizado a las cuentas de los clientes se debiera a una vulneración del entorno empresarial de Snowflake. El propio aviso de investigación y endurecimiento de Snowflake separó de manera similar las cuentas de clientes objetivo de la plataforma de producción y proporcionó a los clientes consultas e indicadores para investigar sus propios entornos.

CISA amplificó esa guía en una alerta del 3 de junio de 2024.

Ese hallazgo negativo es importante. Llamar al evento 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 desbloqueaba a los clientes. El registro revisado no establece ninguna de las dos cosas. También oscurecería las acciones que los clientes necesitaban tomar de inmediato: identificar usuarios solo con 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 pregunta sobre la responsabilidad del proveedor. Un servicio en la nube no es simplemente un disco neutral en el que un cliente coloca bits. Snowflake construyó y operó los puntos de autenticación que aceptaron las credenciales, las interfaces que usaron 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 restringido el origen de la red.

Snowflake también tenía visibilidad entre clientes que ningún cliente individual podrí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 proporcionados a la concentración de datos en su servicio.

El Formulario 10-K del año fiscal 2025 de Snowflake formaliza su posición. Dice que Snowflake es responsable de la plataforma y la seguridad subyacente de la infraestructura en la nube, 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 MFA y políticas de red, mientras registra demandas, investigaciones regulatorias, consultas de legisladores, daños a la reputación y la posibilidad de disputas de indemnización.

Esa es evidencia material de la empresa sobre el modelo declarado de Snowflake y su exposición comercial. No es una adjudicación independiente de que toda responsabilidad o reclamo legal pertenezca al lado del cliente.

Por lo tanto, la pregunta útil es más estrecha que "¿Quién fue vulnerado?" y más amplia que "¿De quién se robó la contraseña?". Es: en cada paso, desde el secreto robado hasta los datos descargados, ¿qué actor pudo prevenir, detectar, interrumpir, reconstruir o advertir sobre la acción? La responsabilidad sigue el control sobre esos pasos.

La campaña combinó el robo antiguo 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 luego se rastrearon hasta una instancia de Snowflake de una víctima. Esa víctima contrató a Mandiant, que concluyó que el intruso utilizó credenciales previamente robadas por malware infostealer. La cuenta relevante no tenía MFA habilitado. El 22 de mayo, después de identificar inteligencia que apuntaba a una campaña más amplia, Mandiant contactó a Snowflake y comenzó a notificar a posibles víctimas. Snowflake publicó una guía de detección y endurecimiento para clientes el 30 de mayo.

Para el informe de junio, Mandiant y Snowflake habían notificado a aproximadamente 165 organizaciones que estaban potencialmente expuestas.

Cada término en esa última oración necesita protección contra la inflación. "Aproximadamente" marca una estimación. "Potencialmente expuestas" describe una población notificada, no 165 hallazgos forenses completos. "Organizaciones" no significa cuentas, bases de datos, personas o registros. Algunas organizaciones pueden operar múltiples cuentas de Snowflake, y una cuenta puede contener datos sobre una población mucho más grande. El informe no proporciona un total de toda la campaña de organizaciones confirmadas, individuos afectados, bytes exportados o pagos de extorsión.

El historial de credenciales explica por qué un inicio de sesión en la nube en 2024 podría comenzar con una infección de endpoint años antes. Mandiant encontró que la mayoría de las credenciales utilizadas por UNC5537 estaban presentes en resultados históricos de infostealer, con la infección asociada más temprana observada 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 los registros de infostealer 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 formaron 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 lo que ese rol pueda leer.

La dimensión del endpoint también estaba más distribuida de lo que sugiere una narrativa convencional de laptop de empleado. En varias investigaciones, Mandiant encontró la infección anterior de infostealer en sistemas de contratistas que también se usaban para actividades personales, incluidos juegos o descargas piratas. Un dispositivo de contratista puede estar fuera del parque de endpoints administrados del cliente mientras lleva credenciales para varios clientes. También puede contener una cuenta administrativa porque a menudo se contrata a contratistas especializados para construir u operar plataformas de datos.

El cliente que creó el 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.

Este es un multiplicador de dependencia en la nube. La credencial se roba de un endpoint, quizás fuera del parque 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 comerciales. El atacante ya no necesita comprometer esos sistemas fuente uno por uno. El valor analítico que hizo útil el almacén para el cliente también hizo que el acceso exitoso fuera valioso para un actor de extorsión.

Los atacantes tienen la responsabilidad directa de robar, comprar, probar y usar credenciales; ingresar a los entornos de los clientes sin autorización; tomar datos; e intentar venderlos o extorsionar. Describir las fallas de control que hicieron posibles esos crímenes no diluye esa responsabilidad. Explica por qué la misma técnica criminal tuvo éxito a escala y dónde se puede reducir la recurrencia.

Las funciones compatibles se convirtieron en una ruta de exfiltración

La campaña no se detuvo en la autenticación. Mandiant observó acceso 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 resultados de consultas en archivos comprimidos y recuperar esos archivos a una máquina local. En varios casos, comandos similares aparecieron en diferentes entornos de clientes.

Esa secuencia hace que el incidente sea legible como funcionalidad ordinaria utilizada bajo 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 de 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. La creación de etapas temporales yCOPY INTOconvirtieron los resultados en archivos descargables.
6. GETmovió los archivos a un cliente controlado por el atacante.

Ningún paso en esa cadena requirió que la base de datos funcionara mal. Por eso el cifrado en reposo, aunque necesario, no fue el control decisivo. La documentación de cifrado de extremo a extremo de Snowflake dice 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 y descargar 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 pida al servicio que devuelva resultados legibles.

El mismo principio se aplica a las claves administradas 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 atender 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 satisfecho la política de autenticación configurada por el propietario.

Por lo tanto, el diseño de roles controló el radio después del inicio de sesión. El modelo de control de acceso actual de Snowflake admite controles de acceso basados en roles y discrecionales, propiedad, jerarquía de roles y privilegios de objetos. Una credencial asignada solo a una base de datos o vista estrecha presenta una consecuencia diferente de una que tieneACCOUNTADMIN, uso amplio de almacén o acceso de selección a conjuntos de datos sin procesar. Una cuenta de servicio utilizada por una integración no debería heredar el alcance exploratorio de un administrador humano.

El rol temporal de un contratista debería caducar 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. La documentación de clasificación de datos sensibles de Snowflake conecta el descubrimiento de columnas personales y sensibles con políticas de enmascaramiento y acceso a filas. Esa es una descripción de capacidad actual, no evidencia de que cada cliente afectado haya clasificado o enmascarado sus datos en 2024. Establece 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 comercial privilegiada y debe gobernarse 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 usar un cliente y origen de red no familiares debe ser observable y, para conjuntos de datos de alto riesgo, puede justificar aprobación, límites de velocidad, restricciones de destino, elevación de corta duración o un rol de exportación separado.

Los comandos de la campaña eran lo suficientemente normales para ejecutarse, pero lo suficientemente inusuales en contexto para merecer una decisión de seguridad rápida.

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

La MFA es la prueba de responsabilidad compartida más nítida porque ambos lados pueden afirmar un hecho verdadero. El administrador del cliente podía y se esperaba que la habilitara. Snowflake ofrecía MFA desde 2015 y políticas de red desde 2016. Al mismo tiempo, las cuentas exitosas de 2024 pudieron autenticarse sin MFA, lo que significa que la línea base efectiva del servicio permitía una ruta solo con contraseña para esas cuentas.

La diferencia entre disponibilidad y aplicación no es semántica. Una característica de seguridad puede ser gratuita, documentada, recomendada y aún así estar ausente en las sesiones que importan. Los administradores enfrentan integraciones antiguas, usuarios de servicio no interactivos, contratistas, cuentas de emergencia, múltiples clientes y miedo al bloqueo. Esas restricciones explican la fricción en la adopción; no justifican dejar el acceso humano privilegiado dependiente de una contraseña reutilizable.

También le dan al proveedor información necesaria para construir 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 hacia valores predeterminados más sólidos. Su anuncio de compromiso de diseño seguro de julio de 2024 enfatizó los controles de política de MFA y las comprobaciones de Trust Center. En septiembre de 2024, Snowflake dijo que MFA se aplicaría de forma predeterminada para usuarios humanos en cuentas creadas a partir de octubre de 2024, mientras recomendaba SSO con MFA del proveedor de identidad para humanos y autenticación OAuth o 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 retira automáticamente cada ruta de contraseña heredada en la base instalada.

Snowflake introdujo posteriormente la protección de contraseñas filtradas, que utiliza fuentes de inteligencia de amenazas para probar contraseñas reportadas como filtradas 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 infostealer que seguían siendo utilizables. También es evidencia de que la responsabilidad compartida puede evolucionar.

Los clientes aún tienen que administrar 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 encuentre de forma independiente.

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

Los estándares ayudan a explicar por qué los valores predeterminados del proveedor pertenecen al análisis. La guía actual de autenticación y gestión de autenticadores de NIST trata 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. El compromiso de diseño seguro de CISA de 2024 identifica específicamente la MFA predeterminada, los empujones persistentes del producto, el soporte base de SSO y la publicación de métricas de adopción como formas en que los fabricantes de software pueden aumentar mediblemente el uso de 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 agota el papel del proveedor.

La línea base responsable distingue los tipos de identidad. Los administradores humanos deben usar MFA resistente al phishing o una identidad federada fuertemente gobernada. Las cargas de trabajo de servicio deben usar credenciales de trabajo que puedan ser limitadas, rotadas y atribuidas sin pretender que un robot pueda responder a una notificación push. El acceso de emergencia debe ser raro, monitoreado, limitado en el tiempo y probado. Las identidades de contratistas deben tener un propietario, fecha de vencimiento, postura de dispositivo aprobada y no reutilización de 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 una segunda puerta, 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 usarse 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.

La documentación actual de políticas de red de Snowflake hace explícito el valor predeterminado: sin una política, los usuarios pueden conectarse desde cualquier computadora o dispositivo. Los clientes pueden permitir o bloquear rangos de IP y puntos finales privados, aplicar controles a nivel de cuenta o usuario, y restringir el acceso a etapas internas con configuración adicional. La conectividad privada y los controles de acceso público pueden endurecer 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 a un administrador cuando no existe una política de cuenta.

Una plataforma puede preservar la elección del cliente mientras hace que el acceso público sin restricciones sea una excepción visible y limitada en el 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, enrutar 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 razones para omitirlos.

La campaña demuestra el valor de las puertas 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 es perfecta; el atacante tuvo éxito donde varias estaban simultáneamente ausentes o permisivas.

Para la rendición de cuentas, cada puerta necesita un propietario y una medida de efectividad. "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 se vuelve significativa solo cuando ambas partes pueden mostrar los resultados en su límite.

El proveedor vio 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 consultas, 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 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. Se crea al operar el servicio a escala.

La vista actual de LOGIN_HISTORY de Snowflake retiene 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_HISTORY retiene 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 a través de la red. Los clientes empresariales pueden usar ACCESS_HISTORY para reconstruir tablas, vistas, columnas, etapas, políticas y objetos modificados a los que se accedió.

Esos esquemas proporcionan el material bruto para una investigación de alta calidad.

El historial bruto no es lo mismo que la detección. El cliente debe otorgar acceso a los analistas, exportar o consultar los datos, comprender el comportamiento normal, escribir alertas, enrutarlas, retenerlas más allá de las ventanas nativas si es necesario y dotar de personal para una respuesta. Una latencia de telemetría de dos horas puede ser aceptable para una 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 la precisión con la que un cliente puede determinar el alcance de la exposición.

Estos hechos del producto y operativos deben probarse durante la adquisición, no descubrirse después de un robo.

El Trust Center actual de Snowflake verifica la inscripción en MFA, la política de red de la cuenta, los roles privilegiados, los usuarios inactivos, los inicios de sesión riesgosos, las direcciones IP inusuales y las transferencias de datos grandes a través de escáneres de seguridad e inteligencia de amenazas. La documentación actual también establece 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.

Nuevamente, la capacidad actual no es evidencia de lo que un cliente o Snowflake detectó en la primavera de 2024. Muestra lo que un proveedor puede convertir en producto una vez que se comprende un patrón de falla entre clientes.

El sistema de advertencia debe operar en dos capas. En la capa del inquilino, los clientes necesitan eventos inmediatos y exportables y controles para bloquear o suspender la actividad. En la capa del proveedor, Snowflake necesita análisis de campañas 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, ID de sesión y consulta, comandos, objetos y columnas tocados, 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 puede exceder la autoridad contractual del proveedor. No actuar puede permitir que continúe el robo. Por lo tanto, el diseño debe definir umbrales de riesgo, suspensiones temporales, canales de escalación del cliente, contactos de emergencia y un proceso de anulación rápida de antemano. Los clientes deben nombrar personas que puedan recibir una alerta de alta gravedad en cualquier momento 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 la implementación regional porque los clientes tienen requisitos de latencia, resiliencia, privacidad, regulatorios y de soberanía. La documentación de regiones compatibles de Snowflake dice que cada cuenta está alojada 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 haber sido almacenadas y procesadas en una ubicación regional o de nube seleccionada. Después de la autenticación exitosa, el atacante podía consultar la cuenta regional desde otro lugar, preparar resultados y descargarlos a 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 o el estado de transferencia legal para cada víctima, por lo que no es defendible una afirmación universal de transferencia transfronteriza ilegal. Sin embargo, la arquitectura muestra que la localidad de almacenamiento por sí sola no podía imponer la localidad del usuario.

El uso compartido y la replicación entre regiones crean una ruta de movimiento separada y legítima. La guía de uso compartido entre regiones de Snowflake dice a las organizaciones que confirmen las restricciones legales y regulatorias antes de replicar datos a una región o país diferente. Eso es 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 registra solo la región de origen continuará diciendo "UE" o "Canadá" incluso después de que un atacante haya eliminado una copia.

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

• Colocación:dónde se aprovisionan los recursos de almacenamiento y computación autorizados.
• Acceso:qué identidades humanas y de máquina pueden conectarse, desde qué dispositivos, redes y jurisdicciones.
• Movimiento:qué consultas, descargas, uso compartido, replicaciones, conectores y descargas pueden crear otra copia.
• Evidencia y remedio:si la organización puede probar 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 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 estrecho de ubicación del centro de datos mientras deja expuesta la autoridad práctica para copiar datos globalmente.

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 infraestructura o de un lector no autorizado de 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 única brecha uniforme

A menudo se describe la campaña a través de nombres de clientes prominentes, 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.

El Formulario 8-K de Live Nation del 31 de mayo de 2024 dijo que identificó actividad no autorizada el 20 de mayo en un entorno de base de datos en la nube de terceros que contenía datos de la empresa, principalmente de Ticketmaster. Dijo que el 27 de mayo un actor criminal ofreció a la venta lo que alegaba ser datos de usuarios de la empresa, y que Live Nation estaba notificando a las autoridades, reguladores y usuarios según correspondiera. La presentación no mencionaba a Snowflake, no proporcionaba un número confirmado de personas afectadas ni explicaba la ruta de autenticación.

La página de incidentes de Ticketmaster Canadá ofrece un nivel diferente de detalle. Describe acceso no autorizado a una base de datos en la nube aislada 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 boletos de América del Norte, y enumera posibles campos que incluyen 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 de back-end no es evidencia de que el atacante haya obtenido el inicio de sesión de Ticketmaster de cada persona ni haya podido realizar transacciones a través de la cuenta de consumidor.

La hoja informativa parlamentaria de la Oficina del Comisionado de Privacidad de Canadá de octubre de 2025 identifica a Snowflake como el proveedor externo utilizado por Ticketmaster, da una ventana de incidente del 2 de abril al 18 de mayo de 2024 para Ticketmaster Canadá, y dice que estaba involucrada información personal de millones, incluidos canadienses. También dice que la investigación permanecía abierta y que Ticketmaster Canadá, como controlador de datos bajo PIPEDA, era la entidad bajo investigación.

Este es un contexto regulatorio útil, pero no es un hallazgo final que resuelva la adecuación de las salvaguardas, el momento de la notificación o la responsabilidad.

El Formulario 8-K de AT&T del 12 de julio de 2024 ilustra por qué los límites de las fuentes son importantes 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 terceros y exfiltró archivos del 14 al 25 de abril. Los archivos contenían registros de interacciones de llamadas y textos para casi todos los clientes inalámbricos de AT&T y los operadores de redes móviles virtuales relevantes para períodos específicos de 2022 y un día de 2023.

AT&T dijo que los archivos no contenían contenido de llamadas o textos, números de Seguro Social, fechas de nacimiento u otra información personal según el uso de ese término por parte de AT&T. La presentación en sí no menciona a Snowflake ni a UNC5537. Respalda los hechos del incidente de AT&T, no una atribución de campaña por sí sola.

Estos registros producen cuatro reglas de disciplina. Primero, use la presentación de un cliente solo para ese cliente. Segundo, distinga entre una base de datos, una cuenta organizacional y un inicio de sesión de consumidor. Tercero, distinga los campos de datos del número de personas representadas por ellos. Cuarto, preserve los hechos negativos como "sin contenido de mensajes" o "cuenta de consumidor no afectada" junto con el impacto. La rendición de cuentas se vuelve menos creíble cuando el análisis expande afirmaciones dramáticas y elimina las limitantes.

Los clientes siguieron siendo responsables de los datos e identidades que delegaron

El lado del cliente de la responsabilidad compartida es sustancial. La organización creó o aprobó usuarios de Snowflake, seleccionó rutas de autenticación, asignó roles, cargó datos, retuvo historial, eligió una región, habilitó integraciones y decidió qué empleados y contratistas podían consultar el almacén. También mantuvo la relación principal con las personas representadas en sus datos y, por lo general, retuvo los deberes de controlador según la ley de privacidad aplicable.

Un cliente podría haber interrumpido la campaña observada en varios puntos. Podría rotar contraseñas después de la exposición del endpoint, prohibir cuentas de servicio solo con contraseña, exigir MFA para humanos, federar el acceso a través de un proveedor de identidad gobernado, restringir redes, caducar usuarios contratistas, reducir concesiones de roles, clasificar y enmascarar campos sensibles, aislar privilegios de exportación, monitorear el historial de inicio de sesión y consultas, y ensayar notificaciones al proveedor de la nube.

Para conjuntos de datos regulados o de alto impacto, esos son deberes operativos básicos, no mejoras opcionales delegadas en la adquisición.

La gobernanza de endpoints y contratistas merece especial atención. Un usuario con un rol en la nube de alto impacto no debería autenticarse desde una computadora personal no administrada. Los contratistas deberían usar escritorios virtuales controlados por el cliente o dispositivos con monitoreo de endpoints cuando sea factible. Su identidad debe ser única por cliente, vinculada a un patrocinador y caducar 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 aparezca evidencia, sin esperar a que se confirme el uso indebido.

El mínimo privilegio debe probarse contra los datos, no contra el título del trabajo. "Analista" puede sonar no administrativo mientras conserva acceso de selección a cada fila en 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 se pueden escribir conjuntos de resultados masivos en etapas y si la identidad puede crear nuevas credenciales o integraciones. Las consultas de muestra bajo el rol son evidencia más sólida que un nombre de rol de apariencia limpia.

Los clientes también son dueños de la preparación para la respuesta. Deberían poder mapear un usuario de Snowflake a un empleado o contratista, una consulta a los sujetos de datos afectados y una exportación a una jurisdicción y análisis de notificación. Los historiales nativos de un año pueden ser insuficientes para una retención legal más larga o un descubrimiento tardío, por lo que los clientes de alto riesgo deberían transmitir 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 tomador de decisiones ejecutivo.

La guía de la cadena de suministro del Marco de Ciberseguridad de NIST recomienda definir y comunicar los requisitos del proveedor según la criticidad. Aplicado aquí, un cliente de Snowflake debería contratar el momento de la notificación de incidentes, los campos de evidencia, la retención, la escalación de soporte, el procesamiento regional, la visibilidad de los subprocesadores, el aviso de cambio de control y el acceso de aseguramiento. También debería 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 siguió siendo responsable de la reducción de riesgos 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. 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 riesgosas producían advertencias persistentes y qué hizo 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 debería depender solo de una contraseña reutilizable. Las identidades de servicio deberían tener un tipo separado y métodos sin contraseña compatibles. Los nuevos valores predeterminados deberían llegar a las cuentas existentes de alto riesgo a través de la aplicación escalonada, excepciones explícitas y ayuda de 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ña, cuentas inactivas, usuarios sin restricciones de red, roles privilegiados y cuentas que permiten ingreso 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 exportaciones grandes pueden formar una señal de campaña. El proveedor debe detectar en la capa de servicio, contactar a las víctimas probables y definir cuándo la actividad de alta confianza desencadena un bloqueo temporal.

Telemetría procesable.Los clientes necesitan evidencia de autenticación, consulta, objeto, etapa y transferencia con suficiente retención y latencia lo suficientemente baja para contener un robo activo. La evidencia de mayor fidelidad no debería volverse no 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 consejos para revisar registros. El proveedor debe rastrear el acuse de recibo, la contención y la exposición recurrente, y debe apoyar las solicitudes de las autoridades y los reguladores sin colapsar observaciones inciertas en recuentos de víctimas confirmadas.

Verificación posterior al incidente.Las características y valores predeterminados anunciados necesitan medidas de adopción y efectividad. Los cambios posteriores de Snowflake hacia MFA predeterminada, deshabilitación de contraseñas filtradas, hallazgos de Trust Center y tipos de identidad más sólidos abordan la ruta observada. La pregunta de responsabilidad restante es la cobertura: qué usuarios y clientes están realmente protegidos, qué excepciones quedan y con qué frecuencia un control detiene un intento real o simulado.

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

El litigio posterior prueba el mismo límite sin resolverlo aún

Snowflake y las empresas afectadas enfrentaron litigios civiles consolidados después de los incidentes. En una orden judicial federal del 29 de octubre de 2025, el Tribunal de 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 trató la supuesta MFA predeterminada y la previsibilidad como relevantes para el deber, la violación y la causalidad en esa etapa procesal.

Esa orden no es un hallazgo de juicio de que Snowflake o Ticketmaster hayan sido negligentes. En una moción de desestimación, el tribunal prueba si las alegaciones bien formuladas establecen un reclamo plausible; no resuelve evidencia en disputa, determina el mecanismo final del incidente para cada demandante ni asigna daños. Snowflake disputó las alegaciones y argumentó que el incumplimiento por parte de los clientes de implementar MFA, políticas de red y otras salvaguardas causó el daño.

La orden es significativa porque muestra que describir la MFA como una configuración del cliente no terminó automáticamente con toda reclamación de deber del proveedor. No es un sustituto del registro final de fondo.

La investigación de privacidad canadiense conllevó una asignación diferente. La OPC dijo que Ticketmaster Canadá seguía siendo el controlador y era la entidad bajo investigación, mientras que la oficina contactó a Snowflake para obtener información. Eso refleja un principio común de privacidad: la subcontratación del almacenamiento no subcontrata el deber del controlador de proteger y notificar. No significa que el proveedor de servicios no tenga deberes contractuales, técnicos o estatutarios propios.

El propio 10-K de Snowflake reconoció numerosas demandas, investigaciones regulatorias y consultas de legisladores, pero no informó una asignación final universal de responsabilidad. Hasta la fecha de publicación, las fuentes públicas revisadas aquí no respaldan declarar que Snowflake haya sido legalmente exonerado, que todos los clientes hayan sido legalmente culpables o 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 actividad entre clientes? Sí. ¿Los criminales explotaron intencionalmente la ruta resultante? Sí. Esas proposiciones pueden coexistir. El derecho de daños, contractual, de privacidad y de valores puede asignar consecuencias de manera diferente según la jurisdicción y el demandante, pero la ingeniería no debería esperar a que gane un eslogan.

Una prueba medible de responsabilidad compartida

La respuesta más sólida no es otro diagrama con "cliente" en un lado y "proveedor" en el otro. Es un conjunto de controles cuya cobertura y comportamiento de falla pueden demostrarse.

Los consejos 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 con capacidad de 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 privilegiadas vencidas, el tiempo medio para alertar sobre orígenes no familiares, 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 debería publicar el progreso agregado donde 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 MFA está disponible es menos informativa que la distribución de inicios de sesión solo con contraseña a lo largo del tiempo. Una declaración de que 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 clientes sospechosos es menos informativa que la latencia de notificación y la integridad del paquete de evidencia.

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

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

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

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

No publica el tipo de usuario, jerarquía de roles, historial de MFA, configuración de red, propietario del endpoint, secuencia de sesión, columnas a las que se accedió ni volumen de exportación para cada organización. Los hallazgos de dispositivos de contratistas de varias investigaciones no deben asignarse a todas las víctimas. La estadística de exposición de credenciales del 79.7 por ciento 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 el código del producto fuera explotado.

No prueba que los datos regionales cruzaron una frontera nacional en cada incidente. La arquitectura permitía el acceso remoto y la descarga local; el análisis de transferencia legal requeriría hechos de origen, destino, sujeto de datos, contractuales y jurisdiccionales 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 mencionaba a Snowflake. La presentación de AT&T no mencionaba a Snowflake ni a UNC5537. La asociación externa puede ser relevante para una investigación adicional, pero las presentaciones deben citarse por lo que realmente establecen.

Finalmente, 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 de Trust Center, las políticas de autenticación y los cambios de identidad pueden reducir la recurrencia, 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 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 falló solo. La evidencia no la respalda. La otra dice que los clientes perdieron contraseñas y, por lo tanto, la pregunta 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 puertas de MFA y red estaban ausentes. Las funciones de consulta y preparación compatibles movían datos rápidamente. El proveedor podía ver un patrón entre inquilinos, mientras que cada cliente veía solo su propia cuenta. Una región de almacenamiento elegida podía mantener los datos fuente 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 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 la campaña y proporcionar evidencia. Los atacantes tenían la responsabilidad directa de los actos criminales. Los reguladores y tribunales deben evaluar los deberes legales según 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 capacidad y resultado. La MFA predeterminada para nuevos usuarios humanos, la deshabilitació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 de 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 de responsabilidad duradera para una plataforma de datos en la nube. Suponga que un cliente ignorará una advertencia, un dispositivo de contratista se infectará, una credencial seguirá siendo válida y un atacante usará funciones ordinarias del producto. Luego pregunte si el valor predeterminado bloquea el inicio de sesión, otra puerta rechaza el origen, el rol revela poco, la exportación desencadena una intervención y la evidencia llega al cliente a tiempo. La responsabilidad compartida es creíble solo cuando el servicio sigue siendo defendible después del error predecible de una de las partes, y cuando ambas partes pueden probar lo que hicieron antes y después.