### Versiones Comprometidas **Socket** y **StepSecurity** han identificado tres versiones maliciosas del paquete **node-ipc**: * [email protected] * [email protected] * [email protected] Estas versiones contienen un comportamiento ofuscado de robo/backdoor diseñado para identificar el entorno del host, enumerar y leer archivos locales, comprimir y dividir los datos recopilados, envolver el payload en un sobre criptográfico e intentar la exfiltración a través de un endpoint de red seleccionado mediante lógica de DNS/dirección. ### Exfiltración de Secretos El código malicioso intenta exfiltrar una amplia gama de secretos de desarrolladores y de la nube a un servidor externo de comando y control (C2). Esto incluye más de 90 categorías de credenciales, como **Amazon Web Services**, **Google Cloud**, **Microsoft Azure**, claves SSH, tokens de Kubernetes, configuraciones de GitHub CLI, configuraciones de Claude AI y Kiro IDE, estado de Terraform, contraseñas de bases de datos e historial de shell. Los datos cosechados se comprimen en un archivo GZIP y se transmiten al dominio `sh.azurestaticprovider[.]net`. ### Compromiso de Cuentas Las versiones comprometidas fueron publicadas por una cuenta llamada "atiertant", que no está conectada con el autor original del paquete, "riaevangelist". La cuenta "atiertant" no tenía historial de publicaciones previo relacionado con el paquete **node-ipc**, lo que sugiere un posible compromiso de cuenta o una adición maliciosa como mantenedor. ### Análisis Técnico  A diferencia de los ataques típicos que dependen de los hooks del ciclo de vida de NPM, este ataque anexa el payload malicioso como una Expresión de Función Invocada Inmediatamente (IIFE) al final de `node-ipc.cjs`, lo que hace que el malware se ejecute incondicionalmente al hacer `require('node-ipc')`. La versión 12.0.1 incluye una verificación de huella digital SHA-256, comparándola con un hash codificado. Esto significa que la versión 12.0.1 solo está activa en máquinas donde la ruta del módulo principal coincide con el hash objetivo. Las versiones 9.x carecen de esta puerta y ejecutarán el payload completo en cualquier sistema que las cargue. ### Técnicas Anti-Detección El malware emplea un canal de exfiltración secundario utilizando registros DNS TXT después de anular el resolvedor DNS del sistema con DNS Público de **Google** para eludir la seguridad basada en DNS local. Resuelve `sh.azurestaticprovider.net` utilizando 1.1.1.1 (primario) o 8.8.8.8 (secundario) para obtener la IP del C2, y luego apunta directamente al resolvedor en la IP del C2 para todas las consultas de exfiltración. Este DNS directo a C2 es una técnica anti-detección notable, ya que las consultas de exfiltración nunca tocan los resolvedores DNS públicos, lo que hace que la actividad sea invisible para las organizaciones que dependen únicamente del registro DNS a través de resolvedores corporativos. Además, el malware intenta continuar la ejecución de forma independiente bifurcándose en procesos hijos en segundo plano desconectados, lo que permite que la exfiltración persista incluso después de que la aplicación principal termine. ### Implicaciones "Esta campaña refleja cómo los ataques a la cadena de suministro de software están evolucionando más allá de simples paquetes maliciosos hacia operaciones de recolección de credenciales conscientes de la infraestructura", dijo Avital Harel, líder de investigación de seguridad en **Upwind**. "Los atacantes se dirigen cada vez más a las identidades y los sistemas de automatización que impulsan las tuberías de entrega de software modernas, al tiempo que diseñan malware específicamente para integrarse en el comportamiento normal de los desarrolladores y las aplicaciones." ### Recomendaciones Se aconseja a los usuarios que: * Eliminen las versiones comprometidas de **node-ipc** y reinstalen una versión limpia conocida (9.2.1 y 12.0.0). * Asuman el compromiso y roten las credenciales y secretos. * Auditen la actividad de publicación de NPM para cualquier paquete accesible con los tokens rotados. * Revisen los registros de ejecución de flujos de trabajo en busca de actividad sospechosa. * Auditen los registros de la nube para verificar acciones no autorizadas realizadas por identidades IAM cuyas credenciales estuvieron disponibles durante la ventana comprometida. * Bloqueen el tráfico saliente al dominio C2.