Parchear no bastó. Dos días después del parche de emergencia de N-able para la oleada de zero-days de N-central, el investigador Sean Bales divulgó dos nuevas cadenas —4EverAble2Shell y Agent2Shell— probadas contra la versión ya parcheada. En cuestión de horas, atacantes reales explotaban la primera: al menos 21 servidores N-central en producción quedaron comprometidos, y 19 de ellos ya tenían instalado el último hotfix.
Qué ha pasado
El 12 de noviembre, Bales publicó las pruebas de concepto (PoC) de dos cadenas de ataque contra N-central, la plataforma de monitorización y gestión remota (RMM) que usan miles de proveedores de servicios gestionados (MSP) para administrar los equipos de sus clientes. 4EverAble2Shell permite a un atacante sin autenticar ejecutar comandos como root en el servidor, y Agent2Shell permite ejecutar comandos con privilegios SYSTEM en equipos Windows gestionados.
Previdian detectó los primeros sondeos contra su honeypot a las 08:30 UTC del 12 de noviembre, horas después de la publicación del PoC; a las 09:16 UTC ya se observaban intentos de ejecutar la cadena completa. A las 12:50 UTC de ese mismo día, Huntback contabilizaba 21 mineros activos en servidores comprometidos, todos con actividad en los cinco minutos anteriores. Los afectados están repartidos por Estados Unidos, Canadá, Sudáfrica, Reino Unido, Alemania, Francia y Suecia: es una campaña de barrido contra cualquier N-central expuesto.
Cómo funciona la cadena
4EverAble2Shell combina dos piezas. Primero, CVE-2026-90436 (CVSS 9.8), una vulnerabilidad crítica en el componente Apache Axis 1.x que N-central lleva integrado: una petición SOAP manipulada permite ejecutar comandos como la cuenta de servicio nable. Después, una escalada de privilegios propia de N-central (Previdian la registra como VULN-2026-0009) abusa del helper setLDFileOwner y de un enlace simbólico para hacer escribible un script que pertenece a root, y lo ejecuta a través de la funcionalidad serverControl, obteniendo acceso root completo.
Según N-able, la explotación requiere que la Legacy API esté habilitada y expuesta a internet, una configuración no predeterminada. Pero Huntback no ha confirmado si los 21 servidores comprometidos la tenían activada.
El payload: mineros de Monero… por ahora
El payload observado es un minero XMRig de Monero, descargado desde 157.20.241.16 (archivo jup.sh) y configurado para usar la mitad de los núcleos de CPU, probablemente para pasar desapercibido.
Pero el minero no debe tranquilizar: la escalada entrega root en el host que gestiona los endpoints de los clientes, así que puede ser solo la primera fase —o la tapadera— de algo peor.
La respuesta de N-able (y su contradicción)
N-able publicó un aviso el 12 de noviembre con medidas adicionales mientras prepara las correcciones definitivas: la API Legacy queda desactivada por defecto en los entornos alojados, la integración con Intune queda desactivada como precaución, y se insta a los clientes on-premises a verificar que la Legacy API está desactivada y a actualizar agentes y sondas a N-central 2026.4 HF1 o superior.
Sin embargo, en ese mismo aviso la compañía afirmó no haber visto indicios de compromiso. Esa afirmación quedó desmentida el mismo día por Previdian y Huntback, que documentaron explotación activa, y la madrugada del 13 de noviembre la propia N-able reconoció en su panel de estado haber identificado indicadores de compromiso adicionales y estar trabajando con los clientes afectados.
Es la segunda oleada en una semana: el 10 de noviembre N-able ya tuvo que parchear de emergencia y apagar sus entornos alojados tras la divulgación de más de 30 supuestos zero-days (la saga «Able2Shell», que ya cubrimos en este blog).
Qué hacer si usas N-central
- Desactiva la Legacy API si la tienes habilitada. Es la condición que N-able señala como necesaria para la explotación; verifícalo, no lo asumas.
- Actualiza agentes y sondas a N-central 2026.4 HF1 o superior. El hotfix 2 no corrige estas cadenas, pero N-able insiste en que es imprescindible para que los dispositivos gestionados se comuniquen y se parcheen.
- Busca los indicadores de compromiso: peticiones a /dms/services/ServerUI que referencien jline.internal.TerminalLineSettings, descargas desde 157.20.241.16 (script jup.sh), servicios systemd llamados xvd.service, procesos de minería y archivos bajo /tmp/.xvd o /var/tmp/.xvd, y procesos Java de N-central lanzando shells, curl o wget.
- Si encuentras un indicio, trátalo como compromiso total del servidor, no como un incidente de minería. Con acceso root, el atacante ha podido robar credenciales, moverse a los endpoints gestionados o plantar persistencia. La limpieza superficial no basta: hay que reconstruir y rotar credenciales.
- Revisa la exposición a internet de tu consola N-central: un RMM nunca debería estar accesible sin restricciones.
El ángulo Blue Team: qué vigilaría un SOC
Tres lecciones. Primero, el parche del día 10 no cerró la historia: 19 servidores con HF2 instalado quedaron comprometidos, y la ventana entre divulgación y explotación se midió en horas. Segundo, los IOCs de red son tu mejor aliado: la petición a /dms/services/ServerUI con la clase JLine es un patrón muy específico y fácil de detectar en los logs del proxy o del WAF, igual que la IP 157.20.241.16 y el servicio xvd.service. Si aparecen, es compromiso, no ruido. Y tercero, vigila el comportamiento, no solo las firmas: un minero al 50% de CPU es un cambio de línea base sutil; monitoriza el consumo de CPU del servidor y alerta ante procesos hijo inesperados del proceso Java. Recuerda: en un RMM, el blast radius no es un servidor, son todos los clientes que gestiona.
Fuentes
- BleepingComputer — «New N-able ‘4EverAble2Shell’ zero-day exploited hours after PoC released» (12 de noviembre de 2026): https://www.bleepingcomputer.com/news/security/new-n-able-4everable2shell-zero-day-exploited-hours-after-poc-released/
- The Hacker News — «Hackers Exploit N-central Flaws to Infect 21 Servers, Including 19 Running Hotfix 2» (13 de noviembre de 2026): https://thehackernews.com/2026/11/hackers-exploit-n-central-flaws-to.html
- N-able — Aviso de seguridad del 12 de noviembre de 2026, con actualización del 13 de noviembre (panel de estado): https://uptime.n-able.com/event/202561/