Binance: entrevista falsa de trabajo causó robo de US$6.300M

Una entrevista de trabajo falsa abrió la bóveda de Binance

Un ingeniero de Binance pasó por dos rondas de entrevistas para un puesto que no existía. Al final de la segunda, le pidieron descargar una "prueba técnica". Ese archivo fue la puerta de entrada al mayor robo de criptomonedas registrado: unos US$6.300M extraídos de las wallets de la casa de cambio el 29 de octubre, según el informe de incidente que la compañía publicó el martes.

Para cualquier founder que contrata desarrolladores en remoto, la lección es incómoda: el eslabón más débil de una infraestructura que custodia miles de millones no fue el código, fue un proceso de selección.

Cómo empezó el ataque: una cadena de suministro comprometida en junio

Según el reporte de Binance, la preparación arrancó meses antes del robo. En junio, uno de sus ingenieros descargó una instalación maliciosa de Homebrew, el gestor de paquetes de macOS, en lo que la compañía describe como un ataque a la cadena de suministro. The Verge reportó que el instalador manipulado llegó a través de un anuncio malicioso en un buscador.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El equipo de seguridad detectó el malware, reemplazó el equipo afectado y rotó todas las credenciales comprometidas. Pero el reporte reconoce que el rol del "Ingeniero A" y de sus colegas del equipo de infraestructura de wallets "quedó expuesto al atacante". Esa exposición silenciosa se convirtió en el mapa que los atacantes usarían tres meses después.

La ingeniería social: dos entrevistas y una prueba técnica envenenada

En septiembre, un segundo ingeniero de software fue contactado a través de una plataforma legítima de búsqueda de empleo por alguien que se presentó como director de proyecto de una empresa ficticia. Ese supuesto reclutador organizó una serie de entrevistas.

La primera ronda fue una videollamada en vivo con una falsa representante de recursos humanos, que compartió una cuenta de redes sociales con fotos y videos personales para construir confianza. Binance describe el método como "más avanzado y engañoso que los enfoques de ingeniería social vistos anteriormente".

La segunda entrevista, con alguien que decía ser el CEO de la empresa falsa, se hizo en una aplicación de chat popular. Hacia el final, el falso CEO le pidió descargar un "assignment" que contenía un repositorio de código con malware. El código se ejecutó en la computadora de trabajo del ingeniero durante el proceso de instalación.

Por qué el antivirus no lo detectó

El malware reemplazó un componente legítimo de una herramienta de desarrollo, el ejecutable pyenv de Homebrew, por una versión maliciosa. El script creó un archivo llamado pyenv_, borró el pyenv válido, renombró el malicioso, modificó el enlace simbólico y lanzó un proceso zsh desde ahí.

El resultado: ejecución de comandos remotos contra un servidor controlado por el atacante. Según Binance, el malware usó técnicas sofisticadas de ofuscación y evasión, y "no fue detectado por las herramientas de protección de endpoints en ese momento". La compañía lo describe como un malware 0-day.

El rol de la IA interna y el detalle del EIP-7702

El 20 de octubre, los atacantes usaron la computadora comprometida y una herramienta de IA interna de Binance para llegar a los equipos del Ingeniero A y de un tercer desarrollador, identificado como Ingeniero C. En el equipo del Ingeniero A encontraron un token de permisos para despliegue de contenedores.

El 29 de octubre, el atacante accedió a la computadora del Ingeniero C, usó las credenciales robadas del Ingeniero A para desplegar un contenedor y disparó el script que ejecutó el robo.

Binance también explicó por qué no pudo frenar las transacciones: como la hot wallet usaba Multi-Party Computation (MPC), no existía una única clave privada que permitiera revocar de inmediato las autorizaciones maliciosas del estándar EIP-7702 de Ethereum. Los atacantes aprovecharon ese mecanismo para seguir extrayendo fondos incluso después de que la casa de cambio suspendió los retiros, según BleepingComputer.

¿Qué significa esto para tu startup?

El ataque no dependió de un fallo exótico. Dependió de tres cosas que casi cualquier startup tiene: un proceso de contratación abierto, una herramienta interna con permisos amplios y credenciales que sobreviven más de lo que deberían.

