NullReceiver: la táctica que oculta la IP del C2 en las direcciones de destino de Ethereum

Investigadores en ciberseguridad han detectado una variación sigilosa de la técnica conocida como EtherHiding: un método que aprovecha la naturaleza pública de blockchains como Ethereum para transferir instrucciones de comando y control (C2) sin recurrir a servidores tradicionales. La nueva táctica, bautizada como NullReceiver por el colectivo OpenSourceMalware, prescinde por completo de contratos inteligentes o de campos de datos en transacciones y, en su lugar, codifica la dirección IP del C2 dentro de los bytes de la dirección de destino de una transferencia Ethereum de valor y datos nulos. Esto reduce el coste en gas, elimina campos evidentes donde buscar payloads y dificulta la creación de huellas estáticas que los defensores puedan monitorizar.

En la cadena de eventos descrita por los analistas, bibliotecas JavaScript maliciosas publicadas en npm —identificadas como bianira-ui y fluid-type-ui— llevaban código capaz de localizar una billetera atacante fija en la blockchain, leer su transacción saliente más reciente y extraer la dirección IP a partir de los primeros cuatro bytes hexadecimales de la dirección "To" de esa transacción. Esa dirección no existe para recibir fondos; su única función es servir como contenedor binario que encodea, por ejemplo, "a658863e" → 166.88.134.62 y, en el resto de bytes, incluir una etiqueta legible ("helloipbot!!") para el autor. Las librerías señaladas fueron retiradas del registro, pero ya habían sido descargadas cientos de veces tras su publicación a finales de julio de 2026.

NullReceiver representa una escalada táctica respecto a EtherHiding, documentado públicamente en 2023, porque elimina el componente que permitió a los equipos de respuesta marcar y perseguir un destino público conocido. Mientras EtherHiding podía alojar URLs o scripts completos en calldata o contratos, NullReceiver solo transporta unas pocas bytes útiles pero lo hace de forma que no hay "campo" para rastrear; cada transacción usa una dirección de destino distinta y desechable, lo que complica las reglas de bloqueo basadas en patrones de transacción.

El uso de la blockchain como canal de C2 no es nuevo en campañas sofisticadas y ha sido asociado por los equipos de inteligencia a actores patrocinados por Estados —en este caso, las señales públicas vinculan la actividad con campañas norcoreanas que han empleado subterfugios en redes profesionales y paquetes maliciosos para lograr ejecución remota—. La novedad técnica está en el refinamiento: transacciones mínimas, baratas y aparentemente inofensivas que solo cobran sentido cuando un cliente comprometido aplica la lógica inversa y convierte bytes de la dirección en una dirección IP.

Para defensores y responsables de desarrollo, la lección principal es doble: la superficie de ataque en la cadena de suministro de código ha evolucionado, y las señales convencionales en la blockchain (contratos reutilizables, calldata sospechoso, dominios públicos) ya no son garantía de detección. Auditorías estáticas convencionales pueden pasar por alto código que solo realiza operaciones criptográficas sencillas y consultas a nodos públicos, por lo que es necesario complementar el control de integridad del código con controles de comportamiento y de red en el endpoint.

Recomiendo a equipos de desarrollo y seguridad corporativos aplicar medidas prácticas y priorizadas: exigir políticas de aprobación y revisión para nuevas dependencias, pinnear versiones en lockfiles y publicar solo paquetes firmados o desde registros internos; habilitar autenticación multifactor para cuentas de publicación en repositorios públicos; utilizar herramientas de análisis de composición de software (SCA) y escaneo estático para detectar patrones sospechosos como llamadas a nodos Ethereum, uso de librerías web3 o decodificación de direcciones; además, implementar controles de egress en endpoints que impidan conexiones salientes no autorizadas desde procesos Node.js. En entornos críticos, contemplar el uso de repositorios proxy privados (por ejemplo, soluciones on-premise) para filtrar y validar paquetes antes de su consumo.

Desde la perspectiva de detección y respuesta, la táctica obliga a cambiar la atención hacia señales de comportamiento: monitorizar y alertar sobre procesos que consultan APIs públicas de blockchain, conexiones inesperadas a direcciones IP recién creadas o patrones de resolución de direcciones, y cualquier intento de convertir datos hexadecimales en direcciones IP dentro de código de terceros. Las capacidades de EDR y las reglas de red deben ajustarse para captar estas anomalías, y los equipos de inteligencia de amenazas deberían rastrear billeteras atacantes conocidas y sus transacciones, aunque esa tarea sea ahora más laboriosa y menos concluyente.

La comunidad se beneficia cuando esta clase de tácticas se documenta y comparte, porque permite anticipar contraataques y endurecer controles antes de que campañas a gran escala logren impacto mayor. Para quien quiera profundizar en cómo funcionan las transacciones y por qué la blockchain permite este tipo de abusos técnicos, la documentación oficial de Ethereum ofrece una base sólida sobre estructuras de transacción y codificación: https://ethereum.org/en/developers/docs/. Para entender mejores prácticas en seguridad de la cadena de suministro de software y medidas concretas de mitigación, los recursos del proyecto OWASP Supply Chain Security resultan muy útiles: https://owasp.org/www-project-supply-chain-security/.

En resumen, NullReceiver es un recordatorio de que los atacantes aprovechan la transparencia de blockchains para mayor resiliencia operacional y anonimato táctico. La defensa ya no puede confiar únicamente en listas negras estáticas: requiere controles en la fase de desarrollo, validación del software que entra en la organización, y una capa de detección basada en comportamiento que bloquee conexiones y procesos inusuales antes de que una dependencia comprometida pivote hacia una intrusión mayor.