Bitget perdió US$387,5 millones: un zero-day abrió la puerta al robo
El robo de US$387,5 millones desde Bitget ya tiene una explicación técnica preliminar: los atacantes no necesitaron robar las llaves privadas de la plataforma. Según los hallazgos publicados este 30 de septiembre de 2026 por Mandiant y SlowMist, la intrusión comenzó al explotar una vulnerabilidad de día cero en un producto de seguridad de terceros. Desde allí, el actor obtuvo acceso privilegiado, se desplazó hacia los servidores que gestionaban las billeteras y consiguió que órdenes fraudulentas parecieran legítimas.
La revelación cambia la lectura del incidente ocurrido el 24 de septiembre. No fue solamente un fallo de custodia de criptomonedas: fue un ataque a la cadena de confianza que rodeaba la infraestructura. Los controles de seguridad, diseñados para frenar intrusos, se transformaron en el primer punto de entrada.
Qué descubrieron Mandiant y SlowMist
El análisis de SlowMist sitúa la actividad maliciosa más antigua disponible en los registros el 31 de agosto. Un servicio de uno de los productos afectados ejecutó un script oculto; el atacante intentó leer una variable de entorno que contenía una contraseña de base de datos y luego se conectó a ella. Actividad similar apareció nuevamente en otros nodos los días 23 y 25 de septiembre.
Mandiant, la unidad de ciberdefensa de Google Cloud, reconstruyó una fase posterior de la operación. El 24 de septiembre, el actor habría conseguido acceso privilegiado no autorizado a dos dispositivos de seguridad de terceros. Después desplegó:
- un web shell para mantener acceso remoto en uno de los dispositivos;
- una conexión de comando y control, o C2;
- paquetes maliciosos en el servidor de producción encargado de tareas de billetera;
- una herramienta personalizada para generar y ejecutar retiros fraudulentos.
Los fabricantes de los productos vulnerados no han sido identificados públicamente. Esa ausencia importa: otras organizaciones podrían utilizar la misma tecnología sin saber todavía si comparten la exposición. Bitget afirma que la vulnerabilidad identificada fue corregida y que notificó al proveedor.
Cómo ocurrió el robo sin sustraer las llaves privadas
Las investigaciones disponibles coinciden en un punto clave: no existe evidencia de filtración de llaves privadas y las billeteras frías no resultaron afectadas. El ataque se dirigió contra el flujo que decide qué transacciones deben firmarse.
En términos simples, el atacante no robó la llave de la bóveda; comprometió al sistema que entrega órdenes al custodio de esa llave. Con credenciales internas y parámetros falsificados, las solicitudes maliciosas pudieron atravesar los controles como si fueran retiros autorizados. Las transferencias se extendieron durante cerca de tres horas y alcanzaron varias cadenas, entre ellas Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BNB Smart Chain y Base.
Bitget elevó su estimación inicial desde US$351,6 millones hasta US$387,5 millones después de incorporar más activos a la contabilidad. La empresa sostiene que los saldos de sus clientes permanecen cubiertos por su fondo de protección y comenzó a restablecer los retiros de forma gradual.
Una advertencia para toda la cadena de suministro
El caso expone un riesgo que trasciende a los exchanges. Una organización puede proteger sus claves, segmentar sus redes y desplegar múltiples capas defensivas, pero seguirá expuesta si un componente con altos privilegios puede convertirse en puente hacia los sistemas críticos.
Los dispositivos de seguridad suelen tener una posición especialmente sensible: inspeccionan tráfico, administran identidades, almacenan secretos operativos o se conectan con múltiples segmentos. Por eso, una falla desconocida en uno de ellos puede ofrecer al atacante visibilidad y alcance superiores a los de un servidor convencional.
La atribución también debe tratarse con cautela. La CEO de Bitget, Gracy Chen, vinculó el patrón del ataque con actores norcoreanos, pero los informes forenses publicados hasta ahora se presentan como hallazgos provisionales. La evidencia disponible confirma la intrusión y la ruta general; no permite presentar una atribución estatal como conclusión independiente y definitiva.
Qué deberían revisar las organizaciones ahora
Aunque los proveedores afectados aún no tienen nombre público, el incidente deja acciones concretas para exchanges, fintech y cualquier empresa con sistemas de firma o pagos automatizados:
- Inventariar los equipos de seguridad de terceros y mapear qué secretos, bases de datos y segmentos pueden alcanzar.
- Rotar credenciales y secretos accesibles desde esos equipos cuando exista cualquier indicio de compromiso.
- Buscar web shells, procesos ocultos, conexiones C2 y accesos anómalos desde cuentas internas.
- Separar la aprobación de una transacción de la infraestructura que prepara la solicitud, con controles independientes.
- Aplicar límites por activo, red, volumen y ventana temporal, incluso cuando la orden llegue con credenciales válidas.
- Conservar registros fuera del alcance de los dispositivos administrados para impedir que el intruso borre su rastro.
También conviene vigilar las próximas publicaciones de Mandiant, SlowMist y Bitget. La identificación de los productos comprometidos podría transformar este incidente particular en una alerta urgente para un conjunto mucho más amplio de organizaciones.
La lección: una identidad válida no equivale a una operación segura
El robo de Bitget demuestra que autenticar una orden no basta cuando el sistema que la origina ya está comprometido. Los controles modernos deben evaluar el contexto completo: origen, comportamiento, monto, destino, secuencia y riesgo acumulado. Una credencial correcta puede ser precisamente el disfraz del atacante.
La investigación continúa y parte de los fondos sigue bajo rastreo. Pero la conclusión defensiva ya es clara: la cadena de suministro de seguridad debe tratarse como superficie crítica, no como una zona automáticamente confiable.