Cómo una entrevista falsa abrió la puerta a Binance

Cómo se desarrolló el ataque

Lo más llamativo no es el phishing en sí, sino cómo un proceso de contratación normal se convirtió en una cadena de compromiso. En su publicación en X, Binance describió un esquema por etapas: localizaron a un ingeniero en una plataforma legítima de empleo, reforzaron la confianza con entrevistas y perfiles creíbles y después le pidieron descargar una prueba de código con malware ofuscado.

En el momento de publicar el aviso, Binance vinculaba la siguiente fase con el entorno de trabajo. El portátil comprometido y una herramienta interna de IA se utilizaron para llegar a los portátiles de otros dos ingenieros. Es un detalle importante: el atacante no avanzó mediante un exploit exótico, sino a través de flujos confiables de usuarios y desarrollo.

Después aparecen un token de despliegue de contenedores, el acceso a otro equipo de ingeniería y la ejecución de un script malicioso. A continuación se usó un servicio interno de firma, y el mecanismo Ethereum EIP-7702 otorgó a un contrato controlado autoridad parcial sobre una cartera caliente.

Desde la perspectiva de ingeniería, fallaron varias fronteras de confianza a la vez. Era posible ejecutar código ajeno en el portátil, un secreto de despliegue estaba disponible desde el endpoint y un servicio crítico aceptó acciones procedentes de una cadena ya comprometida. Prohibir la instalación de aplicaciones no habría resuelto esto.

Por qué MDM por sí solo no basta

En noviembre de 2026, la conclusión es sencilla: MDM es necesario, pero no puede actuar solo. Jamf puede imponer configuraciones, limitar software, retirar privilegios permanentes de administrador, desplegar agentes de protección y facilitar la respuesta remota. Sin embargo, bloquear la terminal no basta: la misma operación puede lanzarse desde otro binario o mediante una herramienta confiable.

La detección real se basa en el comportamiento. El EDR debe observar árboles de procesos, comandos, cambios de archivos, red y acceso a tokens; el SIEM debe relacionarlo con registros de identidad, repositorios, plataforma de contenedores y servicio de firma. Un repositorio nuevo, una shell ofuscada, la lectura de un token y un despliegue inusual ya parecen un incidente en conjunto, no ruido.

Primero revisaría la arquitectura de secretos: por qué el token estaba en una máquina de trabajo, cuán limitados eran sus permisos y si podían revocarse rápidamente. Un modelo de ML puede ayudar con secuencias raras de comandos, pero las reglas contra robo de credenciales y despliegues no autorizados deben bloquear de inmediato. La conclusión más incómoda es que un acceso válido convierte a un ingeniero de confianza en parte del perímetro atacable, incluso con todos los agentes instalados.

Anteriormente explicamos cómo los homoglifos Unicode pueden ocultar URL y comandos maliciosos para engañar a agentes de IA. Las mismas técnicas de ingeniería social usadas en falsas entrevistas muestran por qué los equipos deben verificar enlaces, identidades y solicitudes de ejecución.