Hackers secuestraron aproximadamente una docena de sitios web de protocolos DeFi y drenaron unos $138,000 de usuarios que interactuaron con las interfaces comprometidas. Todos los sitios afectados compartían un detalle en común: sus dominios estaban registrados a través de Name.com. El incidente es un recordatorio directo de que la superficie de confianza de un protocolo DeFi se extiende mucho más allá de sus contratos inteligentes hasta la infraestructura web que sirve su interfaz de usuario.

Lo que se sabe sobre los secuestros de sitios web DeFi

Según un reportaje de The Block del 31 de octubre de 2026, los atacantes tomaron el control de alrededor de doce sitios web DeFi y redirigieron a los usuarios hacia flujos maliciosos que resultaron en aproximadamente $138,000 en fondos robados.

Los hechos confirmados siguen siendo limitados: aproximadamente doce sitios web DeFi fueron afectados, todos registrados a través de Name.com, y se sustrajeron cerca de $138,000 en fondos de usuarios. Los protocolos específicos atacados, el vector de ataque preciso y el número de víctimas individuales no han sido confirmados en los reportes disponibles. El registro compartido por sí solo no establece causalidad, y Name.com no ha sido confirmado como el punto directo de falla.

Lo que sigue sin confirmarse

Según reportes no confirmados, el registro compartido en Name.com podría apuntar a un compromiso de credenciales o a un robo de cuenta a nivel del registrador, lo que habría permitido a los atacantes modificar los registros DNS y redirigir el tráfico del dominio sin tocar los contratos inteligentes subyacentes. El incidente también pudo haber involucrado cuentas de registrador comprometidas, ingeniería social u otro vector por completo.

La distinción importa tanto para los usuarios afectados como para los equipos de los protocolos: si los registros DNS fueron manipulados, los contratos inteligentes en cadena podrían no estar afectados, lo que significa que las tesorerías de los protocolos y los pools de liquidez podrían permanecer intactos mientras los usuarios que interactuaron con las interfaces falsificadas absorbieron las pérdidas.

Los secuestros de interfaces enrutados a través de la infraestructura de dominios tienen precedentes en el sector: en 2022, los atacantes redirigieron el DNS de Curve Finance hacia un clon malicioso de su interfaz tras comprometer una cuenta de un proveedor de dominios, un episodio ampliamente citado que colocó los controles de registrador y DNS en las listas de seguridad de los equipos DeFi. Sin embargo, el precedente no es evidencia: si el registro compartido en Name.com en este caso fue central o incidental solo podrá determinarse con los hallazgos propios de los equipos afectados.

Cómo un sitio web DeFi secuestrado pone en riesgo a los usuarios

Un compromiso de la interfaz web es estructuralmente diferente a un exploit de contrato inteligente. Cuando los atacantes controlan un dominio, pueden servir una copia visualmente idéntica de la interfaz legítima mientras sustituyen silenciosamente los puntos de conexión de billeteras, las direcciones de contratos o los calldata de las transacciones. Un usuario que firma lo que parece una aprobación rutinaria podría en realidad estar autorizando un contrato drainer para barrer todo el saldo de sus tokens.

Qué deben verificar los usuarios antes de firmar cualquier transacción

Antes de conectar una billetera o firmar cualquier transacción en una interfaz DeFi, los usuarios deben verificar de forma independiente la dirección del contrato con la que están interactuando contra la documentación oficial del protocolo, no solo la URL en el navegador. El marco de Verificación y Autorización Segura de Transacciones (STVA) cubre los pasos específicos para inspeccionar los calldata antes de aprobar. Un dominio que resuelve correctamente y muestra un certificado SSL válido no garantiza que la interfaz no haya sido manipulada a nivel de DNS o de hosting.

Las billeteras de hardware resistentes al phishing pueden mostrar los detalles de la transacción en la pantalla del dispositivo, independientemente del navegador, lo que brinda a los usuarios una segunda capa de verificación. Aun así, un atacante decidido que controle la interfaz puede crear descripciones de transacción engañosas. La única protección confiable es verificar la dirección del contrato de destino contra el despliegue canónico en cadena del protocolo, obtenido del repositorio oficial de GitHub o de la documentación de gobernanza, y no de la interfaz del dApp conectado.

