Investigadores de seguridad han documentado una nueva campaña de ataques en la que se utiliza la herramienta open source Nezha, una utilidad legítima de monitoreo de servidores y gestión de tareas, como parte de una sofisticada cadena de ataque.
Infiltración con Nezha
- Vector de Acceso Inicial: En las campañas detectadas (principalmente dirigidas a organizaciones en Taiwán, Japón, Corea del Sur y Hong Kong), los atacantes primero ganan acceso a aplicaciones web vulnerables (por ejemplo, a través de paneles phpMyAdmin expuestos).
- Implantación de Web Shell: Utilizan técnicas creativas, como la inyección de código malicioso en los logs del servidor (log poisoning), para implantar un web shell (como AntSword).
- Despliegue de Nezha: Una vez que el web shell les da control inicial, los atacantes descargan e instalan el agente open source de Nezha.
- Control Remoto Disfrazado: Nezha, que se comercializa como una herramienta ligera de administración de sistemas, es reutilizada para funcionar como un control remoto (Remote Access Trojan) disfrazado. Permite a los atacantes ejecutar comandos a nivel de servidor desde una plataforma centralizada (el dashboard de Nezha) en la infraestructura de los atacantes.
Escalada del Ataque
El uso de Nezha no es el fin, sino la vía para una mayor intrusión. Una vez instalado, los atacantes usan el agente de Nezha para:
- Deshabilitar Defensas: Ejecutar comandos de PowerShell que deshabilitan el scanning de software de seguridad (como Windows Defender).
- Desplegar Malware Final: Instalar malware de mayor impacto, como variantes conocidas de Ghost RAT, para establecer persistencia y exfiltrar datos.
Tácticas de Adaptación Ofensiva
- Modificación de Utilitarios Legítimos: Proyectos de open source con funciones legítimas (como scripts de automatización, frameworks de monitoreo o utilitarios de administración) son alterados para incluir módulos maliciosos, backdoors o capacidades ocultas.
- Parcheo Dinámico y Distribución Maliciosa: Los atacantes distribuyen estas versiones alteradas como forks (versiones derivadas) o paquetes “mejorados”. Los desarrolladores o usuarios legítimos pueden instalarlas pensando que son una actualización, sin saber que integran código ofensivo.
- Ensamblaje Modular: Los atacantes combinan múltiples módulos de open source legítimos para construir cargas maliciosas complejas, agregando solo la lógica extra necesaria (como exfiltración o persistencia). Esto reduce drásticamente el esfuerzo de desarrollo de un malware completo.
- Ocultamiento en Bibliotecas Comunes: El código malicioso se esconde dentro de librerías que son parte del ecosistema habitual (paquetes pip, módulos node_modules), pasando desapercibido en auditorías superficiales.
Peligros que no se mencionan
- Confianza explotada
Los usuarios y desarrolladores suelen confiar en proyectos reconocidos o ampliamente usados. Cuando esos proyectos son adaptados maliciosamente, esa confianza se vuelve riesgo. - Escalabilidad del ataque
Si el ataque se esconde en una biblioteca ampliamente usada (por ejemplo, en frameworks web), un solo cambio malicioso puede afectar múltiples organizaciones que usan esa dependencia. - Difícil atribución
Al usar código open source ampliamente disponible, es más difícil rastrear al autor del cambio malicioso o identificar su origen exacto. - Evasión de herramientas de seguridad
Muchas soluciones de detección (antivirus, scanners) confían en firmas de malware conocidas. Código modificado a partir de herramientas legítimas con ligeros cambios puede evadir esas firmas. - Ecosistema abierto como vector de proliferación
Que el software comunitario esté expuesto a cambios maliciosos debilita toda la cadena de suministro: no solo una aplicación, sino muchas pueden verse afectadas.
Recomendaciones
- Auditar las dependencias y librerías
- Revisar versiones de librerías externas usadas, especialmente forks desconocidos.
- Escanear los cambios recientes en dependencias (commits recientes, diferencias).
- Utilizar herramientas como Snyk, Dependabot, o escáneres de dependencias para detectar modificaciones maliciosas.
- Verificar la integridad del código
- Comparar hashes de librerías instaladas con las versiones oficiales.
- Verificar metadatos, firmas digitales, fechas de compilación.
- Restringir la instalación de paquetes no autorizados
- Prohibir instalar dependencias de fuentes no confiables o no auditadas.
- Usar repositorios internos controlados cuando sea posible.
- Monitorización de comportamiento anómalo
- Alertas cuando módulos comunes comiencen a hacer conexiones salientes extrañas, cargar código dinámico o exfiltrar datos.
- Observación de usuarios o procesos que se aprovechan de funciones ocultas en librerías.
- Separar y aislar módulos críticos
- Que las funciones sensibles (por ejemplo, acceso a datos sensibles) no dependan directamente de librerías externas sin control.
- Limitar el uso de bibliotecas de terceros dentro de contextos críticos.
- Revisión continua y tests de seguridad
- Incluir auditoría de código (code review) para cualquier cambio de librería o dependencia nueva.
- Realizar pruebas de pentesting enfocadas en cadenas de librerías open source dentro del software propio.
Referencias
The Hacker News. (2025, 6 de octubre). Chinese hackers weaponize open-source tools in targeted cyber attacks. https://thehackernews.com/2025/10/chinese-hackers-weaponize-open-source.html
Microsoft Threat Intelligence. (2025, 24 de septiembre). AI vs. AI: Detecting an AI-obfuscated phishing campaign. https://www.microsoft.com/en-us/security/blog/2025/09/24/ai-vs-ai-detecting-an-ai-obfuscated-phishing-campaign
Help Net Security. (2025, 25 de septiembre). Microsoft descubre ataque de phishing ofuscado con IA mediante archivos SVG. https://www.helpnetsecurity.com/2025/09/25/microsoft-spots-llm-obfuscated-phishing-attack
Cybersecurity News. (2025, 2 de octubre). ChatGPT vulnerability lets attackers embed malicious SVGs & images in shared chats. https://cybersecuritynews.com/chatgpt-vulnerability-malicious-images
