Hackeo a Bitget: 388 millones de dólares desaparecidos

Antes de que el hervidor empiece a silbar, Mira mira la app de Bitget. La cifra junto a su USDT parece normal, pero la pantalla de retiros no. La actualiza una vez y luego otra vez, ya que si un saldo sigue apareciendo en el teléfono debería ser accesible igual que el dinero en una cuenta bancaria. Un mensaje indica que los retiros se han suspendido mientras el exchange investiga un incidente de seguridad. El mensaje transmite calma, pero su cocina no.

Hay un pago de alquiler que vence en cuatro días y un proveedor que espera el dinero. Aunque sus fondos siguen mostrándose en pantalla, no puede moverlos. Abre el comunicado y descubre que la cifra ronda ya los cuatrocientos millones de dólares; una cantidad tan abrumadora que resulta imposible de visualizar, por lo que reduce su escala y se pregunta si sus pocos miles de dólares formarán parte de esa suma. Bitget asegura que los saldos de los clientes no se han visto afectados. Esa aclaración es importante, pero no hace que el botón atenuado deje de parecer una puerta cerrada con llave.

Mira es una usuaria ficticia, no una víctima real reportada. Su rutina matutina ilustra la auténtica contradicción que subyace al hackeo de Bitget: el exchange afirma que los fondos robados procedían de hot wallets y warm wallets utilizadas para transferir dinero, no de los saldos de las cuentas de los clientes ni de sus reservas en cold wallets. Aun así, los usuarios sufrieron el incidente a través del mismo sistema del que dependían para retirar sus fondos. Un registro contable puede indicar que todo está intacto mientras una persona espera para saber si podrá mover su dinero.

El número que congeló la app

El 24 de septiembre de 2026, Bitget detectó transferencias no autorizadas desde algunas de sus hot wallets y warm wallets. La empresa estimó posteriormente la suma involucrada en unos 388 millones de dólares distribuidos en doce direcciones de billetera. Las transferencias afectaron a diversas redes y clases de activos. Un cliente que utilizara la aplicación no necesitaba conocer todas las cadenas para comprender las implicaciones: la plataforma había suspendido los retiros mientras investigaba lo sucedido.

Bitget aseguró que sus claves privadas no se habían visto comprometidas y que sus cold wallets —que albergaban la mayor parte de los activos de la plataforma— no sufrieron afectación alguna. Más adelante, tras una investigación conjunta de Bitget con Mandiant y SlowMist, el origen del ataque se atribuyó a un software de seguridad de terceros; los atacantes aprovecharon una vulnerabilidad, obtuvieron credenciales internas privilegiadas e introdujeron instrucciones de retiro fraudulentas en los sistemas backend vinculados a las billeteras. Estas instrucciones forjadas fueron aceptadas como legítimas por los procesos que debieron haberlas cuestionado.

La situación dista mucho de la de un ladrón que roba una llave maestra y vacía la cámara acorazada entera. Sirve también para demostrar que una billetera no es simplemente una clave; es en realidad un entramado de personas, controles de acceso, software, proveedores externos, herramientas de monitorización y criterios sobre qué órdenes se consideran habituales. La clave en sí puede permanecer en secreto mientras la infraestructura circundante es engañada para firmar la solicitud incorrecta. El usuario ve el logotipo del exchange y asume, con lógica, que existe un único perímetro de seguridad; por dentro, sin embargo, puede coexistir una serie de sistemas con propietarios y supuestos operativos muy distintos.

El cronograma forense hace que el fallo parezca menos repentino. La firma de análisis de blockchain Bitquery ya había rastreado pequeñas transferencias de prueba a primera hora de esa tarde, incluido un envío menor en TRX y una fracción de ETH. A continuación, se movieron cantidades mayores en ráfagas a través de varias redes. Bitget declaró después que su sistema de monitorización detectó la actividad anómala a las 19:05 UTC y bloqueó de inmediato los retiros de los usuarios, pero las transferencias desde sus billeteras continuaron tras emitirse esa alerta. Las últimas transferencias registradas por Bitquery tuvieron lugar más de dos horas después. Aunque el detector había visto el humo, las puertas internas del edificio todavía debían cerrarse.

La existencia de ese desfase no demuestra que todos los controles fallaran de la misma manera, y es imposible que los registros de transacciones públicas reflejen cada decisión interna. En cambio, sí evidencian lo rápido que un eslogan popular se queda corto. Aunque el término "cold storage" aluda al lugar donde se custodia gran parte de los activos de un exchange, no cubre todos los movimientos requeridos para operar con los clientes; las hot wallets existen porque los retiros deben procesarse con rapidez, y las warm wallets sirven para reabastecerlas. La plataforma debe encontrar el equilibrio entre seguridad y disponibilidad. El atacante descubrió una vía para colarse justo por el tejido que conecta ambos compromisos.

