¿Cómo Robaron $81M con 5 Emails?

En febrero de 2016, hackers atribuidos a Corea del Norte robaron $81 millones del Banco de Bangladesh explotando vulnerabilidades en el sistema SWIFT mediante emails de malware. Pasaron el dinero por cuatro países en menos de una hora. Se recuperaron solo $20 millones de los $101 millones que intentaron transferir.

El robo de $81 millones al Banco de Bangladesh

El Banco Central de Bangladesh (Bangladesh Bank) es la autoridad monetaria del país, encargada de regular bancos y garantizar estabilidad financiera. En febrero de 2016, sufrió el robo más grande a un banco central en la historia moderna.

Los números son impresionantes: los atacantes intentaron transferir $951 millones en total. Lograron mover $101 millones. De eso, $81 millones llegaron a sus manos en Filipinas. Solo se recuperaron $20 millones (según el análisis del NCSC británico).

La verdad es que los atacantes ganaron por timing, no por genio técnico extraordinario (spoiler: fue una combinación de ambos). Consiguieron acceso a la red del banco el 1º o 2º de febrero, casi dos semanas antes del ataque real. Pasaron 10-14 días dentro del sistema, estudiando cómo funcionaban las transferencias, dónde estaban los servidores, quién tenía qué permisos.

Método de ataque: emails con malware SWIFT

No necesitaban sofisticación extrema. Un email de CV falso llegó a un empleado del banco con un adjunto malicioso. El tipo lo abrió (¿vos también lo habrías hecho con un CV?). El malware instalado fue un backdoor que les permitió moverse lateralmente por la red interna.

Una vez adentro, descargaron credenciales, estudiaron los servidores, y encontraron acceso directo al sistema SWIFT. El malware que dejaron instalado en varias máquinas permitía ejecutar comandos, capturar contraseñas, y estar conectados sin que nadie lo notara. Esto no fue un ataque de fuerza bruta. Fue paciencia.

Los servidores de SWIFT estaban conectados a máquinas Windows 7 sin parches de seguridad, ejecutando software de banca obsoleto. Los logs de las máquinas fueron borrados (limpiamente, sin dejar pistas obvias). Las alertas que se supone deberían avisar sobre transferencias grandes estaban desconectadas o configuradas para ignorar ciertos patrones.

La ventana de tiempo: feriados, zonas horarias y abandono

Subís a la máquina del banco, ejecutás las transferencias SWIFT que preparaste, ves que los mensajes se mandaron correctamente, los receptores confirman que recibieron los fondos, y entonces empezás a contar las horas.

El ataque ocurrió el jueves 4 de febrero de 2016 (noche en Nueva York, donde está el Federal Reserve que procesa los pagos SWIFT). Para Bangladesh eran ya las 14:30 del viernes. Pero acá viene lo importante: Bangladesh festejaba el Bangla New Year el 14 de febrero, así que desde el 4 en adelante el banco empezaba a bajar ritmo. Además, en Filipinas era la semana del Año Nuevo Chino. En Hong Kong también. Los bancos operaban con personal esqueleto.

El Federal Reserve procesó las órdenes de transferencia sin cuestionarlas. El dinero se movió entre bancos corresponsales de Manila a Hong Kong. Para el lunes (cuando alguien en Bangladesh se dio cuenta de lo que pasaba), el dinero ya había pasado por 4 países, estaba en múltiples cuentas, y el tiempo de reacción era casi cero.

El dinero desaparece: Filipinas, Hong Kong y la pared de ladrillo

De los $101 millones, $80.6 millones fueron a una cuenta en Manila (según Bank Info Security). Los hackers sabían qué estaban haciendo: Filipinas tiene casinos que aceptan dinero en efectivo sin demasiadas preguntas si lo fraccionás bien. El dinero se lavó a través de depósitos en casinos de Manila, transacciones pequeñas para evitar alertas automáticas, y transferencias posteriores a Hong Kong.

Desde Hong Kong, parte del dinero fue a Singapur, parte se quedó en cuentas dormidas. Nunca se recuperó. Los $20 millones restantes se quedaron bloqueados en el Hawala (sistema de transferencia de valor no bancario) cuando los bancos filipinos desconfiaron y pararon la operación.

En comparación, el robo anterior más grande a un banco central ocurrió en 1983 en Brasil ($70 millones). Ese dinero fue recuperado. El de Bangladesh? Todavía está perdido, o gastado en operaciones clandestinas de Corea del Norte.

¿Quiénes lo hicieron? Lazarus Group y Corea del Norte

