La Amenaza de Envenenamiento SEO y C2 en Blockchain que Apunta a Administradores con MSI Falsos

Un esquema sofisticado descubierto por el equipo de investigación de amenazas de Atos en marzo de 2026 demuestra cómo actores maliciosos están pasando a la ofensiva contra cuentas de alto privilegio mediante una combinación de técnicas clásicas y recursos de resiliencia modernos: envenenamiento SEO, una arquitectura de distribución en dos fases en GitHub y una resolución de mando y control (C2) anclada en la cadena de bloques pública. El objetivo no es el usuario promedio: buscan deliberadamente a administradores, ingenieros DevOps y analistas de seguridad a través de instaladores MSI que se hacen pasar por utilidades administrativas legítimas.

La campaña explota la confianza implícita en los resultados de búsqueda. Mediante SEO poisoning, los atacantes logran que repositorios de fachada en GitHub —limpios, con README profesionales y bien indexados— aparezcan en los primeros lugares para búsquedas de herramientas especializadas. Esos repositorios actúan como escaparates y redirigen discretamente al usuario a un segundo repositorio oculto que aloja el instalador real. Separar la visibilidad pública de la entrega del payload permite rotar la infraestructura de distribución sin perder posicionamiento en buscadores, lo que dificulta las acciones de mitigación basadas únicamente en cierres de cuentas o eliminación de repositorios.

Técnicamente, los instaladores identificados son MSI que disparan un script por lotes ofuscado, descargan el runtime de Node.js desde su canal oficial y despliegan una cadena multinivel de cargas útiles JavaScript cifradas con AES-256-CBC. La persistencia se logra mediante claves Run del registro con nombres aleatorios, y el proceso malicioso corre dentro de procesos legítimos (p. ej. conhost.exe con parámetros que intentan ocultarlo). El comportamiento final es el de un RAT en memoria capaz de reescribirse a sí mismo y ejecutar código remoto de forma dinámica, lo que complica la detección mediante firmas estáticas.

El componente que da verdadero valor estratégico a esta operación es la resolución de C2 mediante contratos inteligentes en Ethereum: el malware consulta públicamente varios endpoints RPC de Ethereum para leer el valor almacenado en un contrato y así obtener la URL del servidor de mando. Al actualizar ese único dato en la cadena, el adversario redirige todas las infecciones sin tocar los binarios desplegados. Esto convierte la blockchain en un dead-drop público, altamente disponible y resistente a bloqueos por dominio o IP. Para entender el mecanismo técnico subyacente puede consultarse la documentación sobre nodos y clientes de Ethereum en ethereum.org.

Las implicaciones operativas son graves: al apuntar a herramientas que solo usan usuarios con permisos elevados, cada infección tiene una probabilidad elevada de convertirse en «llaves del reino» dentro de una organización. Además, la campaña prioriza la paciencia y el sigilo —post-explotación manual, reconocimiento silencioso y movimientos laterales medidos— lo que incrementa el riesgo de accesos prolongados y exfiltración dirigida.

Detectar esta amenaza exige mirar más allá de indicadores estáticos. Telemetrías útiles incluyen la aparición de procesos node.exe que ejecutan comandos del sistema, conhost.exe lanzado con argumentos inusuales como «--headless», escrituras periódicas en ficheros de traza locales (por ejemplo svchost.log en %APPDATA%), y tráfico saliente hacia servicios RPC públicos de Ethereum. Revisar historiales de egress y registros DNS/HTTP hacia gateways RPC públicos es crítico para descubrir infecciones pasadas.

En cuanto a mitigación práctica, conviene aplicar controles de egress para bloquear o inspeccionar el acceso a los gateways RPC públicos usados para consultar Ethereum, implementar políticas de allowlisting para descargas de software en estaciones administrativas, y centralizar las fuentes de software en catálogos internos o portales de proveedor verificados. La descarga dinámica de Node.js desde su web oficial por parte del instalador malicioso subraya la necesidad de restringir qué sistemas pueden acceder libremente a internet para recuperar runtimes externos; por ejemplo, el sitio oficial de Node.js es nodejs.org, pero su uso debe estar sujeto a control y monitoreo dentro del perímetro corporativo.

También es recomendable endurecer el acceso administrativo con segmentación de red, cuentas con privilegios mínimos, autenticación multifactor sólida y rotación frecuente de credenciales. Desde la detección, las reglas de EDR deberían buscar patrones como ejecuciones repetidas y periódicas (cada ~5 minutos) a endpoints inusuales, parent-child anomalies donde node.exe invoca shells, y la presencia de claves Run con nombres generados aleatoriamente. No delegue la verificación de herramientas críticas a un simple resultado de búsqueda: fomente el uso de repositorios internos firmados y verificados.

En el plano de respuesta y coordinación, los equipos defensivos deben combinar acciones técnicas con proveedores y plataformas (por ejemplo, solicitar la retirada de repositorios maliciosos en GitHub) y trabajar con CSIRTs y autoridades para perseguir la infraestructura en la medida de lo posible. No obstante, hay que reconocer que la naturaleza descentralizada del vector C2 limita la eficacia de las contramedidas tradicionales y obliga a medidas defensivas en capas.

Sobre atribución, hay reportes de solapamientos técnicos entre este módulo «EtherHiding» y trabajos previos vinculados por diferentes equipos a actores estatales. Sin embargo, reutilización de código y técnicas entre grupos es común; la evidencia técnica por sí sola no debe llevar a conclusiones apresuradas de atribución sin un conjunto amplio de corroboraciones.

Finalmente, la comunidad defensiva debe considerar este caso como un recordatorio de que la cadena de suministro humana comienza en los motores de búsqueda y termina en la máquina con privilegios. Adoptar controles de telemetría, restringir egress hacia infraestructuras descentralizadas no supervisadas y entrenar al personal administrativo para verificar la procedencia del software son acciones urgentes. Para entender mejor las medidas de seguridad en la cadena de suministro de software y colaborar en mitigaciones, la guía de GitHub sobre seguridad de la cadena de suministro es un buen punto de partida: Guía de seguridad de la cadena de suministro (GitHub). En entornos donde existan dudas sobre comunicaciones históricas, un análisis forense de los logs y la colaboración con equipos como CSIRT y proveedores de seguridad gestionada serán claves para contener y erradicar esta amenaza.