Análisis de un incidente

El ataque a Binance, explicado sin tecnicismos

Qué pasó, por qué detener las retiradas no bastó y qué puedes revisar en tu empresa.

¿Qué pasó?

El 29 de octubre de 2026, Binance sufrió un robo de criptoactivos. Su informe preliminar describe engaños, como entrevistas de trabajo falsas y descargas de programas manipulados, que permitieron acceder a ordenadores de empleados. Desde allí, el ataque llegó a la herramienta interna que autorizaba movimientos de fondos. El FBI atribuyó el ataque a actores de Corea del Norte.

Piensa en una caja fuerte: no basta con proteger la puerta si alguien consigue que el sistema acepte órdenes que nadie debería haber autorizado. Es una comparación para entenderlo, no una descripción literal de la infraestructura.

Fuentes: informe preliminar de Binance y comunicado del FBI.

Un empleado ante su ordenador recibe una supuesta oferta de trabajo que le pide instalar una herramienta. El programa esconde un acceso para el atacante.
1. El engaño abre una puerta. Una oferta o una descarga pueden parecer legítimas y ocultar un programa malicioso. Personajes ficticios e ilustraciones conceptuales basadas en el informe preliminar; no son imágenes de los empleados ni una reconstrucción exacta.
Una ruta conecta el ordenador de una empleada con permisos internos y un sistema que autoriza movimientos de fondos.
2. El acceso llega a operaciones sensibles. La cadena simplificada: un ordenador, permisos internos y operaciones que el atacante no debería poder autorizar.

No todas las cifras significan lo mismo

Activos reportados por Binance al 3 de noviembre de 2026
Afectados por el incidenteUS$ 6.340 millones
Congelados o interceptadosUS$ 2.850 millones

Importes aproximados, sujetos a conciliación y variaciones de precio. Congelados o interceptados no significa devueltos a los usuarios. Las barras no son cantidades que deban sumarse.

Detener las retiradas no cerró todas las puertas

Binance explica que algunos permisos ya autorizados en la cadena de bloques seguían funcionando fuera de su proceso normal de retiradas. También tuvo que revocarlos.

Una responsable detiene las retiradas habituales, pero identifica otros permisos que también debe revisar y anular para cerrar las rutas restantes.
3. Hay que cerrar las otras rutas. Detener el proceso habitual no anula automáticamente todos los permisos que ya se habían concedido.

Una pregunta para tu empresa

Si bloqueas una cuenta, ¿qué accesos siguen abiertos? Revisa también las sesiones, las conexiones entre aplicaciones y los permisos que esa cuenta haya concedido.

Esta pregunta es una aplicación práctica del caso. No significa que todos los sistemas funcionen como Binance ni que tu empresa tenga la misma exposición.

Cuatro cosas que puedes revisar

Son recomendaciones de Evaleris para reducir riesgos o limitar su impacto. No permiten afirmar que una medida aislada hubiera evitado este ataque.

01 / Instalaciones

Revisa qué se puede instalar

Define cómo se aprueban las herramientas de trabajo. Si una entrevista o un proveedor pide instalar algo, comprueba la petición por un canal independiente.

02 / Permisos

Limita hasta dónde llega una cuenta

Revisa quién puede acceder a sistemas críticos, con qué permisos y durante cuánto tiempo. Una cuenta para tareas diarias no debería dar acceso innecesario a operaciones sensibles.

03 / Operaciones

Comprueba las acciones importantes

Identifica pagos, cambios de cuentas y otras acciones de alto impacto. Revisa si necesitan una aprobación independiente y si se registra lo que se autorizó realmente.

04 / Respuesta

Ensaya cómo cortar todos los accesos

Practica qué hacer con una cuenta o un equipo comprometido. El plan debe contemplar sesiones abiertas, claves de aplicaciones, permisos delegados y dependencias externas.

Lo que todavía no podemos afirmar

El informe de Binance es preliminar. No es una investigación independiente final ni permite comprobar desde fuera todos sus controles. La investigación sigue abierta y las conclusiones pueden cambiar.

Este artículo explica un incidente; no determina responsabilidades ni garantiza que un servicio pueda evitar ataques similares.