Bitget afirma que unas credenciales robadas convirtieron una falla en una herramienta de seguridad en el robo de 388 millones de dólares de sus carteras

La plataforma de intercambio de criptomonedas Bitget afirma que un atacante aprovechó una vulnerabilidad de día cero en un producto de seguridad de un proveedor externo, cuya identidad no ha revelado, para obtener acceso privilegiado a sus sistemas internos y robar aproximadamente 388 millones de dólares.

Según la investigación de la plataforma, la intrusión no se produjo mediante el robo de las claves privadas de las carteras. En cambio, el atacante habría obtenido credenciales internas de alto nivel y utilizado los procesos administrativos legítimos de Bitget para enviar instrucciones fraudulentas de retirada.

Los fondos fueron sustraídos de parte de la infraestructura de carteras calientes y templadas de la plataforma. Las carteras frías, desconectadas de la red, no se vieron afectadas.

Las credenciales robadas abrieron el acceso a los servicios de las carteras

La directora ejecutiva de Bitget, Gracy Chen, describió la vulnerabilidad del producto de terceros como una vulnerabilidad de día cero. Esto significa que, cuando el atacante la aprovechó, la plataforma aún no disponía de una solución proporcionada por el proveedor. Bitget no ha identificado el producto, su desarrollador ni las versiones afectadas.

La falta de información deja varias preguntas técnicas sin respuesta. Se desconoce qué tipo de vulnerabilidad se aprovechó, si se eludió la autenticación o cómo la falla permitió acceder a las credenciales privilegiadas de Bitget.

No se ha anunciado ningún identificador CVE. Por lo tanto, tampoco hay información confirmada sobre el estado de la vulnerabilidad en el catálogo de vulnerabilidades explotadas conocidas de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA).

Según se informa, el exploit permitió acceder a un sistema interno de gestión y a credenciales de alto nivel. Estas credenciales dieron al intruso acceso a servicios backend relacionados con las transacciones de las carteras.

Bitget había señalado anteriormente que se había vulnerado y manipulado un componente crítico del backend de sus carteras para generar datos de transacciones falsos e iniciar aprobaciones. El relato más reciente aclara cómo se produjo el acceso inicial: mediante una vulnerabilidad en software de un proveedor externo de seguridad.

Sin embargo, el atacante aún tuvo que sortear el flujo de transacciones de Bitget. Las transferencias requerían aprobación antes de firmarse, por lo que el acceso a un único componente de las carteras no bastaba necesariamente para mover los fondos.

El robo principal estuvo precedido por pequeñas transferencias de prueba

Las retiradas fraudulentas comenzaron el 24 de septiembre. En lugar de intentar una transferencia grande de inmediato, el atacante probó primero el proceso con dos transacciones pequeñas a las 18:31 UTC.

Ambas transferencias quedaron por debajo del umbral de los controles de riesgo de Bitget y no generaron alertas. Las retiradas de mayor cuantía comenzaron unos 30 minutos después.

El uso de credenciales internas válidas fue clave en el ataque. El backend relacionado con las carteras aceptó las órdenes de retirada como legítimas y las envió al proceso habitual de aprobación. Chen afirmó que la actividad se diseñó para parecer trabajo administrativo rutinario, lo que redujo la probabilidad de que los controles automatizados o los empleados la identificaran como maliciosa.

El atacante también intentó borrar rastros de la operación. Se desconoce hasta qué punto logró hacerlo y si los investigadores han recuperado las pruebas eliminadas.

Esta vía de ataque ayuda a explicar por qué las medidas de protección de las carteras no impidieron las transferencias. El adversario no tuvo que falsificar un inicio de sesión externo ni robar directamente claves criptográficas. En su lugar, operó con identidades internas de confianza y envió órdenes en un formato que los sistemas de Bitget esperaban recibir.

Los controles basados principalmente en el importe de las transacciones, la validez de las credenciales o una actividad administrativa que parece normal a primera vista pueden tener dificultades ante este tipo de escenario. Las dos primeras transferencias sirvieron para comprobar si esos controles intervendrían antes de que el atacante intentara mover cantidades mayores.

Las carteras calientes y templadas absorbieron las pérdidas

Los activos robados procedían de parte de las carteras calientes y templadas de Bitget. Estas son más accesibles que el almacenamiento desconectado de la red, ya que permiten gestionar la liquidez operativa y las retiradas.

Bitget afirma que sus carteras frías no se vieron afectadas. La empresa también asegura que no ha encontrado indicios de que se hayan comprometido las claves privadas de las carteras, aunque la investigación sigue en curso.

Esta distinción es importante para determinar el alcance del incidente. Una clave privada robada podría permitir a un atacante firmar transacciones sin pasar por los sistemas internos de la plataforma. En este caso, según la información disponible, el ataque dependió del acceso a la infraestructura backend de Bitget y a sus mecanismos de aprobación.

