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

Para las instituciones y proveedores de servicios de criptoactivos —incluidos los exchanges de criptomonedas, las empresas de pagos, los custodios de activos digitales y los proveedores de wallets custodiales y no custodiales—, las pruebas de penetración blockchain no son, para quienes entran en el alcance, una precaución opcional. Cuando un compromiso puede llegar a la firma o a los fondos, o cuando las normas aplicables exigen una validación adversarial, constituyen una capa de garantía necesaria. El argumento se sostiene sobre 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 habituales —la auditoría a nivel de código y el monitoreo a nivel de transacciones— ni por las pruebas de penetración tradicionales por sí solas. Esto se aplica a cualquier institución en la que una persona, un proveedor, una interfaz o una 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 alcances, periodicidades y reglas de independencia distintas.

Este artículo abre nuestra serie de pruebas de penetración web3. A lo largo de la serie, "blockchain penetration testing" y "web3 penetration testing" se refieren a la misma disciplina: utilizamos el primer término como término principal y el segundo como su sinónimo habitual en la industria. Presenta el argumento de necesidad a alto nivel y de manera integral; los artículos posteriores definirán la disciplina, sus límites operativos y la superficie de ataque institucional en detalle.

Parte 1: De dónde proviene el riesgo

1.1 El riesgo más allá del contrato inteligente

Las vulnerabilidades de los contratos inteligentes siguen siendo importantes, pero muchas de las pérdidas más grandes recientes han tenido su origen en otros lugares, particularmente en las claves, los sistemas de firma y la infraestructura operativa. En 2024, los atacantes robaron aproximadamente 305 millones de dólares de DMM Bitcoin al comprometer a un proveedor de software de wallet y manipular una solicitud de transacción legítima [2]. En 2025, Bybit perdió aproximadamente 1.500 millones de dólares tras un compromiso en la cadena de suministro que manipuló su interfaz de firma [3], mientras que la pérdida en 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 dólares que rastreamos en 2026, los fallos fuera del contrato representaron aproximadamente uno de cada ocho incidentes, pero más de tres cuartas partes de las pérdidas totales. A agosto de 2026, siete de los diez mayores hackeos en la tabla de clasificación pública de rekt.news, excluyendo el fraude 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 este patrón sea concreto, y la seguridad de las wallets ha seguido siendo un área de incidentes especialmente activa en los últimos años. Nuestra investigación agrupa los fallos en el manejo de claves, el proceso de firma de transacciones, la cadena de suministro y las dependencias, la exposición de datos sensibles y la implementación criptográfica.

* Los ~90 M$ de Coldcard son el mínimo verificado en cadena (unos 1.405 BTC); las estimaciones privadas llegan hasta ~130 M$.

Lo que conecta estos casos con las pruebas de penetración no es simplemente que queden fuera del contrato, sino que si pueden explotarse o no depende, a menudo, de cómo se alinean las piezas desplegadas —identidades, dependencias, controles de firma, aprobaciones y lógica de fondos— formando un camino que un atacante puede 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 —del contrato, de la wallet o de la lógica del 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 cuando se trata de la cadena de manejo de fondos de las instituciones de criptoactivos: 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 los 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 por un atacante es un recorrido a través de esa cadena: puede comenzar en un punto de entrada web, dApp, móvil, API, de nube o de identidad, atravesar la firma, la aprobación y la lógica de fondos, y puede pasar por el comportamiento de un contrato en ese contexto en vivo, hasta llegar a 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 soluciones pueden dejar una brecha de composición: una auditoría muestra que el código era correcto tal como fue escrito, no que las identidades, aprobaciones y firmantes desplegados sigan haciéndolo cumplir; y el monitoreo puede dejar pasar una transferencia que es técnicamente 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 funcionamiento.

Las pruebas de penetración blockchain ejercitan el sistema ensamblado y en funcionamiento para descubrir y demostrar si tal ruta puede llegar a 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 web3 apuntan directamente a esa composición: adoptando la posición de un proveedor, operador o interfaz comprometidos, se prueba si dicho 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 impiden. La garantía a nivel de código del contrato sigue siendo tarea de la auditoría; las pruebas de penetración web3 solo interactúan con un contrato desplegado a través de su comportamiento en vivo cuando eso forma parte de una ruta a nivel institucional hacia los fondos —alcances complementarios que se distinguen por el énfasis, no por un límite estricto—. La Parte 2 define qué valida exactamente las pruebas de penetración web3 y dónde termina su alcance.

