¿Puede protegerse contra los piratas informáticos? - Principales conclusiones de la retransmisión en directo de Certora sobre la evolución de las amenazas y lo que los protocolos deben hacer a continuación

Si alguna vez has vivido con el temor de ser hackeado y tus fondos desviados por un actor malicioso, la empresa líder en seguridad de blockchain Certora intentó aliviar esos temores el jueves 12 de febrero mediante un livestream titulado "Cómo han cambiado los hackeos de DeFi en los últimos 5 años y qué significa esto para los protocolos."

Seth Hallem, CEO de Certora, se unió a Ofek Ray Orlev, investigador de seguridad senior y jefe de equipo en la compañía, para analizar en qué se diferencian los ataques modernos de los anteriores exploits DeFi y qué deben hacer los equipos de protocolo en respuesta.

Seth se incorporó a Certora hace ocho meses tras forjarse una carrera en análisis estático, calidad del software y ciberseguridad. Ahora aplica esa experiencia a Web3 y DeFi. Ofek aporta doce años de experiencia en investigación de vulnerabilidades en dominios ofensivos y defensivos. Antes de entrar en el espacio DeFi hace dos años, dirigió el equipo rojo y los esfuerzos de pruebas de penetración en Intel, donde desarrolló herramientas ofensivas y defensivas para sistemas embebidos.

En lugar de repasar ataques conocidos, el debate se centró en dos recientes y sofisticados ataques. El primero, CPIMP, son las siglas de Clandestine Proxy In The Middle of Proxy. El segundo, GlassWorm, representa el primer gusano criptodirigido y autopropagado que ataca la cadena de suministro de NPM y OpenVSX. Juntos, estos ataques ilustran cómo la seguridad DeFi ha pasado de los fallos obvios a las campañas sistémicas, pacientes y de múltiples capas.

Ataque de proxy clandestino en medio del proxy (CPIMP)

El ataque CPIMP explota patrones de inicialización de proxy en contratos inteligentes. En esencia, el ataque secuestra la fase de inicialización de un contrato proxy. Si un atacante se adelanta a la primera llamada de inicialización, puede inicializar el proxy con una implementación maliciosa.

Lo que hace que CPIMP sea particularmente notable no es sólo su punto de apoyo inicial, sino también la persistencia y el sigilo que le siguen. El proxy malicioso imita la implementación prevista, por lo que todas las pruebas e interacciones normales siguen pasando. Los desarrolladores y usuarios no ven ningún fallo evidente. El atacante inserta un proxy clandestino entre el proxy legítimo y su lógica prevista, lo que le permite interceptar y manipular llamadas sin detección inmediata.

Los actores maliciosos también diseñaron la persistencia a través de actualizaciones. Cuando los desarrolladores actualizan el proxy para añadirle funciones, la capa maliciosa reinyecta su código en la nueva implementación. Una vez infectado, cada actualización posterior fluye a través de la tubería del atacante. Este diseño permite un control a largo plazo en lugar de un rápido ataque de tipo "rompe y atrapa".

Los atacantes incluso explotaron una vulnerabilidad en Etherscan que les permitió falsificar la dirección de implementación mostrada rellenando una ranura de almacenamiento obsoleta. Los observadores externos que utilizaran exploradores de bloques verían la implementación incorrecta, lo que dificultaría aún más la detección.

Seth y Ofek compararon este planteamiento con un rug pull, pero con un horizonte temporal diferente. Un tirón de alfombra tradicional suele agotar los fondos rápidamente. CPIMP parece diseñado para esperar hasta que un protocolo crezca lo suficiente como para justificar su activación. El atacante puede tratar el sistema comprometido como un activo latente que madura con el tiempo. Esa paciencia sugiere una mentalidad de campaña más que una explotación oportunista.

Ataque GlassWorm: Extracción de claves privadas de 50 extensiones de cartera

GlassWorm desplaza el campo de batalla de la lógica onchain a la cadena de suministro de desarrollo. Los atacantes introdujeron una extensión maliciosa de VS Code que infectó las máquinas de los desarrolladores. Una vez instalada, la extensión extraía claves privadas de aproximadamente cincuenta extensiones de monedero. También buscaba credenciales de GitHub y determinaba si el desarrollador infectado mantenía otras extensiones de VS Code.

Si el desarrollador publicaba una extensión, el gusano inyectaba código malicioso en esa extensión antes de su distribución. Este mecanismo de propagación transformó el malware en un verdadero gusano. Cada nueva extensión infectada propaga aún más la carga útil, amplificando su alcance en todo el ecosistema.

Tómate un segundo para comprender esta información. Eres un desarrollador. Tu máquina se infecta. Probablemente te drenan tus fondos. Las extensiones que desarrollas se infectan, y cualquiera que las descargue también infecta su máquina, y así sucesivamente.

La etiqueta "glass" hace referencia al uso de caracteres no imprimibles para ocultar el código malicioso. La carga útil aparecía como líneas en blanco o espacios en blanco en los editores. Las herramientas tradicionales de análisis estático no detectaron el código antes de que los investigadores identificaran el ataque.