Esta situación también pone de manifiesto por qué un proveedor externo puede acabar formando parte del perímetro de seguridad de un exchange, aun cuando no figure en el mapa mental del usuario. Bitget no reveló qué productos se vieron comprometidos. Según informó CNBC, Mandiant y SlowMist descubrieron que dos herramientas de seguridad de terceros habían sido vulneradas, y SlowMist logró rastrear la primera actividad maliciosa en los registros disponibles hasta el 31 de agosto. Eso ocurrió semanas antes de que el robo fuera visible en la blockchain. Un cliente no puede evaluar a un proveedor del que no tiene constancia. Corresponde al exchange realizar esa auditoría, y el proveedor debe gestionar sus accesos con la misma cautela que si custodiara las propias claves del exchange.

Cuando «cubierto» no significa «disponible»

Bitget comunicó que los saldos de las cuentas de sus clientes seguían intactos y que la compañía asumiría la pérdida en su totalidad. Hizo referencia a su Protection Fund, valorado en más de 464 millones de dólares antes del hackeo; como resultado del incidente, el fondo se utilizó y fue posteriormente reabastecido con reservas propias de Bitget hasta superar los 300 millones de dólares, de acuerdo con la empresa y las informaciones de CNBC. Asimismo, Bitget publicó datos sobre sus reservas y señaló que el estado del fondo podía verificarse on-chain.

Se trata de una respuesta sensata. Que una empresa recurra a su propio capital para asumir una pérdida es muy diferente a pedir a los usuarios que se pongan a la cola de acreedores no garantizados. Sin embargo, no equivale a haber evitado la brecha. Los seguros y las reservas son mecanismos de pago a posteriori; no sustituyen a los controles preventivos que frenan una transferencia no autorizada. Aunque la distinción sea clara en la teoría, resulta más difícil de valorar cuando el botón de retiro está desactivado.

Mira no se detiene a analizar la valoración del fondo de protección. En su lugar, se pregunta si puede fiarse de la afirmación «su saldo no se ha visto afectado» cuando la aplicación se ha convertido, de facto, en una trampa de la que no puede salir. Son dos cuestiones vinculadas pero distintas. Un exchange puede contar con activos de sobra para asumir una pérdida y, aun así, verse obligado a suspender los retiros mientras investiga; puede reanudar sus servicios más tarde y, a pesar de todo, haber dado motivos a los usuarios para replantearse cuánto capital desean mantener bajo su custodia. La solvencia determina si la empresa puede hacer frente a sus obligaciones; el acceso determina si el cliente puede disponer de su dinero cuando lo necesita. La confianza es el factor humano situado entre ambos.

Bitget reabrió los retiros de forma gradual: empezó con Bitcoin el 28 de septiembre, continuó con ether y varias redes EVM al día siguiente, y habilitó USDT el 30 de septiembre. La compañía anunció que el resto de activos, sus servicios fiat y los retiros peer-to-peer volverían a operar el 2 de octubre. Una reapertura por fases resulta lógica desde el punto de vista operativo, dado que cada red y activo exige sus propios procesos de validación. Sin embargo, para los clientes supone fragmentar una única promesa a lo largo de varios días. El activo de una persona entra en el turno del martes, mientras que el de otra queda relegado al viernes. Aunque un cronograma ayuda a mitigar la incertidumbre, inevitablemente hace que los usuarios cuenten las horas.

La compañía afirmó que este calendario se aplicaba por igual a todos los niveles de cuenta. El matiz es crucial: una interrupción puede hacer temer a los usuarios que las cuentas institucionales o de mayor volumen tendrán prioridad. Una política homogénea aporta un mínimo de equidad, si bien la equidad no hace que la espera sea más llevadera. En una situación de crisis, los clientes no solo quieren saber si la empresa podrá restablecer el servicio, sino también si serán tratados como personas y no como simples entradas en una cola de balances pendientes.

Bitget declaró a CNBC el 2 de octubre que se habían congelado cerca de 1,1 millones de dólares de los fondos sustraídos, advirtiendo de que la congelación cautelar no garantiza su devolución. Su CEO, Gracy Chen, admitió que no confiaba en recuperar una parte significativa del botín, teniendo en cuenta los patrones habituales en los grandes robos de criptomonedas. El exchange habilitó un programa de recompensas (bounty) para incentivar la ayuda que facilitara la congelación o recuperación de fondos. Son datos desprovistos de dramatismo o tintes de película. Una congelación puede ser temporal, los saltos entre cadenas (cross-chain) complican el rastreo y el mero etiquetado de una dirección no devuelve automáticamente los fondos a la billetera del exchange. La recuperación exige negociaciones complejas entre cadenas, emisores, bridges, exchanges, investigadores y los propios movimientos del atacante.