Si tu equipo contrata developers de forma remota, lo normal en LATAM y España, el vector es idéntico; solo cambia el monto. Que un candidato ejecute código en su propia máquina es la norma. Que lo haga en un equipo con acceso a producción no debería serlo nunca.

Además, el caso deja una pregunta que pocas startups se hacen: ¿qué accesos tiene tu herramienta de IA interna? En Binance, esa herramienta sirvió de escalera entre tres empleados. Si tu copiloto de código, tu bot de soporte o tu agente interno pueden leer repositorios, tickets o credenciales, ya son superficie de ataque.

Acciones concretas para blindar tu equipo

Aísla la ejecución de código de terceros. Nunca corras una prueba técnica de un candidato en una máquina con acceso a repositorios privados, tokens de despliegue o VPN corporativa. Usa una máquina virtual desechable o un entorno en la nube sin credenciales.
Verifica identidad en ambos sentidos. Exige videollamada en vivo con cámara, correo con dominio corporativo y perfiles verificables. Si la "empresa" solo existe en un chat, es una señal de alarma.
Aplica permisos mínimos y rotación agresiva. Un token de despliegue de contenedores no debería vivir en la laptop de un ingeniero. Rota credenciales cada vez que alguien sale de un proyecto, no solo cuando renuncia.
Audita tus herramientas de IA internas. Revisa qué datos y sistemas puede alcanzar cada agente o asistente, y trátalos como cuentas privilegiadas, no como utilidades.
Asume que el antivirus no alcanza. El malware de Binance era 0-day y evadió las herramientas de endpoint. La detección temprana depende de segmentación y monitoreo de comportamiento, no solo de firmas.

Qué hizo Binance después del robo

La casa de cambio reconstruyó el sistema de wallets comprometido y la herramienta de IA interna, reemplazó los dispositivos afectados y desactivó todas las credenciales y tokens de los ingenieros comprometidos. También contrató expertos independientes para una revisión de ciberseguridad y anunció que trabaja en un fondo de investigación en seguridad junto a empresas de IA y de seguridad, enfocado en entornos blockchain.

En recuperación, según BleepingComputer, unos US$2.850M en activos robados ya habían sido congelados o interceptados al 3 de noviembre, y el 98% de los tokens afectados estaba repuesto al 31 de octubre. El CEO Richard Teng afirmó que ningún usuario asume la pérdida, según The Verge. Binance también dijo haber prevenido 57 casos sospechosos vinculados a Corea del Norte.

El contexto: Corea del Norte convirtió el hackeo en industria

El robo a Binance no es un caso aislado, es la punta de una operación estatal sostenida.

TRM Labs estima que actores norcoreanos robaron US$7.400M solo en 2026, el 85% de todo el valor robado en hackeos cripto a nivel global ese año, según Crypto Briefing.
El analista on-chain Darkfost calcula que el grupo Lazarus acumula unos US$11.870M en cripto robado, equivalente al 45% del PIB estimado de Corea del Norte en 2025.
BleepingComputer repasa los antecedentes: US$387,5M de Bitget en septiembre de 2026, US$280M de Drift en abril de 2026, US$1.500M de Bybit en febrero de 2025 y US$308M de DMM Bitcoin en mayo de 2024.
El FBI publicó una lista de 628 direcciones de criptomonedas vinculadas al robo: 608 de Ethereum, 19 de Bitcoin y una de Solana.

El patrón se repite. En el hackeo de DMM Bitcoin, los atacantes se hicieron pasar por un reclutador en LinkedIn y engañaron a un empleado de la empresa de wallets Ginco para que ejecutara código Python malicioso disfrazado de prueba de preempleo. En el de Bybit, el punto de entrada fue la computadora de un desarrollador de Safe{Wallet}. La campaña conocida como Operation DreamJob lleva años explotando exactamente el mismo guion.

Conclusión

Binance perdió miles de millones por una entrevista de trabajo. No por un contrato inteligente mal auditado ni por una clave filtrada en un repositorio público, sino por un candidato que descargó un archivo en la laptop equivocada.

Para un founder, la conclusión práctica es que la seguridad de tu startup se juega en los procesos, no solo en el stack. Tu pipeline de contratación, tus permisos de despliegue y tus herramientas de IA interna son infraestructura crítica, aunque no lo parezcan. Revisarlos cuesta una tarde; ignorarlos puede costar la compañía.