GlassWorm combinaba técnicas conocidas con nuevas innovaciones. Reutilizaba estrategias establecidas para comprometer la cadena de suministro y métodos de extracción de claves privadas. Sin embargo, introdujo un novedoso mecanismo de mando y control aprovechando la cadena de bloques Solana. El gusano leía instrucciones cifradas incrustadas en los campos "memo" de las transacciones. Como los atacantes firmaban esas transacciones con su propia cartera, las máquinas infectadas podían verificar y ejecutar nuevas instrucciones sin depender de un servidor tradicional.

Este diseño de mando y control en cadena dificultó enormemente las labores de desmantelamiento. Las fuerzas del orden o los equipos de seguridad no podían simplemente confiscar un servidor centralizado. Los atacantes también utilizaron los temas de eventos de Google Calendar como canal de comunicación de reserva. Estas capas crearon una resistencia y flexibilidad que los investigadores de seguridad rara vez observan en gusanos Web2 anteriores.

El gusano también instaló un cliente VNC oculto y configuró un proxy SOCKS en las máquinas infectadas. Esas capacidades indican que los atacantes buscaban algo más que drenar carteras. Su objetivo era obtener un amplio acceso a los sistemas de las víctimas. El ataque difuminó la línea entre Web2 y Web3 y demostró que la seguridad DeFi ya no se detiene en los contratos inteligentes.

¿Qué se puede hacer para protegerse?

Ambos ponentes insistieron en que los desarrolladores no deben adoptar una mentalidad nihilista. La seguridad perfecta no existe, pero las mejoras prácticas reducen significativamente el riesgo.

Ofek aconsejó a los equipos que examinaran sus cadenas de herramientas, limitaran las extensiones innecesarias y mantuvieran actualizadas las dependencias. Instó a los desarrolladores a comprender realmente cómo se ejecutan sus procesos de despliegue.

También recomendó la verificación posterior a la implantación. Los equipos deberían inspeccionar directamente las ranuras de almacenamiento onchain en lugar de confiar únicamente en los exploradores de bloques. Deben confirmar que no se han producido llamadas de delegación o pasos de inicialización inesperados.

Seth hizo hincapié en el pensamiento arquitectónico. Afirmó que "la idea de que una extensión del navegador es un lugar seguro para descifrar una clave privada y firmar transacciones que mueven dinero es un concepto erróneo construido a partir de un modelo de amenaza equivocado", y argumentó que las extensiones del navegador se ejecutan en entornos altamente dinámicos y no deben manejar operaciones criptográficas de alto valor. Los módulos de seguridad de hardware y los entornos de firma aislados ofrecen mayores garantías.

Mert Mumtaz, consejero delegado de Helius Labs, se hizo eco de esta opinión en un post público, escribiendo que la idea de que los monederos sean extensiones de Chrome representa una de las decisiones UX más cuestionables de la industria.

Ambas perspectivas ponen de relieve la necesidad de replantearse los supuestos de seguridad de los monederos a medida que aumentan las entradas de capital.

¿Qué hay que tener en cuenta en 2026?

De cara a 2026, ambos ponentes esperan una mayor participación institucional en Web3. A medida que los gobiernos y las grandes instituciones financieras evalúen una mayor participación, los protocolos se enfrentarán a requisitos de diligencia debida y cumplimiento más estrictos. Es probable que la documentación, la verificación formal, los procedimientos estandarizados y las asociaciones de seguridad continuas se conviertan en expectativas básicas.

En el lado ofensivo, los atacantes seguirán combinando técnicas de Web2 y Web3. A medida que mejore la calidad de los contratos inteligentes y se generalicen las auditorías, los atacantes se centrarán en la ingeniería social, la exfiltración de claves privadas, los frontales, los procesos de gobernanza y las cadenas de suministro. Seth comparó este cambio con el aumento del ransomware en Web2 después de que las organizaciones endurecieran los servicios expuestos.

Los protocolos deben esperar que los atacantes se comporten como empresas. Algunas campañas perseguirán beneficios transaccionales como el phishing y el robo de carteras. Otras perseguirán oportunidades estratégicas dirigidas a debilidades sistémicas en infraestructuras de billones de dólares.

Reflexiones finales

La retransmisión en directo puso de manifiesto un claro cambio en la seguridad de DeFi. Los primeros ataques se basaban a menudo en errores de programación evidentes. Los ataques modernos operan con paciencia, persistencia y sofisticación entre dominios. CPIMP demostró cómo los atacantes pueden esconderse dentro de arquitecturas proxy y esperar a que se acumule valor. GlassWorm demostró cómo los compromisos de la cadena de suministro y el mando y control en la cadena pueden extenderse más allá de los contratos inteligentes a los entornos de desarrollo.

Los protocolos no pueden predecir todas las técnicas futuras. Sin embargo, pueden aumentar el coste de los ataques mediante una arquitectura disciplinada, un despliegue cuidadoso, la minimización de las superficies de amenaza y la verificación continua. A medida que aumenten el capital y el escrutinio normativo, la seguridad pasará de ser una auditoría puntual a un requisito operativo continuo.

Más información sobre SolanaFloor

Los desarrolladores de Solana se multiplican casi por 10 desde 2020, ya que la red acoge la cifra récord de 3.830 nuevos desarrolladores en 2025
Solana Perps Scene Snubbed Once Again As Trojan Terminal Integrates Elsewhere

¿Pueden los Tesoros de Activos Digitales Sobrevivir al Crash?