De incidentes a regulación: por qué las instituciones cripto necesitan pruebas de penetración en blockchain

Para instituciones y proveedores de servicios cripto—incluidos los exchanges de criptomonedas, empresas de pago, custodios de activos digitales y proveedores de wallets custodiales y no custodiales—las pruebas de penetración blockchain son, para aquellos dentro del alcance, no una precaución opcional. Cuando un compromiso puede alcanzar la firma o los fondos, o las normas aplicables exigen validación adversarial, se trata de una capa necesaria de garantía. El argumento se apoya en dos pilares: el origen del riesgo más allá del código del contrato y los requisitos o expectativas regulatorias de validación adversarial.

La exposición institucional se extiende más allá de los errores en los contratos, hacia la firma, la custodia, las claves, las personas, las cadenas de suministro y la infraestructura [1]. Como tal, esta superficie no está totalmente cubierta por las soluciones de seguridad web3 conocidas—auditoría a nivel de código y monitoreo a nivel de transacciones—ni por las pruebas de penetración tradicionales por sí solas. Esto aplica a cualquier institución en la que una persona, proveedor, interfaz o aplicación pueda influir en lo que se firma, aprueba, acredita o mueve—incluso cuando la custodia esté externalizada. En paralelo, los reguladores de varios mercados imponen requisitos, obligaciones condicionales o expectativas de supervisión con diferentes alcances, periodicidades y reglas de independencia.

Este artículo abre nuestra serie sobre pruebas de penetración blockchain. A lo largo de la serie, blockchain penetration testing y blockchain penetration testing se refieren a la misma disciplina: usamos el primero como término principal y el segundo como su sinónimo común en la industria. Presenta el argumento general y de alto nivel sobre la necesidad; artículos posteriores definen la disciplina, sus límites operativos y la superficie de ataque institucional en detalle.

Parte 1: De dónde proviene el riesgo

1.1 Riesgo más allá del contrato inteligente

Las vulnerabilidades de los contratos inteligentes siguen siendo importantes, pero muchas de las mayores pérdidas recientes se han originado en otros lugares, particularmente en claves, sistemas de firma e infraestructura operativa. En 2024, atacantes robaron aproximadamente $305 millones de DMM Bitcoin al comprometer a un proveedor de software de wallets y manipular una solicitud de transacción legítima [2]. En 2025, Bybit perdió aproximadamente $1.5 mil millones tras un compromiso en la cadena de suministro que manipuló su interfaz de firma [3], mientras que la pérdida de la hot wallet de BtcTurk se remontó de manera similar a claves privadas comprometidas [4]. Nuestra investigación apunta en la misma dirección: entre los incidentes con pérdidas superiores a $100,000 que rastreamos en 2026, las fallas fuera del contrato representaron aproximadamente uno de cada ocho incidentes, pero más de las tres cuartas partes de las pérdidas totales. Hasta agosto de 2026, siete de los diez mayores hackeos en la tabla pública de rekt.news, excluyendo fraudes y otras entradas que no son hackeos, fueron compromisos fuera del contrato, representando aproximadamente el 70% tanto en número de incidentes como en valor en dólares [5].

Las wallets y los sistemas de custodia hacen que el patrón sea concreto, y la seguridad de las wallets se ha mantenido como un área especialmente activa de incidentes en los últimos años. Nuestra investigación agrupa las fallas en manejo de claves, la canalización de firma de transacciones, cadena de suministro y dependencias, exposición de datos sensibles e implementación criptográfica.

* Los ~$90M de Coldcard son el piso verificado en cadena (aproximadamente 1,405 BTC); las estimaciones privadas llegan hasta ~$130M.

Lo que vincula estos casos con las pruebas de penetración no es simplemente que queden fuera del contrato, sino que si pueden explotarse o no a menudo depende de cómo se alinean las piezas desplegadas—identidades, dependencias, controles de firma, aprobaciones y lógica de fondos—en una ruta que un atacante pueda recorrer de principio a fin—desde un punto de entrada hasta los fondos.

