A las 18:31 UTC del 24 de septiembre, los sistemas de Bitget detectaron transferencias no autorizadas saliendo de sus hot wallets. Cuando se cortó la hemorragia, faltaban 351.6 millones de dólares. Y el dato que convierte este incidente en material de estudio para cualquiera que diseñe arquitecturas de autorización es este: las llaves privadas nunca se comprometieron.
Qué pasó
Bitget confirmó el robo en un comunicado en X y lo repitió su CEO, Gracy Chen, con un detalle que cambia toda la lectura del caso:
El atacante comprometió un sistema backend crítico dentro de nuestra infraestructura de wallets, lo usó para falsificar datos de transacción y disparó nuestro proceso de autorización para mover los fondos. El compromiso de llaves privadas queda descartado. — Gracy Chen, CEO de Bitget
Traducido a términos de arquitectura: nadie forzó la bóveda. Alguien entró a la oficina que redacta las órdenes de pago, generó papeleo que se veía legítimo y lo metió por la misma ventanilla de aprobación que el negocio usa todos los días. Para el sistema que autorizaba, era una operación normal.
El golpe tocó las hot wallets —el cajón de efectivo permanentemente conectado que alimenta trading, depósitos y retiros— y también la capa de warm wallets, ese búfer semiconectado que rellena las hot cuando bajan de nivel y empuja el exceso hacia offline. Las cold wallets, dice la empresa, quedaron intactas.
La respuesta operativa fue de manual: depósitos y trading siguen abiertos, retiros congelados "por precaución" mientras corre una revisión de seguridad, y un User Protection Fund de más de 464 MDD declarado suficiente para absorber la pérdida completa. Bitget contrató a Mandiant y SlowMist para la investigación forense de terceros. La empresa también aclaró que Bitget Wallet, su producto self-custodial, corre sobre infraestructura independiente y no fue afectado.
Por qué importa (y no es por el cripto)
Es tentador archivar esto como "otro exchange hackeado" y seguir con la vida. Sería un error, porque el patrón técnico no tiene nada de exclusivo de las criptomonedas.
Lo que falló aquí no fue la criptografía. Falló la confianza implícita en el origen de una instrucción. El sistema de autorización de Bitget hacía exactamente lo que le pidieron: validar y firmar transacciones que llegaban de un componente interno considerado confiable. El atacante no rompió la firma; se puso del lado correcto de la frontera y pidió firmas legítimas.
Cambia "hot wallet" por "workflow de pagos en el ERP", "orquestador de la pipeline de CI/CD" o "servidor de administración que empuja política a 4,000 firewalls", y el escenario es idéntico: un plano de control interno cuya salida se acepta sin validación independiente porque "viene de adentro". Es el mismo hueco que explotaron los ataques a la cadena de suministro de gestión remota de los últimos años, y el mismo que hace que un bypass de autenticación en una consola central sea un evento de nivel CVSS 10 y no una molestia.
La lección incómoda: una arquitectura puede tener cold storage impecable, HSMs, multi-firma y segregación de llaves, y perder 351 millones de dólares igual, porque el eslabón débil no era la llave sino quién tiene permiso de pedir que se use.
El detalle técnico y lo que falta
Bitget no ha publicado el método de intrusión inicial —dice que sigue bajo investigación activa y que habrá reporte técnico completo— así que aquí toca ser disciplinado y no rellenar el hueco con especulación. Lo que sí está sobre la mesa:
- Spoofing de datos de transacción, no de firmas. La distinción es importante porque define la remediación. Un robo de llaves privadas obliga a rotar llaves y migrar fondos a direcciones nuevas; un backend comprometido obliga a rediseñar el flujo de autorización, y eso es mucho más profundo.
- Contención confirmada. Chen afirma que no son posibles más transferencias no autorizadas, lo que sugiere que el componente comprometido ya está aislado o revocado.
- Fondos en movimiento y congelamiento parcial. Bitget contactó a las fundaciones de las cadenas afectadas y algunas confirmaron el congelamiento de direcciones del atacante. En XRP Ledger, BSC o los stablecoins emitidos centralmente, eso es técnicamente posible; en Ethereum o Arbitrum, con ETH nativo, no lo es.
- Atribución por comportamiento, no por IOC público. La empresa habla de "patrones de IP" y análisis on-chain "altamente consistentes" con grupos norcoreanos. Es atribución preliminar de la víctima, no de un reporte independiente: hay que tratarla como hipótesis hasta que Mandiant publique.
Sobre esa hipótesis, el contexto sí la hace verosímil. La semana pasada SentinelOne atribuyó al grupo norcoreano TraderTraitor un ataque contra una empresa india de servicios de TI. TraderTraitor es el mismo actor detrás del robo de 1,500 MDD a Bybit y de 292 MDD al bridge de LayerZero de KelpDAO. Su firma característica no es explotar el blockchain: es comprometer a las personas y los sistemas de desarrollo que rodean al exchange —proveedores, contratistas, laptops de developers, dependencias— para llegar al plano de control desde adentro. Un backend de wallets manipulado encaja perfectamente en ese modus operandi.
Y encaja con algo más que ya cubrimos esta semana: los paquetes maliciosos de Go y los providers de Terraform subidos al registry de HashiCorp, atribuidos también a DPRK, cuyo objetivo declarado son developers de proyectos Web3 contactados vía LinkedIn con ofertas de trabajo falsas. Es la misma campaña industrial vista desde el otro extremo del túnel.
Qué hacer
Nada de esto requiere que operes un exchange. Traducido a un entorno enterprise:
- Inventaría tus planos de control que autorizan movimiento de valor. Pagos, transferencias, aprovisionamiento, cambios de política, despliegues a producción. Pregunta de cada uno: ¿qué componente puede pedir la acción, y qué valida que la petición sea legítima más allá de su origen de red?
- Valida el contenido, no solo el emisor. Límites por transacción y por ventana de tiempo, umbrales que exigen segunda aprobación humana fuera de banda, listas de destinos conocidos. Si un backend comprometido puede pedir cualquier monto a cualquier destino y ser aprobado, no tienes autorización: tienes un sello automático.
- Trata a los sistemas de build y a las estaciones de developers como parte del perímetro crítico. El vector favorito de este actor es el developer, no el firewall. Revisa dependencias nuevas en Go, npm y PyPI, y bloquea la instalación de providers de Terraform no verificados.
- Ensaya el escenario "el plano de control miente". Tus playbooks de IR probablemente cubren credenciales robadas y ransomware. ¿Cubren "un sistema interno legítimo está emitiendo instrucciones válidas y maliciosas"? La detección ahí no es un IOC: es anomalía de comportamiento sobre flujos que tu SIEM probablemente marca como normales.
- Si tienes exposición en Bitget, los retiros siguen suspendidos. Espera el reporte técnico y desconfía de cualquier "portal de recuperación" o soporte que te contacte primero: la segunda ola de estos incidentes siempre es phishing a las víctimas.
Queda pendiente el reporte de Mandiant. Ahí estará lo que realmente importa: cómo se entra a un backend de wallets de un exchange top-10. Hasta entonces, la parte aprovechable del caso ya es clara, y no se parcha con un update.
Fuentes
- Bitget Says Suspected North Korean Hackers Stole $351.6M After Backend Compromise — The Hacker News
- Bitget's $352 million hack happened via spoofed transfers, not private keys, CEO Gracy Chen says — CoinDesk
- Crypto exchange Bitget loses $352 million in hack, claims user funds are safe — CoinDesk
- Bitget CEO suspects North Korea behind $352M hack, citing IP clues — Cointelegraph
- Attackers Use Malicious Terraform Providers to Deliver Go Malware via HashiCorp Registry — The Hacker News