Pentesting blockchain y smart contracts: auditoría Web3 2026

Una auditoría de smart contracts es un ejercicio ofensivo y defensivo sobre código que, una vez desplegado en una blockchain pública, no se puede parchear como una aplicación web normal. Esta es la diferencia fundamental con un pentesting web tradicional: cuando un contrato Solidity entra en mainnet, el bytecode queda inmutable, cualquier persona del mundo puede invocarlo, los adversarios son bots automatizados que rastrean cada bloque buscando oportunidades y cada operación tiene un coste en gas que el atacante también puede pagar para forzar comportamientos. No hay WAF que te proteja, no hay rate limiting que pongas a posteriori, no hay rollback gratis.

Esta guía cubre qué es un pentesting Web3, qué stack típico audita, las vulnerabilidades más explotadas en smart contracts y DeFi, los casos históricos que cualquier auditor debería conocer, la metodología, el tooling habitual y cómo encaja en el marco regulatorio europeo emergente con MiCA y DORA.

Auditoría de smart contracts frente a pentesting web

Un pentesting web clásico evalúa una aplicación que vive en servidores que tú controlas. Si encuentras una vulnerabilidad y la explotan, en el peor caso restauras backup, rotas credenciales y emites un parche en horas. En Web3 las reglas cambian:

• Inmutabilidad post-despliegue. El bytecode desplegado en mainnet no se modifica. Existen patrones de upgradeable proxy, pero introducen su propia superficie de ataque. Un bug crítico en un contrato no upgradeable solo se mitiga abandonando el contrato y migrando estado a uno nuevo, con todas las complicaciones de comunicación a usuarios y posibles ataques en la migración.
• Economía del gas. Cada operación cuesta gas, y el atacante también lo paga. Eso introduce vectores únicos: griefing por consumo de gas, DoS por bloquear funciones con loops costosos, condiciones de carrera donde el atacante puede pagar más gas para ejecutar antes (front-running, MEV).
• Adversarios automatizados 24/7. En cuanto una transacción entra al mempool, bots la analizan en milisegundos buscando oportunidades de extracción de valor o vulnerabilidades. La ventana entre detección de un bug y explotación masiva se mide en segundos, no en días.
• Composabilidad como vector. Tu contrato interactúa con otros contratos de terceros que pueden cambiar comportamiento, integrarse de formas no previstas, ser comprometidos o construirse específicamente para atacarte. La superficie de ataque incluye protocolos que ni siquiera existen el día del despliegue.
• Transparencia total. Todo el bytecode, todo el storage, todas las transacciones son públicas. El atacante tiene acceso completo a tu lógica desde el primer bloque, mientras que tú no ves quién está estudiando tu contrato hasta que ataca.

Un smart contract en mainnet es código corriendo en hostil por defecto: cada cuenta del mundo puede invocarlo, cada bot lo está leyendo, cada bug es una factura abierta hasta que migres estado. El audit no es opcional, es la única defensa antes del despliegue.

Stack típico Web3 que se audita

El ecosistema Web3 no es una sola blockchain. Cuando hablamos de pentesting Web3, las plataformas y componentes habituales son:

• Blockchains EVM compatibles. Ethereum es la referencia, pero la mayoría de auditorías cubren también redes EVM como Polygon, BNB Smart Chain, Arbitrum, Optimism, Base, Avalanche C-Chain. Comparten lenguaje y herramientas, pero cambian costes de gas, finalidad y supuestos sobre validadores.
• Solidity como lenguaje dominante. La versión recomendada en 2026 es Solidity 0.8.x o superior, que incorpora checks de overflow nativos. Aún se ven contratos legacy en 0.6 o 0.7 que requieren tratamiento especial. Vyper aparece en protocolos como Curve, con su propio set de bugs.
• Wallets como punto de entrada del usuario. MetaMask, Rabby, hardware wallets como Ledger o Trezor, wallets multisig como Safe (antes Gnosis Safe). Cualquier audit que afecte a UX de firma toca este stack.
• Oracles. Chainlink es la referencia para feeds de precio, pero existen alternativas (Pyth, RedStone, API3) y oracles propios que cada protocolo puede implementar mal. Casi cualquier ataque grave reciente contra DeFi ha pasado por manipulación de oracle.
• DEXs y AMMs. Uniswap V2 y V3, Curve, Balancer, PancakeSwap. La matemática de los AMMs es vector de ataque cuando un protocolo deriva precios directamente de spot.
• Bridges cross-chain. Wormhole, LayerZero, Axelar, Hop, Stargate. Concentran TVL enorme y han sido protagonistas de los mayores hacks del sector.
• Capa de aplicación DeFi. Protocolos de lending (Aave, Compound), stablecoins (DAI, frax, crvUSD), derivados perpetuos, liquid staking, restaking.
• Frontends. Webapps en React/Next que firman transacciones contra el wallet. Comprometer el frontend (DNS hijack, dependencia npm comprometida) es vector documentado real.