La atribución llegó semanas después. El FBI, el GCHQ británico, y agencias de seguridad de varios países señalaron a Lazarus Group, un colectivo patrocinado por el Estado norcoreano. ¿Por qué? Porque el malware, el tooling, y los patrones de ataque eran idénticos a los que habían usado en el ataque a Sony Pictures en 2014.

Lazarus Group opera desde Corea del Norte bajo patrocinio directo del gobierno. Tienen capacidad sofisticada de ingeniería inversa, conocimiento profundo de sistemas SWIFT, y acceso a vulnerabilidades no públicas (zero days). No son script kiddies. Son una unidad militar del Estado.

El porqué? Corea del Norte necesitaba dinero en efectivo. Estaba bajo sanciones económicas internacionales. Robar de un banco central era más limpio que vender armas o tráfico de drogas (bueno, también hacen eso, pero esto no dejaba víctimas visibles). Fue un ataque de Estado contra otro Estado, financiado por la necesidad.

Comparación: Bangladesh vs otros ataques financieros

Lecciones de seguridad que aprendió la banca mundial

Después del robo, el SWIFT cambió sus protocolos. Pero eso no es lo que importa. Lo que importa es que Bangladesh Bank cometió errores básicos de ciberseguridad que cualquier empresa puede evitar.

Primero, no segmentó su red. Los empleados tenían acceso a máquinas conectadas tanto a internet como a SWIFT sin firewall que las separara. Un malware en una máquina de email podía saltar a los servidores de transacciones.

Segundo, no monitoreaba el sistema SWIFT en tiempo real. Nadie notó que se ejecutaban transferencias fuera de horarios normales, o que se estaban haciendo a destinos raros, o que los mismos usuarios estaban accediendo desde múltiples IPs simultáneamente.

Tercero, Windows 7 sin parches. Eso es inexcusable en un banco, en cualquier año. Especialmente en 2016, cuando Windows 7 ya llevaba 6 años en el mercado y había patches de seguridad acumuladas.

Cuarto, los logs de auditoría se limpiaban automáticamente cada 15 días. Así que cuando el banco se dio cuenta del robo, ya no había registro de lo que los atacantes habían hecho semanas atrás.

Cómo defenderse de ataques similares

Acá no estamos hablando de tecnología mágica. Estamos hablando de lo que ya existía en 2016 y que sigue siendo gratis o barato hoy.

Segmentación de red: separá la red de empleados de la red de transacciones con firewall. Usa VLANs. Haz que un ataque en una máquina de email no alcance directamente a los servidores SWIFT. Las máquinas que ejecutan transacciones no necesitan acceso a internet.

Monitoreo de anomalías: configura alertas automáticas para transferencias grandes, accesos fuera de horario, logins desde IPs nuevas, cambios en permisos. Si ves 50 transferencias a Filipinas en una noche cuando normalmente hacés 2 por día, eso es raro. Los sistemas SIEM (Security Information and Event Management) que hacen esto existen desde 2005.

Autenticación multifactor: obligatoria para acceso a sistemas críticos. Dos factores, tres si podés. Si alguien roba la contraseña de un empleado, un código OTP le impide acceder sin tener también el teléfono.

Parches de seguridad: mantenete actualizado. Windows 7 tenía actualizaciones disponibles cada mes. Bangladesh Bank simplemente no las instalaba.

Logs duraderos: no borrés los registros cada 15 días. Guardá 6 meses, un año si podés. Cuando investigás qué pasó después de un ataque, necesitás histórico.

Educación de empleados: el ataque comenzó con un email de CV falso. Si una sola persona no abre adjuntos de desconocidos, el ataque nunca empieza.

Errores comunes que sigue cometiendo la gente

1. Pensar que “no nos van a atacar a nosotros”

Los bancos pequeños creen que no son objetivo de atacantes sofisticados. Incorrecto. Lazarus Group golpea bancos chicos en Asia, Oriente Medio, y América Latina. Si procesás dinero, sos objetivo. No necesita ser un banco grande.

2. Creer que una sola herramienta de seguridad es suficiente

Un firewall de borde no te salva si el atacante ya está adentro. Un antivirus no te salva si tus logs no registran las anomalías. Un parche no sirve si tu máquina no está en la red. Necesitás capas: red, host, aplicación, monitoreo, educación.

3. Desconectar alertas “porque generan muchos falsos positivos”

Eso fue exactamente lo que pasó en Bangladesh. Las alertas se desconectaban porque los empleados se quejaban de demasiadas notificaciones. Mejor tener 100 falsos positivos que un verdadero negativo de $81 millones.

4. No probar los backups