Las aprobaciones de tokens otorgadas a un contrato comprometido persisten en cadena hasta que se revocan explícitamente. Cualquier usuario que haya conectado una billetera y firmado una transacción durante el periodo en que estos sitios estuvieron bajo control de los atacantes debe tratar las aprobaciones pendientes como potencialmente maliciosas. Las herramientas de gestión de aprobaciones permiten a los usuarios auditar y revocar permisos en tokens ERC-20, pero solo después de confirmar de forma independiente las direcciones de contrato correctas a revocar y la red correcta en la que operar.

Qué deben hacer a continuación los usuarios y los equipos DeFi

Acciones de los usuarios

Los usuarios que interactuaron con cualquiera de los sitios web DeFi afectados deben primero evitar conectar billeteras o firmar nuevas transacciones hasta que el protocolo correspondiente confirme públicamente que la interfaz ha sido restaurada y verificada. Las comunicaciones oficiales deben obtenerse de las cuentas sociales verificadas del protocolo y de sus foros de gobernanza, no de enlaces incluidos en mensajes directos o chats comunitarios, que son un vector de ataque secundario común tras un compromiso de la interfaz. Dado que los reportes disponibles no han nombrado a los protocolos afectados, los usuarios de cualquier interfaz DeFi deben estar atentos a los anuncios directos de los protocolos que utilizan en lugar de asumir que no fueron afectados.

Para los usuarios que sí firmaron transacciones durante la ventana del incidente, revocar las aprobaciones es aconsejable solo después de confirmar la dirección correcta del contrato malicioso desde una fuente verificada e independiente. Revocar el contrato equivocado desperdicia gas y brinda una falsa seguridad. Protocolos como Aave V4 publican registros canónicos de contratos que pueden servir como punto de referencia para distinguir los contratos legítimos del protocolo de los drainers desplegados por atacantes.

Respuesta del equipo del protocolo

Los equipos afectados deben tratar esto como un incidente activo hasta que se confirme la cadena de ataque completa. Las prioridades inmediatas incluyen auditar los registros de acceso de las cuentas del registrador de dominios, rotar todas las credenciales asociadas con las cuentas de Name.com, verificar los registros DNS actuales contra instantáneas confiables y revisar los registros de transparencia de certificados HTTPS en busca de certificados no autorizados emitidos durante la ventana del ataque.

Los equipos también deben preservar toda la evidencia del incidente antes de realizar cambios, ya que se necesitarán datos forenses sobre la ventana del ataque —incluidos los registros de cambios de DNS y cualquier comunicación con el registrador— para establecer exactamente qué fue comprometido y cuándo. Publicar un informe de incidente claro y con marca de tiempo una vez confirmado el vector de ataque, en lugar de emitir comunicaciones especulativas durante la investigación, es el estándar que las comunidades afectadas esperarán.

La seguridad de las cuentas del registrador de dominios, incluida la aplicación de la autenticación de dos factores y los bloqueos de dominio a nivel del registrador, es una medida básica de endurecimiento que evita modificaciones no autorizadas del DNS incluso cuando las credenciales del atacante son válidas. El bloqueo de dominio impide transferencias y cambios de DNS sin la confirmación explícita del registrador, lo que lo convierte en un control significativo para cualquier protocolo cuyo sitio web representa una superficie de confianza de cara al usuario para transacciones que involucran fondos reales.

La lección más amplia

La pérdida de $138,000 reportada en alrededor de una docena de protocolos es modesta en comparación con el TVL total de DeFi en Ethereum. Pero la vulnerabilidad estructural que expone —a saber, que una cuenta de registrador web2 puede convertirse en el eslabón más débil de la pila de seguridad de un protocolo— aplica a cualquier proyecto DeFi que dependa de un dominio registrado de forma centralizada para servir su interfaz de usuario. La seguridad de las interfaces, incluido el monitoreo del DNS, el endurecimiento de las cuentas del registrador y la orientación a los usuarios sobre la verificación independiente de contratos, merece el mismo rigor operativo que se aplica a la auditoría de contratos inteligentes.