Hackeo de Binance: tu portátil de developer es producción

El jueves 29 por la noche, hora europea, empezó el hackeo de Binance: alguien sacó del exchange unos 6.300 millones de dólares. Según TRM Labs y Elliptic, es el mayor robo de criptomonedas de la historia.

Lo raro no fue la cifra. Fue la primera explicación de Binance. No habló de una clave privada filtrada ni de un contrato con un fallo. Habló del portátil de un ingeniero de DevOps.

Horas después rebajó esa explicación: el portátil "pudo estar implicado", pero hubo más puntos de entrada. No lo ha confirmado ni descartado. Y esa pista es la parte del hackeo de Binance que va contigo aunque nunca hayas tocado una criptomoneda.

En corto: Binance estima en unos 6.300 M$ el robo del 29 de octubre de 2026 y dice que su investigación preliminar apunta al portátil comprometido de un ingeniero de DevOps, aunque después ha encontrado más puntos de entrada. La lección para developers: si desde tu portátil se llega a producción, tu portátil es producción. Y tu agente de código lee lo mismo que tú.

Última actualización de los hechos: 30 de octubre de 2026, 15:56 UTC. La investigación sigue abierta y las cifras cambian por horas.

¿Qué pasó en el hackeo de Binance?

El hackeo de Binance es el robo de unos 6.300 millones de dólares de los monederos calientes del exchange, iniciado el 29 de octubre de 2026, que según Binance pudo empezar en el portátil comprometido de un ingeniero de DevOps.

En su comunicado en X, Binance explica que desde ese portátil el atacante llegó a un contenedor de servicio y envió retiradas no autorizadas. Y añade: "We have found no evidence of any wallet private key leak."

Elliptic lo lee igual desde la cadena: el atacante parece haber conseguido que los propios sistemas de Binance firmaran transacciones en su nombre. Si se confirma, no hizo falta llevarse las claves. Richard Teng lo confirmó en parte: el atacante usó EIP-7702, una función de Ethereum, para obtener permiso sobre un monedero caliente sin pasar por los controles de aprobación de Binance.

Cronología y cifras del robo a Binance

Las cifras del hackeo de Binance no coinciden porque cada fuente mide a una hora y con un precio distintos.

Hora (UTC)	Qué pasó	Fuente
29 oct, 20:05	Empieza el drenaje de los monederos calientes	TRM Labs
30 oct, 00:04	Yi He, cofundadora: depósitos y retiradas suspendidos; Binance cubrirá las pérdidas	CryptoTicker
30 oct, 00:30	TRM Labs: 6.360 M$ robados y unos 2.700 M$ congelados en cadena	TRM Labs
30 oct, 02:25	Binance: portátil de DevOps → contenedor de servicio → retiradas. Unos 6.300 M$ de impacto, unos 3.000 M$ congelados	Binance en X
30 oct, 07:37	Richard Teng, co-CEO: "this was not a single 'one-click' action"; no atribuyen la culpa a ninguna persona	Richard Teng en X
30 oct, 08:47	Binance: "additional points of breach"; retiradas previstas en unas 45 horas; depósitos sin afectar	Binance en X
30 oct, 13:10 (última actualización)	Elliptic: 6.430 M$, probablemente Corea del Norte	Elliptic
30 oct, 14:33	Richard Teng, co-CEO: Binance reserva más de 6.340 M$ de fondos propios (unos 5.000 M$ ya en los tokens afectados); el atacante usó EIP-7702 para saltarse los controles de aprobación; retiradas en unas 40 horas, antes del domingo; prueba de reservas completa el lunes	Richard Teng en X

Según CoinDesk, Chainalysis lo estima en unos 5.900 M$, Tether congeló más de 1.570 M$ en USDT y Circle más de 800 M$ en USDC. Binance asegura que cubrirá todas las pérdidas con fondos propios y dice haber reservado más de 6.340 M$ para ello, unos 5.000 M$ ya en los mismos tokens robados.

TRM Labs atribuye el ataque "con alta confianza" a TraderTraitor, un grupo patrocinado por Corea del Norte. Binance no ha nombrado a nadie.

Por qué el hackeo de Binance te importa aunque no uses cripto

Una estación de trabajo de developer es superficie de ataque de producción cuando desde ella se llega a producción, y su seguridad es la de la credencial más poderosa que guarda.