Un pentesting Web3 puede limitarse a contratos, o cubrir también frontend, oracles, infraestructura de nodos, claves de admin y operativa de upgrade. Define alcance antes de empezar.

Top 10 vulnerabilidades en smart contracts

Estas son las categorías que cualquier auditor profesional cubre por defecto en Solidity. Documentadas por SWC Registry, OWASP Smart Contract Top 10 y bases como Code4rena findings.

1. Reentrancy

El bug fundacional del DAO en 2016. Un contrato llama externamente antes de actualizar su estado interno, y el contrato llamado vuelve a invocar la función original, drenando fondos en bucle. El patrón Checks-Effects-Interactions (CEI) y ReentrancyGuard de OpenZeppelin son la mitigación estándar. Sigue apareciendo en variantes cross-function y cross-contract.

2. Integer overflow y underflow

Mitigado por defecto en Solidity 0.8.x, que revierte ante overflow. Contratos legacy en 0.6 o 0.7 sin SafeMath siguen siendo vulnerables. También aplica cuando se usa unchecked explícitamente por optimización de gas, donde el auditor debe validar manualmente que la asunción es correcta.

3. Oracle manipulation

Cuando un contrato deriva precio de un AMM spot o de una fuente manipulable en un bloque, un atacante con flash loan puede mover el precio temporalmente, ejecutar la lógica afectada (liquidación injusta, mint a precio inflado) y revertir el movimiento. La mitigación es usar TWAPs robustos, oracles agregados como Chainlink con heartbeat y deviation thresholds, y nunca asumir que un precio spot es seguro.

4. Front-running y MEV

El mempool es público. Un atacante observa una transacción rentable, copia los parámetros, paga más gas y se ejecuta primero. Variantes: sandwich attack en DEXs, liquidaciones competitivas, NFT sniping. La mitigación parcial pasa por commit-reveal schemes, batched auctions, o relays privados tipo Flashbots Protect.

5. Signature replay

Un mensaje firmado fuera de cadena (typed data EIP-712, meta-transacciones) que se ejecuta on-chain. Si la firma no incluye nonce, chainId o domain separator, puede reproducirse en otra cadena o en el mismo contrato. Crítico en bridges, gasless transactions, permits ERC-20.

6. Access control roto

Funciones administrativas sin modificador onlyOwner, roles mal definidos, tx.origin usado en lugar de msg.sender, ownership transferible sin verificación, contratos que no implementan los checks que su documentación promete. Es uno de los hallazgos más frecuentes en audits.

7. Delegatecall abuse

delegatecall ejecuta código de otro contrato en el contexto del llamante. Si el contrato llamado puede ser controlado por un atacante, este puede modificar arbitrariamente el storage del contrato origen. Causa del segundo hack de Parity en 2017. Crítico en proxies upgradeables mal implementados.

8. Timestamp manipulation

block.timestamp puede ser ajustado por los validadores dentro de un margen. Usar timestamps como fuente de entropía o como medida exacta de tiempo en lógica financiera abre la puerta a manipulaciones por parte del bloque productor.

9. DoS y gas griefing