Bangladesh Bank tenía backups (probablemente). Pero después del ataque, si la data estaba corrupta o los backups también habían sido comprometidos, de poco servía. Hacé pruebas cada 3 meses: apagá el servidor, restaurá desde backup, verificá que funcione.

Qué significa para empresas y equipos en Latinoamérica

En Latinoamérica hay 23 bancos centrales. Varios tienen infraestructura igual o peor que Bangladesh en 2016. Si creés que eso no es problema, recordá que Lazarus Group también atacó bancos en El Salvador, Costa Rica, y México en años posteriores.

Pero no solo bancos. Cualquier empresa que maneja dinero, transferencias internacionales, o datos críticos es objetivo. Retail, criptomonedas, fondos de inversión, PayPal, mercado libre local (eso sí le preocupa a los atacantes). La diferencia es que Lazarus Group prefiere bancos porque el dinero sale limpió sin intermediarios.

La mala noticia: equipos de seguridad en Latam son frecuentemente esqueleticos, los presupuestos son bajos, y hay resistencia a la educación de empleados. La buena: los errores de Bangladesh son fáciles de arreglar. No cuesta millones hacer segmentación de red, monitoreo básico, y parches regulares. Cuesta decisión de hacerlo.

Preguntas Frecuentes

¿Qué es SWIFT y por qué es importante para los bancos?

SWIFT es la red global de mensajería de transacciones financieras. Todos los bancos del mundo la usan para transferencias internacionales. Si controlás SWIFT en un banco, controlás el dinero. No necesitás reventar bóvedas ni robar físicamente nada.

¿Por qué no se recuperó el dinero?

Porque en Hong Kong y Filipinas, una vez que el dinero entra al sistema bancario local, es difícil seguirle la pista. Los atacantes lo fraccionaron en múltiples cuentas, lo lavaron en casinos, y lo transfirieron a cuentas que desaparecieron en el sistema financiero subterráneo. Después del 5º o 6º salto, los investigadores pierden la huella.

¿Se capturó a alguien por el robo?

No. Bangladesh Bank trabajó con el FBI para investigar, pero los atacantes operan desde Corea del Norte, donde el gobierno los protege. Hace 10 años que pasó y nadie está en prisión. La única consecuencia fue que los gobiernos impusieron sanciones adicionales a Corea del Norte.

¿Puede pasar de nuevo?

Sí, y ha pasado. Lazarus Group atacó el Banco de Bangladesh de nuevo en 2017 (sin éxito). También atacó bancos en El Salvador, Costa Rica, y otros países. La diferencia es que algunos de esos bancos tenían mejor seguridad y los ataques fueron detectados a tiempo. La receta que funcionó una vez funciona de nuevo si la víctima no aprende.

¿Qué pasó con el Banco de Bangladesh después?

Pasaron la humillación histórica. Mejoraron la seguridad (parcialmente). El gobernador del banco se fue. Bangladesh pidió ayuda al FMI. Otros bancos centrales learned the lesson (algunos, no todos). El Banco de Bangladesh sigue operando hoy, pero la mancha quedó.

Conclusión

El robo al Banco de Bangladesh en 2016 no fue un quiebre fundamental en ciberseguridad bancaria. Fue la confirmación de que los gobiernos de ciertos países estaban dispuestos a usar hackers sofisticados para financiarse. Fue una advertencia ignorada.

Diez años después, Corea del Norte sigue robando dinero de bancos (la noticia más reciente es de 2023, sin dar nombres públicos). Otros actores copiaron la receta. Las lecciones están ahí, claras: segmentación, monitoreo, parches, educación, logs duraderos. No es ciencia de cohete. La pregunta es si los bancos —y tu empresa— van a aprenderlas antes de que el atacante llegue a la puerta.

Si trabajás en IT o seguridad de una empresa que maneja dinero o datos críticos, el Bangladesh Bank es tu recordatorio más importante. No es “qué tan sofisticado es el ataque”, es “qué tan preparado estoy yo”. Porque el atacante puede ser sofisticado. Pero si no entra, no roba nada.

Fuentes

• Wikipedia — Bangladesh Bank robbery — Timeline detallada del incidente, cronología del ataque, análisis técnico.
• ISACA — Lessons Learned from the Bangladesh Bank Heist — Análisis de lecciones de seguridad, recomendaciones para bancos.
• UK National Cyber Security Centre — Bangladesh Bank Heist Case Study — Análisis técnico de atribución, patrones de Lazarus Group.
• Bank Info Security — Bangladeshi Bank Hackers Steal $100M — Detalles de la operación, monto exacto, distribución de fondos.
• Darknet Diaries — Episode 72 Transcript — Relato narrativo del ataque, entrevistas con investigadores, cronología del robo.