El 7 de mayo de 2019, Binance, el mayor exchange de criptomonedas del mundo por volumen, sufrió una brecha de seguridad a gran escala. Un grupo de atacantes obtuvo claves API, códigos 2FA y otra información de usuarios mediante phishing y malware, y logró estructurar una única transacción de retiro que evadió los controles de riesgo previos, sustrayendo 7,000–7,074 BTC del hot wallet de la compañía. Binance detuvo el incidente en minutos, cubrió la pérdida en su totalidad con el fondo SAFU y publicó el caso como un ejercicio de transparencia poco habitual en la industria.

Haz clic en los encabezados para ordenar la tabla.

Fuente: comunicado oficial "Binance Security Breach Update".

El ataque no explotó ninguna falla criptográfica de Bitcoin: se dirigió contra la capa humana y operativa del exchange. Explora los tres pilares tácticos que permitieron sustraer los fondos sin activar las alarmas preventivas.

Un año antes, en julio de 2018, Binance ya había sufrido un incidente prácticamente idéntico. La comunidad lo bautizó como "el hackeo anual de 7,000 BTC", aunque nunca hubo confirmación oficial de que se tratara del mismo grupo. Ordena la tabla para comparar ambos eventos.

La evidencia del caso se divide entre lo verificable públicamente en la blockchain (on-chain) y los registros internos de Binance (off-chain), complementados por la colaboración de firmas externas de análisis.

Filtra por tipo de aporte para explorar quién participó en el rastreo.

Este caso, al tratarse de un exchange centralizado y no de un dispositivo confiscado, no encaja en el modelo clásico de forense de disco o teléfono. La evidencia está repartida entre la infraestructura interna de Binance y la propia red pública de Bitcoin. A continuación se describe cómo se manejaría esa evidencia siguiendo estándares forenses reconocidos (NIST SP 800-86, ISO/IEC 27037) y las reglas de admisibilidad aplicables en jurisdicciones que siguen las Federal Rules of Evidence (FRE) de EE. UU.

No aplica adquisición física (no hay disco/teléfono que clonar). Es adquisición lógica: exportación de logs de servidor + consulta directa de la transacción vía nodo/explorador de blockchain. Es la norma en exchanges e infraestructura cloud.

Es fundamental distinguir dos hashes con propósitos completamente distintos:

• FRE 902(13)/902(14) (vigentes desde dic. 2017): auto-autenticación de evidencia electrónica vía certificación de hash por persona calificada, sin necesidad de testimonio en vivo.
• La naturaleza pública/verificable de la blockchain es una ventaja probatoria: cualquier perito de la contraparte puede reproducir la verificación de forma independiente.
• Vía formal de acceso a registros internos de Binance: su portal LERS (Government Law Enforcement Request System), con orden judicial correspondiente.

Binance nunca publicó un informe forense detallado con esta metodología específica para el caso de 2019 — mantuvo los detalles técnicos internos por seguridad operativa. Lo descrito aquí es la metodología estándar (NIST SP 800-86, ISO/IEC 27037, FRE 902) que se aplicaría, no un procedimiento confirmado públicamente por Binance.

Al tratarse de fondos en Bitcoin, el análisis forense posterior fue esencialmente forense de blockchain: la evidencia central era pública y trazable, y la investigación se centró en el clustering de direcciones y la detección de patrones de fusión de fondos a través de un mixer.

El hackeo de Binance en mayo de 2019 demuestra que las amenazas más efectivas contra plataformas de criptomonedas no provienen de vulnerabilidades criptográficas del protocolo, sino de la capa humana y operativa: phishing, malware y la explotación de procesos de autenticación débiles. La respuesta de Binance (cobertura total mediante el fondo SAFU, comunicación transparente en tiempo real y coordinación con otros exchanges para bloquear los fondos) estableció un referente de gestión de crisis en la industria. Sin embargo, el análisis forense posterior reveló las limitaciones estructurales del rastreo de fondos en Bitcoin: el uso de mixers como ChipMixer diluyó la trazabilidad y, a la fecha, no existe una atribución pública confirmada del atacante.

El caso refuerza una lección fundamental para la seguridad de exchanges centralizados: mientras la custodia de activos digitales dependa de claves API, tokens 2FA y credenciales operadas por humanos, ningún volumen de cifrado protegerá lo que un correo de phishing puede comprometer.