Un fallo de control y un problema de confianza

La secuencia que hizo posible el ataque encierra una lección incómoda. Las empresas integran software de seguridad de terceros porque sería inviable que una sola entidad desarrollara cada componente de su infraestructura desde cero. Para cumplir su cometido, estos proveedores necesitan permisos de acceso, y dichos permisos pueden llegar a ser tan amplios que adquieren un papel crítico en momentos de tensión. Aunque el exchange dé la cara ante el público con una sola aplicación, su perímetro defensivo puede depender de software diseñado por una compañía de la que el usuario jamás ha oído hablar. De este modo, el eslabón débil puede situarse muy lejos de la persona que, al final de la cadena, se queda esperando su retiro.

La investigación llevada a cabo por Bitget reveló que los intrusos emplearon credenciales privilegiadas y emitieron órdenes forjadas que los sistemas de sus billeteras consideraron auténticas. No necesitaron engañar a cada usuario para que hiciera clic en un enlace malicioso; bastó con que los sistemas internos del propio exchange dieran por buena la identidad de quien cursaba la orden. El ataque resulta especialmente alarmante porque subvierte un principio básico de seguridad: no se trata solo de quién custodia las claves, sino de quién tiene capacidad para convencer a quien las custodia de que una instrucción es legítima. Las capas adicionales de defensa solo son eficaces si son capaces de contradecirse entre sí e impedir que una orden fraudulenta desemboque en una transferencia real de fondos.

Mandiant y SlowMist fueron contratadas para liderar la investigación, y la compañía comunicó que había restringido sus permisos internos, restablecido credenciales, desactivado las funciones afectadas e introducido controles independientes para validar los retiros. No obstante, estas medidas solo representan el punto de partida del proceso de remediación y no constituyen por sí solas una explicación exhaustiva de lo ocurrido. Los usuarios tienen derecho a conocer qué partes del procedimiento se han transformado y cómo tiene previsto el exchange ponerlas a prueba. El análisis forense sirve para describir la brecha; solo la constatación reiterada de una operativa segura logra que los clientes vuelvan a confiar.

La persona que espera

La gente no percibe un informe de seguridad como un diagrama técnico; lo vive a través de una llamada telefónica, un chat de soporte sin respuestas, un pago no atendido y la pequeña vergüenza de pedir tiempo a un familiar. Algunos usuarios operaban con fondos que podían permitirse arriesgar; otros utilizaban las stablecoins como un equivalente funcional a su caja del día a día. El mismo saldo en USDT puede representar una inversión especulativa para un operador y la nómina del mes siguiente para un pequeño negocio. La interfaz de la plataforma es ciega a esa diferencia.

Por esa razón, el volumen total sustraído no guarda una correlación directa con la intensidad de la angustia. Un robo de trescientos ochenta y ocho millones de dólares marca un récord histórico. Sin embargo, el usuario que tiene mil dólares depositados no encuentra consuelo dividiendo esa cifra entre las reservas globales de la entidad. Su única preocupación es si podrá ejecutar la transferencia que tenía prevista. En cuanto la respuesta es un no, el riesgo abstracto de contraparte se materializa en un problema doméstico tangible.

La custodia delegada en un exchange entraña una asimetría moral. El usuario elige una aplicación, en parte, para desentenderse de la gestión de claves privadas, las copias de seguridad, la seguridad del dispositivo físico y el peligro de un error fatal. Al aceptar ese rol, el exchange asume la posición de guardián experto. Justifica el uso de hot wallets en nombre de la inmediatez que demandan los clientes, y recurre a proveedores externos porque la seguridad actual se estructura en múltiples soluciones especializadas. Ahora bien, lo que no puede hacer es trasladar a los usuarios el impacto anímico derivado de esa arquitectura tachándolo de mero tecnicismo; quien depositó su confianza en la plataforma nunca dio su consentimiento expreso al esquema de accesos concedido a un tercero.

Al mismo tiempo, el axioma de que «no son tus claves, no es tu dinero» tampoco resuelve por sí solo las dificultades prácticas de la vida real. Si bien la autocustodia otorga el control absoluto al individuo, también le impone la responsabilidad total: gestionar la frase semilla, asumir averías en los dispositivos, evitar transferencias a direcciones erróneas y asumir el coste de las comisiones de red. La opción adecuada depende de la capacidad de gestión de cada cual. Resulta sencillo reivindicar la independencia financiera a toro pasado tras un fallo de seguridad; lo difícil es admitir que la comodidad constituye una necesidad real y no un síntoma de negligencia individual. Los usuarios de Bitget no renunciaron a sus claves por descuido, sino porque recurrieron a un servicio diseñado para simplificar la complejidad técnica de la custodia.