La plataforma afirma que los saldos de las cuentas de los clientes permanecen intactos. El Fondo de Protección de Bitget, una reserva destinada a cubrir pérdidas relacionadas con la seguridad, sufragará los activos desaparecidos.

No se pide a los usuarios que restablezcan sus credenciales, muevan sus fondos ni realicen ninguna otra acción correctiva. Por ahora, no hay indicios de que las cuentas individuales de los clientes fueran el punto de entrada.

Las retiradas de Bitcoin se reanudaron el lunes. Está previsto que las retiradas de otros activos vuelvan a habilitarse de forma gradual hasta el 2 de octubre.

Sistemas aislados mientras el proveedor trabaja en la vulnerabilidad

Bitget notificó al proveedor del producto, cuya identidad no ha revelado, y desactivó la funcionalidad afectada. No ha indicado si el proveedor ha publicado un parche u otra solución permanente.

Sin el nombre del producto, información sobre las versiones ni un identificador de la vulnerabilidad, otras organizaciones no pueden determinar si utilizan la misma tecnología afectada. Tampoco pueden comprobar por su cuenta si hay una actualización disponible.

Bitget ha aislado los sistemas implicados en el incidente, revocado las credenciales internas y emitido otras nuevas. También ha limitado el acceso interno, introducido verificaciones independientes para las retiradas y reforzado la monitorización de actividades anómalas.

La plataforma revisará cómo selecciona, evalúa e implementa productos de seguridad de terceros. El incidente pone de manifiesto un riesgo complejo de la cadena de suministro: el software instalado para proteger una infraestructura sensible puede convertirse en una vía de acceso a ese mismo entorno.

La validación independiente de las retiradas podría reducir el riesgo de que se comprometa una única capa de gestión, sobre todo si la segunda verificación utiliza credenciales, telemetría y límites de confianza independientes. Bitget no ha revelado la arquitectura de sus nuevos controles.

Mandiant y SlowMist están colaborando en la investigación. Bitget prevé publicar un informe formal sobre el incidente esta semana, que podría aclarar qué componente se explotó, cómo se accedió a las credenciales y cuál fue la secuencia de aprobaciones.

La atribución a Corea del Norte sigue sin confirmarse

Bitget había señalado anteriormente que los responsables probablemente eran hackers norcoreanos. Chen declaró a The Hacker News que la plataforma sigue sospechando del mismo actor, pero se negó a nombrar a un grupo concreto antes de la publicación del informe sobre el incidente.

TRM Labs identificó coincidencias entre los activos robados y las carteras que ya se habían utilizado para blanquear fondos procedentes de robos atribuidos a Corea del Norte. La empresa de inteligencia de blockchain afirmó que la actividad apuntaba a TraderTraitor, pero no realizó una atribución definitiva.

Las coincidencias en las transacciones, por sí solas, no permiten determinar quién llevó a cabo la intrusión. El uso de una misma infraestructura de blanqueo, de servicios intermediarios y de direcciones reutilizadas puede respaldar una evaluación, pero no demuestra necesariamente que los mismos operadores perpetraran la intrusión inicial.

El movimiento de fondos a través de puentes y servicios de intercambio entre cadenas complica aún más el rastreo. Estos servicios pueden cambiar tanto la red como el activo involucrado, por lo que no basta con vigilar las transferencias directas.

Direcciones receptoras y exposición indirecta bajo vigilancia

El 25 de septiembre, Bitget publicó las direcciones receptoras junto con un panel de seguimiento en tiempo real y un portal de recuperación. También pidió a las plataformas de intercambio, custodios, emisores de stablecoins, puentes y otros operadores de infraestructura que señalaran cualquier actividad relacionada.

Las direcciones publicadas son:

• Redes Ethereum y EVM: 0x770b10b273fc44fe9197d6bf20f145c2e98463ee
• XRP: rwNhefsz1UQEusxhCvHip3RANinWi4CTck
• Zcash: t1WgMdtND8NF7NDUuYmq8MpMj1NTCXkMDVG
• TRON: TBWNguTTgezw9dVorX441C6nDrZpRxYwKD

TRM recomendó a las empresas de criptomonedas que no limitaran las comprobaciones a los depósitos enviados directamente desde estas direcciones. Los investigadores prevén que los fondos robados lleguen a través de varias carteras intermediarias después de pasar de una red a otra.

Por ello, los equipos de cumplimiento deberían vigilar las direcciones posteriores etiquetadas y la exposición indirecta, especialmente tras movimientos a través de puentes o servicios de intercambio entre cadenas. Es más probable que un depósito realizado varios saltos después del robo proceda de una de esas direcciones que una transferencia directa desde una dirección receptora identificada públicamente.

Por ahora, no hay ninguna medida específica para otros posibles usuarios del producto de seguridad vulnerable. No se han revelado la identidad del proveedor, las versiones afectadas, el estado de los parches ni los indicadores técnicos.