La campaña XCTDH oculta las direcciones de comando de sus malware en Ethereum

A finales de septiembre de 2026, el grupo de inteligencia especializado en ransomware Ransom‑ISAC publicó un informe detallado que describe una nueva metodología, llamada «HashHiding», empleada por la campaña de ransomware XCTDH, ampliamente atribuida a Corea del Norte. Según el informe, los operadores de XCTDH comenzaron a codificar la dirección del servidor de comando y control (C2) en campos de destinatario de transacciones de Ethereum que no corresponden a ninguna dirección real o que sólo transportan una cantidad insignificante de cripto‑activos. Esta técnica tiene como objetivo dificultar la detección del servidor C2 por parte de los analistas de seguridad, al tiempo que mantiene la capacidad del malware para recuperar dinámicamente la información desde la cadena de bloques. La estrategia se basa en ocultar datos críticos dentro de transacciones que, a simple vista, parecen inofensivas y sin valor económico significativo.

Cómo funciona la técnica HashHiding

En una transacción estándar de Ethereum, el campo «to» indica la dirección del destinatario. Los investigadores de Ransom‑ISAC observaron que los operadores de XCTDH sustituyen esa dirección por una cadena hexadecimal que, al decodificarse, revela el identificador del servidor C2. La decodificación generalmente se basa en una función de hash inversa o en una tabla de correspondencia preestablecida por el malware. La propia transacción puede contener cero ether o una cantidad inferior a 0,0001 ETH, lo que la hace poco atractiva para los mineros y los exploradores de bloques, pero suficiente para quedar registrada de forma permanente en la cadena. Esta práctica permite que la información de comando quede incrustada en la blockchain sin generar un coste significativo.

El componente de recuperación del malware consulta un nodo público de Ethereum o un punto de acceso RPC para extraer las últimas transacciones que contienen el patrón sospechoso. Una vez identificada la transacción, el código del malware aplica la misma lógica de decodificación utilizada por los operadores, reconstruye la dirección IP o el nombre de dominio del servidor C2 y establece una conexión cifrada para descargar las cargas útiles o las claves de descifrado. Este enfoque elimina la necesidad de un servidor DNS dinámico o de una lista codificada de forma rígida, haciendo que la rotación del servidor sea prácticamente invisible para los sistemas de detección tradicionales. De este modo, la infraestructura de comando se vuelve más resiliente frente a bloqueos manuales.

Evidencias y alcance de la campaña XCTDH

La investigación llevada a cabo por Ransom‑ISAC permitió identificar más de 2 600 transacciones que coinciden con el modelo HashHiding en un período de tres meses, desde finales de julio hasta finales de octubre de 2026. Durante esa ventana, los operadores modificaron la dirección codificada cuatro veces, lo que condujo al uso de tres servidores C2 distintos. Cada cambio de dirección estuvo acompañado de un breve período de prueba en el que varias decenas de víctimas recibieron el nuevo cargador, antes de que la nueva configuración se difundiera ampliamente. Estos números confirman que la técnica no es una prueba aislada, sino una componente integrada de la cadena de infraestructura de XCTDH. La consistencia de los patrones observados indica una operación bien planificada y sostenida.

Además de Ethereum, los investigadores constató que los mismos operadores replican el esquema HashHiding en otras redes de contratos inteligentes, como BNB Smart Chain, TRON y Aptos. Esta diversificación obliga a los equipos de defensa a monitorizar simultáneamente varios exploradores de bloques y a establecer reglas de correlación entre los diferentes ledgers. El hecho de que cada cadena posea sus propios parámetros de tarifas y confirmación complica aún más la implementación de bloqueos automatizados, ya que una dirección oculta en Ethereum puede replicarse rápidamente en BNB Smart Chain con un coste marginal. Esta capacidad de adaptación multipla a distintas plataformas aumenta la superficie de ataque.

Limitaciones de la ocultación

Si la técnica HashHiding hace que la rotación del servidor C2 sea más resistente a los bloqueos manuales, no vuelve al malware indetectable. Los analistas aún pueden identificar transacciones sospechosas mediante filtros basados en el tamaño de la transacción, la ausencia de valor transferido y la presencia de patrones hexadecimales recurrentes. Además, el código del malware que realiza la decodificación debe estar presente en el binario o descargarse durante la primera infección, lo que ofrece un punto de anclaje para soluciones de detección basadas en análisis estático o dinámico. Estas señales permiten a los investigadores crear firmas específicas que detecten la actividad subyacente.

Los equipos de respuesta a incidentes han comenzado a integrar firmas de transacción HashHiding en sus sistemas de vigilancia de la blockchain. Estas firmas buscan direcciones de destino que no correspondan a ninguna cartera conocida y que estén asociadas a montos inferiores a un umbral predefinido, generalmente 0,001 ETH. Paralelamente, las soluciones de sandboxing pueden instrumentar el comportamiento del malware para detectar llamadas a la API RPC de Ethereum y la decodificación de datos hexadecimales, lo que genera alertas tempranas antes de que el cargador contacte al servidor C2. La combinación de monitoreo de blockchain y análisis de comportamiento aumenta la capacidad de detección precoz.

• Monitorear transacciones en Ethereum, BNB Smart Chain, TRON y Aptos en busca de patrones de HashHiding
• Desplegar filtros de valor mínimo para ignorar micro‑transacciones sospechosas
• Integrar firmas de decodificación en soluciones EDR y sandbox
• Bloquear o redirigir las solicitudes RPC hacia nodos de confianza controlados por la empresa
• Compartir indicadores de compromiso (IOCs) con las comunidades ISAC para una respuesta coordinada

Para las empresas, la presencia de HashHiding significa que la simple inclusión en listas negras de direcciones IP o dominios ya no basta para interrumpir la cadena de infección. Los actores maliciosos pueden cambiar la dirección C2 en cuestión de horas sin alertar a los sistemas de filtrado de red, mientras conservan una huella permanente en la blockchain. Las organizaciones deben, por tanto, ampliar su perímetro de detección a actividades de la blockchain pública, combinando análisis de tráfico de red, registros de llamadas RPC e inteligencia sobre transacciones sospechosas. Esta ampliación del alcance de vigilancia es esencial para contrarrestar la flexibilidad que brinda la blockchain a los atacantes.

A la luz de estos hallazgos, se invita a los equipos de ciberseguridad a actualizar sus manuales de respuesta a ransomware, incorporando procedimientos de vigilancia de la blockchain y reglas de alerta específicas para la técnica HashHiding. Ransom‑ISAC también recomienda reforzar la cooperación entre proveedores de servicios en la nube, exploradores de bloques y plataformas de intercambio para facilitar la notificación y neutralización rápida de direcciones ocultas. Adoptando estas medidas, los defensores podrán reducir la ventaja que la ocultación en Ethereum otorga a los operadores de XCTDH y limitar el alcance de sus futuras campañas.