@apexacc/cli: paquete npm malicioso instala un infostealer en Windows

Crédito por delante: los hallazgos de este artículo son de Elastic Security Labs. Resumimos su investigación en curso sobre un paquete npm malicioso porque es un patrón que conviene reconocer antes de ejecutar npx contra algo desconocido, no porque hayamos verificado la cadena por nuestra cuenta. Elastic habla de una investigación activa, así que trata los detalles de abajo como su valoración actual, no como un caso cerrado.

Qué encontró Elastic

Elastic Security Labs investiga @apexacc/cli, un paquete npm cuyo comportamiento, según su valoración inicial, cambia drásticamente en Windows. En esa plataforma:

• Modifica configuraciones del registro ligadas a Windows Smart App Control
• Añade exclusiones del antivirus
• Intenta elevar privilegios mediante UAC
• Ejecuta PowerShell codificado en Base64

Nada de eso es un comportamiento que necesite una herramienta CLI legítima. Smart App Control y las exclusiones del antivirus existen precisamente para impedir que código desconocido se ejecute sin control; desactivarlos desde un postinstall de npm o un paso invocado por la CLI es una señal fuerte de que el resto de la cadena está diseñado para evadir la detección, no para ofrecer una función del producto.

La cadena, de principio a fin

El triaje completo de Elastic rastrea una cadena de varias etapas en la ruta de Windows:

1. El paso de «verificación» del paquete llama a vrf.apexaccs[.]org
2. Ese endpoint devuelve comandos que desencadenan la ejecución de más PowerShell codificado
3. El PowerShell lleva a un binario de Python compilado, empaquetado con PyInstaller
4. Ese binario está ofuscado con PyArmor, un framework comercial de ofuscación de Python usado específicamente para resistir la descompilación y el análisis estático
5. La ejecución acaba pasando a un cargador de shellcode escrito en Go
6. El componente final que instala ese cargador muestra fuertes características de infostealer

Vale la pena detenerse en el encuadre de «verificación»: un paso que consulta a un servidor antes de decidir qué ejecutar es una forma habitual de esconder la carga maliciosa detrás de una comprobación del entorno, sirviendo algo inofensivo (o nada) a investigadores y escáneres automáticos que no encajan con el perfil esperado y la carga real a los objetivos previstos. Es la misma idea general (entrega condicional de la carga según la huella del entorno) documentada en otras campañas recientes de npm, aunque la mecánica concreta difiera.

Cronología

Elastic ha dicho que actualizará su hilo a medida que avance la investigación; este artículo refleja lo que habían publicado al momento de escribirlo, no necesariamente la última palabra. Si npm retira el paquete o Elastic publica un análisis más completo, toma esa actualización como la referencia por encima de este resumen.

Campañas y técnicas relacionadas

El hilo de Elastic apunta a variantes de esta campaña y técnica en otros lugares. Dos que conviene conocer:

• El análisis de SafeDep sobre @copilot-mcp/apex: una campaña relacionada pero distinta, de un operador con la marca «Apex Foundation», dirigida específicamente a macOS, con su propia infraestructura C2 y un patrón de cambio de marca tras la retirada (el mismo dropper se volvió a publicar con otro nombre de paquete horas después de que npm retirara el primero). No es la misma cadena técnica que la ruta de Windows descrita arriba, pero pertenece al mismo grupo más amplio con la marca «Apex» que vale la pena vigilar.
• Otra observación relacionada señalada en el hilo de Elastic, que documenta más coincidencias de técnica.

No afirmamos que todos sean el mismo actor de amenaza: esa conexión la deben confirmar o descartar Elastic, SafeDep y la propia investigación de npm. Lo que está claro es que paquetes con la marca «Apex» que prometen herramientas de Web3/IA han aparecido más de una vez este año con cargas de robo de credenciales detrás.

Qué revisar ahora mismo

1. No instales ni ejecutes con npx @apexacc/cli «solo para ver qué hace»: el paso de verificación por sí solo basta para disparar la cadena en un objetivo que encaje.
2. Si ya se ejecutó en un host Windows, revisa el estado de la política de Smart App Control y la lista de exclusiones de tu antivirus en busca de cambios inesperados, y busca conexiones salientes a apexaccs[.]org en los logs del proxy/DNS.
3. Trata una coincidencia como un host comprometido, no como un paquete que desinstalar. La cadena termina en un infostealer: asume que las credenciales y los datos del navegador y de sesión de esa máquina deben rotarse, no solo que hay que quitar el paquete.
4. Revisa los scripts postinstall/preinstall antes de ejecutar npm install sobre paquetes desconocidos o publicados recientemente: es exactamente el gancho del que depende esta familia de ataques.
5. Fija las versiones de las dependencias en lugar de aceptar rangos flotantes de publicadores de baja reputación, para que una versión posterior comprometida o maliciosa no llegue en silencio a tu build.

El escáner de paquetes npm de PlayCISO revisa los hooks postinstall, las cargas codificadas y los indicadores maliciosos conocidos de un paquete antes de instalarlo. Si ya tienes un dominio o un hash de archivo de un incidente y quieres una comprobación rápida de reputación, el verificador de reputación (basado en VirusTotal) cubre hashes, URL, dominios e IP.

Preguntas frecuentes

¿Qué es @apexacc/cli y por qué es peligroso? Es un paquete npm que, según la investigación en curso de Elastic Security Labs, se comporta de forma muy distinta según el sistema operativo. En Windows modifica configuraciones del registro ligadas a Smart App Control y a las exclusiones del antivirus, intenta elevar privilegios saltándose UAC y ejecuta PowerShell codificado en Base64; nada de eso lo necesita una herramienta CLI para su función legítima.

¿Qué hace realmente la cadena de infección en Windows? Según Elastic: el paquete llama primero a un endpoint de «verificación» en vrf.apexaccs[.]org, que responde con comandos que desencadenan más PowerShell codificado. Ese PowerShell lleva a un binario de Python (empaquetado con PyInstaller y ofuscado con PyArmor), que pasa la ejecución a un cargador de shellcode en Go. La carga final muestra fuertes características de infostealer.

¿Sigue disponible @apexacc/cli en npm? Según el reporte de Elastic, sí: se descubrió en julio de 2026 y seguía publicado al momento de escribir. Elastic dice que lo reportó a npm y que la investigación continúa; es una noticia en desarrollo, así que consulta la base de avisos de npm y el hilo de Elastic para conocer el estado más reciente.

¿Es la misma campaña que el infostealer de macOS @copilot-mcp/apex? Relacionada pero distinta. SafeDep documentó @copilot-mcp/apex (y su predecesor @apexfdn/apex) como una campaña separada centrada en macOS, de un operador con la marca «Apex Foundation» y con una infraestructura C2 diferente de la cadena de Windows que describe Elastic. Ninguno de los dos reportes confirma si comparten operador.

¿Qué deberían hacer ahora los desarrolladores y los equipos de seguridad? No ejecutes @apexacc/cli ni lo lances con npx para comprobarlo. Si ya se ejecutó en un host Windows, revisa los cambios en Smart App Control y en las exclusiones del antivirus, busca conexiones a apexaccs[.]org y trata el host como potencialmente comprometido, no solo el paquete como algo que quitar. Revisa los scripts postinstall antes de instalar paquetes desconocidos y fija las versiones de las dependencias.