1.2 Auditoría a nivel de código y monitoreo a nivel de transacciones: esenciales pero limitados

Cada una de las soluciones de seguridad web3 existentes y bien conocidas funciona en un nivel específico. La auditoría a nivel de código examina el código (auditoría de código) examina el código—de contrato, wallet o lógica de servicio. El monitoreo a nivel de transacciones (monitoreo) examina las transacciones a medida que llegan a la cadena; Phalcon [11], por ejemplo, detecta, alerta y bloquea actividad maliciosa en tiempo de ejecución.

Estas soluciones son útiles pero limitadas en lo que respecta a la cadena de manejo de dinero de las instituciones cripto—las identidades conectadas, la infraestructura en la nube, los flujos de trabajo de firma, las cadenas de aprobación, las wallets, los proveedores y las consolas de operadores a través de las cuales el valor se mueve desde un punto de entrada hasta una acción de movimiento de fondos. La ruta alcanzable de un atacante es un recorrido a través de esa cadena: puede ir desde un punto de entrada web, dApp, móvil, API, nube o de identidad, a través de la firma, la aprobación y la lógica de fondos, y puede pasar por cómo se comporta un contrato en ese contexto en vivo, hasta la acción de movimiento de fondos en el otro extremo. Revisar el código no ensambla esa ruta, y observar las transacciones no la anticipa. Incluso usadas juntas, ambas pueden dejar una brecha de composición: una auditoría muestra que el código era correcto tal como se escribió, no que las identidades, aprobaciones y firmantes desplegados aún lo hagan cumplir; y el monitoreo puede dejar pasar una transferencia que técnicamente es válida pero que nunca fue lo que el operador pretendía. Lo que cierra esa brecha es la validación adversarial independiente de que los controles se componen correctamente en el sistema en ejecución.

Las pruebas de penetración blockchain ejercitan el sistema ensamblado y en ejecución para descubrir y demostrar si dicha ruta puede llegar hasta los fondos antes de que un incidente la exponga. El patrón de Bybit muestra la forma del problema: una interfaz de firma comprometida convirtió la propia aprobación de los operadores en una transferencia que nunca pretendieron—un resultado que el contrato, una auditoría del mismo y el monitoreo de transacciones podrían haber leído como legítimo. Las pruebas de penetración blockchain apuntan directamente a esa composición: adoptando la posición de un proveedor, operador o interfaz comprometido, prueban si ese punto de apoyo puede convertir una aprobación de apariencia válida en un movimiento de fondos no autorizado, y qué controles desplegados—identidades, pasos de aprobación, verificaciones de firma—realmente lo detienen. La garantía a nivel de código del contrato sigue siendo tarea de la auditoría; las pruebas de penetración blockchain interactúan con un contrato desplegado solo a través de su comportamiento en vivo cuando esto forma parte de una ruta a nivel institucional hacia los fondos—alcances complementarios que se distinguen por énfasis, no por un límite estricto. La Parte 2 define qué valida las pruebas de penetración blockchain y dónde termina su alcance.

1.3 Pruebas de penetración tradicionales: útiles pero no suficientes

Las pruebas de penetración tradicionales siguen siendo valiosas en superficies de nube, web y API, identidad y acceso privilegiado. Su limitación es el alcance y el contexto de dominio: un compromiso convencional puede no aportar la semántica de negocio propia de las criptomonedas ni el modelo acoplado de seguridad y cumplimiento.

En cripto, una firma puede autorizar un movimiento de valor irreversible; la aprobación de un retiro es una decisión de control de fondos, no simplemente el envío de un formulario. El acreditado de depósitos, la contabilidad de saldos y las transferencias internas son lógica monetaria. Las direcciones y las transacciones también pueden tener significado en términos de sanciones u origen de los fondos. Un tester podría encontrar un bypass de autenticación pero pasar por alto cómo se combina con un desajuste en la visualización de la firma, una política de aprobación débil o un fallo de redondeo, formando una ruta hacia los fondos.

