Campaña explota CVE-2026-90436 en N-able N-central para minar XMRig; mitigaciones en curso

Esta semana se reportó una campaña activa que explota nuevas vulnerabilidades en N-able N-central identificadas como 4EverAble2Shell y Agent2Shell. N-able confirmó que está tomando medidas preventivas temporales —como desactivar la API Legacy por defecto, suspender la integración con Intune y pedir la actualización obligatoria de Agents y Probes a la versión 2026.4 HF1— mientras sigue desarrollando remediaciones adicionales. Investigadores independientes y empresas de inteligencia de amenazas han documentado intentos de explotación que terminan, en al menos varios casos verificados, con la instalación de un minero de criptomoneda (XMRig) en servidores N-central comprometidos.

En términos técnicos, los reportes describen un exploit encadenado: primero se aprovecha una vulnerabilidad crítica en el componente Apache Axis que maneja SOAP (identificada en informes como CVE-2026-90436) para lograr ejecución remota no autenticada en la aplicación N-central. Ese fallo permite forzar la instanciación de clases inseguras durante el procesamiento de errores SOAP; un atacante puede inducir a que se ejecute una clase de la biblioteca JLine con entrada maliciosa que termina ejecutando comandos como el usuario del servicio nable. A partir de ahí, según las firmas de inteligencia, actores han usado una vulnerabilidad de escalada de privilegios adicional en N-central para elevar a root en sistemas Linux gestionando clientes, y en escenarios específicos para obtener SYSTEM en máquinas Windows gestionadas por esos servidores.

Hechos confirmados: N-able publicó una actualización de estado en la que enumera acciones temporales (Legacy API desactivada por defecto, Intune apagada en Hosted, y petición de actualizar Agents y Probes a 2026.4 HF1) y advierte que la restauración de funcionalidad será gradual. Investigadores como Sean Bales y varias firmas de ciberinteligencia (entre ellas reportes mencionados públicamente por empresas como Huntback y Previdian) han divulgado cadenas de explotación y muestras de actividad maliciosa, incluyendo la descarga de un script remoto ("jup.sh") desde el IP 157.20.241[.]16 y la posterior ejecución de un minero XMRig. Huntback documentó despliegues activos del minero en servidores de distintos países.

Estimaciones y elementos todavía inciertos: la magnitud exacta del alcance de la campaña (número total de servidores afectados), la identidad o la motivación de los atacantes, y si las intrusiones se limitan a despliegues de criptomineros o incluyen otras cargas útiles y exfiltración, siguen siendo inciertas. También hay reportes que indican que algunas víctimas ya tenían instaladas actualizaciones (por ejemplo, Hotfix 2) pero aun así fueron comprometidas; eso sugiere que la protección completa requiere acciones combinadas (actualización de servidor + Agents/Probes + desactivación de APIs), pero los límites exactos de mitigación todavía se están confirmando.

¿A quién afecta esto? Principalmente a proveedores de servicios gestionados (MSP) y a sus clientes que utilizan N-able N-central para administrar infraestructuras y endpoints. Un servidor N-central comprometido no es una máquina aislada: gestiona agentes en decenas, cientos o miles de endpoints. Con control root/SYSTEM sobre el servidor de gestión, un atacante puede desplegar código malicioso a todos los endpoints gestionados, manipular políticas, robar credenciales o provocar interrupciones masivas. Además de la amenaza técnica, las empresas sufren riesgo reputacional y posibles obligaciones regulatorias si clientes quedan expuestos o datos son exfiltrados.

Consecuencias reales y riesgos derivados: recursos consumidos por minería (impacto en rendimiento y costes), pérdida de integridad del entorno de gestión, posibilidad de movimiento lateral hacia redes de clientes, y riesgo de persistencia que haga inútiles limpiezas parciales. Firmas que analizaron incidentes recomiendan tratar cada compromiso como una pérdida total de confianza en la máquina afectada —no como un simple incidente «de limpieza»— y considerar recrear y reprovisionar los servidores afectados.

Qué debe hacer ahora un responsable técnico o administrador que use N-central (pasos concretos y priorizados):

1) Siga las instrucciones oficiales de N-able inmediatamente. Si está en un entorno Hosted, verifique las actualizaciones del proveedor y confirme si su instancia ha sido objeto de medidas específicas. Sitios de soporte de N-able: https://www.n-able.com/ y su portal de soporte (contacte al soporte técnico oficial para instrucciones puntuales).

2) Para entornos on-premises: desactive cualquier acceso a la Legacy API si estaba habilitado y actualice el servidor N-central a 2026.4 HF1 o la versión que N-able recomiende como mínima. Asegúrese además de actualizar simultáneamente Agents y Probes; N-able ha señalado que la comunicación entre Probe y Agent cambia con la actualización y que ambos deben actualizarse para mantener gestión funcional.

3) Presuma compromiso si hay signos de explotación. Indicadores observados incluyen conexiones de salida hacia 157.20.241[.]16 y la descarga/ejecución de scripts como jup.sh; procesos XMRig corriendo (busque procesos con nombres como xmrig), remounts de /tmp a exec, cronjobs sospechosos, y scripts en /tmp o /var/tmp. Bloquee a nivel de firewall las IPs involucradas mientras investiga.

4) Realice contención y respuesta forense. Aísle servidores comprometidos de la red, preserve logs (syslog, logs de N-central, registros de Agents), y recabe artefactos para análisis forense. Busque persistencias (servicios nuevos, usuarios, tareas programadas), revisiones de integridad de binarios, conexiones salientes y cambios en claves/credenciales. Si hay indicios de escalada a root o SYSTEM, planifique una reconstrucción completa del servidor afectado y no confíe en parches aislados como único remedio; considere restaurar desde imágenes conocidas limpias.

5) Revise y rote credenciales y certificados vinculados al servidor de gestión. Cambie contraseñas administrativas, claves de API, y cualquier secreto que el servidor N-central pudiera exponer; controle accesos remotos y reduzca privilegios a lo estrictamente necesario.

6) Active monitoreo y medidas de detección adicionales. Añada reglas de detección para tráfico inusual, picos de CPU en servidores de gestión, y patrones de comportamiento de XMRig. Revise integraciones activas (Intune, otras API) y manténgalas deshabilitadas hasta que N-able confirme seguridad y restauración.

7) Si hay dudas o impacto, escale a respuesta profesional y notifique a clientes según sus obligaciones legales y contractuales. Contar con un equipo de respuesta a incidentes externo acelera el análisis de alcance y la contención.

Para entender mejor la raíz técnica del problema puede consultarse la documentación del proyecto Apache Axis (componente implicado en la cadena de explotación): https://axis.apache.org/, y para análisis de campañas y detección, firmas de ciberinteligencia como Huntback han publicado investigaciones relevantes sobre despliegues activos que conviene revisar: https://huntback.io/.

En resumen, la recomendación inmediata es actuar como si cualquier servidor N-central expuesto pudiera haber sido comprometido, seguir las guías oficiales de N-able y ejecutar una respuesta forense completa antes de restaurar su confianza operativa. Las actualizaciones y desactivaciones temporales que aplica el fabricante son pasos adecuados, pero no sustituyen a la contención, la inspección detallada y, en los casos confirmados, la reconstrucción de sistemas afectados.