El sobresalto no convierte automáticamente a nadie en un purista de la descentralización. Es muy probable que Mira retire el capital que necesita para sus compromisos inmediatos, mantenga un saldo operativo mucho más bajo en el exchange y examine las próximas publicaciones de prueba de reservas (Proof of Reserves) con mayor escepticismo. Con el tiempo, puede que vuelva a utilizarlo por pura practicidad. Tras una mañana de desconcierto no se toman decisiones categóricas e irreversibles; se introducen ajustes graduales y se evalúa si los nuevos márgenes de riesgo encajan con las exigencias del día a día.

La salida más constructiva no radica en culpar a los usuarios por operar en un exchange centralizado. Más bien exige examinar la respuesta de la entidad ante el siniestro: qué datos hizo públicos, la rapidez con la que contuvo la brecha, si recurrió a auditorías externas independientes, si restableció el servicio de forma estructurada y transparente, y su claridad a la hora de explicar qué contingencias cubre realmente su fondo de protección y cuáles no. El ratio de reservas es un dato relevante, pero no garantiza inmunidad. Una dirección pública de billetera ayuda a auditar los saldos en un instante dado, pero ninguna de las dos cosas demuestra que los canales de retiro sean del todo invulnerables.

El dilema trasciende a los exchanges. Cualquier servicio dedicado a encaminar valor debe evaluar el destino de cada operación. Un envío puede partir de una plataforma en regla y terminar en una billetera vinculada a fraudes, ataques de phishing o infracciones de sanciones internacionales. Por ejemplo, Netts contrasta las solicitudes de Energy y Bandwidth en TRON con una lista común de exclusión antes de asignar los recursos, aplicando medidas de seguridad por defecto si las comprobaciones fallan o no están actualizadas. Este filtro no soluciona el hackeo de un exchange ni sustituye sus obligaciones de compliance, pero ilustra cómo una capa básica de infraestructura transaccional puede filtrar qué peticiones está dispuesta a procesar.

Cuando el banner desaparece

Los incidentes de ciberseguridad abandonan las portadas con rapidez, pero dejan huella en los hábitos del usuario. Es habitual que alguien vuelva a abrir la aplicación para consultar una cotización y dude justo al entrar en la pestaña de retiros. Esa pausa es comprensible y no presupone una nueva caída de la plataforma; es simplemente la memoria recordando que ver un saldo reflejado en pantalla no equivale a disponer libremente de él.

Para Bitget, la labor más ardua tras la reactivación de octubre va mucho más allá de cumplir el calendario de aperturas: implica recomponer la confianza, visibilizar las reformas técnicas introducidas, emitir un dictamen formal sobre la brecha sufrida y acreditar que el mismo vector de entrada ha quedado completamente cerrado. La compañía informó del reseteo de credenciales internas, un endurecimiento en los accesos con privilegios elevados, la desconexión del software del proveedor implicado y la implantación de auditorías independientes reforzadas en la tramitación de retiros. Estas medidas constituyen compromisos; su validez radicará en la disciplina de su aplicación y en una supervisión constante.

Para los clientes, la lección práctica va más allá del clásico «jamás operes en un exchange». Radica en mantener bajo custodia de la plataforma únicamente la cuantía coherente con el uso real que se le dé. Conviene tener muy claro qué saldos corresponden a gastos corrientes, cuáles a inversiones a largo plazo y cuáles actúan como respaldo de emergencia en el peor momento posible. Si tus nóminas o el pago de tu alquiler dependen de la inmediatez en los retiros, asegúrate de contar con un canal alternativo. No asumas la familiaridad de la interfaz de un exchange como garantía de control sobre tus propios fondos.

Mira consigue finalmente enviar su dinero; lo hace tarde, cuando el proveedor ya ha reclamado el pago por segunda vez. No ha sufrido pérdidas y el balance de su cuenta no se ha visto mermado financieramente. Sin embargo, no olvidará esa media hora en la que su dinero figuraba en pantalla sin poder salir de allí. Ese recuerdo la acompañará al utilizar el próximo producto financiero, recordándole que no se puede delegar ciegamente la vigilancia en manos ajenas.

Siempre que el siguiente paso implique transferir USDT en TRON, la Calculadora de transferencias USDT de Netts estima la cantidad exacta de Energy y Bandwidth requerida tanto por el emisor como por el receptor antes de ordenar la transacción. Esto permite al usuario contrastar alternativas con comisiones reducidas en USDT frente a la quema habitual de TRX y acceder a las tarifas más competitivas disponibles para cada envío, transformando un gasto pequeño y controlable en una decisión premeditada antes de confirmar la operación en la billetera.