Las pruebas de penetración blockchain aplican técnicas adversariales establecidas a superficies tradicionales, además de superficies específicas de web3 como firma, aprobación, lógica de fondos y dinámica de contratos en todo el sistema en ejecución. Su diferenciador es el juicio especializado en seguridad web3, no herramientas nuevas: los testers interpretan la custodia, la intención de las transacciones, los flujos de fondos y los controles de cumplimiento como lo haría un atacante. La diferencia radica en el objetivo: una prueba convencional típicamente demuestra el impacto sobre el control de TI—una sesión de administrador tomada, un servidor alcanzado—mientras que una prueba blockchain trata el movimiento de valor como la condición final. Continúa: altera el destinatario o el monto dentro de una solicitud de firma legítima y verifica si lo que ve el aprobador, la política de aprobación y los fondos que realmente se mueven siguen alineados.

En resumen, esto es una garantía complementaria, no un muro estático frente a dinámico. Las auditorías a nivel de código, el monitoreo a nivel de transacciones y las pruebas de penetración tradicionales siguen siendo necesarias. Las pruebas de penetración blockchain las conectan al validar rutas alcanzables; no las reemplazan, ni garantizan el descubrimiento de una vulneración, ni garantizan su prevención.

Parte 2: Lo que exigen los reguladores

Los requisitos varían según la jurisdicción, creando un espectro de obligaciones de licenciamiento, continuas y activadas por el regulador para entidades y sistemas específicos.

Estos ejemplos son ilustrativos, no asesoría legal. Las instituciones deben confirmar su estatus, exenciones, sistemas y obligaciones con asesoría legal.

• Estados Unidos, Nueva York: requisito explícito con exención limitada. Las entidades cubiertas bajo NYDFS 23 NYCRR Parte 500 [12], incluidos los negocios de moneda virtual licenciados por el DFS, deben probar los sistemas de información desde dentro y desde fuera de sus límites, con base en una evaluación de riesgo, al menos anualmente. Una parte interna o externa calificada puede realizar la prueba. Las entidades pequeñas que califican reciben una exención limitada de esta disposición de pruebas, pero permanecen sujetas a las demás disposiciones aplicables de la Parte 500.

• Dubái: requisito anual y activado por cambios. Los VASP licenciados deben realizar evaluaciones de vulnerabilidad y pruebas de penetración al menos anualmente y antes de introducir nuevos sistemas, aplicaciones o productos [13], utilizando un tercero calificado e independiente. La auditoría de contratos inteligentes aplica cuando es relevante para el negocio y las actividades del VASP. Las pruebas de penetración dirigidas por amenazas (threat-led) no tienen una periodicidad universal: la VARA puede exigirlas cuando sea necesario y proporcional según el riesgo.

• Hong Kong: requisito de condición de licencia para solicitantes considerados licenciados. Los solicitantes de plataformas de comercio de activos virtuales consideradas licenciadas deben completar pruebas de penetración y evaluación de vulnerabilidades con resultados satisfactorios antes de la operación restringida [14]. Se aplica orientación separada a los solicitantes de nuevas corporaciones. Un tercero independiente debe cubrir la infraestructura y las aplicaciones especificadas en las capas de aplicación y red. Antes de la operación restringida, la gerencia debe completar todos los pasos de rectificación mayores y críticos para los hallazgos de riesgo medio a alto.

• Unión Europea: marco proporcional; TLPT condicional a la identificación. DORA cubre a las entidades financieras, incluidos los proveedores de servicios de activos criptográficos [15]. Exige pruebas apropiadas—no específicamente pruebas de penetración—al menos anualmente para los sistemas que respaldan funciones críticas o importantes. Las pruebas de penetración son un método seleccionado según el riesgo y la proporcionalidad. Las pruebas de penetración dirigidas por amenazas se aplican solo a entidades identificadas por las autoridades competentes, se ejecutan en sistemas de producción en vivo y, por lo general, se requieren al menos cada tres años; las autoridades pueden ajustar esa frecuencia según el riesgo. DORA también impone condiciones de independencia del tester. Las microempresas quedan fuera del requisito del programa de pruebas.