Funciones que iteran sobre arrays controlados por el usuario pueden bloquearse cuando el array crece. Pagar a múltiples destinatarios en un loop puede dejar el contrato bloqueado si uno de ellos rechaza la transferencia. Push payments frente a pull payments.

10. Flash loan attacks

Préstamos atómicos sin colateral que permiten al atacante mover capital masivo en una sola transacción. Por sí solos no son ataque, son habilitador. Combinados con oracle manipulation, gobernanza votada por tokens, o errores de matemática AMM, han causado pérdidas de cientos de millones.

Casos históricos sin glamorizar

El sector arrastra incidentes públicos que cualquier auditor estudia para reconocer patrones. No los repasamos para hacer espectáculo, sino porque las mismas familias de bugs siguen apareciendo:

• The DAO (junio 2016). Reentrancy en un fondo de inversión descentralizado. Pérdidas estimadas alrededor de 60 millones USD a la cotización del momento. Provocó el hard fork que separó Ethereum y Ethereum Classic.
• Parity Multisig (julio y noviembre 2017). Dos incidentes distintos. El primero, robo por bug en función initWallet. El segundo, congelación accidental de fondos por un usuario que invocó suicide() en la library compartida. Pérdidas combinadas en centenares de millones USD valoración entonces.
• Ronin Bridge (marzo 2022). Compromiso de claves privadas de validadores. Pérdidas reportadas en torno a 600 millones USD. No fue un bug de smart contract, fue operativa de claves, recordatorio de que el alcance del audit debe cubrir más que el código.
• Nomad Bridge (agosto 2022). Bug en función de verificación de mensajes que permitió a cualquiera copiar y modificar transacciones legítimas. El hack se convirtió en saqueo masivo cuando otros usuarios copiaron la técnica observada en mempool.
• Curve Finance (julio 2023). Bug en versiones específicas del compilador Vyper que rompía protección de reentrancy. Pools afectados con pérdidas reportadas en torno a 70 millones USD. Recordatorio de que el toolchain también es superficie de ataque.

Verifica siempre cifras y fechas contra fuentes primarias (Rekt News, post-mortems oficiales de los protocolos) antes de citarlas en informes.

Tooling de auditoría Web3

El ecosistema dispone de herramientas maduras para análisis estático, simbólico y de fuzzing. Combinarlas es la práctica estándar.

• Slither. Análisis estático de Solidity desarrollado por Trail of Bits. Detecta patrones conocidos de vulnerabilidad. Rápido, integrable en CI, baseline obligatorio.
• Mythril. Análisis simbólico que explora caminos de ejecución y busca violaciones de propiedades. Más lento que Slither pero encuentra bugs distintos.
• Echidna. Fuzzer basado en propiedades, también de Trail of Bits. Defines invariantes que el contrato debe cumplir siempre y Echidna intenta romperlas.
• Foundry. Framework de testing en Rust, sustituto moderno de Truffle/Hardhat para muchos auditores. Permite fuzzing nativo en tests (forge test con argumentos aleatorios) y forking de mainnet para reproducir contextos reales.
• Manticore. Otra herramienta de ejecución simbólica, útil cuando Mythril se queda corto.
• Halmos. Symbolic testing más reciente, integra con Foundry y resulta práctico para verificación de propiedades sin escribir todo en Coq o similar.
• Tenderly. Plataforma de simulación y debugging de transacciones, útil para reproducir exploits paso a paso.
• MythX y servicios SaaS. Existen, conviene contrastar resultados con tooling open source.

Ninguna herramienta sola sustituye al code review manual. El proceso típico combina al menos Slither, Foundry tests con fuzzing, y revisión humana experta.

Metodología de audit

Un audit serio sigue una estructura reconocible, independientemente del despachador:

1. Reconocimiento. Lectura de documentación, whitepapers, diagrama de arquitectura, threat model si existe. Identificación de invariantes del protocolo (qué debe cumplirse siempre).
2. Code review manual. Lectura línea por línea de los contratos en alcance. Anotación de áreas sospechosas. Esta fase encuentra la mayoría de bugs lógicos que el tooling no detecta.
3. Análisis estático automatizado. Slither completo, revisión de findings, descarte de falsos positivos.
4. Análisis simbólico. Mythril o Manticore sobre funciones críticas.
5. Fuzzing basado en propiedades. Echidna y/o Foundry fuzz tests sobre invariantes definidas. Cobertura mínima razonable (millones de ejecuciones por invariante).
6. Análisis económico. Para protocolos DeFi, modelar incentivos. Qué pasa si un actor controla X% del token de gobernanza, qué pasa si un atacante puede manipular el oracle X bps, qué pasa si los liquidadores no aparecen.
7. Verificación formal cuando el riesgo lo justifica. Certora, Halmos, escritura de specs en TLA+. Caro en tiempo pero indispensable para componentes críticos como bridges o stablecoins de tamaño relevante.
8. Informe. Findings clasificados por severidad (critical, high, medium, low, informational), con PoC reproducible y recomendación concreta.
9. Re-audit tras fixes. El equipo aplica fixes, el auditor verifica que no introducen nuevos bugs.

Específicos DeFi

Los protocolos DeFi añaden vectores propios sobre los bugs Solidity genéricos.

• Matemática AMM. Las fórmulas de curve, constant product, stableswap tienen casos extremos con liquidez baja, slippage extremo o tokens con fee on transfer. Audit debe modelar matemáticamente las invariantes.
• Oracle TWAP. Las medias temporales mitigan manipulación spot pero pueden ser engañadas en ventanas largas con capital suficiente. Verificar ventana usada y costo de manipulación.
• Lógica de liquidación. Quién puede liquidar, en qué condiciones, con qué incentivo, qué pasa si nadie liquida. Las liquidaciones canceladas o front-runeadas son vector documentado.
• Ataques a gobernanza. Quien acumula tokens suficientes puede pasar propuestas maliciosas. Timelocks, quorum mínimo, multisig de emergencia mitigan pero no eliminan el riesgo. Casos como Beanstalk 2022 mostraron gobernanza atacada vía flash loan.

Bridges y cross-chain

Los bridges concentran TVL altísimo y son responsables de los hacks más grandes del sector. Riesgos amplificados:

• Confianza distribuida. Casi todos los bridges actuales dependen de un set de validadores externos o de un puzzle criptográfico que valida pruebas entre cadenas. Comprometer ese set compromete los fondos.
• Mensajes y firmas. La verificación de mensajes cross-chain es lugar habitual de bugs (Nomad).
• Gestión de claves. Las claves que firman transacciones en una cadena para liberar fondos en otra son objetivo directo (Ronin).
• Asunciones de finalidad. Si una cadena fuente revierte tras enviar mensaje, la cadena destino ya liberó. Ataques que exploten reorganizaciones de bloque están documentados.

Un audit serio de bridge cubre código, operativa de claves, monitoring y plan de respuesta.

Hardening

Buenas prácticas para protocolos en producción:

• OpenZeppelin contracts como base. Standardizan ERC-20, ERC-721, AccessControl, Ownable, ReentrancyGuard. Reusar componentes auditados reduce superficie.
• Patrón Checks-Effects-Interactions (CEI). Validar todo, modificar estado, llamar fuera. En este orden.
• ReentrancyGuard en funciones que llaman externamente y modifican estado.
• Multisig para funciones administrativas. Safe (Gnosis Safe) es el estándar de facto. Recomendable umbral 3 de 5 mínimo para protocolos serios.
• Timelocks para upgrades y cambios de parámetros. Da margen a usuarios para salir si una propuesta es maliciosa.
• Patrones de proxy upgradeable con cuidado. UUPS, transparent proxy, beacon. Cada uno tiene sus riesgos: storage collision, initializer abuse, función upgradeTo sin protección.
• Circuit breakers y pause. Capacidad de pausar funciones críticas en emergencia, con multisig que tenga el poder y con límites a su abuso (no pausa indefinida que congele fondos).
• Límites de exposición. Caps por usuario, por bloque, por día. Limita pérdida máxima de un exploit antes de que se detecte.
• Bug bounty programs. Immunefi como plataforma estándar, con bounties proporcionales al TVL en riesgo.

