Brecha fuera de la cadena de Bitget por $387.5M: más allá de las claves y los contratos

El 24 de septiembre de 2026, aproximadamente $387.5M fueron transferidos desde algunas de las billeteras operativas de Bitget a través de Ethereum y otras redes EVM, XRP Ledger, Zcash y TRON. Bitget describió las billeteras afectadas como billeteras calientes y tibias (hot y warm wallets). Las transacciones en cadena llevaban firmas de billetera válidas. Bitget atribuyó el punto de entrada a una vulnerabilidad en un producto de seguridad de terceros y afirmó que las claves privadas y las billeteras frías no se vieron comprometidas [1, 2].

Con base en las divulgaciones públicas y la evidencia en cadena disponible hasta el 29 de septiembre de 2026, 16:35 UTC, la primera parte resume la secuencia de ataque divulgada, los movimientos de fondos posteriores, la restauración del servicio y las diferentes respuestas de los participantes del ecosistema. La segunda parte combina esas observaciones con nuestra experiencia en seguridad para presentar un marco de defensa en profundidad para instituciones cripto, junto con recomendaciones prácticas de seguridad.

1. Del acceso fuera de la cadena a la pérdida y recuperación en la cadena

Bitget ha atribuido el punto de entrada a una vulnerabilidad en un producto de seguridad de terceros, pero no ha revelado el producto, el componente afectado ni el mecanismo técnico de explotación [1, 2]. Su relato público describe la ruta posterior como acceso interno, comandos de retiro falsificados, verificación de riesgo eludida, firmas válidas y transferencias en cadena.

1.1 Cronología del ataque y atribución

La cronología reportada por la CEO de Bitget, Gracy Chen, junto con los registros en cadena, muestra cómo se desarrolló el incidente [3]:

• 18:31 UTC, 24 de septiembre: Los primeros movimientos fueron 0.84 ETH y 93 TRX. Ambos estaban por debajo del umbral de control de riesgo del exchange.
• 18:58-20:09 UTC: Chen describió diecisiete transferencias más grandes a través de Ethereum, XRP Ledger, Zcash, BNB Chain, Base, Arbitrum, Optimism y Avalanche, que sumaron aproximadamente $361M [3]. Los registros en cadena también muestran una transferencia de 20.59M TRX en TRON a las 19:16 UTC.
• Siete minutos después de la primera transferencia grande: El sistema de conciliación de Bitget detectó una discrepancia y detuvo los retiros iniciados por usuarios. La cronología de Bitget distingue esa acción del cierre posterior de los servicios de retiro y firma de billeteras a las 21:44 UTC [1].

Chen dijo que el atacante eliminó los rastros dejados por los comandos fraudulentos [3]. Sobre la atribución preliminar, también dijo que el comportamiento de las direcciones IP y los patrones en cadena eran muy consistentes con grupos de hackers norcoreanos conocidos [4]. Esto sigue siendo una atribución preliminar y no un hallazgo definitivo; la página oficial de incidentes de Bitget no ha nombrado a un grupo responsable, y la investigación sigue en curso [1].

1.2 Flujo de fondos y recuperación operativa

Los registros en cadena reflejados en el rastreador oficial de Bitget muestran que las stablecoins robadas se convirtieron en ETH en cuestión de minutos [5]. A diferencia de USDT o USDC, los activos nativos como ETH no exponen una función de congelamiento controlada por el emisor. Este comportamiento es consistente con un intento de reducir la exposición a congelamientos controlados por el emisor, pero no establece la identidad ni el nivel de experiencia del atacante.

El monto oficial afectado luego aumentó a aproximadamente $387.5M a medida que Bitget incorporó una contabilidad más completa que incluía Zcash y TRON [1]. Bitget publicó las direcciones del atacante, un portal de reporte de recuperación y una API de direcciones [1, 6], junto con el sitio de rastreo en tiempo real [5]. La vista de tenencias del sitio reporta la distribución actual, mientras que su gráfico de flujo de fondos mapea las direcciones posteriores, servicios, puentes y rutas entre cadenas.

A las 16:35:28 UTC del 29 de septiembre, el rastreador oficial reportó $322.67M en tenencias actuales del atacante, alrededor de $632,700 congelados en ocho entidades, $312,500 en stablecoins congelables por el emisor y $55.87M en tránsito o aún bajo análisis [5]. El total congelado comprendía $293,507 en NEAR Intents (que reportó aproximadamente $503,000 congelados durante la ejecución [12]), $239,242 congelados por Tether y $99,990 congelados por Circle. Las fuentes públicas no concilian las cifras de NEAR Intents.

