Protege lo que importa
Protege endpoints, correo electrónico y empleados con el poder de nuestro SOC 24/7. Prueba Huntress gratis y despliega en minutos para empezar a combatir las amenazas.
Filtración de datos de Snowflake
Filtración de datos de Snowflake
La filtración de datos de Snowflake de 2024 marcó pauta como uno de los incidentes de seguridad más impactantes del año. Dirigida a la plataforma de almacén de datos en la cloud de Snowflake, la filtración expuso información confidencial de clientes, interrumpió operaciones comerciales y generó preguntas importantes sobre la seguridad en la cloud. A continuación, te damos un panorama detallado de lo que ocurrió, sus efectos y cómo todos podemos actuar para fortalecer la resiliencia en ciberseguridad.
Filtración de datos de Snowflake explicada: ¿qué pasó?
La filtración de datos de Snowflake se dio a conocer públicamente a fines de mayo de 2024. En lugar de explotar una vulnerabilidad en la plataforma de Snowflake, los actores de amenazas usaron credenciales robadas (recolectadas por malware infostealer como Vidar, RISEPRO y LummaC2) para iniciar sesión directamente en los tenants de clientes de Snowflake que no tenían habilitada la autenticación multifactor (MFA). La infraestructura propia de Snowflake no se vio comprometida. Las investigaciones de Mandiant (Google) y CrowdStrike confirmaron que la campaña fue una operación de toma de control de una cuenta basada en credenciales a gran escala, dirigida a entornos de datos empresariales en la cloud. Esto provocó la exposición de datos de clientes, incluidos registros financieros e información de identificación personal (PII). La campaña es una de las mayores intrusiones en la cloud basadas en credenciales registradas hasta la fecha, y afectó a aproximadamente 165 organizaciones de clientes de Snowflake confirmadas.
¿Cuándo ocurrió la filtración de datos de Snowflake?
Las infecciones de malware infostealer que recolectaban credenciales de Snowflake se remontan al menos a 2020 en algunos casos identificados. La campaña activa de exfiltración contra víctimas específicas comenzó en serio en abril de 2024 y continuó hasta junio de 2024. Snowflake, Mandiant y CrowdStrike emitieron comunicados públicos coordinados a fines de mayo de 2024 después de detectar el patrón de acceso no autorizado en los inquilinos de los clientes.
¿Quién hackeó a Snowflake?
Los atacantes han sido atribuidos a un actor de amenazas rastreado por Mandiant como UNC5537, un grupo cibercriminal con motivación financiera que adquirió sistemáticamente credenciales robadas de registros de malware infostealer y las usó para acceder a repositorios de datos en la cloud. La persona principal asociada con UNC5537 operaba bajo el alias en línea "Judische". Alexander "Connor" Moucka (alias Judische) fue arrestado en Canadá el 30 de octubre de 2024, a solicitud de las autoridades estadounidenses. Un cómplice, John Binns, fue arrestado por separado en Turquía. El Departamento de Justicia de EE. UU. abrió una acusación federal contra Moucka y Binns en noviembre de 2024.
¿Cómo ocurrió la filtración de datos de Snowflake?
Cronología de la filtración de datos de Snowflake
- 2020–2024: el malware infostealer (Vidar, RISEPRO, LummaC2, entre otros) infectó dispositivos pertenecientes a empleados de clientes de Snowflake, recolectando credenciales guardadas para inquilinos de Snowflake. Los registros de credenciales robadas fueron luego adquiridos y usados por UNC5537.
- Abril–junio de 2024: UNC5537 realizó exfiltración de datos activa desde aproximadamente 165 organizaciones clientes de Snowflake, incluyendo Ticketmaster/Live Nation, Santander Bank, AT&T, Advance Auto Parts, Pure Storage y Neiman Marcus, entre otras.
- Finales de mayo de 2024: Snowflake, en coordinación con Mandiant y CrowdStrike, divulgó públicamente la campaña. Snowflake confirmó que su propia plataforma no había sido comprometida. La causa raíz identificada fue la ausencia de MFA obligatoria en las cuentas de los clientes.
- 30 de octubre de 2024: Alexander "Connor" Moucka (alias Judische) fue arrestado en Canadá a solicitud de extradición de EE. UU.
Noviembre de 2024: el Departamento de Justicia de EE. UU. abrió una acusación federal contra Moucka y John Binns en relación con la campaña.
Detalles técnicos
Los atacantes usaron credenciales robadas, obtenidas de registros de malware infostealer comprados o adquiridos en mercados criminales, como vector de acceso inicial. Dado que un gran número de las cuentas afectadas de clientes de Snowflake no tenía MFA aplicada, nombres de usuario y contraseñas válidos fueron suficientes para autenticarse directamente en los entornos de los inquilinos de Snowflake. Tras obtener acceso, se movieron lateralmente dentro de los inquilinos de los clientes y realizaron una exfiltración de datos significativa. No se implementaron puertas traseras dentro de la infraestructura compartida de Snowflake; el acceso fue completamente a través de autenticación legítima usando credenciales comprometidas.
Indicadores de compromiso (IoC)
Según la investigación de Mandiant de junio de 2024, UNC5537 usó principalmente nodos de salida VPN de Mullvad y Private Internet Access (PIA) para acceder a las instancias de Snowflake de las víctimas, y usó infraestructura VPS de ALEXHOST SRL (AS200019) para la exfiltración de datos. Los datos robados se almacenaron en proveedores de VPS internacionales y en el almacenamiento en la cloud de MEGA. Los indicadores más útiles son las cadenas de aplicación cliente registradas de forma nativa por Snowflake. Si alguna de las siguientes aparece en tus registros de acceso de Snowflake, debe tratarse como de alta fiabilidad e investigarse de inmediato:
- rapeflake: una herramienta de reconocimiento personalizada (rastreada por Mandiant como FROSTBITE) usada para enumerar usuarios, roles y datos de sesión dentro de las instancias de las víctimas
- DBeaver_DBeaverUltimate: una herramienta comercial de bases de datos observada al usarse para consultar instancias de Snowflake
- Cadenas adicionales: Go 1.1.5, JDBC 3.13.30, JDBC 3.15.0, PythonConnector 2.7.6, SnowSQL 1.2.32
Para una lista de IoC completa y actualizada, consulta el informe de UNC5537 de Mandiant y la guía de detección y endurecimiento de la seguridad de Snowflake.
Investigación forense y de incidentes
Tanto Mandiant como Snowflake afirmaron explícitamente que no se explotó ninguna vulnerabilidad en el producto o la plataforma de Snowflake en esta campaña. Investigaciones forenses independientes confirmaron que la causa raíz fue el robo de credenciales mediante infecciones de malware infostealer en dispositivos administrados por los clientes, combinado con la ausencia de aplicación de MFA en las cuentas de Snowflake de los clientes. Snowflake fue criticado posteriormente por no exigir MFA de forma predeterminada, y tras el incidente, Snowflake anunció medidas para hacer obligatoria la MFA en las cuentas de los clientes. Las auditorías también revelaron que las prácticas de registro inadecuadas dentro de algunos inquilinos afectados retrasaron la detección inicial y la respuesta al incidente.
¿Qué datos se comprometieron en la filtración de Snowflake?
Los datos expuestos variaron según la organización, pero incluían PII como nombres completos, direcciones, números telefónicos y registros financieros. En el caso de AT&T, se robaron metadatos de llamadas y mensajes de texto de aproximadamente 110 millones de clientes. El conjunto de datos robado de Ticketmaster incluía nombres, direcciones y datos parciales de tarjetas de pago de aproximadamente 560 millones de personas. Algunos archivos estaban cifrados, pero en los tenants afectados, los atacantes tenían acceso de lectura completo, acorde con los privilegios de las credenciales de la cuenta comprometida usadas para autenticarse.
¿A cuántas personas afectó la brecha de datos de Snowflake?
Se confirmó que alrededor de 165 organizaciones clientes de Snowflake tuvieron acceso no autorizado a sus tenants de Snowflake. El total de registros de consumidores individuales robados en esas organizaciones llega a cientos de millones: AT&T por sí sola representó aproximadamente 110 millones de registros, y Ticketmaster/Live Nation, aproximadamente 560 millones.
¿Se expusieron mis datos en la brecha de Snowflake?
Que tus datos personales se hayan visto afectados depende de si eres cliente de una de las aproximadamente 165 organizaciones afectadas. Las personas afectadas recibieron correos de notificación de las empresas correspondientes y pueden contactar a los equipos de soporte de esas organizaciones para obtener más ayuda. Si quieres verificar si tu correo electrónico o tus datos personales formaron parte de la filtración, puedes usar la popular herramienta "Have I Been Pwned." Este sitio web gratuito y fácil de usar te permite buscar cuentas comprometidas ingresando tu dirección de correo electrónico.
Impactos clave de la filtración de Snowflake
La filtración causó daños financieros y reputacionales significativos en decenas de grandes empresas. AT&T, Ticketmaster y Santander enfrentaron el escrutinio de los reguladores, obligaciones de notificación a clientes y, en algunos casos, litigios. Las repercusiones se extendieron hasta la propia Snowflake, que enfrentó cuestionamientos sobre sus configuraciones de seguridad predeterminadas y la capacidad de sus clientes para aplicar MFA. Los clientes cuestionaron la seguridad de las plataformas cloud en términos más amplios, y el incidente generó una renovada conversación en la industria sobre los modelos de responsabilidad compartida en entornos cloud.
Respuesta a la brecha de datos de Snowflake
Snowflake reveló la brecha de inmediato, coordinó con las fuerzas del orden y empresas de ciberseguridad, e implementó parches de emergencia para resolver la vulnerabilidad explotada.
Lecciones de la brecha de datos de Snowflake
Las conclusiones clave destacan que las organizaciones no pueden depender de que los proveedores de plataformas cloud impongan MFA de forma predeterminada; los equipos de seguridad deben auditar los requisitos de autenticación en cada entorno de datos SaaS y cloud de su organización. Las revisiones periódicas de higiene de credenciales, las capacidades de detección de infostealers y la capacitación proactiva de los empleados son fundamentales para evitar brechas similares.
¿Es segura Snowflake después de la brecha?
Desde entonces, Snowflake ha fortalecido la postura de seguridad al implementar controles que exigen MFA para las cuentas de los clientes y al mejorar sus capacidades de monitoreo.
Estrategias de mitigación y prevención
Usa autenticación multifactor (MFA) en todos los endpoints.
Mantén actualizaciones de parches y evaluaciones de vulnerabilidades de forma regular.
Usa herramientas SIEM y asegura el monitoreo 24/7 de los sistemas críticos.
Invierte en capacitación de ciberseguridad para empleados para reconocer el phishing y otros vectores de ataque.
Incidentes relacionados de brechas de datos
Artículos educativos y videos relacionados
Preguntas frecuentes
La vulneración ocurrió a través de una campaña a gran escala de toma de control de una cuenta basada en credenciales. Los actores de amenazas obtuvieron credenciales robadas por malware infostealer de dispositivos de empleados y usaron esas credenciales para autenticarse directamente en los tenants de clientes de Snowflake que no tenían MFA habilitada. No se explotó ninguna vulnerabilidad en la plataforma de Snowflake.
Los datos expuestos incluían PII como nombres, direcciones e información financiera. Los datos específicos variaron según la organización afectada: AT&T perdió metadatos de llamadas y mensajes de texto de ~110 millones de clientes; Ticketmaster perdió datos de clientes y datos parciales de pago de ~560 millones de personas.
UNC5537 (designación de Mandiant) es responsable de la campaña. El actor principal, Alexander "Connor" Moucka (alias en línea: "Judische"), fue arrestado en Canadá en octubre de 2024. El cómplice John Binns fue arrestado en Turquía. Ambos enfrentan cargos federales de EE. UU. que se dieron a conocer en noviembre de 2024.
Las empresas deben exigir MFA de inmediato en todos los entornos cloud y SaaS, implementar soluciones de endpoint capaces de detectar malware infostealer, realizar evaluaciones regulares de exposición de credenciales y tratar las infecciones por infostealer como un incidente crítico que requiere la rotación inmediata de credenciales en todos los servicios a los que accedió la cuenta afectada.