1.3 Pruebas de penetración tradicionales: útiles pero insuficientes

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

En el mundo 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 acreditar depósitos, la contabilidad de saldos y las transferencias internas son lógica monetaria. Las direcciones y transacciones también pueden tener un significado en materia de sanciones o de origen de fondos. Un tester podría encontrar una omisión de autenticación pero pasar por alto cómo esta 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 así una ruta hacia los fondos.

Las pruebas de penetración blockchain aplican técnicas adversariales establecidas a las superficies tradicionales, además de las superficies específicas de web3 de firma, aprobación, lógica de fondos y dinámica de contratos a lo largo de todo el sistema en funcionamiento. Su elemento diferenciador es el juicio especializado en seguridad web3, no nuevas herramientas: los testers interpretan la custodia, la intención de las transacciones, los flujos de fondos y los controles de cumplimiento tal como lo haría un atacante. La diferencia radica en el objetivo: una prueba convencional normalmente demuestra el impacto sobre el control de TI —una sesión de administrador tomada, un servidor alcanzado—, mientras que una prueba web3 trata el movimiento de valor como la condición final. Continúa más allá: altera al destinatario o al monto dentro de una solicitud de firma legítima y comprueba 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 de 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 web3 las conectan al validar rutas alcanzables; no las reemplazan, ni garantizan el descubrimiento de brechas, 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 constituyen asesoría legal. Las instituciones deben confirmar su situación, exenciones, sistemas y obligaciones con asesoría jurídica.

• Estados Unidos, Nueva York: requisito explícito con exención limitada. Las entidades cubiertas bajo el reglamento NYDFS 23 NYCRR Part 500 [12] del Departamento de Servicios Financieros del Estado de Nueva York, incluidos los negocios de moneda virtual con licencia del DFS, deben probar sus sistemas de información desde dentro y fuera de sus límites, en función de una evaluación de riesgos, al menos una vez al año. Una parte interna o externa calificada puede realizar la prueba. Las entidades pequeñas que califiquen reciben una exención limitada de esta disposición de pruebas, pero siguen sujetas a las demás disposiciones aplicables de la Part 500.

• Dubái: requisito anual y activado por cambios. Los VASP con licencia deben realizar una evaluación de vulnerabilidades y pruebas de penetración al menos una vez al año, y antes de introducir nuevos sistemas, aplicaciones o productos [13], utilizando un tercero calificado e independiente. La auditoría de contratos inteligentes se aplica cuando resulta pertinente para el negocio y las actividades del VASP. Las pruebas de penetración basadas en amenazas (threat-led) no tienen una periodicidad universal: VARA puede exigirlas cuando sea necesario y proporcional en función del riesgo.

• Hong Kong: requisito de condición de licencia para los solicitantes considerados licenciados. Los solicitantes de plataformas de negociación de activos virtuales considerados licenciados deben completar pruebas de penetración y evaluaciones de vulnerabilidad con resultados satisfactorios antes de la operación restringida [14]. Se aplica una guía separada para los solicitantes de nueva constitución. Un tercero independiente debe cubrir la infraestructura y las aplicaciones especificadas, tanto en las capas de aplicación como de red. Antes de la operación restringida, la dirección debe completar todos los pasos de rectificación mayores y críticos para los hallazgos de riesgo medio-alto.

• Unión Europea: marco proporcional; TLPT condicionado a la identificación. La DORA cubre a las entidades financieras, incluidos los proveedores de servicios de criptoactivos [15]. Exige pruebas apropiadas —no específicamente pruebas de penetración— al menos una vez al año para los sistemas que soportan 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 basadas en amenazas (TLPT) se aplican solo a las entidades identificadas por las autoridades competentes, se ejecutan en sistemas de producción en vivo y generalmente se exigen al menos cada tres años; las autoridades pueden ajustar esa frecuencia por motivos de riesgo. La DORA también impone condiciones de independencia para los testers. Las microempresas quedan fuera del requisito de programa de pruebas.

• Singapur: expectativa de supervisión no vinculante. Las Directrices de Gestión de Riesgo Tecnológico de la MAS indican que las instituciones financieras deben realizar pruebas de penetración y esperan que los sistemas accesibles por Internet se prueben al menos una vez al año o tras cambios o actualizaciones importantes [16]. Se trata de una guía de supervisión no vinculante y no exige un tercero independiente. El Aviso de Higiene Cibernética vinculante, específico para bancos, no especifica pruebas de penetración. El aviso 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 "web3" con marca propia. La versión especializada en web3 se deriva de los sistemas dentro del alcance: cuando estos autorizan, firman, custodian o contabilizan valor cripto, probarlos adecuadamente requiere el mismo dominio de firma y flujo de fondos que describe la Parte 1.