En la misma marca de tiempo, el explorador de direcciones mostró saldos de direcciones atribuidas concentrados en BTC ($288.51M), ZEC ($28.91M) y ETH ($7.17M) [5]. El explorador utiliza un alcance de clasificación diferente al del resumen, por lo que su total de $327.69M a nivel de direcciones no es directamente comparable con la cifra de $322.67M de tenencias actuales del resumen.

La recuperación operativa también avanzó. Bitget reanudó los retiros de ETH a las 08:00 UTC del 29 de septiembre. Para las 09:00 UTC, reportó aproximadamente 9,674 ETH en entradas y 9,023 ETH en salidas, por lo que las entradas superaron a las salidas en aproximadamente 651 ETH [7].

1.3 Después de que los fondos salen: Respuesta de la comunidad

Una vez que los activos salen de las billeteras de la institución afectada, la recuperación depende de organizaciones fuera del límite de seguridad original. Bitget abrió sus datos de rastreo y lanzó una recompensa por asistencia elegible que congelara o recuperara fondos [1, 6]. Binance dijo que su equipo de seguridad compartió inteligencia, rastreó fondos y apoyó la recuperación [8]. El CEO de Bybit, Ben Zhou, ofreció asistencia y actualizó la plataforma de recuperación LazarusBounty, señalando que Bitget había ayudado a Bybit después de su propio incidente de 2025 [9]. La respuesta de Bybit continuó un patrón de asistencia mutua entre los dos exchanges.

Los proveedores de infraestructura tuvieron diferentes opciones debido a sus diseños técnicos y modelos de gobernanza. Bitget pidió a THORChain que rechazara el servicio a las direcciones del atacante públicamente listadas y rastreadas activamente. Gracy Chen argumentó que "la descentralización es un principio de diseño, no un escudo para facilitar fondos robados conocidos" [10]. THORChain explicó que no admite la lista negra selectiva: sus controles de emergencia pueden detener una actividad más amplia o una ruta de cadena, no una dirección o transacción individual. Algunos activos robados continuaron moviéndose de ETH a BTC a través de la red [11].

NEAR Intents reportó una respuesta diferente. Su sistema de riesgo SHIELD identificó y bloqueó más de $50M en flujos intentados vinculados a los atacantes después de filtrar intentos duplicados; aproximadamente $503,000 se congelaron durante la ejecución, mientras que alrededor de $166,000 pasaron. NEAR Intents también renunció a su parte de la recompensa de recuperación de Bitget [12]. La cifra de $50M es flujo intentado que el sistema se negó a procesar, no un monto congelado o recuperado.

Las recuperaciones grandes entre cadenas generalmente requieren varios participantes. Los exchanges pueden retener depósitos o retiros, los emisores de stablecoins pueden congelar tokens, los servicios de enrutamiento pueden rechazar flujos atribuidos donde su diseño lo permita, y los protocolos base pueden solo estar en capacidad de monitorear y compartir indicadores. La coordinación efectiva comienza cuando cada participante declara qué acción puede tomar y qué evidencia requiere.

La intervención también crea riesgos. Una atribución falsa puede bloquear a usuarios inocentes, mientras que las listas negras persistentes pueden expandirse de herramientas de respuesta a incidentes a mecanismos más amplios de restricción de transacciones. Una respuesta defendible usa evidencia corroborada, restricciones estrechas y acotadas en el tiempo, un proceso de apelación, registros de acciones transparentes y una revisión posterior al incidente. Donde un sistema carece de controles selectivos, la divulgación transparente de capacidades ayuda a establecer expectativas realistas. Donde existe discreción, los criterios publicados y la toma de decisiones responsable pueden respaldar respuestas consistentes.

2. Romper y contener la ruta de explotación: Un marco sistemático de seguridad de defensa en profundidad

Basándonos en la ruta del incidente y la respuesta documentadas en la Sección 1, junto con nuestra experiencia y conocimiento especializado, proponemos el marco de dos capas que se describe a continuación. Para más información sobre por qué las auditorías de código y el monitoreo no cubren toda la ruta de manejo de fondos, consulte Why Crypto Institutions Need Blockchain Penetration Testing [13].