• Singapur: expectativa de supervisión no vinculante. Las Directrices de Gestión de Riesgos Tecnológicos de la MAS establecen que las instituciones financieras deberían realizar pruebas de penetración y esperan que los sistemas accesibles a través de Internet sean probados al menos anualmente o tras cambios o actualizaciones importantes [16]. Se trata de una guía de supervisión no vinculante y no exige un tercero independiente. La Notificación de Higiene Cibernética, vinculante y de alcance bancario, no especifica pruebas de penetración. La notificación vinculante sobre pagos o tokens de pago digital queda fuera del alcance de este artículo.

En conjunto, estos regímenes exigen o esperan pruebas de penetración—no una categoría de marca "web3". La versión especializada en web3 se deriva de los sistemas en el alcance: cuando estos autorizan, firman, custodian o contabilizan valor cripto, probarlos adecuadamente requiere la misma fluidez en firma y flujo de fondos que describe la Parte 1.

La conclusión es precisa: un conjunto sustancial de entidades licenciadas en jurisdicciones específicas ya enfrenta un requisito o expectativa de supervisión—no el mismo mandato en todos los mercados. Las distinciones determinan el alcance, la periodicidad, la independencia del tester, la remediación, la evidencia y si las pruebas respaldan la obtención de licencias, el cumplimiento continuo o un ejercicio activado por el regulador.

Conclusión: Los dos pilares convergen

El origen del riesgo y los requisitos o expectativas regulatorias apuntan a la misma conclusión: para las instituciones dentro del alcance, las pruebas de penetración blockchain son una capa de garantía necesaria. Validan las rutas alcanzables a través del acceso, la aprobación, la firma y los fondos, complementando los controles existentes. No pueden garantizar la prevención, demostrar que habrían detenido algún incidente específico del pasado, ni encontrar todas las rutas explotables. El objetivo es una garantía continua a lo largo del lanzamiento, la operación, la detección, la respuesta y la evidencia regulatoria—no un informe puntual.

Continúe con la serie:

• Part 2: What Is Blockchain Penetration Testing? Definitions and Boundaries

• Part 3: Rules of Engagement and Production Safety for Institutional Bockchain Penetration Testing

• Part 4: Web3 Attack Surfaces: A Penetration Testing Overview

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

BlockSec ayuda a las instituciones a ubicar con precisión esta capa: mapea los activos, los flujos de fondos, los límites de confianza y las garantías existentes; confirma las obligaciones que la asesoría legal indica que aplican; luego define el objetivo de la prueba, el alcance, el acceso, las salvaguardas de producción, la evidencia de remediación y el plan de reprueba. Para identificar tu brecha de garantía, habla con nuestro equipo de pruebas de penetración blockchain; el alcance del compromiso y los precios están disponibles a solicitud. Comienza donde se mueven los fondos.

Referencias

Numeradas en orden de primera aparición.

Referencias

Numeradas en orden de primera aparición.

1. BlockSec, Crypto Payment Security Playbook.
2. U.S. Federal Bureau of Investigation, DC3, and Japan National Police Agency, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (December 2024).
3. BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack.
4. rekt.news, BtcTurk — Rekt.
5. rekt.news, Leaderboard.
6. SwissBorg, SwissBorg Security Update: Kiln Breach.
7. BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor.
8. Slope, Slope Wallet Sentry Vulnerability: Digital Forensics and Incident Response Report.
9. BlockSec, Our Short Analysis of the Profanity Tool Vulnerability.
10. BlockSec, Coldcard Entropy Failure and Seed Recovery.
11. BlockSec, Phalcon Security.
12. New York State Department of Financial Services, 23 NYCRR Part 500 — Cybersecurity Requirements for Financial Services Companies.
13. Dubai Virtual Assets Regulatory Authority, Technology and Information Rulebook, Part I, Section E.
14. Hong Kong Securities and Futures Commission, Circular 24EC65 (18 December 2024, PDF).
15. European Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Articles 24–27.
16. Monetary Authority of Singapore, Technology Risk Management Guidelines (January 2021), Sections 2 and 13; Notice FSM-N06: Notice on Cyber Hygiene (2024).