Piensa en tu portátil: credenciales de tu nube, un token de npm que publica, claves SSH, una docena de .env. Y un agente de código (Claude Code, Codex, Cursor) que corre con tu usuario y lee lo que tú lees.

Saco tres ideas:

Tu portátil es producción. Nadie lo dibuja en el diagrama, pero si de él sale un kubectl contra el clúster, está dentro.
Tu agente hereda tu radio de explosión. Lo que lee un malware, lo lee tu agente. Y al agente lo puede manipular un README o un issue con instrucciones escondidas.
Las credenciales que no caducan son el premio. Según la documentación de IAM, las claves de AWS AKIA… son claves de acceso de usuario IAM, que no caducan solas, y las ASIA…, temporales de STS. Si alguien entra el martes, importa qué sigue funcionando el miércoles.

En el post sobre API keys y agentes de IA repaso las cinco vías por las que una key se escapa de un agente.

El patrón de TraderTraitor: ofertas de trabajo y perfiles DevOps

El FBI atribuyó a TraderTraitor el robo de unos 1.500 M$ a Bybit en febrero de 2025. Según el análisis que recoge el Wilson Center, empezó cuando un developer de Safe{Wallet} cayó en ingeniería social: comprometieron su estación de trabajo y desde ella secuestraron tokens de sesión de AWS.

En 2022, FBI, CISA y el Tesoro de EE. UU. describieron el método en el aviso AA22-108A: phishing a empleados de empresas cripto, a menudo de sistemas o DevOps, con mensajes que "often mimic a recruitment effort" para que instalen aplicaciones con malware.

Binance no ha dicho que esta vez fuera así. Solo encaja el perfil: un ingeniero de DevOps.

El hilo de Hacker News sobre el robo (más de 1.000 comentarios) recoge las dos lecturas. Un usuario cuenta un caso de una empresa que cayó porque un ingeniero descargó un troyano en el portátil del trabajo durante una entrevista falsa. Otro resume la otra mitad del problema: "Separation of duties so more than one person is needed to create and then approve such transactions?"

Qué puede leer tu agente de código en tu portátil

Tu agente de código puede leer cualquier fichero al que llegue tu usuario: credenciales de nube, tokens de npm y GitHub, claves SSH y los .env de tus proyectos. Esta tabla resume qué permite cada uno si alguien lo lee y cómo reducirlo.

Qué hay en tu portátil	Qué permite si alguien lo lee	Mitigación
`~/.aws/credentials` con `AKIA…`	Tu cuenta de AWS hasta que alguien revoque la clave	`aws sso login` o roles con credenciales temporales
`~/.npmrc` con `_authToken`	Publicar versiones de tus paquetes	Tokens granulares o publicar desde CI
`~/.kube/config` con `token` o `client-key-data`	Operar el clúster	Login OIDC con caducidad; nada de admin de producción en local
`~/.ssh/id_*` sin passphrase	Entrar en servidores y empujar a repos	`ssh-keygen -p -f ~/.ssh/id_ed25519` y agente SSH
Token de `gh` en disco	Leer y escribir en tus repos	Llavero del sistema y scopes mínimos
`.env` de proyectos	Las claves que contengan	Las de producción, fuera del portátil

Cómo auditar las credenciales de tu portátil

Este script lista las credenciales de larga duración de tu equipo. No imprime secretos ni modifica nada: solo rutas y tipos. Sirve en macOS, Linux y WSL2. En Windows, usa la versión de PowerShell de más abajo.

#!/usr/bin/env bash
# creds-audit.sh: lista credenciales de larga duracion en este equipo.
# Solo imprime rutas y tipos. No muestra ningun secreto ni modifica nada.
# Sirve en macOS, Linux y WSL2.