• La ruta de explotación divulgada va desde el producto de seguridad de terceros hasta las transferencias en cadena.
• La capa de prevención y detección del marco contiene las primeras tres prácticas de seguridad. Las Secciones 2.1 y 2.2 examinan cómo los controles de acceso privilegiado y la verificación independiente de intención pueden evitar que un punto de apoyo en la infraestructura avance hacia la firma. La Sección 2.3 cubre el monitoreo de flujo de activos, que detecta y escala anomalías salientes y puede retener depósitos entrantes riesgosos.
• La capa de respuesta y recuperación contiene la cuarta práctica. Puede activarse mediante una señal de alta confianza desde cualquier punto de la capa de prevención y detección, o mediante una falla operativa. La Sección 2.4 cubre la capacidad independiente de pausar las operaciones afectadas o transferir activos expuestos a destinos seguros verificados.

Cada subsección sigue la misma estructura: el objetivo de seguridad, el riesgo expuesto por la ruta del incidente y las capacidades preventivas, detectivas o de respuesta que las instituciones pueden establecer. Estas prácticas deben depender de autoridad y evidencia separadas. Juntas, reducen la dependencia de cualquier salvaguarda única y brindan a las instituciones opciones preparadas para contener pérdidas.

2.1 Acceso privilegiado y comandos de retiro

El objetivo es evitar que un compromiso de la infraestructura o de los sistemas privilegiados sea suficiente para crear un comando de retiro confiable.

Un producto de terceros no necesita acceso directo de firma para afectar el movimiento de activos. El acceso a credenciales o sistemas que dan forma a los comandos de retiro puede ser suficiente para determinar qué firma otro sistema. Dichos productos pertenecen a la superficie de ataque Web3 a nivel institucional [14]. Su riesgo depende del valor que pueden influir y de los sistemas a los que pueden llegar.

Los controles requeridos incluyen privilegio mínimo, segmentación de red, rutas restringidas de actualización y administración, credenciales de corta duración, registros resistentes a manipulaciones y un procedimiento de revocación probado. El acceso interno no debe otorgar automáticamente la capacidad de crear un comando de retiro confiable. Cada comando debe llevar un origen autenticado, un identificador de solicitud inmutable y una versión de configuración firmada o autenticada de otra manera. La creación, aprobación, firma y transmisión de comandos deben pertenecer a privilegios separados, y los sistemas posteriores deben rechazar comandos con orígenes desconocidos, configuraciones obsoletas o vinculaciones incompletas.

2.2 Intención de retiro y firma

El objetivo es evitar que un comando de retiro falsificado o manipulado se convierta en una transacción válidamente firmada.

Una firma válida confirma que la clave privada correspondiente firmó los datos de la transacción; no establece que la solicitud de retiro subyacente fuera genuina o aprobada de forma independiente.

El límite de firma debe reconstruir la transacción esperada a partir de un registro confiable independiente y comparar cada campo que pueda mover valor. Como mínimo, la aprobación debe vincular la cadena, el activo, el monto, el destinatario, la billetera de origen, el nonce de la transacción, los límites de tarifas, la expiración y la solicitud original de retiro o tesorería.

El componente que construye un retiro no debe ser la única fuente utilizada para autorizarlo. La evaluación de políticas debe consumir datos independientes de cuenta y riesgo, mientras que el sistema de firma verifica que los datos finales de la transacción coincidan con la intención aprobada. El conjunto activo de firmantes autorizados, el umbral de firma, el nonce de la transacción y la configuración deben coincidir con el estado de producción esperado. Los revisores humanos necesitan una vista normalizada de la transacción generada a partir de los bytes exactos a firmar, no un resumen mutable suministrado por el backend solicitante.

2.3 Flujos de activos salientes y entrantes

El objetivo es detectar cuándo el movimiento real de activos diverge de la intención comercial reconstruida de forma independiente.

Una institución cripto puede ser tanto origen como destino de flujos de activos digitales. El monitoreo de salidas debe comparar la actividad real en la cadena con un conjunto reconstruido de forma independiente de los retiros aprobados. Para preservar la independencia, el monitor no debe depender únicamente del mismo comando producido por el sistema de retiro.

El monitor debe derivar la cadena, el activo, el monto, el destinatario, el momento y la billetera esperados a partir de un registro comercial separado. Debe agregar el comportamiento a través de dimensiones que los límites por transacción no detectan:

