La investigación sobre amenazas en la cadena de suministro de software continúa dando giros. En esta ocasión, expertos en ciberseguridad han descrito una evolución de una técnica basada en blockchain para ocultar la dirección IP del servidor de comando y control (C2). El hallazgo se centra en NullReceiver en npm, un método observado en dos paquetes maliciosos que fueron publicados como si fueran librerías legítimas.
Según los reportes, los paquetes bianira-ui y fluid-type-ui pertenecen a una campaña vinculada a Corea del Norte. Aunque ya no están disponibles en npm, los registros indican descargas desde su publicación, lo que aumenta la importancia de revisar entornos que hayan instalado dependencias de fuentes no confiables.
Qué es NullReceiver y por qué importa
NullReceiver se describe como una mejora deliberada de un enfoque anterior conocido como EtherHiding. Ambos métodos comparten la idea de usar transacciones en una blockchain pública para esconder información operativa. En el caso de EtherHiding, la lógica consistía en incrustar código o datos dentro de un contrato inteligente o en campos asociados a la transacción.
Lo relevante es que NullReceiver busca reducir señales que permitan a los defensores identificar el patrón rápidamente. En vez de emplear un destino fijo y “observable”, el malware construye una lógica que utiliza una dirección de receptor que, en términos prácticos, no es “real” para el propósito típico de una transferencia. Esa dirección funciona como contenedor para codificar la IP del C2.
La base: EtherHiding y su límite principal
Para entender el salto de NullReceiver, vale la pena recordar cómo funcionaba EtherHiding. El trabajo inicial describió que la técnica podía esconder código peligroso en un entorno público de blockchain, como BNB Smart Chain o Ethereum, con la ventaja de hacer la operación más resiliente ante takedowns.
Sin embargo, investigadores señalan un punto débil: EtherHiding dependía de una dirección destino “conocida”, fija y rastreable. Cuando aparecen nuevas transacciones que incorporan la carga útil (por ejemplo, datos, guiones o la propia IP C2) los defensores pueden asociarlas con esa dirección observada, lo que facilita la correlación.
NullReceiver en npm intenta corregir precisamente esa limitación. Al no reutilizar un destino rastreable, reduce el valor del patrón fijo como “huella” para la detección.
Cómo el malware codifica la IP C2 en una transferencia Ethereum vacía
El corazón del método consiste en que el malware no guarda la IP C2 como una constante incrustada directamente, ni la oculta en la calldata de la transacción. En lugar de ello, la información se deriva desde bytes de la dirección destino de una transferencia Ethereum con valor cero y sin datos.
De forma general, el flujo descrito por los investigadores es el siguiente:
- Usa una cartera del atacante predefinida (un monedero fijo incorporado por el malware) para localizar transacciones salientes recientes.
- Localiza la última transacción saliente desde esa cartera.
- Lee la dirección destino de esa transacción.
- Decodifica la IP convirtiendo los primeros bytes de esa dirección desde su representación hexadecimal a valores numéricos.
- Se conecta a la IP decodificada para continuar el flujo del ataque.
En el análisis se menciona una IP observada como destino final del C2: 166.88.134[.]62. También se detalla que la dirección destino usada en las transacciones contiene, además de los bytes que codifican la IP, una cadena ASCII que aparece como “helloipbot!!” en el remanente de bytes.
Claves operativas: cero “smart contract” y cero carga útil
Uno de los aspectos que vuelve a NullReceiver en npm especialmente relevante para la detección es su “silencio” técnico. Los paquetes señalados no llaman a un smart contract y no incluyen contenido en el campo calldata.
En otras palabras: en lugar de intentar esconder datos en el lugar donde los defensores esperan “ver” un patrón (carga extra, campos con texto, scripts o datos incrustados), el malware aprovecha que una transferencia en Ethereum puede tener forma mínima y aun así contener información codificable en la dirección.
Los investigadores también remarcan que la transacción es barata y “menos conspicua” porque está pensada para ser lo más simple posible: al estar en blanco (valor cero y sin datos), evita pagar por bytes adicionales. Esto reduce tanto el coste como el ruido.
El papel de las direcciones: por qué no hay destino reutilizado
Otro elemento clave es la estrategia contra el seguimiento. En la descripción del método, se afirma que NullReceiver nunca reutiliza un destino. Cada consulta genera una dirección nueva, “desechable”, que no se había visto antes.
Esa elección cambia el juego frente a técnicas con destino fijo. En EtherHiding, la existencia de un destino constante permitía a los equipos de defensa rastrear con mayor facilidad nuevas transacciones relacionadas con el payload o con la información del C2. En NullReceiver, al no existir ese “objetivo fijo observable”, la atribución y la correlación por patrón se vuelven más difíciles.
Además, como no hay un campo persistente que “marque” el intento, tampoco hay un lugar claro donde buscar huellas repetidas. El malware evita así la creación de un fingerprint estable.
Los paquetes trojanizados en npm: bianira-ui y fluid-type-ui
La alerta se basa en dos paquetes publicados en npm: bianira-ui y fluid-type-ui. En conjunto, se reporta que fueron descargados unas pocas centenas de veces desde su publicación el 28 de julio de 2026, con cifras aproximadas:
- bianira-ui: 109 descargas (publicado por un usuario de npm identificado como npmuser1101).
- fluid-type-ui: 587 descargas (publicado por un usuario de npm identificado como npmuser3002).
Actualmente, ambos paquetes ya no están disponibles para descarga desde npm, pero el daño potencial puede persistir en entornos que ya los instalaron.
Además, el análisis de transacciones relacionadas con el monedero usado por el malware indica que, desde el 27 de julio de 2026 (un día antes de la publicación de los paquetes), se registraron numerosas transacciones, lo que sugiere que el mecanismo pudo estar preparado con anterioridad.
Relación con campañas y por qué se vuelve más difícil defenderse
El reporte vincula la actividad con un actor asociado a Corea del Norte. También se menciona que la técnica se ha observado en el contexto de campañas que buscan engañar a objetivos para que realicen acciones que terminan facilitando la entrega de malware.
Lo que sugiere el nuevo desarrollo es una continuación de una tendencia: los atacantes no solo cambian infraestructura o payload, sino que refinan el método para aumentar la dificultad de detección. En particular, al pasar de esconder datos en entornos más rastreables a codificarlos en direcciones de transferencias vacías y no reutilizadas, el patrón visible para los defensores se reduce.
En términos prácticos, esto obliga a los equipos de seguridad a ampliar la vigilancia. No basta con buscar “código embebido” en un contrato o en calldata; también hay que prestar atención a cómo algunos paquetes pueden extraer información indirectamente desde la estructura de direcciones y transacciones.
Qué pueden hacer los equipos para reducir el riesgo
Aun cuando los paquetes ya fueron retirados de npm, la lección es clara: en entornos con dependencias de terceros, el riesgo no termina con el cierre del paquete. Para reducir el impacto, conviene:
- Revisar proyectos que hayan instalado dependencias desde npm alrededor de la fecha del incidente.
- Auditar el uso de librerías y verificar si existen llamadas inesperadas a red, decodificación de datos o lógica que interactúe con blockchain.
- Aplicar principios de mínimo privilegio y bloquear la ejecución de código no confiable donde sea posible.
- Monitorear indicadores de compromiso relacionados con conexiones a IPs o patrones de red inusuales.
Si bien este artículo no sustituye un análisis forense, ofrece un marco para entender por qué algunos ataques modernos se apoyan en técnicas “menos evidentes” y cómo esas decisiones alteran el tipo de señales que se deben buscar.
Conclusión
NullReceiver en npm muestra una evolución en el uso de blockchain para ocultar comunicación C2. En lugar de depender de un destino fijo o de incrustar información en campos más evidentes, el método codifica la IP del servidor dentro de bytes de la dirección destino de una transferencia Ethereum con forma mínima. Como además no reutiliza direcciones, el patrón para detección y atribución se vuelve menos directo.
Con paquetes como bianira-ui y fluid-type-ui retirados de npm, el enfoque más importante ahora es aprender del mecanismo: reforzar la auditoría de dependencias y mejorar la capacidad de detectar comportamientos que derivan información de transacciones y direcciones, incluso cuando la transacción no contiene “carga” visible.
Fuente: https://thehackernews.com/2026/08/trojanized-npm-packages-decode-c2-ip.html
