Saltar al contenido
>_ITDITDPlataforma de seguridad web

Incidentes y vulnerabilidades

El robo de NEM a Coincheck (2018) — Cómo se robaron unos 530 millones de dólares y la defensa de la gestión de claves

En enero de 2018 se robaron unos 523 millones de XEM (~530 M USD) del exchange japonés Coincheck: un saldo enorme estaba en un 'monedero caliente' sin multifirma, así que una sola clave robada movió casi todo. Defiéndete manteniendo las claves en frío, exigiendo aprobación múltiple y detectando salidas anómalas.

Publicado 2026-07-07 Actualizado 2026-07-07 10 min de lectura

Leemos las brechas reales y públicas no como noticias repetidas, sino desde la óptica de «¿cómo te defiendes de esto?». Este artículo se basa en el registro público (reguladores, comunicados de la empresa, prensa de referencia). Las fuentes se enumeran al final y no se incluye ningún manual de ataque.

~530 M USD
Robado (valor de la época)
~523 M
XEM (NEM) sustraídos
Caliente
Conectado a Internet = una clave lo mueve todo
Sin multifirma
Firma única = punto único de fallo
Ficha del caso
Objetivo
Activos de clientes (XEM/NEM) alojados en el monedero caliente de un exchange
Detección
26 de enero de 2018 (transferencias no autorizadas)
Patrón
Phishing dirigido / malware contra el personal → robo de la clave privada del monedero caliente → transferencia masiva única
Alcance
~523 millones de XEM, ~530 millones de dólares de la época (~260.000 usuarios afectados)
Causa raíz
Gran saldo en un monedero caliente conectado a Internet + sin multifirma (punto único de fallo) + resiliencia débil de los endpoints + detección/parada débil de las salidas masivas
Solución real
Claves en frío / en una bóveda dedicada, aprobación múltiple, minimizar el saldo caliente, defensa de endpoint/correo, detectar salidas anómalas

Qué ocurrió (en términos sencillos)

Un «monedero» de criptoactivos no guarda el activo en sí: protege la clave privada que puede moverlo. Las claves pueden guardarse de dos maneras: un «monedero caliente» conectado a Internet e instantáneamente utilizable, o un «monedero frío» fuera de línea (almacenamiento en frío). Lo caliente es cómodo, pero un atacante puede alcanzarlo a través de la red.

Aquí, un gran saldo de XEM se mantenía en un monedero caliente y, además, sin multifirma. La multifirma exige que varias claves estén de acuerdo antes de mover fondos, así que una clave filtrada no puede mover nada por sí sola. Sin ella, en cuanto se robó una sola clave privada, casi todo el saldo podía moverse. La información pública indica que el primer paso fue malware entregado mediante phishing dirigido contra empleados, que se usó para robar esa clave.

Un saldo enorme e instantáneamente gastable es el objetivo ideal de un atacante

Lo que más valoran los atacantes es un punto único de fallo que se traduce directamente en mucho valor. Un gran saldo en un monedero caliente conectado a Internet, protegido por una sola firma, es exactamente eso. Y no es cosa solo de los criptoactivos: una clave de API que lee toda la base de datos, o una cuenta de administrador que puede hacerlo todo, entraña el mismo peligro.

La cadena de ataque es también un mapa de defensa

Esta fue una cadena con un punto donde detenerla en cada paso. Léela como dónde se podría haber roto, no como un manual.

1. Entrada: phishing dirigido / malware contra el personal

Un correo falso y bien documentado infecta un endpoint con malware.

Parada: defensa de correo / endpoint (EDR, cautela con adjuntos y macros)

2. Robo de la clave privada del monedero caliente

Desde el endpoint infectado, se roba la clave que puede mover fondos.

Parada: mantén las claves fuera de línea / en un HSM; exige varias firmas

3. Transferencia masiva única (~523 M XEM)

Una sola firma puede moverlo, así que casi todo sale rápidamente.

Parada: minimiza el saldo caliente; detecta, aprueba y congela las transferencias grandes

4. Blanqueo / dispersión

Los activos se mueven de formas pensadas para resistir el rastreo.

Parada: detección y detención inmediata; reduce de antemano el radio de impacto

Cada paso tenía un punto de parada. La defensa en profundidad consiste en tener varios de estos puntos de parada, no un solo muro.

Cronología publicada

  1. 2018-01-26

    Se detectan transferencias no autorizadas; salen unos 523 M XEM (unos 530 M USD). Se suspenden los depósitos/retiros de XEM y la negociación.
  2. 2018-01-27

    Rueda de prensa pública; la empresa declara que reembolsará a los usuarios afectados en yenes japoneses.
  3. 2018-03

    La FSA de Japón emite una orden de mejora empresarial en virtud de la Ley de Servicios de Pago; se reembolsan unos 46.300 millones de yenes a unos 260.000 usuarios.
  4. 2018-04

    Se anuncia una adquisición por parte de Monex Group; se renueva la dirección.
  5. 2018–

    El incidente impulsa un endurecimiento paulatino de la supervisión de los exchanges de criptoactivos.

La causa raíz fue el fallo de varias capas, no un solo error

Despachar esto como «los golpeó el malware» invita a que se repita. En realidad, fallaron varias capas en secuencia.