• Pequeñas transferencias de prueba seguidas de una rápida escalada.
• Reutilización de nuevos destinatarios entre cuentas, activos o cadenas.
• Un aumento repentino en la velocidad de retiro o la exposición total.
• Salidas simultáneas de múltiples niveles de billeteras operativas.
• Un cambio hacia activos nativos que son más difíciles de congelar.
• Diferencias entre la solicitud aprobada, los datos de la transacción firmada y la transacción transmitida.

Los controles deben evaluar el monto acumulado, la velocidad, si un destino es nuevo, el nivel de la billetera, la facilidad con la que se puede convertir un activo y el comportamiento entre cadenas dentro de una ventana de tiempo. Los movimientos iniciales de ETH y TRX de Bitget ilustran el valor de evaluar las transacciones como una secuencia y no solo como eventos aislados [3]. Una discrepancia de alta confianza debe activar la ruta de respuesta de emergencia descrita en la Sección 2.4. Las anomalías de menor confianza pueden requerir una segunda aprobación, un período de enfriamiento del destino, un límite reducido o una retención temporal de retiro.

El monitoreo de entradas debe examinar los depósitos antes de acreditarlos y volver a examinarlos antes de un retiro. Debe seguir los fondos a través de puentes, exchanges descentralizados (DEX), servicios de enrutamiento basados en intención y direcciones intermedias, porque coincidir solo con la primera dirección del atacante es insuficiente. Las coincidencias de alta confianza necesitan un proceso documentado para retener fondos, investigar la coincidencia, manejar apelaciones y completar cualquier traspaso legal.

El intercambio rápido de inteligencia entre exchanges convierte el monitoreo de entradas en un efecto de red. Una institución puede detectar el incidente mientras otra ve las ganancias. Los indicadores compartidos y legibles por máquina, junto con contactos actualizados, acortan el intervalo entre la atribución y la acción.

2.4 Pausa de emergencia y transferencia de activos

El objetivo es contener la exposición restante una vez que se identifica una señal de seguridad de alta confianza o una falla operativa.

Las señales pueden incluir violaciones de acceso privilegiado o integridad de comandos, discrepancias en la intención de retiro o la firma, actividad anormal en cadena de salida, entrada u otro tipo, y fallas de conciliación. La institución debería entonces poder pausar la firma, transmisión, retiro u operaciones de billetera afectadas. Si los activos permanecen expuestos, también debería poder moverlos desde la billetera sospechosa a destinos seguros predefinidos. Una pausa gana tiempo de investigación; una transferencia reduce la exposición restante.

• Autoridad de pausa independiente: La pausa debe seguir disponible si el sistema de administración principal está comprometido. Su alcance debe ser lo suficientemente estrecho como para detener una cadena, billetera, activo u operación específicos donde la arquitectura lo permita. La activación y la liberación requieren autoridad autenticada, registros resistentes a manipulaciones, criterios explícitos de reanudación y pruebas en condiciones degradadas.
• Continuidad de la ruta de transferencia: Un cambio de configuración no debe invalidar la antigua ruta de emergencia antes de que su reemplazo haya sido implementado, autorizado, firmado, almacenado y probado.
• Preparación de transacciones ejecutables: Las transacciones de emergencia almacenadas pueden quedar obsoletas debido a cambios de nonce, saldo insuficiente de token nativo para pagar tarifas, cambios en el saldo del activo de origen, cambios en el mercado de tarifas que hacen inutilizables los límites de tarifas firmados, expiración o actualizaciones de configuración. Las verificaciones de preparación deben validar estas dependencias de forma continua. Los datos de transacción totalmente firmados deben permanecer cifrados y con acceso controlado hasta que la acción de emergencia sea aprobada y esté lista para su transmisión inmediata.
• Cobertura y conmutación por error: Cada billetera operativa, cadena, activo nativo y token compatible necesita rutas de transferencia primarias y de respaldo. La infraestructura de transmisión y verificación también necesita redundancia entre los puntos de acceso de llamada a procedimiento remoto (RPC), los sistemas de operaciones y las herramientas de recuperación manual.
• Verificaciones de finalización y simulacros: El procedimiento de respuesta de emergencia debe definir la finalización mediante la ejecución confirmada en cadena, la verificación por activo, las verificaciones de saldo residual y la conciliación entre el estado en cadena y los registros internos. También debe detectar reorganizaciones de cadena y transacciones fallidas. Los simulacros regulares deben medir el tiempo de recuperación completo, desde la detección hasta la verificación final del saldo.

