Binance: roban 6300 millones de dólares de sus monederos calientes, un portátil DevOps como primera pista y el FBI señala a Corea del Norte

Binance confirma que sus monederos calientes fueron comprometidos el 29 de octubre, con pérdidas de unos 6300 millones de dólares. Primero apuntó al portátil de un ingeniero DevOps y luego halló otros puntos de intrusión. Según BleepingComputer, el FBI atribuye el robo al grupo norcoreano TraderTraitor.

Qué ha pasado

Binance afirma que sus monederos calientes fueron comprometidos hacia las 20:05 UTC del 29 de octubre de 2026, lo que permitió retiradas no autorizadas por unos 6300 millones de dólares. TRM Labs, que eleva la cifra a 6360 millones, indica que los fondos salieron por diez cadenas de bloques, en su mayoría en unos 20 minutos, y habla del mayor robo de criptoactivos registrado. Según BleepingComputer, el FBI publicó el 31 de octubre una alerta que atribuye el robo a TraderTraitor, un grupo respaldado por el Estado norcoreano; junto con el Secret Service y el IRS Criminal Investigation, pidió a las plataformas que bloqueen 628 direcciones vinculadas al blanqueo.

Cómo entraron los atacantes

El primer comunicado de Binance apuntaba al portátil comprometido de un ingeniero DevOps, usado para llegar a un contenedor de servicio y enviar transacciones de retirada. El siguiente añade que hallazgos posteriores revelaron otros puntos de intrusión. La empresa dice no tener pruebas de una filtración de claves privadas y promete un informe detallado. Según BleepingComputer, uno de sus codirectores ejecutivos afirmó que el atacante no se limitó a usar los permisos de un solo ingeniero y que no se ha responsabilizado a ninguna persona. Para TRM Labs, la explicación más probable es el control de la infraestructura de firma de los monederos calientes; Binance no ha publicado una causa raíz.

Binance informa de unos 3000 millones de dólares congelados en las cadenas de bloques y asegura que asumirá la pérdida. El 1 de noviembre indicó que cerca del 95 % del importe estaba cubierto, que los depósitos no estaban afectados y que una primera fase de retiradas estaba prevista ese mismo día de 06:00 a 09:00 UTC.

Qué hacer ahora

  1. Dedique equipos a la administración: nada de correo ni navegación general en una máquina con acceso a producción.
  2. Retire los secretos de larga duración de los portátiles: revise ~/.ssh, ~/.kube/config y los archivos de credenciales de la nube, y pase a accesos de corta duración mediante SSO con MFA por llave física.
  3. Mida lo que puede hacer un portátil: ejecute kubectl auth can-i --list con las credenciales de un administrador, elimine lo innecesario y bloquee el acceso directo desde las redes de oficina a los contenedores de producción.
  4. Exija una segunda aprobación para acciones irreversibles: exportaciones masivas, borrado de copias de seguridad, pagos.
  5. Configure alertas de volumen con parada automática: en 20 minutos no hay tiempo para una decisión humana.

Nuestra opinión

Pocas empresas custodian miles de millones, pero casi todas tienen un portátil de administrador capaz de llegar a producción. Sea cual sea la conclusión del informe final, el objetivo es el mismo: una sola máquina comprometida nunca debe bastar para desencadenar una acción irreversible. La revocación rápida de accesos también conviene ensayarla antes de necesitarla.

Fuentes

Cómo elegimos, verificamos y redactamos nuestros análisis →

Compruebe antes de hacer clic y controle lo que exponen sus servidores, gratis y sin intrusión:

Comprobar un correo Comprobar un servidor

¿Le preocupa que sus servidores estén expuestos? Nuestro equipo audita, parchea y supervisa infraestructuras Linux y cloud 24/7.

Hablar con un experto Nuestros servicios de servidores gestionados →