ByBit, un año después: clear signing, Guardrail y EIP-7702 — qué cambió en el ecosistema multi-sig

El 21 de febrero de 2026 cumple un año del hack ByBit — 401.347 ETH ($1.5B) drenados por TraderTraitor a través de Safe{Wallet} frontend. Lo contamos con detalle en el momento: cadena de compromiso del developer machine, JavaScript inyectado en el bucket S3 de app.safe.global, divergencia entre lo que el firmante ve y lo que firma, operation=0 → operation=1, slot 0 reescrito al implementation del atacante.

Doce meses después la pregunta no es qué pasó — eso ya está cerrado — sino qué cambió. La respuesta corta: tres piezas concretas en la cadena defensiva. Una pieza on-chain (Safe Guardrail, agosto 2025), una pieza de protocolo (EIP-7702 y la familia de smart EOA, Pectra mayo 2025), y una pieza de UX (ERC-7730 y el stewardship de la Ethereum Foundation sobre clear signing, anunciado en mayo de 2026). Y una pieza que no cambió: las cifras de recuperación. Solo el 3,54 % de los fondos robados se ha congelado al cumplir el año.

Lectura: trabajo sobre material público de Safe Foundation, Ledger, Ethereum Foundation, Bybit (LazarusBounty reports) y los post-mortem técnicos originales. PoC propio en testnet Sepolia que reproduce el patrón ByBit en miniatura y muestra cuáles de las tres defensas habría bloqueado el ataque — sin tráfico contra terceros, sin víctima.

Recordatorio en una frase

Si no leíste el post del año pasado: atacantes con acceso a un developer machine de Safe inyectaron JavaScript en _app-52c9031bfa03da47.js que solo actuaba si el firmante era la dirección de la cold wallet de ByBit. El JavaScript sustituía la transacción que el operador quería firmar por otra con operation=1 (DELEGATECALL) a un contrato del atacante. Al firmar y ejecutar, el SSTORE(0, ...) del contrato reescribía el slot 0 del proxy — su implementation address. El multi-sig dejaba de ser multi-sig. Tres firmas legítimas, una llamada transfer(address,uint256) disfrazada, y el control del proxy cambia de manos.

El control que cierra ese vector es doble: que el firmante vea decodificado lo que firma (clear signing) y que el propio contrato Safe rechace DELEGATECALL no autorizado (Guardrail). Cualquiera de las dos defensas habría bloqueado el ataque. Las dos a la vez son el patrón maduro.

Recuperación — un año después

Al 21 de febrero de 2026 el saldo es el siguiente, según el LazarusBounty program del propio ByBit:

Ben Zhou (CEO ByBit) mantiene la actividad pública del bounty — pagos totales rozan los $4M de los $140M provisionados. La LazarusBounty ha demostrado dos cosas: la red de exchanges UE/US/JP/KR coopera más rápido que el ciclo de movimiento de Lazarus en mixers, pero el final mile (convertir trazado en congelado fuera de jurisdicciones colaborativas) sigue trabado. THORChain y bridges cross-chain con jurisdicción asiática absorben buena parte del flujo. Sin presión jurisdiccional adicional, la recuperación se estanca en la frontera del 3-4 %.

Comparativa con otros hacks Lazarus para perspectiva: el WazirX hack de julio 2024 (~$235M) recuperó al cierre de 2025 en torno al 85 % del valor — pero solo porque WazirX se reestructuró legalmente y la deuda se asumió contra equity, no porque los fondos fueran recuperados on-chain. Phemex ($100M, abril 2024) cerró el caso sin reembolso público al usuario. ByBit absorbió la pérdida vía solvencia 1:1 con reservas, sin reestructuración.

La lectura: los fondos robados por Lazarus en operaciones de la escala de ByBit no se recuperan. La pérdida queda absorbida por el operador o transferida al usuario. La defensa práctica está en no firmar la transacción maliciosa, no en perseguirla después.

Lo que cambió on-chain — Safe Guardrail (7 de agosto de 2025)

Safe Research publica Guardrail el 7 de agosto de 2025. Es un Safe Guard — el mecanismo de Transaction Guards que ya existía en Safe v1.3 y que la documentación recomendaba pero pocos operadores usaban — implementado como contrato sobre Safe v1.5.0+.

Lo que hace, en una línea: rechaza cualquier execTransaction con operation=1 (DELEGATECALL) cuyo to no esté en el allowlist pre-aprobado del Safe.

Detalles operativos:

• Allowlist pre-aprobado. Al instalar Guardrail, el operador define la lista inicial de contratos que el Safe puede delegate-call. Sin delay para esta inicialización (one-shot al setup).
• Time delay para nuevos. Añadir un contrato al allowlist tras la instalación inicial requiere commit con timer (configurable, e.g. 24h). Durante el delay, cualquier owner puede vetar la adición. La inspiración es el patrón de timelock de governance de Compound/Aave aplicado a allowlist de DELEGATECALL.
• Cobertura de modules. Guardrail no solo intercepta execTransaction directo; también verifica los DELEGATECALL ejecutados a través de modules Safe (módulos como SafeModuleGuard están en el mismo perímetro).
• Verificación formal. Safe Research incluye specs Certora del contrato. La intención: que la propiedad “no se puede ejecutar DELEGATECALL fuera del allowlist sin pasar por el delay” sea probada, no testeada.

Si Guardrail hubiera estado activo en el Safe de ByBit el 21 de febrero de 2025, el contrato del atacante 0x96221423... no estaba en el allowlist. La transacción habría revertido al pasar por el guard antes de llegar a execTransaction. Ninguna de las tres firmas habría servido. El JavaScript inyectado no habría podido escalar.

Por qué pocos operadores grandes lo tenían en febrero de 2025: Safe Guards existían pero eran feature opcional, sin presión de la propia UI para activar. Tras agosto de 2025 y con Guardrail como reference implementation con verificación formal, Safe{Wallet} empuja la instalación de Guards en el flujo de enterprise onboarding. Para multi-sigs con >$10M en custodia, Safe{Wallet} muestra security score degradado si no hay Guard activo. La presión es de UX, no de protocolo.

Lo que cambió en el protocolo — EIP-7702 y Pectra (mayo de 2025)

Pectra, el upgrade Ethereum mainnet, entra en producción el 7 de mayo de 2025. Trae EIP-7702, entre otras cosas — propuesto por Vitalik Buterin en mayo de 2024 y refinado a lo largo de Q3 2024 a Q1 2025.

Lo que hace EIP-7702, en una frase: permite a cualquier EOA (cuenta externa, externally owned account) registrar una delegation designator — la dirección de un smart contract cuyo código se ejecuta como si fuera el código de la EOA durante la duración de la transacción.

Para ByBit-tipo de ataque, la pieza interesante son las session keys constrained que esta primitive habilita. Setup típico:

1. El firmante de cold wallet usa EOA-A con clave master en hardware wallet sin conexión.
2. EOA-A delega a un smart contract C que implementa session keys: permite a una clave secundaria K (en un dispositivo conectado, e.g. otro Ledger en hot path) firmar transacciones solo si cumplen reglas: gasto máximo, allowlist de destinatarios, allowlist de selectores, ventana temporal.
3. Para operaciones rutinarias (transferencias pequeñas a hot wallet), el firmante usa la clave K en el dispositivo conectado. Para operaciones excepcionales (upgrade del Safe, cambio de owners), tiene que sacar la clave master.

Donde esto entra en el threat model de ByBit: el ataque se ejecutó sobre los firmantes con su clave principal. Si la operación rutinaria de ByBit se hubiera resuelto vía session key constrained, el JavaScript inyectado habría tenido que conseguir que la session key firmara una transacción de tipo setImplementation() o delegatecall — operación fuera del scope de la session key. El firmante con clave master no habría estado en ese flujo.

EIP-7702 no es defensa per se contra el patrón ByBit; es infraestructura para separar caminos. Operaciones rutinarias con clave de bajo privilegio, operaciones excepcionales con clave master. La defensa real es lo que el operador construye encima.

Safe Foundation propone path para que despliegues Safe existentes se registren como delegation targets válidos de EIP-7702. Implementación operativa durante 2026. Riesgo conocido: una EOA con delegation puede cambiar la delegation en cualquier momento (la clave master siempre tiene poder); el patrón no convierte EOAs en multi-sig trustless — sigue habiendo single point of compromise en la clave master.

Lo que cambió en la UX — Clear signing pasa a estándar

El control que más se discutió tras ByBit fue clear signing: la wallet hardware decodifica la calldata y muestra al firmante qué hace cada parámetro en lenguaje humano, en vez de hex truncado. Ledger lo soportaba con plugins específicos por contrato; Trezor lo soportaba parcialmente; MetaMask delegaba en Tenderly y Blockaid. Sin estándar abierto entre wallets, la experiencia era inconsistente.

Doce meses después:

• Mayo de 2025 — Ledger publica ERC-7730 como Generic Parser open spec. Permite a dApps publicar descriptors JSON con cómo decodificar sus transacciones; las wallets que entienden el formato muestran human-readable. ERC-7730 v1.0 entra al proceso EIP en Q2 2025.
• Mayo de 2026 — Ethereum Foundation toma el stewardship de ERC-7730 y lo combina con ERC-8176 (framework de atestación criptográfica para los descriptors). Anuncio el 12 de mayo de 2026 desde la Trillion Dollar Security Initiative de la Foundation.
• Backers iniciales: Ledger, Trezor, MetaMask, WalletConnect. Trezor anuncia implementación en firmware Safe 5 / Safe 7 con planes de transaction decoding completo para Q2 2026 (CTO Tomáš Sušánka en CoinDesk, abril 2026).
• Ledger introduce ERC-7730 como motor de Clear Signing en Ledger Nano Gen5 (octubre 2025) y backports a Ledger Stax / Flex / Nano X con firmware ≥ 2.4.

Estado a febrero de 2026 (justo antes del anuncio EF):

El patrón sectorial es claro: clear signing pasa de opt-in a default. Lo que en febrero de 2025 era discusión de buenas prácticas se ha vuelto baseline para hardware wallets enterprise.

PoC en Sepolia — comparar firma con y sin defensas

Reaprovechamos el lab del post original y añadimos los dos controles defensivos. La pregunta operativa: ¿qué pasa si en febrero de 2026 reproducimos el ataque ByBit, pero el Safe tiene Guardrail y el firmante usa clear signing?

Setup

- Sepolia RPC: https://sepolia.infura.io/v3/<key>
- Foundry para compilar y desplegar
- Ledger Nano X firmware 2.4.x con Safe Eth app instalada
- node 20 + express para el "frontend" malicioso
- Safe v1.5.0 con Guardrail v1.0 desplegado

Paso 1 — Safe 1-of-1 + Guardrail instalado

Misma factory que en el post original (createProxyWithNonce), pero con setup(...) extendido para registrar el Guard:

GUARDRAIL=$(forge create Guardrail --constructor-args $SAFE_ADDRESS [$ALLOW_LIST] --rpc-url $SEPOLIA_RPC --private-key $OWNER_KEY)
# Después del setup del Safe, llamada a setGuard(GUARDRAIL):
cast send $SAFE_ADDRESS "setGuard(address)" $GUARDRAIL \
  --rpc-url $SEPOLIA_RPC \
  --private-key $OWNER_KEY

El [$ALLOW_LIST] inicial contiene solo contratos de upgrade legítimos del propio Safe (e.g., MultiSendCallOnly). El contrato Mimic del atacante no está dentro.

Paso 2 — Mimic + Drainer (igual que el post original)

// Mimic — reescribe slot 0 vía delegatecall, como en febrero-2025
contract Mimic {
    function transfer(address _to, uint256 /* _value */) external returns (bool) {
        assembly { sstore(0, _to) }
        return true;
    }
}

forge create deja 0xMIMIC y 0xDRAINER desplegados en Sepolia. La cadena del atacante está intacta.

Paso 3 — Frontend local que miente (igual)

El servidor Express del lab original sirve la divergencia UI-vs-calldata. La página HTML del operador renderiza “transferencia rutinaria 0.01 ETH”; el bloque que invoca al Ledger usa tx.to = 0xMIMIC, tx.operation = 1.

Paso 4 — Resultado A: Ledger sin clear signing, Safe sin Guardrail

Igual que el lab del año pasado. La pantalla del Ledger muestra hex truncado:

Review transaction
To:    0xMIMI...iC
Data:  0xa9059cbb...
Value: 0 ETH

El firmante confía en la UI del navegador, firma. La transacción ejecuta. cast storage 0xLAB_SAFE 0 devuelve 0xDRAINER. Lab comprometido. Es el escenario febrero-2025.

Paso 5 — Resultado B: Ledger con clear signing, Safe sin Guardrail

Plugin Safe Eth instalado, firmware ≥ 2.4.x, Safe app activa. La pantalla del Ledger ahora muestra:

WARNING: delegate call
This transaction will execute code from
  0xMIMI...iC
in the context of YOUR SAFE.
Storage may be modified.

Continue?

Si el firmante lee el aviso y rechaza, no hay hack. Si confía en la UI del navegador y aprueba pulsando Continue, la transacción ejecuta igual. La defensa es humana: depende de que el firmante mire el dispositivo y entienda qué dice. Bajo presión operativa, con el operador acostumbrado a aprobar transacciones rutinarias varias veces al día, el ratio de “skim through and approve” no es cero. Clear signing convierte el blind sign en informed sign; informed sign sigue dependiendo del humano.