found=0
hit() { printf &#39;  [!] %-45s %s\n&#39; "$1" "$2"; found=$((found + 1)); }
has() { [ -f "$1" ] && grep -qE "$2" "$1" 2>/dev/null; }

echo "Credenciales en $HOME:"

has ~/.aws/credentials &#39;aws_access_key_id *= *AKIA&#39; \
  && hit ~/.aws/credentials "clave de acceso AWS permanente (AKIA...)"
has ~/.npmrc &#39;_authToken&#39; && hit ~/.npmrc "token de npm"
has ~/.docker/config.json &#39;"auth" *:&#39; && hit ~/.docker/config.json "login de registry en el fichero"
has ~/.kube/config &#39;^ *(token|client-key-data):&#39; \
  && hit ~/.kube/config "acceso a Kubernetes con token o clave"
has ~/.config/gh/hosts.yml &#39;oauth_token&#39; && hit ~/.config/gh/hosts.yml "token de GitHub en disco"
[ -f ~/.config/gcloud/application_default_credentials.json ] \
  && hit ~/.config/gcloud/application_default_credentials.json "credenciales por defecto de Google Cloud"

for key in ~/.ssh/id_*; do
  [ -f "$key" ] || continue
  case "$key" in *.pub) continue ;; esac
  ssh-keygen -y -P &#39;&#39; -f "$key" >/dev/null 2>&1 && hit "$key" "clave SSH sin passphrase"
done