La conclusión es precisa: un conjunto sustancial de entidades con licencia en jurisdicciones específicas ya enfrenta un requisito o una 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 el licenciamiento, 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 web3 son una capa de garantía necesaria. Validan 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, ni demostrar que habrían detenido algún incidente pasado específico, 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:

• Parte 2: ¿Qué son las pruebas de penetración web3? Definiciones y límites

• Parte 3: Reglas de compromiso y seguridad en producción para las pruebas de penetración web3 institucionales

• Parte 4: Superficies de ataque web3: una visión general de las pruebas de penetración

También en esta serie, próximamente:

• Parte 5: Seguridad de autorización y firma: web, dApps y móvil
• Parte 6: Seguridad en la nube y CI/CD: superficies de ataque de las operaciones automatizadas
• Parte 7: Seguridad del plano de control de tesorería: firma y aprobaciones de retiro
• Parte 8: Seguridad del libro mayor del exchange: rutas de robo y lógica del plano de datos

BlockSec ayuda a las instituciones a ubicar esta capa con precisión: mapea los activos, los flujos de fondos, los límites de confianza y la garantía existente; confirma las obligaciones que la asesoría jurídica 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 su brecha de garantía, hable con nuestro equipo de pruebas de penetración blockchain ; el alcance y los precios del contrato están disponibles a solicitud. Comience por donde se mueven los fondos.

Referencias

Numeradas en orden de primera aparición.

1. BlockSec, Crypto Payment Security Playbook. https://blocksec.com/crypto-payment-playbook

2. Oficina Federal de Investigación de EE. UU. (FBI), DC3, y la Agencia Nacional de Policía de Japón, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (diciembre de 2024). https://www.fbi.gov/news/press-releases/fbi-dc3-and-npa-identification-of-north-korean-cyber-actors-tracked-as-tradertraitor-responsible-for-theft-of-308-million-from-bitcoindmmcom

3. BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack. https://blocksec.com/blog/bybit-1-5-b-hack-in-depth-analysis-of-the-malicious-safe-wallet-upgrade-attack

4. rekt.news, BtcTurk — Rekt. https://rekt.news/btcturk-rekt

5. rekt.news, Leaderboard. https://rekt.news/leaderboard

6. SwissBorg, SwissBorg Security Update: Kiln Breach. https://swissborg.com/blog/swissborg-security-update-kiln-breach

7. BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor. https://blocksec.com/blog/trust-wallet-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. https://slope-finance.medium.com/slope-wallet-sentry-vulnerability-digital-forensics-and-incident-response-report-d7a5904e5a39

9. BlockSec, Our Short Analysis of the Profanity Tool Vulnerability. https://blocksec.com/blog/our-short-analysis-of-the-profanity-tool-vulnerability

10. BlockSec, Coldcard Entropy Failure and Seed Recovery (exposición de clave privada). https://blocksec.com/blog/coldcard-entropy-failure-seed-recovery

11. BlockSec, Phalcon Security (monitoreo y bloqueo de transacciones). https://blocksec.com/phalcon/security

12. Departamento de Servicios Financieros del Estado de Nueva York, 23 NYCRR Part 500. https://www.dfs.ny.gov/industry_guidance/cybersecurity

13. Autoridad Reguladora de Activos Virtuales de Dubái, Technology and Information Rulebook, Part I, Section E. https://rulebooks.vara.ae/rulebook/e-testing-and-audit

14. Comisión de Valores y Futuros de Hong Kong, Circular 24EC65, 18 de diciembre de 2024. https://apps.sfc.hk/edistributionWeb/api/circular/openFile?lang=EN&refNo=24EC65

15. Unión Europea, Reglamento (UE) 2022/2554 (Ley de Resiliencia Operativa Digital), Artículos 24-27. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng

16. Autoridad Monetaria de Singapur, Technology Risk Management Guidelines (enero de 2021), Secciones 2 y 13, https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines; _Notice FSM-N06, Notice on Cyber Hygiene_ (2024), https://www.mas.gov.sg/regulation/notices/notice-fsm-n06