Tu whitelist no es un muro. Para los atacantes patrocinados por Estados, es un mapa que muestra exactamente a quién comprometer para llegar a tus activos.
USD 1.788.000.000 ROBADOS A INSTITUCIONES CON WHITELISTS, MULTISIGS Y HARDWARE WALLETS EN FUNCIONAMIENTO
Cuando un banco o institución mantiene activos digitales relevantes en una blockchain pública, ocurre algo único: cada aspecto de su postura de seguridad se vuelve visible para los atacantes. Los balances on-chain son públicos. Los patrones de transacción son trazables. Las direcciones con las que interactuás —tu whitelist— no son un secreto. Se transmiten al mundo entero con cada operación.
Para grupos profesionales de amenazas, en particular actores patrocinados por Estados como el Lazarus Group de Corea del Norte (responsable de más de USD 2.000 millones en robos cripto desde 2017), esta transparencia es un regalo. No necesitan adivinar tu arquitectura de seguridad. Pueden mapearla.
La perspectiva del atacante
Un grupo estatal que vigila un objetivo de alto valor va a: Identificar las wallets on-chain del objetivo y sus balances. Mapear cada dirección con la que interactúa regularmente (la whitelist). Investigar cada entidad whitelisteada —proveedores, custodios, contratos puente, protocolos DeFi, etc.— para encontrar el eslabón más débil. Comprometer esa entidad de confianza. Usar la confianza preexistente para concretar el ataque.
La whitelist no los frena. Les dice dónde mirar. Esto no es teoría. Es exactamente el playbook que se ejecutó tres veces en siete meses contra tres instituciones distintas, con pérdidas por USD 1.800 millones.
El problema de la falsa confianza
El whitelisting genera una suposición peligrosa: “Si la dirección está en nuestra lista, la transacción es segura”. Esa suposición solo es válida si cada entidad de la whitelist está garantizada como no comprometida en todo momento. Frente a adversarios sofisticados, con meses de paciencia y recursos estatales, esa garantía es imposible.
La suposición operativa correcta es la opuesta: cualquier dirección en la whitelist puede estar comprometida en cualquier momento. Cada proveedor, cliente o protocolo en tu lista debe tratarse como potencialmente malicioso. No porque lo sea, sino porque los atacantes los van a apuntar específicamente para explotar la confianza que depositaste en ellos.
La evidencia: tres ataques, un mismo playbook
Entre julio de 2024 y febrero de 2025, el Lazarus Group ejecutó tres ataques usando exactamente esta estrategia. En cada caso, comprometió una entidad de confianza incluida en la whitelist y utilizó esa confianza para vaciar los fondos.
Bybit 21 de febrero de 2025 · 401.347 ETH robados · USD 1.500M
Entidad whitelisteada comprometida: Safe{Wallet} (proveedor de infraestructura de wallets). Lazarus comprometió la workstation macOS de un desarrollador de Safe mediante un proyecto Docker malicioso, secuestró tokens de sesión de AWS e inyectó JavaScript malicioso en la interfaz de Safe servida desde S3. Cuando los firmantes de Bybit iniciaron una transferencia rutinaria de cold a warm wallet, la interfaz mostraba una transacción legítima. Pero el payload real reemplazaba la implementación del smart contract de la wallet por un contrato controlado por el atacante, con funciones sweepETH() y sweepERC20().
El chequeo de whitelist pasó, porque la dirección destino era la propia wallet de Bybit.
WazirX 18 de julio de 2024 · más de 200 tokens drenados · USD 235M
Entidad whitelisteada comprometida: Liminal (proveedor de custodia). Los atacantes explotaron discrepancias entre cómo se veían las transacciones en la interfaz de custodia de Liminal y el calldata real en la blockchain. Los firmantes aprobaron lo que parecía una transferencia pequeña a una dirección whitelisteada. En realidad, la transacción reemplazó la implementación del multisig Safe por un contrato del atacante desplegado ocho días antes. Una vez cambiada la implementación, el multisig y la whitelist dejaron de existir. El contrato del atacante no tenía esas restricciones.
Radiant Capital 16 de octubre de 2024 · Arbitrum + BSC · USD 53M
Entidad whitelisteada comprometida: 3 firmantes internos. Un operador de Lazarus se hizo pasar por excontratista en Telegram y envió un PDF malicioso. El malware realizó un ataque man-in-the-middle sobre la interfaz de Safe{Wallet}, mostrando transacciones legítimas mientras intercambiaba silenciosamente el calldata enviado a las hardware wallets.
Los dispositivos Ledger/Trezor no pudieron interpretar los payloads complejos de Safe, por lo que los firmantes realizaron “blind-signing” de una llamada transferOwnership() que nunca vieron. Las simulaciones en Tenderly también mostraban resultados limpios: el malware enviaba datos distintos al simulador que al flujo de firma real.
Lo que la whitelist no puede ver
El defecto fundamental es que el whitelisting de direcciones solo responde una pregunta:
“¿Esta dirección está aprobada?”
Las operaciones que habilitaron los tres robos —cambio de implementación de proxy, transferencias de ownership, payloads firmados a ciegas— son invisibles para cualquier sistema que solo valide direcciones. Son ataques de cambio de estado, no de destino.
El cambio necesario: de direcciones aprobadas a resultados verificados
Si la whitelist no puede protegerte frente a adversarios que comprometen entidades confiables, el modelo operativo tiene que cambiar. La industria debe pasar de una confianza estática basada en direcciones a una validación continua y en tiempo real que verifique qué hará realmente cada transacción, sin importar de quién provenga.
1. Simulación de transacciones en tiempo real
Cada transacción —sin importar cuán rutinaria sea o cuán confiable parezca la contraparte— debe simularse contra el estado actual de la cadena antes de ejecutarse. La simulación produce un state diff: una lista completa de cada slot de almacenamiento, balance, ownership y aprobación que va a modificarse. Las decisiones de seguridad deben basarse en ese diff, no en la dirección destino.
Esto habría detectado los tres ataques:En Bybit y WazirX, el cambio de implementación del proxy produce un cambio inequívoco en el slot 0 de almacenamiento. En Radiant, la llamada transferOwnership() emite un evento OwnershipTransferred hacia una dirección inesperada. Nada de esto es visible con whitelisting de direcciones. Todo es trivialmente visible mediante simulación.
2. Monitoreo continuo on-chain
La protección en tiempo real no se limita al momento de la firma. Requiere monitoreo continuo de actividad on-chain para detectar señales previas al ataque y anomalías posteriores.
Señales visibles pero no monitoreadas:
- WazirX: el contrato malicioso fue desplegado ocho días antes del ataque.
- Bybit: el contrato con funciones sweep fue desplegado dos días antes.
- Radiant: el atacante practicó el exploit con transacciones de prueba días antes.
Todo estaba visible on-chain. Un sistema de monitoreo habría disparado alertas ante despliegues sospechosos dirigidos a wallets conocidas.
3. Verificación independiente en la capa de firma
Los ataques MITM funcionaron porque la simulación y la firma ocurrían dentro de la misma infraestructura comprometida. Agregar una capa independiente que intercepte cada transacción antes de enviarla a la blockchain, la simule en infraestructura separada y bloquee la ejecución si el resultado difiere de lo esperado, rompe completamente esta cadena de ataque.
Los USD 1.800 millones perdidos en estos tres ataques no fueron producto de negligencia. Bybit, WazirX y Radiant operaban bajo las mejores prácticas de la industria: multisigs, hardware wallets, whitelists, proveedores de custodia. Fueron vaciados porque esas mejores prácticas asumen un modelo de amenaza que ya no aplica.
Cuando tu adversario es un grupo patrocinado por un Estado con recursos para pasar meses haciendo reconocimiento, comprometer proveedores, manipular tu infraestructura de firma y borrar rastros en minutos, tu whitelist no es un muro. Es un mapa. La suposición operativa debe cambiar.
Acerca de Check Point Software Technologies Ltd.
Check Point Software Technologies Ltd. (www.checkpoint.com) es un proveedor líder de plataformas de ciberseguridad basadas en la nube y basadas en IA que protege a más de 100 000 organizaciones en todo el mundo. Check Point aprovecha el poder de la IA en todas partes para mejorar la eficiencia y la precisión de la ciberseguridad a través de su plataforma Infinity, con tasas de detección líderes en la industria que permiten una anticipación proactiva de las amenazas y tiempos de respuesta más rápidos e inteligentes. La plataforma integral incluye tecnologías entregadas en la nube que consisten en Check Point Harmony para proteger el espacio de trabajo, Check Point CloudGuard para proteger la nube, Check Point Quantum para proteger la red y Check Point Infinity Core Services para operaciones y servicios de seguridad colaborativos.