dir="${1:-$HOME/code}"
if [ -d "$dir" ]; then
  n=$(find "$dir" -maxdepth 4 -name node_modules -prune -o \
        -type f -name &#39;.env*&#39; ! -name &#39;*.example&#39; -print 2>/dev/null | wc -l | tr -d &#39; &#39;)
  [ "$n" -gt 0 ] && hit "$dir" "$n ficheros .env (revisa cuales tienen claves reales)"
fi

echo
echo "Hallazgos: $found"

Pásale la carpeta de tus proyectos: bash creds-audit.sh ~/proyectos.

En Windows con PowerShell 5.1 o 7, esta versión hace lo mismo salvo la comprobación de claves SSH:

# creds-audit.ps1: credenciales de larga duracion en este equipo (Windows, PowerShell 5.1 o 7).
# Solo imprime rutas y tipos. No muestra ningun secreto ni modifica nada.
param([string]$Proyectos = "$env:USERPROFILE\code", [string]$Base = $env:USERPROFILE)

$checks = @(
  @{ p = "$Base\.aws\credentials";    r = &#39;aws_access_key_id\s*=\s*AKIA&#39;; d = &#39;clave de acceso AWS permanente (AKIA...)&#39; },
  @{ p = "$Base\.npmrc";              r = &#39;_authToken&#39;;                   d = &#39;token de npm&#39; },
  @{ p = "$Base\.docker\config.json"; r = &#39;"auth"\s*:&#39;;                   d = &#39;login de registry en el fichero&#39; },
  @{ p = "$Base\.kube\config";        r = &#39;^\s*(token|client-key-data):&#39;; d = &#39;acceso a Kubernetes con token o clave&#39; },
  @{ p = "$env:APPDATA\GitHub CLI\hosts.yml"; r = &#39;oauth_token&#39;;          d = &#39;token de GitHub en disco&#39; },
  @{ p = "$env:APPDATA\gcloud\application_default_credentials.json"; r = &#39;.&#39;; d = &#39;credenciales por defecto de Google Cloud&#39; }
)
foreach ($c in $checks) {
  if ((Test-Path $c.p) -and (Select-String -Path $c.p -Pattern $c.r -Quiet)) {
    &#39;  [!] {0,-45} {1}&#39; -f $c.p, $c.d
  }
}
if (Test-Path $Proyectos) {
  $n = @(Get-ChildItem -Path $Proyectos -Recurse -Depth 3 -Force -File -Filter &#39;.env*&#39; -ErrorAction SilentlyContinue |
        Where-Object { $_.FullName -notlike &#39;*\node_modules\*&#39; -and $_.Name -notlike &#39;*.example&#39; }).Count
  if ($n -gt 0) { &#39;  [!] {0,-45} {1} ficheros .env (revisa cuales tienen claves reales)&#39; -f $Proyectos, $n }
}

Ejecútalo con powershell -ExecutionPolicy Bypass -File creds-audit.ps1 -Proyectos C:\proyectos.

Lo pasé por mi portátil: un token de npm en el .npmrc. Lo que salga en el tuyo es una lista de tareas. Para cada línea, pregúntate: ¿esto necesita vivir en disco y para siempre?

Cómo impedir que tu agente lea tus secretos

En Claude Code necesitas dos capas. En ~/.claude/settings.json:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(~/.aws/**)",
      "Read(~/.ssh/**)",
      "Read(~/.kube/**)",
      "Read(~/.npmrc)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

Según la documentación de permisos, las reglas Read de deny cubren las herramientas de ficheros del agente y comandos de Bash que reconoce, como cat o head. No cubren un script de Python o Node que abre el fichero por su cuenta. Para eso está el sandbox, que limita a nivel de sistema operativo los comandos y sus procesos hijos.

Ojo: según esa documentación, el sandbox por defecto deja leer ~/.ssh y ~/.aws/credentials. Activarlo sin el bloque credentials o sin reglas Read de deny (que se fusionan con su configuración) no protege tus secretos.

Explico qué capa decide qué en hooks vs permissions en Claude Code. Y si construyes tus propios agentes, el ebook gratuito El Developer Agéntico tiene un capítulo dedicado a su seguridad.

Una regla sin configuración: el código de un proceso de selección no se ejecuta en tu portátil de trabajo. Máquina virtual, Codespace o contenedor desechable.

Lo que todavía no sabemos del hackeo de Binance

Cómo se comprometió el portátil. Binance no lo ha dicho y ha prometido un informe técnico. Según Teng, el atacante usó un mecanismo de autodestrucción que borró sus herramientas y su rastro, lo que complica la investigación. Lo de las ofertas de trabajo falsas, en este caso, es hipótesis.

Cuáles son los "puntos de entrada adicionales". En Hacker News circula que fueron registros de imágenes de contenedores; no lo he encontrado en ninguna fuente oficial.

La cifra exacta. Entre 5.900 y 6.430 M$ según quién mida. Lo congelado, entre unos 2.700 M$ (TRM, 00:30 UTC) y unos 3.000 M$ (Binance).

La atribución oficial. TRM Labs y Elliptic apuntan a Corea del Norte. Binance colabora con las fuerzas del orden (según Cointelegraph, entre ellas el FBI), pero ningún gobierno ha confirmado la atribución para este caso.

Límites de estas medidas

El script encuentra lo obvio. No ve secretos en el llavero del sistema, en variables de entorno, en el historial de la terminal ni en ficheros con nombres poco habituales.

Las reglas de Claude Code te protegen de tu agente, no de un malware. Y el sandbox no funciona en Windows nativo: hay que ejecutar Claude Code dentro de WSL2.

Y la más incómoda: un portátil comprometido no explica por sí solo 6.300 millones. Pregúntate cuánto daño puede hacer una persona con un solo portátil. Si la respuesta es "todo", el problema no es el portátil. Y si te toca responder a un incidente, recuerda lo que conté sobre parchear vulnerabilidades con un agente: rotar credenciales no se delega.

Por dónde empezar después del hackeo de Binance

Ejecuta el script hoy. Elige el hallazgo más peligroso, normalmente una clave AKIA o un token que puede publicar, y elimínalo antes del lunes. Solo uno. El resto, uno por semana.

Si vas a montar tu flujo con Claude Code de la idea al producto, como enseño en Construye con IA, pon esta configuración desde el primer commit. Sacar los secretos del alcance del agente después cuesta más.

Porque la seguridad de tu portátil es la de su credencial más poderosa. Y tu agente la tiene a mano.

Preguntas frecuentes

¿Cuánto dinero se robó en el hackeo de Binance?

Binance estima unos 6.300 millones de dólares. TRM Labs cuenta 6.360 M$, Elliptic 6.430 M$ y Chainalysis unos 5.900 M$. La diferencia viene de la hora y el precio que usa cada uno.

¿Cómo empezó el hackeo de Binance?

Según la investigación preliminar de Binance, en el portátil comprometido de un ingeniero de DevOps, desde el que el atacante llegó a un contenedor de servicio. Después Binance añadió que hubo más puntos de entrada. No ha explicado cómo se comprometió el portátil.

¿Quién está detrás del robo a Binance?

TRM Labs lo atribuye con alta confianza a TraderTraitor, un grupo norcoreano, y Elliptic también apunta a Corea del Norte. Binance no ha nombrado a ningún atacante.

¿Puede un agente de código leer mis credenciales?

Sí, si nadie se lo impide: corre con tu usuario. En Claude Code, bloquéalo con reglas Read en permissions.deny y activa el sandbox con el bloque credentials.

¿Qué credenciales de mi portátil son las más peligrosas?

Las de larga duración que llegan a producción: claves de AWS AKIA… en ~/.aws/credentials, tokens de npm que publican en ~/.npmrc y un ~/.kube/config con token o client-key-data. Sustitúyelas por credenciales temporales (aws sso login, login OIDC) o publica desde CI.

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.