{"id":45046,"date":"2026-10-30T02:00:00","date_gmt":"2026-10-30T02:00:00","guid":{"rendered":"https:\/\/www.iprofesional.com\/tecnologia\/467874-hackers-habian-dado-un-golpe-a-bitget-por-us388-millones-y-ahora-lo-sufre-binance"},"modified":"2026-10-30T02:00:00","modified_gmt":"2026-10-30T02:00:00","slug":"un-mes-antes-que-el-caso-binance-habian-hackeado-bitget-y-se-robaron-us388-millones","status":"publish","type":"post","link":"https:\/\/latecordoba.com\/index.php\/2026\/10\/30\/un-mes-antes-que-el-caso-binance-habian-hackeado-bitget-y-se-robaron-us388-millones\/","title":{"rendered":"Un mes antes que el caso Binance hab\u00edan hackeado Bitget y se robaron u$s388 millones"},"content":{"rendered":"\n
<\/div>\n
<\/div>\n

El mercado de las criptomonedas volvi\u00f3 a quedar en alerta por un posible ataque inform\u00e1tico contra uno de sus principales jugadores. Binance, el mayor exchange del mundo, investiga una serie de movimientos sospechosos de activos digitales que encendieron las alarmas sobre una eventual vulnerabilidad de seguridad. La dimensi\u00f3n del episodio es in\u00e9dita: la plataforma inform\u00f3 que logr\u00f3 congelar alrededor de u$s3.000 millones en criptomonedas vinculadas con las operaciones bajo investigaci\u00f3n.<\/span><\/p>\n

La respuesta involucr\u00f3 a dos actores centrales del ecosistema de las stablecoins. Tether y Circle<\/strong>, emisores de USDT y USDC<\/strong>, respectivamente, bloquearon activos por m\u00e1s de u$s2.360 millones<\/strong>, mientras Binance asegur\u00f3 que los fondos de sus clientes est\u00e1n a salvo y que trabaja con autoridades, firmas de inteligencia blockchain y otros participantes de la industria para rastrear nuevos movimientos. Por ahora, la compa\u00f1\u00eda no confirm\u00f3 que se haya producido un robo de fondos ni precis\u00f3 el alcance definitivo del incidente. La investigaci\u00f3n sigue abierta y el episodio ya tuvo repercusiones en el mercado.<\/p>\n

El caso vuelve a poner bajo la lupa la seguridad de las grandes plataformas de intercambio y la capacidad de respuesta de una industria que custodia miles de millones de d\u00f3lares en activos digitales. No es una preocupaci\u00f3n nueva: el 24 de septiembre, Bitget sufri\u00f3 un ataque <\/strong>que deriv\u00f3 en transferencias no autorizadas por aproximadamente u$s388 millones<\/strong>, en uno de los incidentes de seguridad m\u00e1s relevantes del a\u00f1o. A diferencia de lo que todav\u00eda ocurre con Binance, en ese episodio la plataforma pudo reconstruir el mecanismo de intrusi\u00f3n y public\u00f3 una cronolog\u00eda detallada de lo sucedido.<\/p>\n

La investigaci\u00f3n revel\u00f3 un aspecto especialmente inquietante: los atacantes no necesitaron vulnerar directamente la blockchain ni robar las claves privadas de las billeteras. La puerta de entrada fue una falla en un producto de seguridad de un proveedor externo, que permiti\u00f3 comprometer sistemas internos y ejecutar movimientos fraudulentos. El episodio dej\u00f3 al descubierto los riesgos que enfrenta el negocio cripto cuando la seguridad de una plataforma depende tambi\u00e9n de terceros y plantea una pregunta central para el sector: \u00bfqu\u00e9 tan protegidos est\u00e1n los fondos cuando la vulnerabilidad no est\u00e1 en la blockchain, sino en la infraestructura que administra las operaciones?<\/p>\n

La dimensi\u00f3n econ\u00f3mica del incidente lo convirti\u00f3 en un episodio de relevancia para la industria, pero su particularidad est\u00e1 en la metodolog\u00eda utilizada. Seg\u00fan la investigaci\u00f3n difundida por la compa\u00f1\u00eda, los atacantes no consiguieron vulnerar directamente la blockchain ni robar las claves privadas de las billeteras. El punto de entrada fue una vulnerabilidad en un producto de seguridad de un proveedor externo<\/strong>, que les permiti\u00f3 obtener credenciales internas de alto privilegio y operar sobre los sistemas que administraban las transferencias.<\/span><\/p>\n

El caso deja una advertencia para todo el sector: incluso una plataforma que cuenta con mecanismos de protecci\u00f3n, almacenamiento en fr\u00edo y controles de riesgo puede quedar expuesta cuando alguno de los componentes de su infraestructura tecnol\u00f3gica<\/strong> se convierte en la puerta de entrada para un atacante.<\/p>\n

C\u00f3mo fue el ataque a Bitget: la puerta de entrada estuvo en un tercero<\/h2>\n

El primer movimiento irregular se produjo el 24 de septiembre, alrededor de las 18:31 UTC<\/strong>. Los atacantes consiguieron ejecutar transferencias no autorizadas desde una parte de la infraestructura de billeteras calientes y tibias (hot y warm wallets)<\/strong> de Bitget.<\/p>\n

A las 19:05 UTC<\/strong>, el sistema de conciliaci\u00f3n de la plataforma detect\u00f3 una diferencia significativa en los movimientos de fondos. La respuesta autom\u00e1tica fue bloquear las solicitudes de retiro en toda la plataforma, mientras el equipo de seguridad activaba el protocolo de emergencia y comenzaba a aislar los sistemas comprometidos.<\/p>\n

La investigaci\u00f3n posterior permiti\u00f3 reconstruir una secuencia m\u00e1s compleja que la de un robo convencional de criptomonedas. Los atacantes explotaron una vulnerabilidad de tipo zero-day<\/strong> en un producto de seguridad de terceros utilizado por Bitget. Se trata de fallas que pueden ser aprovechadas antes de que exista una correcci\u00f3n disponible o, en determinados casos, antes de que el fabricante y los usuarios conozcan su existencia.<\/p>\n

A partir de esa brecha, consiguieron acceder a sistemas internos de administraci\u00f3n y obtener credenciales con permisos elevados<\/strong>. La informaci\u00f3n de identidad utilizada para ingresar parec\u00eda leg\u00edtima, por lo que los sistemas interpretaron esas operaciones como actividad interna autorizada.<\/p>\n

Con ese nivel de acceso, los intrusos llegaron a los servidores de backend vinculados con la gesti\u00f3n de billeteras y pudieron introducir instrucciones de retiro fraudulentas directamente en el sistema. El mecanismo resulta especialmente relevante: las \u00f3rdenes fueron procesadas como operaciones normales<\/strong>, sin atravesar correctamente los controles de verificaci\u00f3n de riesgo que deb\u00edan intervenir antes de autorizar los movimientos.<\/span><\/p>\n

Despu\u00e9s de ejecutar las transferencias, los atacantes tambi\u00e9n eliminaron rastros de los comandos falsificados para dificultar la reconstrucci\u00f3n del incidente.<\/p>\n

La investigaci\u00f3n t\u00e9cnica difundida por Mandiant<\/strong>, la firma de ciberseguridad de Google Cloud, aport\u00f3 detalles adicionales sobre el acceso inicial. En un informe de situaci\u00f3n fechado el 28 de septiembre<\/strong>, la compa\u00f1\u00eda describi\u00f3 el compromiso de dos dispositivos de seguridad de terceros, la instalaci\u00f3n de una web shell<\/strong> \u2014una herramienta que permite controlar un servidor de manera remota\u2014 y el establecimiento de una conexi\u00f3n de comando y control. Desde all\u00ed, los atacantes habr\u00edan avanzado lateralmente hacia un servidor de producci\u00f3n encargado de procesar operaciones de las billeteras e instalado paquetes maliciosos.<\/p>\n

El documento de Mandiant ten\u00eda car\u00e1cter preliminar y confidencial, por lo que sus hallazgos deben leerse en el contexto de una investigaci\u00f3n en curso. El 30 de septiembre<\/strong>, Bitget inform\u00f3 que tanto Mandiant como la firma especializada SlowMist hab\u00edan completado sus respectivos reportes y que sus conclusiones coincid\u00edan, en t\u00e9rminos generales, con el vector de ataque identificado por el exchange.<\/p>\n

Qu\u00e9 criptomonedas y redes fueron afectadas en el ataque a Bitget<\/h2>\n

La cifra del incidente tambi\u00e9n tuvo una evoluci\u00f3n durante los primeros d\u00edas. En su comunicaci\u00f3n inicial, Bitget estim\u00f3 que los fondos comprometidos ascend\u00edan a u$s351,6 millones<\/strong>. Luego, a medida que avanz\u00f3 el an\u00e1lisis de las transacciones en blockchain y se incorporaron movimientos que no estaban contemplados en el c\u00e1lculo original, la estimaci\u00f3n subi\u00f3 primero a u$s387,5 millones<\/strong> y finalmente qued\u00f3 establecida en aproximadamente u$s388 millones<\/strong>.<\/p>\n

La compa\u00f1\u00eda aclar\u00f3 que la actualizaci\u00f3n no represent\u00f3 nuevos robos posteriores al ataque, sino una clasificaci\u00f3n m\u00e1s completa de las operaciones realizadas durante el incidente original.<\/p>\n

El an\u00e1lisis identific\u00f3 12 direcciones de billeteras<\/strong> vinculadas con la infraestructura caliente y tibia de la plataforma. Las operaciones involucraron 11 redes blockchain<\/strong>, entre ellas:<\/p>\n

    \n
  • Ethereum<\/li>\n
  • XRP Ledger<\/li>\n
  • Zcash<\/li>\n
  • TRON<\/li>\n
  • Arbitrum<\/li>\n
  • Optimism<\/li>\n
  • Base<\/li>\n
  • BNB Smart Chain<\/li>\n
  • Avalanche<\/li>\n
  • Algorand<\/li>\n
  • Celestia<\/li>\n<\/ul>\n

    Entre los activos alcanzados aparecen XRP, Ethereum (ETH), Tether (USDT), USD Coin (USDC), Zcash (ZEC), BNB, Avalanche (AVAX), TRON (TRX), Algorand (ALGO), Celestia (TIA) y Tether Gold (XAUt)<\/strong>, entre otros.<\/p>\n

    Uno de los puntos centrales para dimensionar el episodio es que el ataque estuvo limitado a una parte de las billeteras calientes y tibias<\/strong>. En la arquitectura de custodia de los exchanges, las hot wallets permanecen conectadas a Internet y permiten procesar operaciones y retiros con mayor rapidez. Las warm wallets funcionan como una capa intermedia de almacenamiento y gesti\u00f3n. En cambio, las cold wallets mantienen los activos fuera de l\u00ednea y reducen la exposici\u00f3n a ataques remotos.<\/p>\n

    Seg\u00fan Bitget, las billeteras fr\u00edas de todas las redes permanecieron intactas<\/strong>. La investigaci\u00f3n tambi\u00e9n descart\u00f3 que se hubieran comprometido las claves privadas. Esto marca una diferencia t\u00e9cnica importante: los atacantes no necesitaron extraer las claves criptogr\u00e1ficas para mover los fondos, sino que lograron manipular los mecanismos internos que autorizaban las operaciones.<\/p>\n

    Qu\u00e9 pas\u00f3 con los fondos de los usuarios y c\u00f3mo respondi\u00f3 Bitget<\/h2>\n

    La primera medida de contenci\u00f3n fue suspender los retiros<\/strong>. La decisi\u00f3n gener\u00f3 incertidumbre entre los clientes, aunque la compa\u00f1\u00eda sostuvo que los saldos de las cuentas no hab\u00edan sido afectados y que las operaciones de trading y los dep\u00f3sitos continuaron funcionando durante el proceso de revisi\u00f3n.<\/p>\n

    Bitget tambi\u00e9n inform\u00f3 que notific\u00f3 a las autoridades correspondientes y que puso en marcha tareas de rastreo junto con empresas de an\u00e1lisis blockchain, exchanges, proyectos del ecosistema y especialistas en seguridad.<\/p>\n

    En paralelo, la compa\u00f1\u00eda aisl\u00f3 los servidores afectados, corrigi\u00f3 la vulnerabilidad identificada, revoc\u00f3 y renov\u00f3 credenciales internas y restringi\u00f3 los permisos de acceso a los sistemas m\u00e1s sensibles. Tambi\u00e9n comunic\u00f3 que incorpor\u00f3 controles adicionales para las operaciones cr\u00edticas<\/strong>, con mecanismos de aprobaci\u00f3n m\u00faltiple y una verificaci\u00f3n m\u00e1s estricta de los retiros.<\/p>\n

    La restauraci\u00f3n de los servicios se realiz\u00f3 por etapas. Los retiros de Bitcoin se habilitaron el 28 de septiembre<\/strong>; los de Ethereum, el 29<\/strong>; y los de USDT, el 30<\/strong>. Finalmente, el 2 de octubre<\/strong> volvieron a estar disponibles los retiros de los dem\u00e1s activos compatibles, junto con los servicios de moneda fiduciaria y operaciones entre usuarios (C2C).<\/p>\n

    De esta manera, Bitget complet\u00f3 el cronograma de normalizaci\u00f3n anunciado despu\u00e9s del ataque. La empresa afirm\u00f3 que no identific\u00f3 nuevas transferencias no autorizadas una vez contenida la intrusi\u00f3n.<\/p>\n

    El fondo de protecci\u00f3n de Bitget: \u00bfalcanza para cubrir el hackeo?<\/h2>\n

    Otro de los puntos centrales de la respuesta fue el respaldo financiero anunciado por la compa\u00f1\u00eda. Bitget cuenta con un fondo de protecci\u00f3n (Protection Fund)<\/strong> destinado a funcionar como una cobertura adicional frente a incidentes de seguridad que afecten a la plataforma.<\/p>\n

    Tras conocerse el ataque, la empresa se comprometi\u00f3 a recomponer ese fondo hasta alcanzar al menos u$s300 millones en el plazo de una semana<\/strong>. Seg\u00fan inform\u00f3 el 30 de septiembre, logr\u00f3 superar ese objetivo antes de lo previsto. Su \u00faltima actualizaci\u00f3n indic\u00f3 que el fondo contaba con 3.705 bitcoins, valuados en m\u00e1s de u$s300 millones<\/strong>.<\/p>\n

    Bitget sostiene que el impacto econ\u00f3mico del incidente est\u00e1 contemplado dentro de la cobertura de ese mecanismo y que no ser\u00e1 trasladado a los saldos de los clientes.<\/span><\/p>\n

    La compa\u00f1\u00eda tambi\u00e9n public\u00f3 una actualizaci\u00f3n de su sistema de Prueba de Reservas (Proof of Reserves)<\/strong>, que inform\u00f3 una tasa de respaldo global del 131% sobre 19 activos<\/strong>, de acuerdo con una fotograf\u00eda de las reservas tomada el 29 de septiembre. Seg\u00fan esos datos, todos los activos incluidos en el relevamiento superaban el umbral del 100%.<\/p>\n

    Sin embargo, ambos instrumentos cumplen funciones diferentes. La Prueba de Reservas busca demostrar que los activos mantenidos por la plataforma respaldan los saldos de los usuarios contemplados en el informe. El Protection Fund, en cambio, constituye una reserva adicional destinada a afrontar determinados incidentes de seguridad.<\/p>\n

    Por eso, contar con reservas superiores al 100% no equivale, por s\u00ed solo, a demostrar que una plataforma es inmune a ataques inform\u00e1ticos. La seguridad tambi\u00e9n depende de la infraestructura tecnol\u00f3gica, los controles de acceso, los procesos de autorizaci\u00f3n<\/strong> y la capacidad de detectar operaciones an\u00f3malas.<\/p>\n

    Rastreo de criptomonedas y recompensas para recuperar los fondos<\/h2>\n

    Con el ataque contenido, una de las prioridades pas\u00f3 a ser seguir el recorrido de los activos y recuperar la mayor cantidad posible de fondos.<\/p>\n

    Para eso, Bitget public\u00f3 un tablero de seguimiento en tiempo real que permite observar los movimientos de las direcciones identificadas y puso en marcha un programa de recompensas<\/strong> para quienes colaboren voluntariamente con el congelamiento o la recuperaci\u00f3n de los activos.<\/p>\n

    La propuesta contempla una recompensa equivalente al 5% de los fondos<\/strong> que puedan ser congelados o recuperados como resultado directo de la colaboraci\u00f3n de terceros, sujeta a las condiciones de elegibilidad del programa.<\/p>\n

    La iniciativa tambi\u00e9n contempla la cooperaci\u00f3n con LazarusBounty<\/strong>, el programa de recompensas impulsado por Bybit para combatir el robo de activos digitales. La estrategia apunta a involucrar a exchanges, emisores de stablecoins, puentes entre redes, proyectos blockchain y empresas especializadas en rastreo de transacciones.<\/p>\n

    Bitget confirm\u00f3 que algunos fondos ya hab\u00edan sido congelados gracias a la coordinaci\u00f3n con distintos participantes de la industria. Sin embargo, no public\u00f3 un monto acumulado definitivo de activos recuperados, debido a que las tareas de seguimiento contin\u00faan y las cifras pueden modificarse a medida que se identifican nuevos movimientos.<\/p>\n

    \n
    \n

    COMPARTIR ESTA NOTA<\/p>\n<\/p><\/div>\n<\/p><\/div>\n","protected":false},"excerpt":{"rendered":"\n

    <\/div>\n

    Ambos casos ponen bajo la lupa la seguridad de las grandes plataformas de intercambio y la capacidad de respuesta de la industria