Encaje regulatorio

El marco europeo para activos digitales y servicios cripto está consolidándose:

• MiCA (Markets in Crypto-Assets Regulation). Reglamento UE en aplicación, regula la emisión de activos cripto, las stablecoins (ART y EMT) y los proveedores de servicios sobre criptoactivos (CASP). No regula directamente smart contracts DeFi, pero sí impone obligaciones a entidades que custodian, intercambian o asesoran sobre criptoactivos en la UE.
• DORA aplicable a CASP. Los proveedores de servicios sobre criptoactivos autorizados bajo MiCA pueden caer dentro del ámbito de DORA, con obligaciones de gestión de riesgo TIC, testing de resiliencia operativa digital y notificación de incidentes graves. Para CASP relevantes, los pentests de los smart contracts que operan son evidencia exigible.

Si tu protocolo opera en la UE o tiene usuarios en la UE, conviene revisar con asesor legal el encaje específico antes de mainnet.

Preguntas frecuentes

¿Es seguro actualizar un smart contract una vez desplegado?

Solo si lo desplegaste tras un patrón upgradeable correctamente implementado (UUPS, transparent proxy, beacon) y el upgrade se gobierna por multisig con timelock. El proceso de upgrade es en sí superficie de ataque: storage collisions, initializer abuse, funciones admin sin protección. Un protocolo serio audita tanto el contrato implementación como el flujo de upgrade.

¿Cuánto cuesta una auditoría de smart contracts en mercado?

Varía mucho con alcance y complejidad. Audits indicativos pueden ir desde cifras de cinco dígitos USD para contratos simples hasta seis o siete dígitos USD para protocolos DeFi grandes con verificación formal. Plataformas como Code4rena ofrecen modelo de auditoría competitiva con presupuestos públicos. Solicita varias propuestas y compara metodología, no solo precio.

¿La verificación formal es obligatoria?

No es obligatoria por regulación general, pero sí muy recomendable para componentes críticos como bridges, stablecoins de tamaño relevante, lógica de liquidación o módulos de gobernanza. Es cara en tiempo, requiere personal especializado y resulta más eficaz cuando la spec del protocolo está bien definida desde el diseño.

¿Hace falta bug bounty tras mainnet?

Sí, y debería ser permanente. Plataformas como Immunefi gestionan bounties con escala proporcional al TVL. Un bug bounty serio paga por findings críticos en seis dígitos USD o superiores, lo que hace económicamente racional para un investigador reportarlo en lugar de explotarlo.

¿Existen seguros para protocolos DeFi?

Sí, plataformas como Nexus Mutual, Sherlock o InsurAce ofrecen coberturas. Las pólizas tienen exclusiones, requisitos de auditoría previa y suelen no cubrir errores económicos o de oracle. No sustituyen al audit, complementan.

¿Va a cambiar MiCA el sector?

MiCA ya está en aplicación y está cambiando el sector en la UE, especialmente en stablecoins y proveedores de servicios. La parte DeFi pura sigue en zona gris regulatoria. Esperar nuevas guías de ESMA y posibles ampliaciones del reglamento en próximos años. Mantener seguimiento legal activo si operas en UE.

Recursos relacionados

• Pentesting de aplicaciones web: guía completa
• Pentesting de APIs REST y GraphQL
• Ciberseguridad en banca y DORA para entidades financieras
• Top 10 herramientas de pentesting 2026
• Qué es PKI: infraestructura de clave pública

Audit Web3 con Secra

En Secra cubrimos auditorías de smart contracts Solidity, revisión de arquitectura DeFi, análisis económico de protocolos y pentesting de los frontends y oracles que rodean tu contrato. Combinamos code review manual con Slither, Foundry fuzzing y Mythril, y escalamos a verificación formal cuando el riesgo lo justifica. Entregamos informe con findings reproducibles, recomendaciones concretas y re-audit tras fixes.

Si tu protocolo va a salir a mainnet o ya está en producción y necesita revisión, escríbenos a contacto@secra.es o agenda una llamada desde la página de contacto. Revisamos alcance, plazos y propuesta sin compromiso.