La configuración que falló

  • Un gran saldo de XEM mantenido en un monedero caliente conectado a Internet
  • Sin multifirma: una sola clave robada podía moverlo todo (punto único de fallo)
  • Los endpoints del personal no resistieron el primer paso de phishing dirigido / malware
  • Escasa capacidad de detener a tiempo una transferencia grande y anómala

La configuración que aguanta

  • Mantén la mayoría de los activos en almacenamiento en frío (fuera de línea); mantén el saldo caliente al mínimo
  • La multifirma / aprobación múltiple neutraliza una sola clave filtrada
  • La defensa de endpoint / correo detiene el primer paso del phishing dirigido
  • Integra en las operaciones la detección, aprobación y congelación de las salidas masivas

Reembolso y regulación: la factura posterior es enorme

Coincheck reembolsó a los usuarios afectados en yenes (unos 260.000 usuarios, unos 46.300 millones de yenes), recibió una orden de mejora empresarial de la FSA y finalmente se reestructuró mediante una adquisición. El coste del reembolso posterior, de reconstruir la confianza y de responder a la regulación es muchísimo mayor que la inversión previa en el diseño. Diseña la gestión de claves a la altura del valor que proteges: antes de un incidente, no después.

Cómo te defiendes de esto

Aunque no toques los criptoactivos, si existe un solo lugar donde una clave o una cuenta mueve mucho valor, esto va contigo. Por orden de prioridad:

1

Mantén las claves/secretos más importantes 'en frío'

Las claves y secretos que no necesitas de forma constante deben estar fuera de línea o en una bóveda dedicada (HSM/KMS). Mantén la porción accesible desde Internet (la «caliente») al mínimo, para que la cantidad en riesgo si hay una brecha sea pequeña.

2

Elimina los puntos únicos de fallo (aprobación múltiple, división de privilegios)

Evita un estado en el que una sola clave o una sola persona pueda mover todos los activos/permisos. Exige varias aprobaciones (equivalente a multifirma) para las acciones críticas y divide los privilegios, para que una sola filtración no sea fatal.

3

Refuerza los endpoints y el correo contra el malware

El primer paso suele ser phishing dirigido y malware. Detecta las anomalías del endpoint con EDR e integra en tu rutina la cautela ante adjuntos, macros y enlaces sospechosos.

4

Detecta y detén las operaciones masivas anómalas

Marca «mucho movido en poco tiempo» y «destinos inusuales», y ten la capacidad de pausar, retener para aprobación o congelar de inmediato. Aunque no puedas evitarlo, acortar el tiempo para notarlo y detenerlo reduce la pérdida.

En qué coincide con la filosofía de diseño de este sitio

En esencia, este incidente consistió en mantener un secreto (una clave) demasiado 'caliente' (instantáneamente utilizable), en grandes cantidades, como un punto único de fallo. Es la imagen invertida de los propios principios de este sitio: no custodiar secretos, mantener accesible solo el mínimo y reducir el radio de impacto. Más allá de los criptoactivos, una clave de API que lee toda la base de datos, o una cuenta de administrador que puede hacerlo todo, entraña el mismo peligro. «Mantenlo en frío, mantén lo caliente al mínimo, nunca dejes que una sola clave lo mueva todo» es una defensa que cualquiera puede implementar a cualquier escala.

Fuentes (registro público)

Los hechos aquí expuestos se basan en la siguiente información pública. No se incluye ningún manual de ataque, solo las lecciones defensivas.

  • Agencia de Servicios Financieros de Japón (FSA), acción administrativa relativa a Coincheck (2018) — fsa.go.jp
  • Comunicados oficiales de Coincheck (aviso de transferencia no autorizada / política de reembolso, 2018) — coincheck.com
  • Reuters, «Japan's Coincheck exchange loses $530 million in cryptocurrency heist» (2018) — reuters.com

Sigue leyendo

FAQ

Q¿Cuál fue la causa raíz del incidente de Coincheck?
A

Se mantenía una cantidad muy grande de XEM (NEM) en un 'monedero caliente' conectado a Internet, sin firma múltiple (multifirma). En esa configuración, robar una sola clave privada basta para mover casi todo el saldo. La información pública indica que el punto de apoyo inicial fue malware entregado mediante correos de phishing dirigido contra empleados, que se usó para robar esa clave.

QNo tengo criptoactivos, ¿esto me afecta?
A

Sí. La lección no es específica de los criptoactivos: trata de mantener secretos valiosos (claves, claves de API, permisos de administrador) en un estado 'caliente' instantáneamente utilizable, en grandes cantidades, como un punto único de fallo. Mantén los secretos importantes en frío o en una bóveda dedicada (HSM/KMS), minimiza lo que es accesible desde Internet y asegúrate de que ninguna clave por sí sola pueda moverlo todo. Eso vale para cualquier sistema.

Q¿Puede un servicio pequeño aprender algo de esto?
A

Sí: (1) mantén las claves/secretos más importantes fuera de línea o en un almacén dedicado (HSM/KMS); (2) asegúrate de que ninguna clave ni persona por sí sola pueda mover todos los activos/permisos (aprobación múltiple, división de privilegios); (3) defiende los endpoints contra el malware y al personal contra el phishing dirigido; (4) detecta y detén las operaciones masivas anómalas. Todo esto se adapta a cualquier escala.