El artículo anterior, From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing, expuso por qué el pentesting de blockchain es necesario. Este artículo aborda en qué consiste, examinando con más detalle las definiciones y los límites del pentesting de blockchain.
No existe una definición formal ampliamente aceptada del pentesting de blockchain, y muchas de las definiciones propuestas lo mezclan con otras medidas de mitigación, por lo que términos como auditoría, escaneo y bug bounty a veces se incluyen como parte del pentesting, aunque cada uno tenga un objetivo diferente. Esto dificulta saber qué validó realmente un determinado trabajo. Nuestro punto de partida, extraído de la práctica tanto académica como industrial, es deliberadamente simple: el pentesting de blockchain es, como su nombre indica, pentesting —una disciplina definida desde hace décadas— aplicado al ecosistema web3, realizado como una evaluación adversarial de todo el sistema contra un entorno web3 en funcionamiento. Se parte de esa disciplina conocida y luego se examina qué añade web3 al modelo de amenazas y al criterio que se exige a los evaluadores.
El pentesting de blockchain es una evaluación adversarial y práctica de un sistema en funcionamiento, realizada dentro de un entorno y unas reglas de compromiso acordados, para validar rutas explotables y cadenas de control. Complementa las auditorías de seguridad a nivel de código y también puede encargarse de forma independiente [1].
Busca rutas en lugar de debilidades aisladas y opera bajo autorización explícita, alcance, supuestos de acceso y restricciones de seguridad. Este artículo responde a tres preguntas: qué es el pentesting de blockchain, qué puede validar —especialmente más allá de la evidencia que suele aportar una auditoría— y cómo puede empezar una institución a un nivel general.
Qué añade web3: el modelo de amenazas del manejo de fondos
Web3 conserva las superficies tradicionales del pentesting: infraestructura en la nube, sitios web, API, identidades, acceso privilegiado, proveedores y herramientas operativas. En lugar de reemplazar ese modelo de amenazas por uno exclusivo de blockchain, lo extiende a sistemas donde los mismos puntos de apoyo pueden derivar directamente en acciones que autorizan, contabilizan o mueven valor.
Tres características determinan esa extensión.
-
Primero, los activos digitales son directamente transferibles. Un atacante que llegue a la ruta correcta de transacción o retiro puede ser capaz de mover valor sin pasar por los mismos mecanismos de reversión y conciliación que se usan en los pagos tradicionales.
-
Segundo, firmar suele ser una acción que mueve dinero. Una firma criptográficamente válida demuestra que una clave autorizó una carga útil; por sí sola, no demuestra que un operador haya visto el destino correcto, entendido la transacción o seguido la política de aprobación prevista.
-
Tercero, cuando una institución despliega sus propios contratos —algo cada vez más común a medida que los productos añaden funcionalidad on-chain más rica—, esos contratos son públicamente invocables y componibles. Usuarios externos y otros contratos pueden invocarlos en secuencias que la institución no controla. Por lo tanto, la seguridad depende no solo de cada componente, sino también de cómo interactúan entre sí las identidades, las aplicaciones, las políticas, los sistemas de firma, la lógica contable y los contratos.
Modelamos la exposición resultante como una cadena de manejo de fondos: los controles off-chain de intención de firma, aprobación y lógica de fondos que conducen a transacciones on-chain (y, cada vez más, a los contratos propios desplegados por la institución), junto con las capas de nube, web, API e identidad que respaldan esos pasos [1]. Un atacante puede comenzar con un punto de apoyo ordinario y avanzar a través de varios controles: manipular lo que se presenta para firmar, alcanzar un flujo de trabajo privilegiado, explotar una brecha de autorización o hacer que la lógica de fondos acepte una transición de estado no deseada.
La brecha de composición determinante es el traspaso entre off-chain y on-chain: si los controles de identidad, interfaz, aprobación, firma y lógica de fondos preservan la acción prevista cuando esta se convierte en una transacción on-chain. No todos los ataques recorren toda la cadena. La cuestión es que el objetivo de aseguramiento es transversal a las capas: controles que parecen sólidos de forma aislada pueden, aun así, combinarse en una ruta explotable a través del sistema de manejo de fondos en funcionamiento.
Qué hace el pentesting de blockchain
El pentesting de blockchain convierte esa brecha de composición en evidencia. Dentro del alcance autorizado y las reglas acordadas, los evaluadores traducen los supuestos transversales a las capas en escenarios de ataque, ejercen esos escenarios contra el entorno en funcionamiento y determinan si producen una ruta reproducible y un impacto concreto. El resultado conecta la ruta con la evidencia de respaldo, la severidad, las orientaciones de remediación y la reevaluación de las correcciones acordadas, en lugar de limitarse a una lista de debilidades inconexas.
Su elemento diferenciador es el criterio experto en seguridad web3, no un conjunto de herramientas único. Los evaluadores deben interpretar la custodia, la intención de las transacciones, la política de aprobación, los flujos de retiro, la contabilidad de fondos y el comportamiento de las transacciones on-chain (incluidos los contratos desplegados), a la vez que conectan la evidencia proveniente de las superficies convencionales de nube, web, API, identidad y acceso privilegiado. Las herramientas pueden facilitar el descubrimiento o la validación, pero es el criterio experto el que determina si las condiciones observadas conforman una ruta creíble para el movimiento de dinero.
La evaluación es metódica, se basa en evidencia y corresponde a un momento puntual. Sus conclusiones se aplican a los sistemas, versiones, configuraciones, supuestos de acceso y condiciones evaluadas. Se examinan las posibles rutas; las rutas explotables confirmadas se documentan con evidencia reproducible.
Tenga en cuenta que un trabajo sistemático dentro de la superficie acordada no puede garantizar que se descubran todas las debilidades o rutas de ataque, y un compromiso responsable no garantiza que los evaluadores logren una vulneración.
Dentro de un entorno web3 institucional, ese proceso de escenario a evidencia se ejecuta a través de cinco capacidades conectadas, las superficies evaluables de esa misma cadena de manejo de fondos. Abarcan la infraestructura que sustenta la cadena, sus tres controles off-chain y las transacciones on-chain a las que dan paso; están conectadas porque una sola ruta puede atravesar varias de ellas:
-
Entorno de producción y operaciones de automatización: los evaluadores validan si el acceso, la implementación, los secretos o los controles operativos pueden encadenarse hacia una acción de manejo de fondos, generando evidencia que vincula el punto de apoyo operativo con su impacto alcanzable.
-
Interfaces web y de dApp, autorización e intención de firma: los evaluadores validan si la transacción presentada a un usuario u operador puede diferir de la acción finalmente autorizada, registrando el flujo manipulado y el comportamiento firmado o enviado resultante.
-
Cadenas de autorización de firma, aprobación y retiro: los evaluadores validan si las identidades, roles, verificaciones de políticas o pasos de aprobación pueden eludirse o combinarse, documentando la secuencia y la acción no autorizada que esto permite.
-
Lógica de negocio de los fondos: los evaluadores validan si los saldos, límites, la conciliación, las reglas de retiro o las transiciones de estado aceptan condiciones no previstas, capturando una ruta de impacto de negocio reproducible y no solo un defecto técnico.
-
Transacciones on-chain y contratos desplegados: los evaluadores validan cómo se comportan las interacciones on-chain de la institución bajo condiciones de ejecución adversariales; cuando la institución ha desplegado sus propios contratos, ejercen el comportamiento en tiempo de ejecución de esos contratos y conservan evidencia a nivel de transacción del resultado observado. El aseguramiento a nivel de código sigue siendo función del Code Audit correspondiente.
Part 4: Web3 Attack Surfaces: A Penetration Testing Overview traza el mapa de estas superficies y sus conexiones sin modificar el objetivo central: determinar si las condiciones presentes en el entorno en funcionamiento acordado se encadenan hasta producir un impacto reproducible.
Dónde encaja junto a otras formas de aseguramiento
La comparación más clara se hace por objetivo de aseguramiento: la decisión que el trabajo pretende respaldar y la evidencia que se espera que produzca. Como muestra la figura a continuación, los métodos pueden superponerse, las disciplinas pueden colaborar, y ningún límite útil se basa en fingir que un equipo es exclusivamente estático mientras otro es exclusivamente dinámico. Un mismo objetivo —un contrato desplegado, una superficie de nube o RPC, un sistema de firma— puede caer bajo más de una de estas disciplinas; lo que difiere es el objetivo de aseguramiento que cada una enfatiza, no una reivindicación exclusiva sobre el sistema.
Pentesting y auditoría a nivel de código
Un Code Audit —la forma específica de auditoría a nivel de código— genera aseguramiento principalmente en el código (incluyendo también el diseño, la arquitectura y los supuestos del protocolo). Combina revisión experta con herramientas de detección, puede incluir técnicas dinámicas y produce un informe firmado según el alcance de auditoría acordado. Para contratos, cadenas, puentes, rollups, wallets u otras implementaciones, la auditoría pregunta si el diseño y el código satisfacen las propiedades de seguridad previstas.
El pentesting establece principalmente si las condiciones reales presentes en un entorno institucional acordado y en funcionamiento pueden encadenarse hasta producir un impacto reproducible. Sigue la interacción entre aplicaciones desplegadas, identidades, configuraciones, flujos de trabajo, lógica de negocio, sistemas de firma y llamadas a contratos, y luego registra la evidencia necesaria para reproducir y remediar la ruta.
Esto es una diferencia de objetivo y de evidencia, no una prohibición de capacidades. Los auditores pueden ejecutar pruebas, aplicar fuzzing a componentes e investigar el comportamiento en tiempo de ejecución; los evaluadores de pentesting pueden revisar configuraciones, lógica de aplicación y detalles de implementación para entender una ruta. Los métodos pueden superponerse y los equipos pueden trabajar juntos. Los servicios son complementarios, no sustitutos: la auditoría por sí sola normalmente no proporciona esta evidencia de explotabilidad en tiempo de ejecución a nivel institucional, mientras que el pentesting no reemplaza el aseguramiento a nivel de código en las propiedades de implementación y protocolo que cubre una auditoría.
Por lo tanto, el comportamiento adversarial de un contrato dentro de una ruta institucional en vivo puede quedar dentro del pentesting, mientras que el aseguramiento sobre el propio código del contrato se dirige al Code Audit correspondiente.
Escaneo, bug bounties y pruebas especializadas
El escaneo de vulnerabilidades proporciona amplitud automatizada frente a firmas conocidas, servicios expuestos, parches faltantes y problemas de configuración comunes. Respalda la visibilidad repetible y puede contribuir al reconocimiento, mientras que el pentesting añade profundidad guiada por expertos y determina si las condiciones pueden encadenarse en una ruta significativa.
Un bug bounty invita a investigadores independientes a reportar hallazgos elegibles conforme a reglas publicadas. Su modelo continuo y colaborativo puede sacar a la luz problemas de cola larga, mientras que un trabajo de pentesting asigna un equipo para examinar metódicamente un entorno acordado y entregar evidencia consolidada, severidad, orientaciones de remediación y reevaluación. Ambos modelos son complementarios y ninguno garantiza un descubrimiento completo.
Por ejemplo, Blockchain Security Testing de BlockSec es un programa hermano, no un padre ni un subconjunto del pentesting. Utiliza motores especializados —incluyendo pruebas diferenciales, fuzzing, despliegue privado, pruebas de denegación de servicio de RPC a gran escala, y pruebas de infraestructura de nodos o clústeres— para validar la corrección de implementación y la resiliencia de infraestructura personalizada [2]. El pentesting de blockchain se centra en rutas transversales a nivel institucional a través del sistema de manejo de fondos en funcionamiento. El alojamiento de aplicaciones y el CI/CD de aplicaciones se dirigen a la superficie de pentesting; la infraestructura de nodos y clústeres y la resiliencia de RPC a gran escala se dirigen a Blockchain Security Testing. Una arquitectura puede necesitar ambas.
Los objetivos cercanos también requieren una asignación precisa. El aseguramiento a nivel de código de contratos se dirige al Code Audit correspondiente. La corrección criptográfica de las implementaciones de custodia de claves, incluyendo diseños MPC, TSS y TEE, se dirige a Wallet Security Audit. Los sistemas agénticos del lado de los pagos se dirigen a Agentic Payment Security [1]. El pentesting aún puede examinar el flujo de trabajo de firma circundante, los agentes operativos o la ruta de la aplicación cuando forman parte del alcance institucional acordado.
| Objetivo de aseguramiento | Enfoque correspondiente |
|---|---|
| Validar si existen rutas explotables que atraviesan las aplicaciones, identidades, controles de aprobación, lógica de fondos y transacciones on-chain (incluidos los contratos desplegados) de una institución en funcionamiento | Blockchain Penetration Testing |
| Evaluar el código, el diseño, la arquitectura o los supuestos del protocolo | Code Audit |
| Evaluar la corrección criptográfica en una implementación de MPC, TSS, TEE o custodia de claves | Wallet Security Audit |
| Validar la corrección de implementación y la resiliencia de infraestructura personalizada de nodos, clústeres, EVM, bases de datos, MPT o RPC a gran escala | Blockchain Security Testing |
| Mantener una visibilidad amplia y automatizada de firmas conocidas y problemas de configuración | Vulnerability Scanning |
| Invitar a una investigación continua e incentivada sobre una superficie elegible publicada | Bug Bounty |
| Evaluar sistemas agénticos del lado de los pagos y sus supuestos de seguridad | Agentic Payment Security |
Esto es una guía de asignación, no una secuencia. Un mismo sistema puede generar múltiples objetivos de aseguramiento y, por lo tanto, justificar un conjunto coordinado de evaluaciones; las etiquetas no son mutuamente excluyentes.
Dependiendo de la jurisdicción y de la clase de institución, las pruebas pueden ser un requisito regulatorio o una expectativa de supervisión, y algunos regímenes exigen un tercero independiente; Part 1 explica esas distinciones [3]. La aplicabilidad regulatoria debe confirmarse con asesoría legal.
Cómo empezar
Antes de tomar la decisión, podemos comenzar con las siguientes tres preguntas: ¿Qué sistemas están moviendo fondos? ¿Qué evidencia de aseguramiento ya existe? ¿Qué cadena de control aún no se ha validado de forma adversarial? Las respuestas identifican la brecha de aseguramiento sin elegir prematuramente un servicio por su nombre.
Una conversación de definición de alcance puede entonces alinear el objetivo, los supuestos de acceso, las salvaguardas y los entregables esperados. Part 3: Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing cubre la autorización, la seguridad y la coordinación necesarias para poner en marcha el trabajo [4].
Cuando esté listo para actuar al respecto, defina el alcance de su brecha de aseguramiento con BlockSec para alinear el objetivo, la evidencia y las salvaguardas antes de que comiencen las pruebas.
Continúe con las guías de superficie de ataque:
También en esta serie, próximamente:
- Part 5: Authorization and Signing Security: Web, dApps, and
- Part 6: Cloud and CI/CD Security: Automated Operations Attack Surfaces
- Part 7: Treasury Control-Plane Security: Signing and Withdrawal Approvals
- Part 8: Exchange Ledger Security: Theft Paths and Data-Plane Logic
La Blockchain Penetration Testing pillar page ofrece la perspectiva a nivel de compromiso.
Referencias
Numeradas en orden de primera aparición.