Una prueba de penetración blockchain autorizada puede convertir supuestos entre capas en evidencia al ejercitar el entorno en producción dentro de un alcance acordado [15]. Para las pruebas en producción, las Reglas de Compromiso (RoE) documentadas deben establecer la autorización, las técnicas permitidas, los criterios de detención, los límites de valor, las comunicaciones, el manejo de evidencia y la autoridad de pausa antes de que comiencen las pruebas [16].

Conclusión

El incidente de Bitget no fue ni un compromiso de clave privada ni una explotación de contrato inteligente. Bitget dijo que los atacantes explotaron una vulnerabilidad en un producto de seguridad de terceros para obtener credenciales de acceso a la intranet, y luego falsificaron comandos de retiro que el sistema de billetera procesó como transferencias en cadena válidamente firmadas [1, 2]. Después de que los activos salen de la institución afectada, la recuperación se convierte en un esfuerzo compartido del ecosistema. Las respuestas de Bitget, Binance, Bybit, THORChain y NEAR Intents muestran que los participantes pueden responder de diferentes maneras [8-12]. Cómo puede la comunidad coordinar esas capacidades de forma rápida y responsable cuando surge un incidente o amenaza de seguridad importante sigue siendo un desafío más amplio para la industria cripto.

La ruta posterior conocida fundamenta el marco sistemático propuesto aquí, que conecta la prevención y detección con la respuesta y recuperación. Las instituciones pueden reducir la dependencia de cualquier salvaguarda única restringiendo el acceso privilegiado y autenticando el origen de los comandos, reconstruyendo de forma independiente la intención de retiro aprobada en el momento de la firma, monitoreando las secuencias salientes y los ingresos entrantes, y manteniendo rutas de pausa y transferencia operables de forma independiente. La custodia sigue siendo esencial, y estas prácticas la complementan a lo largo de toda la cadena de manejo de fondos [13, 15].

Referencias

[1] Bitget. Bitget Security Incident: Official Progress Update. https://www.bitget.com/campaigns/bitget-security-incident-2026

[2] Gracy Chen. Security Incident Root-Cause Boundary. https://x.com/GracyBitget/status/2104515761691939026

[3] The Block. Bitget Attacker Tested Risk Controls with Small Transfers Before $388 Million Theft, CEO Says. https://www.theblock.co/news/regulation/2026-09-28-bitget-attacker-tested-risk-controls-small-transfers-388-million-theft-ceo-says-417045

[4] Gracy Chen. Preliminary Attribution Assessment. https://x.com/GracyBitget/status/2103359775723626736

[5] Bitget. Live Tracing Dashboard and Fund-Flow Graph. https://trace.bgblockchain.xyz/v2#track

[6] Bitget. Live Tracing Information and Recovery Portal. https://x.com/bitget/status/2103485491220033607

[7] Gracy Chen. ETH Withdrawal Resumption Update. https://x.com/GracyBitget/status/2104886024979816508

[8] Binance. Richard Teng Puts Binance's Security Muscle Behind an Industry-Wide Response. https://www.binance.com/en/square/post/09-25-2026-binance-news-richard-teng-puts-binance-s-security-muscle-behind-an-industry-wide-response-370442242243629

[9] Ben Zhou. Bybit Support for Bitget. https://x.com/benbybit/status/2103328213141508335

[10] Gracy Chen. Request to THORChain. https://x.com/GracyBitget/status/2103812967066439817

[11] CoinDesk. THORChain Rejects Bitget Request to Block Hacker as $6 Million Moves to Bitcoin. https://www.coindesk.com/tech/2026/09/28/thorchain-rejects-bitget-request-to-block-hacker-as-usd6-million-moves-to-bitcoin

[12] Gracy Chen. NEAR Intents and SHIELD Response. https://x.com/GracyBitget/status/2104602301503816040

[13] BlockSec. From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing. https://blocksec.com/blog/why-crypto-institutions-need-blockchain-penetration-testing

[14] BlockSec. Web3 Attack Surfaces: A Penetration Testing Overview. https://blocksec.com/blog/web3-attack-surfaces-penetration-testing

[15] BlockSec. What Is Blockchain Penetration Testing? Definitions and Boundaries. https://blocksec.com/blog/what-is-blockchain-penetration-testing

[16] BlockSec. Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing. https://blocksec.com/blog/blockchain-penetration-testing-rules-of-engagement