Los 90 millones de registros que terminan siendo un SMS en tu teléfono
Exfilsquad reclamó 874 GB de un banco africano. Cl0p reapareció con 42 víctimas de nombres tachados. Ninguno de los dos casos es chileno, y los dos explican por qué en julio hubo cinco campañas de fraude contra marcas bancarias en Chile.
- El 23 de julio de 2026, el grupo Exfilsquad reclamó la vulneración de Zenith Bank PLC: ~874 GB en cerca de 90 millones de registros, con PII, datos de cuentas, movimientos financieros e identificadores emitidos por el gobierno.
- El 5 de agosto, Cl0p publicó 42 nuevas víctimas en su sitio de filtraciones, con los nombres aún tachados. Ese patrón de ocultamiento inicial es idéntico al de sus campañas previas de explotación masiva.
- Ninguno de los dos casos es chileno. Pero en julio de 2026 la ANCI publicó cinco campañas de fraude contra marcas bancarias chilenas —Santander tres, BancoEstado dos—, y esas campañas se alimentan exactamente de este tipo de datos.
Qué pasó
23 de julio — Exfilsquad contra Zenith Bank. El grupo publicó el reclamo alegando la vulneración de Zenith Bank PLC, entidad financiera con presencia en múltiples países africanos y considerada uno de los mayores bancos comerciales de la región. Según la publicación, el paquete alcanzaría los ~874 GB distribuidos en cerca de 90 millones de registros. Ni el banco ni fuentes independientes han confirmado la autenticidad completa del lote, por lo que el estado es pendiente de verificación. De confirmarse, ubicaría al incidente entre los más grandes reportados contra el sector financiero en el año a nivel global.
5 de agosto — Cl0p reaparece. El grupo publicó 42 nuevas víctimas en su sitio de filtraciones en la dark web, con los nombres aún tachados. Ese patrón de ocultamiento inicial es idéntico al usado en campañas previas del grupo, donde la identidad de las víctimas se revela progresivamente semanas después del primer anuncio. El hecho permanece en estado de verificación, y la comunidad de inteligencia de amenazas lo interpreta como posible señal de una nueva campaña de explotación masiva en curso.
En el caso de Zenith, lo que hace crítico el paquete reclamado no es el volumen sino la combinación: PII, datos de cuentas y movimientos, identificadores emitidos por el gobierno y registros de contacto y soporte al cliente. Esa mezcla permite construir perfiles completos de víctimas, habilitando desde suplantación de identidad hasta fraude de originación de crédito.
Y hay un detalle de mercado que importa: en mercados clandestinos, los paquetes con PII financiera verificada se cotizan considerablemente más alto que credenciales simples, precisamente por su utilidad directa en fraude monetizable.
Por qué importa acá
Acá está el puente, y no es teórico.
Durante julio de 2026, la ANCI publicó cinco alertas de campaña fraudulenta contra marcas bancarias chilenas: tres contra Banco Santander y dos contra BancoEstado. Sumadas a los peajes y la paquetería, la banca fue uno de los tres sectores más suplantados del mes.
Esas campañas no nacen de la nada. Se alimentan de datos, y los datos no respetan fronteras. Un paquete con PII financiera verificada permite personalizar un mensaje: el nombre correcto, los últimos dígitos correctos, una referencia a un movimiento real. Eso convierte un SMS genérico en uno creíble, y la tasa de éxito cambia por completo.
El sector financiero latinoamericano comparte con Zenith una característica estructural: alta concentración de datos sensibles en sistemas core interconectados con múltiples canales digitales y proveedores externos. Y hay un efecto cruzado que se subestima: los mismos datos pueden usarse para ataques de ingeniería social contra clientes de bancos completamente distintos, aprovechando patrones de comportamiento comunes entre usuarios de banca digital en la región.
En términos regulatorios el paralelo es directo. La Ley 21.719 impone obligaciones de notificación de brechas y medidas de seguridad proporcionales al riesgo, con fiscalización creciente sobre entidades que manejan datos financieros masivos. Y bajo la Ley 21.663, las entidades de infraestructura crítica y servicios financieros esenciales enfrentan deberes reforzados de gestión de incidentes que no existían hace pocos años. La escala de un incidente así, de ocurrir en Chile, activaría múltiples obligaciones legales simultáneas.
La conexión entre estos dos casos y lo que pasa en Chile es el mercado secundario del dato robado, y conviene entenderlo como una cadena con etapas, no como un evento.
Primero ocurre la brecha masiva, típicamente en otro continente. Después el paquete se vende o se publica. Luego alguien lo cruza con otras filtraciones para verificar y enriquecer los registros. Y finalmente ese dato enriquecido financia campañas de phishing dirigidas contra marcas locales, que es lo que termina llegando por SMS o WhatsApp a un chileno cualquiera.
Evaluamos con confianza media —el vínculo es estructural y no trazamos un paquete específico— que buena parte de las campañas bancarias que la ANCI reportó en julio se apoyan en datos de este origen. El razonamiento: personalizar un señuelo exige información previa sobre la víctima, y esa información no se obtiene atacando a cada persona.
El caso de Cl0p aporta la otra mitad del cuadro. Sus 42 víctimas con nombres tachados no son una lista: son el anuncio de un inventario. El patrón histórico del grupo consiste en explotar masivamente una vulnerabilidad en un producto muy desplegado —típicamente de transferencia de archivos—, recolectar de decenas de organizaciones a la vez, y revelar identidades de forma escalonada para maximizar la presión.
Si ese patrón se repite, la pregunta operativa no es si alguna organización chilena está en esa lista, sino cuánto va a tardar en enterarse. Los nombres tachados significan que las víctimas ya fueron comprometidas; simplemente todavía no lo saben públicamente.
Sobre el vector de Zenith, el volumen extremadamente alto de registros sugiere acceso prolongado a una base de datos central o a un repositorio de respaldo, más que una extracción puntual desde un endpoint comprometido. Es también consistente con escenarios de acceso indebido mediante terceros proveedores con privilegios elevados sobre sistemas core bancarios, un vector cada vez más común en el sector financiero global.
cinco campanas contra banca chilena en julio de 2026 — Santander 3, BancoEstado 2. La banca fue uno de los tres sectores mas suplantadosPII financiera verificada se cotiza mas alto que credenciales simples — Explica por que el dato bancario financia campanas mas personalizadas42 victimas con nombres tachados — Patron historico de revelacion escalonada: las victimas ya lo son, aun sin saberloLa tendencia observada durante el último trimestre muestra un incremento sostenido de reclamos contra entidades financieras en mercados emergentes, lo que sugiere que los grupos de amenaza están priorizando ese sector por su alta tasa de monetización.
Para la banca chilena eso implica revisar dos cosas concretas: la superficie de exposición de las aplicaciones orientadas a clientes, y la gestión de accesos de terceros con privilegios sobre datos core. Ese segundo punto es el que menos se audita y el que más aparece en los incidentes de escala.
Y una consecuencia que se olvida: aunque tu banco nunca sea vulnerado, tus clientes van a recibir fraude construido con datos robados en otra parte. La defensa contra eso no es perimetral, es de detección de fraude y de comunicación con el cliente.
Anatomía del ataque
Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.
T1190— Vector estadisticamente mas frecuente en incidentes bancarios de magnitud comparable.T1078— Credenciales robadas o filtradas previamente, incluidas las de terceros proveedores.T1530— El volumen sugiere acceso a un repositorio de respaldo, no a un endpoint.T1567— 874 GB no salen sin dejar rastro de volumen, aunque no dejen rastro de firma.T1199— Terceros con privilegios elevados sobre sistemas core: vector creciente en banca.
Estructurado sobre las seis funciones del NIST CSF 2.0, según el ciclo de respuesta a incidentes de NIST SP 800-61r3 (abril 2025, reemplaza al r2). Proteger y Detectar vienen abiertas.
GV GobernarQuien decide, que se reporta y a quien
Dos decisiones de gobierno. La primera: quién responde cuando la brecha no es tuya pero el fraude sí llega a tus clientes. Ese escenario no está en casi ningún plan de respuesta, y es el más probable de todos.
La segunda: bajo la Ley 21.719 y la 21.663, un incidente de esta escala activaría múltiples obligaciones simultáneas. Conviene tener claro de antemano quién notifica a la autoridad, quién a los titulares, y en qué plazo.
- Definir el protocolo para fraude construido con datos robados en otra organización.
- Aclarar quién notifica a la autoridad y a los titulares, y en qué plazos.
- Incluir a proveedores con acceso a datos core en el alcance del plan de incidentes.
ID IdentificarSi esto me toca, por donde me toca
La pregunta que importa no es solo si te vulneraron, sino qué de lo tuyo ya está circulando. La lista de monitoreo de la sección de detección cubre eso, y las cuatro fuentes son gratuitas.
Y una segunda que casi nadie tiene mapeada: qué terceros tienen privilegios sobre tus sistemas core. En incidentes de esta escala ese es el vector recurrente, y es el que menos se audita.
- Levantar el monitoreo de exposición de credenciales y menciones, semanal.
- Inventariar terceros con privilegios sobre bases de datos con información de clientes.
- Revisar la superficie de exposición de las aplicaciones orientadas a clientes.
PR ProtegerComo evito que ocurra
Contra la brecha propia: segmentación de bases de datos con información de clientes, y autenticación multifactor en todo acceso administrativo, incluidos los de proveedores.
Contra el fraude alimentado por brechas ajenas —que es lo más probable que te toque— el control que rinde es distinto: forzar MFA a los clientes y detectar patrones de credential stuffing en el portal. Si tus usuarios reutilizan claves, un volcado que no es tuyo igual te golpea.
Controles priorizados
P1: esta semana · P2: este mes · P3: este trimestre
| Prio | Control | Esfuerzo | Mapeo |
|---|---|---|---|
| P1 | Implementar monitoreo continuo de exposición de credenciales y datos en volcados públicos y portales de filtración. Las cuatro fuentes de la lista son gratuitas y la revisión es semanal. | bajo | CIS Controls v8 7.1 ISO 27001 A.5.7 |
| P1 | Auditar y restringir accesos de terceros y proveedores a sistemas core bajo mínimo privilegio. Es el vector recurrente en incidentes de esta escala y el que menos se revisa. | medio | MITRE ATT&CK M1018 CIS Controls v8 6.8 ISO 27001 A.5.15 |
| P1 | Habilitar alertas por volumen de tráfico saliente. Una exfiltración de cientos de gigabytes no deja rastro de firma, pero es imposible que no deje rastro de volumen. | medio | CIS Controls v8 13.3 ISO 27001 A.8.16 |
| P2 | Fortalecer autenticación multifactor y segmentar las bases de datos con información de clientes, separando el acceso de aplicación del acceso administrativo. | medio | MITRE ATT&CK M1032 CIS Controls v8 6.5 ISO 27001 A.8.5 |
| P2 | Alertar sobre picos de autenticación fallida en el portal de clientes. Es la señal de que un volcado ajeno se está probando contra tus usuarios, y precede al fraude en días. | bajo | MITRE ATT&CK M1036 CIS Controls v8 6.2 ISO 27001 A.8.5 |
| P3 | Ejecutar ejercicios de simulación trimestrales de respuesta a incidentes con protocolos de notificación alineados a la Ley 21.719 y la Ley 21.663. | medio | CIS Controls v8 17.6 ISO 27001 A.5.24 |
El primer control es el más barato de toda la serie y el que da más tiempo de reacción: te entera de que estás en una lista antes de que te lo confirmen. Con nombres tachados como los de Cl0p, esos días de ventaja son la diferencia entre responder y reaccionar.
DE DetectarComo me doy cuenta de que ya ocurrio
Para la exfiltración masiva, la señal no es una firma: es el volumen. Ochocientos setenta y cuatro gigabytes no salen sin dejar rastro de tráfico, aunque no dejen rastro de malware. Las reglas de esta pieza persiguen eso: transferencias salientes anómalas y consultas a base de datos que devuelven cientos de miles de filas.
Del lado del fraude ajeno, la señal más útil es un aumento súbito de intentos fallidos de autenticación contra tu portal de clientes. Significa que alguien está probando un volcado ajeno contra tus usuarios, y suele preceder al fraude efectivo en días.
Qué necesitas tener logueado
- Volumen de tráfico saliente por equipo y por hora, no solo destinos
- Registros de auditoría de base de datos: consultas y filas devueltas por usuario
- Intentos de autenticación fallidos contra el portal de clientes
- Fuentes públicas de exposición: volcados de credenciales y portales de filtración
Reglas y consultas de detección
// Exfiltracion masiva desde repositorios de datos: volumen, no firma
let ventana = 90d;
let umbral_gb = 5.0;
DeviceNetworkEvents
| where Timestamp > ago(ventana)
| where isnotempty(RemoteIP)
| summarize BytesSalida = sum(todouble(coalesce(column_ifexists("BytesSent", 0), 0)))
by DeviceName, RemoteIP, RemoteUrl, bin(Timestamp, 1h)
| where BytesSalida > umbral_gb * 1024 * 1024 * 1024
| join kind=leftouter (
DeviceInfo | distinct DeviceName, OSPlatform
) on DeviceName
| project Timestamp, DeviceName, OSPlatform, RemoteIP, RemoteUrl,
GB = round(BytesSalida / 1024 / 1024 / 1024, 2)
| order by GB desc
index=db OR index=oracle OR index=mssql earliest=-90d
| eval consulta = lower(coalesce(sql_text, query, statement))
| eval lectura_masiva = if(match(consulta, "select\\s+\\*\\s+from") AND rows_returned > 100000, 1, 0)
| eval sin_where = if(match(consulta, "select") AND NOT match(consulta, "where"), 1, 0)
| eval hora = strftime(_time, "%H")
| eval fuera_horario = if(hora < 6 OR hora > 22, 1, 0)
| where lectura_masiva=1 OR (sin_where=1 AND fuera_horario=1)
| stats count AS consultas, sum(rows_returned) AS filas_totales,
values(src_ip) AS origenes, min(_time) AS primera, max(_time) AS ultima
by user, database
| convert ctime(primera) ctime(ultima)
| where filas_totales > 500000
| sort - filas_totales
MONITOREO DE EXPOSICION DE CREDENCIALES Y DATOS
Un dato robado en Lagos termina en un SMS en Santiago. El puente es el mercado
secundario, y se puede vigilar sin comprar nada.
QUE VIGILAR
1. Dominios corporativos propios en volcados de credenciales.
Fuente gratuita: Have I Been Pwned, API de dominio (requiere verificar propiedad).
2. Menciones del nombre de la organizacion en portales de filtracion.
Los grupos publican primero ahi, dias antes de cualquier confirmacion.
3. Dominios recien registrados parecidos al propio.
Fuente gratuita: registros de Certificate Transparency (crt.sh). Avisa el mismo
dia en que se emite el certificado.
4. Aumento subito de intentos de autenticacion fallidos contra el portal de clientes.
Es la senal de que alguien esta probando un volcado ajeno contra tus usuarios.
QUE HACER CON CADA HALLAZGO
· Credencial corporativa en un volcado -> rotacion forzada y revision de sesiones.
· Mencion en portal de filtracion -> activar protocolo de respuesta ANTES de
que el proveedor o la matriz confirmen.
· Dominio parecido con certificado -> solicitud de derribo y bloqueo preventivo.
· Pico de fallos de autenticacion -> el volcado no es tuyo, pero tus clientes
reutilizan claves. Forzar MFA, no esperar.
CADENCIA
Los tres primeros, semanal. El cuarto, alerta automatica en el SIEM.
La regla de volumen va a marcar respaldos legítimos, sincronizaciones y transferencias programadas. Esas deben estar inventariadas y excluidas por equipo y destino. Si no puedes listar qué procesos mueven más de 5 GB por hora en tu red, ese es el hallazgo previo.
La de base de datos requiere calibrar el umbral de filas según el tamaño real de tus tablas. Un SELECT * sin WHERE fuera de horario es sospechoso incluso si devuelve poco: lo que importa es la combinación de patrón y momento, no solo el número.
RS ResponderContencion y erradicacion
Si apareces en una lista de víctimas, el reloj regulatorio corre desde que lo sabes, no desde que se confirma. Con nombres tachados como los de Cl0p, la respuesta prudente es activar el protocolo antes de la confirmación pública, no después.
Si el fraude viene de una brecha ajena, tu respuesta es hacia el cliente: comunicación clara por un canal que no sea el suplantado, y refuerzo de autenticación sin esperar a que el usuario lo pida.
- Activar el protocolo ante mención en portal de filtración, sin esperar confirmación.
- Determinar qué datos salieron y en qué ventana, para dimensionar la notificación.
- Forzar rotación de credenciales y MFA a los clientes potencialmente afectados.
- Evaluar las obligaciones simultáneas bajo Ley 21.719 y Ley 21.663.
RC RecuperarVolver a operar y no repetirlo
En una brecha de datos no hay restauración posible: el dato salió y no vuelve. La recuperación es de confianza y de proceso.
La métrica útil es cuánto tardaste en detectar la exfiltración. Un acceso prolongado a un repositorio central, como sugiere el caso de Zenith, significa meses de ventana. Si tu monitoreo no detecta 874 GB saliendo, no detecta nada.
- Medir la ventana entre acceso inicial y detección. Es la única métrica que importa acá.
- Dejar el monitoreo de volumen de salida como alerta permanente, no como revisión.
- Revisar accesos de terceros a datos core como control trimestral.
Llévatelo
Lo de arriba explica. Esto se ejecuta. Son archivos, no capturas de pantalla: se abren, se pegan y funcionan.
La regla Sigma es la canónica: es el formato neutral del que se derivan las demás. Si tu SIEM no aparece en la lista, esa se convierte con pySigma. Las traducciones a motores concretos van sin validar contra tu modelo de datos — revisa los nombres de tabla y campo antes de subirlas a producción.
Fuentes
- ANCI / CSIRT NacionalAlertas de campañas fraudulentas contra banca chilena, julio de 2026 · 2026-07-31
- MITRE ATT&CKT1530 — Data from Cloud Storage
- MITRE ATT&CKT1199 — Trusted Relationship
- BCNLey 21.719 sobre protección de datos personales
- BCNLey 21.663, Ley Marco de Ciberseguridad
¿Esto te aplica y no sabes por dónde partir?
Revisamos tu exposición real frente a lo que describe este análisis: superficie expuesta, cobertura de detección y brechas frente a la Ley 21.663. Diagnóstico de 15 minutos, sin costo.
Agendar diagnósticoRelacionado
Ocho campañas contra GTD Telsur en un mes salieron de tres servidores
ANCI publicó ocho alertas distintas por suplantación de la telco entre el 3 y el 31 de agosto. Al cruzar los indicadores…
ShinyHunters no rompió ningún control: usó la confianza que ya estaba concedida
EY confirmó una intrusión a través de una plataforma de soporte de terceros. Días después, el mismo grupo reclamó tres b…
El phishing que no te pide la contraseña, y por eso el MFA no lo detiene
La ANCI detectó una campaña masiva a nivel nacional que abusa del flujo Device Code de Microsoft Entra ID. La vÃctima…