Paso 6 — Resultado C: Safe con Guardrail activo (con o sin clear signing)

La transacción llega a execTransaction del Safe. Antes de ejecutar, el Safe invoca al Guard registrado. Guardrail comprueba to = 0xMIMIC y operation = 1 contra el allowlist. 0xMIMIC no está. La llamada revierte con error: DelegateCallNotInAllowlist(0xMIMIC).

> cast send $SAFE_ADDRESS "execTransaction(...)" 0xMIMIC 0 0xa9059cbb... 1 ... \
    --rpc-url $SEPOLIA_RPC --private-key $OWNER_KEY
Error: execution reverted: DelegateCallNotInAllowlist

cast storage 0xLAB_SAFE 0 devuelve la implementation legítima. Slot 0 no cambia. La firma del Ledger no importa — el contrato Safe rechaza la transacción antes de ejecutar el delegatecall. La defensa es on-chain y no negociable: para que el ataque pase, el atacante tendría primero que hacer que 0xMIMIC entrara en el allowlist, lo que requiere una addToAllowlist(0xMIMIC) con su propia firma de los 3-of-N + esperar el time delay. Durante el delay, cualquier owner ve la propuesta pendiente y puede vetarla.

Paso 7 — Conclusión del lab

El patrón maduro 2026 es C + D combinados. Guardrail como red de seguridad on-chain (no dependiente del firmante); clear signing como verificación adicional para el humano. Cualquiera de los dos por sí solo es mejor que febrero de 2025; los dos juntos cierran el vector.

Coste del lab entero en Sepolia: < 0.1 ETH de testnet, gas trivial. Tiempo de implementación: ~2 horas con Foundry instalado.

Lo que cambió en audit y vendor side

Las firmas de auditoría que en 2025 hicieron post-mortems de ByBit han expandido scope durante el año:

• Sygnia mantiene el caso ByBit como reference customer y publica varios análisis sectoriales sobre developer machine compromise en cripto durante 2025. El playbook TraderTraitor de “Docker project malicioso vía social engineering” sigue activo; Sygnia documenta más casos durante 2025 sin escalada a hack mayor.
• NCC Group y Trail of Bits incorporan frontend security review como parte estándar de auditorías para protocolos con UI hosted. Lo que antes era “auditamos el smart contract” pasa a ser “auditamos el smart contract + el bundle JavaScript + la cadena de deploy”. La práctica sectorial cambia.
• Hypernative se convierte en partner de Safe Foundation. Safe Shield integra el motor de detección en tiempo real de Hypernative dentro de app.safe.global — cada transacción se escanea contra heurísticas pre-ejecución, con políticas que el operador define. Disponible para clientes enterprise en 2025-2026.

Donde no ha habido cambio significativo: el segmento de wallets no-custodial individuales que dependen de extensiones de navegador o de mobile apps con autoupdates. Los incidentes Trust Wallet de septiembre y diciembre de 2025 (extensión Chrome v2.68 comprometida vía supply-chain) muestran que el patrón ByBit aplicado a usuarios individuales sigue funcionando: si la extensión está comprometida, el firmante ve una cosa y firma otra. Clear signing en hardware wallet es la defensa local válida; Guardrail-tipo de protección en wallet personal no existe todavía como producto generalizado.

Lo que TraderTraitor está haciendo en 2026

El cluster norcoreano dentro de Lazarus que ejecutó ByBit sigue activo. Patrón documentado durante 2025-2026:

• TTP inicial estable. Docker projects maliciosos descargados por developers cripto vía social engineering en LinkedIn / Discord / GitHub. La sofisticación de la apertura no ha aumentado — el vector funciona porque sigue cayendo.
• Diversificación de targets. En abril de 2026, Lazarus drena $285M de Drift Protocol y $292M de KelpDAO — meses de social engineering previo, según los reportes. El modus operandi es el mismo: comprometer un developer / operador con acceso a infraestructura crítica, esperar la transacción de valor, intervenir.
• Atribución más rápida. FBI publica advisories de atribución a Lazarus en plazo de días tras incidentes mayores, no semanas. La inteligencia sectorial está consolidada; lo que queda lento es la respuesta operativa de exchanges receptoras en jurisdicciones no colaborativas.

Detección y mitigación operativa actualizada

Para operadores de Safe multi-sig con custodia significativa, el baseline a 2026 ya no es opcional:

1. Guardrail u otro Safe Guard equivalente activo. Block DELEGATECALL no autorizado on-chain. Para Safe v1.5.0+. Documentado en docs.safe.global.
2. Clear signing default en todos los firmantes. Ledger Nano Gen5 / Stax / Flex con firmware ≥ 2.4 + Safe Eth app activa, o Trezor Safe 5/7 con ERC-7730 a medida que se actualice durante 2026. Sin clear signing, el firmante depende ciegamente del frontend.
3. Doble verificación independiente del payload pre-firma. Antes de pulsar Continue, el operador decodifica el safeTxHash en un segundo cliente (Etherscan Transaction Decoder, Tenderly Simulator, cast 4byte-decode local). Si la decodificación no coincide con la UI del frontend, parar y escalar.
4. EIP-7702 session keys para operativa rutinaria, master keys solo para excepciones (upgrades del Safe, owner changes). Trabajo de 2026 — implementación todavía en proceso para Safe.
5. Monitorización on-chain del slot 0 del proxy. Servicios de on-chain monitoring (Forta, Blockaid, Hypernative) tienen detectores específicos para Safe implementation changes. Alerta inmediata si cambia.
6. Air-gap del proceso de propuesta. La máquina que propone la transacción debe ser distinta de la que firma. La que firma construye desde la raw transaction hash recibido por canal alternativo, no desde el JavaScript del frontend hosted.
7. Frontend hosted como single point of failure documentado. Si la multi-sig gestiona >$10M, el frontend hosted oficial (app.safe.global) es un riesgo conocido y aceptado pero registrado. Alternativas: self-deploy del frontend Safe (es open-source), o cliente CLI puro (Safe CLI, Ape Safe). Tras la integración de Safe Shield + Hypernative en 2025, el hosted oficial es más seguro que en febrero de 2025 — pero no es el único path.

Lo que esto deja para el resto de 2026

• Guardrail-tipo de protecciones se generalizan. La discusión de 2026 no es si instalar un Safe Guard, es cuál. Variantes (Fiducia con co-signers on-chain, integraciones con Cedar policies estilo AWS AgentCore) entran al catálogo.
• EIP-7702 implementations operativas en Safe. Durante 2026 Safe completa el path para que despliegues existentes acepten delegation; las primeras operativas de session keys constrained en producción enterprise.
• ERC-7730 como estándar de facto. La Trillion Dollar Security Initiative de la EF mantiene el registry; wallets que no soporten clear signing perderán cuota de mercado enterprise.
• Lazarus sigue activo, sigue funcionando el mismo vector inicial. Abril 2026 con Drift + KelpDAO confirma que el developer machine compromise vía social engineering no es problema cerrado. La defensa en el endpoint del developer es trabajo continuo, no resuelto.

Referencias

• IRONHACKERS — post original: ByBit / Safe{Wallet}: cómo Lazarus robó $1.5B (feb-2025)
• Safe Research, Guardrail: Locking Down Delegate Calls in Safe (7-ago-2025): https://safefoundation.org/blog/safe-research-guardrail-locking-down-delegate-calls
• Safe Foundation, EIP-7702: A Win for Smart Accounts in Ethereum’s Pectra Upgrade: https://safefoundation.org/blog/eip-7702-smart-accounts-ethereum-pectra-upgrade
• Ledger, Stewardship of Clear Signing Passed to Ethereum Foundation: https://www.ledger.com/blog-ledger-clear-signing-ethereum-foundation
• Ledger Developer Portal, ERC-7730 Specifications: https://developers.ledger.com/docs/clear-signing/reference/specifications
• Safe Foundation, Safe partners with Hypernative: https://safe.global/blog/safe-partners-with-hypernative-to-launch-enterprise-security-integration
• Coira, Bybit Hack Anniversary: One Year Later: https://coira.io/news/bybit-hack-anniversary-1-5b-lazarus-recovery
• FBI / IC3, North Korea Responsible for $1.5 Billion Bybit Hack (PSA 250226): https://www.ic3.gov/PSA/2025/PSA250226
• Sygnia, Investigation into the Bybit Hack: https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/
• NCC Group, In-Depth Technical Analysis of the Bybit Hack: https://www.nccgroup.com/research/in-depth-technical-analysis-of-the-bybit-hack/
• Safe Guards documentation: https://docs.safe.global/advanced/smart-account-guards
• EIP-7702 spec: https://eips.ethereum.org/EIPS/eip-7702
• ERC-7730 registry (Ethereum Foundation): https://github.com/ethereum/clear-signing-erc7730-registry