Able2Shell: N-able desconectó N-central tras publicarse 33 fallos con exploit

El equipo de investigación de Tenable data a las 04:14 UTC del 9 de noviembre el primer commit de Able2Shell en GitHub. El repositorio describe 33 fallos en N-central, la plataforma de monitorización y gestión remota (RMM) de N-able, cada uno, según su autor, con una prueba de concepto. Once horas después, a las 15:15 UTC, N-able declaró un incidente activo y desconectó su N-central alojado en América, Europa y Asia-Pacífico, según GovInfoSecurity. A los clientes con servidores instalados en su infraestructura les pidió que también los apagaran hasta nuevo aviso.

El 10 de noviembre llegó N-central 2026.4 Hotfix 2 (compilación 2026.4.1.26) y la nube volvió a funcionar. Corrige siete CVE, detallados por The Hacker News. N-able no ha publicado qué entradas del repositorio cubren esos siete, y anuncia otro hotfix con más correcciones.

La vuelta del servicio no cerró el problema. Una plataforma capaz de ejecutar scripts con privilegios máximos en cada equipo que gestiona estuvo alrededor de un día con exploits públicos y sin parche, recibió una corrección parcial y acumula cinco vulnerabilidades en el catálogo KEV de CISA. Para quien la usa, o para quien contrata a un proveedor de servicios gestionados que la usa, queda una revisión pendiente. Y el 11 de noviembre el mismo investigador publicó exploits que, según él, funcionan contra ese parche.

¿Qué se publicó y qué ha confirmado N-able?

El repositorio lo firma una cuenta llamada Oracle-Security. SecurityWeek identifica como autor al investigador Sean Bales, que lo anunció en LinkedIn. Huntress agrupa los hallazgos en cuatro cadenas de ataque: tres terminan en ejecución remota de código y la cuarta en una escalada de privilegios hasta root. Las pruebas se hicieron sobre la versión preliminar 2026.4.0.31, y el autor cree que las anteriores también están afectadas.

Las clases de fallo son bien conocidas. Hay fallos de entidad externa XML (XXE) que permiten leer datos internos del servidor; inyección OGNL (el lenguaje de expresiones de la aplicación web); escritura de ficheros fuera de la ruta prevista, y un XSS almacenado que se activa cuando un administrador consulta los metadatos de un parche. Field Effect añade que algunas pruebas de concepto no exigen autenticación y que una de ellas permitiría manipular los registros de auditoría. Salvo lo que reconoce el hotfix, nada de esto se ha verificado de forma independiente.

Lo confirmado son los siete CVE del Hotfix 2, que Tenable puntúa entre 8,3 y 9,3 en CVSS v4. Un identificador agrupa varias XXE y otro varias inyecciones OGNL. El resto son una escalada a root a través de una configuración de syslog-ng que el usuario de servicio podía modificar y el XSS de los metadatos de parches. Completan la lista una falsificación de peticiones desde el servidor (SSRF) en la importación de servicios, una subida de ficheros con salto de directorio y canales de comunicación entre procesos sin protección. Ninguno figuraba en KEV cuando salió el parche, el 10 de noviembre.

¿Qué cambia con los exploits publicados contra el Hotfix 2?

A última hora del 11 de noviembre, Bales publicó dos nuevas colecciones de exploits, según la actualización del 12 de noviembre de Huntress. De acuerdo con su autor, 4EverAble2Shell encadena fallos hasta ejecutar código como root en el servidor N-central sin autenticarse. Agent2Shell reúne más de diez problemas en la comunicación del servidor con los agentes y sondas de Windows, y dos de sus cadenas permiten ejecutar órdenes como SYSTEM en los equipos gestionados; The Hacker News precisa que el atacante necesita conocer el identificador del equipo (appliance ID). Los dos funcionarían contra el Hotfix 2.

N-able y Huntress discrepan sobre el alcance. El fabricante, según The Hacker News, sostiene que el problema depende de una configuración no predeterminada: la Legacy API (la interfaz de programación heredada) activada y expuesta a internet. Pide desactivarla de inmediato y afirma que el servicio alojado no está afectado. Huntress no menciona esa condición. Trata como vulnerable cualquier servidor con el Hotfix 2 y recomienda volver a desconectar los servidores locales o, como mínimo, cortarles el acceso desde internet, sin confiar solo en una lista de IP permitidas.

watchTowr informó de intentos de usar 4EverAble2Shell contra instalaciones con la Legacy API activa, y Previdian, que ya había registrado actividad desde una IP a partir del 9, detectó esta vez sondeos dirigidos desde otra en las horas siguientes, según The Hacker News. A 12 de noviembre nadie ha confirmado una explotación con éxito ni hay parche para los fallos que aprovechan. Para un servidor local, lo prudente es sumar las dos recomendaciones: Legacy API desactivada y consola fuera del alcance de internet.

¿Por qué N-able desconectó tan rápido?

El código llegó antes que el parche

La divulgación coordinada suele dejar unos 90 días entre el aviso privado al fabricante y la publicación, recuerda GovInfoSecurity. Aquí el código salió primero. Según SecurityWeek, Bales justificó la publicación porque N-able no había corregido fallos que él mismo le comunicó antes en otro producto. El medio no recoge respuesta de la empresa sobre ese punto.

Intentos de explotación en cuestión de horas

The Hacker News recoge dos observaciones. watchTowr detectó intentos contra sus señuelos de N-central en las horas siguientes a la publicación, y Defused Cyber vio sondeos que abrían sesiones de agente anónimas, descargaban la configuración del equipo y llamaban sin autenticar al servicio de control remoto. Tenable añade que Previdian registró 68 eventos procedentes de una sola IP en su entorno señuelo a partir del 9 de noviembre.

N-able confirma escaneos ligados al código publicado. También afirma que no tiene pruebas de que ningún entorno de cliente resultara comprometido.

Cinco entradas en KEV en trece meses

N-central suma cinco entradas en el catálogo de CISA desde agosto de 2025, tres de ellas en algo más de cinco semanas de 2026. GovInfoSecurity contaba además el Hotfix 2 como el quinto parche de emergencia desde el 1 de agosto.

El precedente de agosto y septiembre

Durante la explotación de CVE-2026-86218, Huntress observó a los atacantes enviando scripts y herramientas no autorizados a las redes de los clientes gestionados. Un servidor RMM reparte software a decenas o cientos de organizaciones, lo que ayuda a entender por qué N-able optó por desconectar primero y parchear después. Un efecto multiplicador parecido se vio con la credencial comprometida de ConnectWise Cloud Backup, que alcanzó más de 300 inquilinos de Microsoft 365.

¿En qué se diferencia de hace un año?

Las dos primeras entradas de N-central en KEV son de agosto de 2025. Las tres siguientes llegaron entre el 3 de agosto y el 8 de septiembre de 2026, y, según Huntress, CVE-2026-18577 apareció porque el arreglo de CVE-2026-18556 había quedado incompleto. Para los proveedores gestionados, eso pudo suponer varias paradas fuera de calendario en pocas semanas.

El segundo cambio es el orden de los acontecimientos. Ian Thornton-Trump, CISO de Inversion6, lo describió ante GovInfoSecurity como un tipo de divulgación ligado a la IA, en el que las pruebas de concepto se publican sin esperar al parche. Es una opinión y no un dato, aunque encaja con la presión que ya reflejan los plazos de la BOD 26-04 de CISA, pensada para un mundo en el que la explotación llega en días.

¿Cómo afecta a la arquitectura de defensa?

Una consola RMM concentra buena parte de lo que un atacante busca después de entrar: credenciales de administración guardadas, cuentas de servicio, integraciones por API y la capacidad de ejecutar código como SYSTEM o root en cada equipo. Field Effect recomienda inventariar qué sistemas confían en N-central y hasta dónde llega ese acceso: controladores de dominio, virtualización, copias de seguridad, identidad, herramientas de seguridad.

La interfaz de gestión debería ser alcanzable solo desde una red de administración dedicada, como recomiendan Field Effect y N-able. Comprobarlo desde fuera es tarea básica de una revisión de la superficie de ataque.

Luego está la continuidad. Durante la desconexión, los clientes del servicio alojado perdieron la consola clásica, aunque seguían activos los servicios de Ecoverse bajo N-able Login, entre ellos la gestión de parches y el inventario, según The Hacker News. El Hotfix 2 desactiva además de forma temporal el control remoto integrado y elimina la gestión de móviles heredada, mientras que Take Control sigue operativo, según Tenable. Un proveedor gestionado que solo pueda llegar a sus clientes a través de la consola necesita tener escrito cómo trabaja sin ella.

Queda el lado de quien contrata. Una empresa cuyo soporte informático presta un proveedor con N-central tiene en sus equipos un agente con privilegios máximos administrado desde fuera. Esta semana toca preguntarle si aplicó el Hotfix 2, si desactivó la Legacy API, si su consola estaba expuesta desde el 8 de noviembre, qué encontró en los registros y si ha rotado las credenciales. Hacerlo forma parte de la gestión del riesgo de terceros, y las respuestas deben quedar por escrito.

¿Dónde buscar desde el 8 de noviembre?

Huntress y Tenable sitúan el inicio de la ventana de revisión el 8 de noviembre, un día antes de la publicación. Huntress pide además mirar con especial atención la actividad del servidor y de los equipos desde el 11, cuando aparecieron los exploits nuevos. En la consola hay que buscar inicios de sesión inesperados, cuentas de administrador nuevas, cambios de privilegios o de configuración, scripts desplegados y sesiones remotas anómalas. Beazley Security Labs y Previdian han publicado indicadores de compromiso de red que deben cruzarse con los registros del cortafuegos.

Como uno de los hallazgos publicados permitiría alterar los registros de auditoría, lo que muestre la consola no puede ser la única fuente. La telemetría EDR de los equipos gestionados, el cortafuegos perimetral y el proveedor de identidad sirven de contraste, porque quien controla la consola no controla necesariamente esos sistemas.

En Microsoft Defender for Endpoint, una consulta inicial localiza los intérpretes de comandos lanzados por el agente de N-central en los equipos gestionados durante la ventana. La ruta de instalación del agente varía, así que hay que ajustarla al entorno:

DeviceProcessEvents | where Timestamp > datetime(2026-11-08) | where InitiatingProcessFolderPath has "N-able Technologies" | where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe") | summarize Ejecuciones = count(), Equipos = dcount(DeviceId), Primera = min(Timestamp), Ultima = max(Timestamp) by FileName, ProcessCommandLine | order by Equipos desc

El agente ejecuta scripts legítimos a diario, de modo que el resultado es una lista de líneas de comando que hay que comparar con las tareas que el proveedor tiene programadas. Interesa lo que nadie reconoce, sobre todo si aparece en muchos equipos a la vez. Si hay indicios, el siguiente paso es una respuesta a incidentes que incluya las redes de los clientes gestionados, como pide Huntress, y la rotación de las credenciales de administración, de servicio y de integración guardadas en N-central. Una búsqueda proactiva de amenazas sobre esos mismos equipos ayuda a descartar persistencia.

Para el parche, Tenable marca un orden: los agentes antes que las sondas, porque una sonda actualizada deja de comunicarse con agentes antiguos. Huntress advierte de que N-able no siempre cambia el número de versión en los hotfixes aplicados en caliente, así que la versión que muestra la consola no sirve como prueba de que el arreglo está instalado.

¿Qué controles siguen valiendo y qué supuestos han caducado?

Siguen vigentes los controles básicos de cualquier herramienta de administración: consola sin exposición a internet, MFA resistente al phishing para los operadores, cuentas de administración separadas de las de uso diario y una segmentación de la red interna que limite lo que alcanza el servidor RMM. También un EDR en los equipos gestionados cuya configuración y alertas no dependan de la consola.

Han caducado tres supuestos. El primero, que habrá un CVE antes que un exploit: Able2Shell publicó código para fallos sin identificador, y un programa de gestión de vulnerabilidades que solo reacciona a CVE no lo habría visto el 9 de noviembre. El segundo, que el parche cierra el episodio; en agosto hizo falta otro arreglo, y al día siguiente de salir el Hotfix 2 ya había exploits que, según su autor, lo superan. El tercero, que los registros de la propia consola bastan para descartar un compromiso.

Lo que todavía no se sabe

N-able no ha publicado qué hallazgos de los 33 corrige el Hotfix 2 ni cuándo llegará el próximo hotfix, ni qué arreglo tendrán 4EverAble2Shell y Agent2Shell. No hay un recuento público de servidores locales expuestos el 9 de noviembre ni de cuántos tienen hoy la Legacy API accesible desde internet, ni confirmación independiente de que nadie los explotara antes de la desconexión. Y nadie ha contrastado la acusación del investigador sobre avisos previos sin respuesta.

Lo que sí puede decidirse ya es cuántas horas aguanta la organización sin su herramienta RMM y quién da la orden de desconectarla. Entre la publicación y la desconexión pasaron once horas, y la segunda tanda de exploits llegó dos días después. Un cliente que no lo haya hablado antes tendrá que decidirlo con el ataque ya en marcha.

Aviso: la consulta KQL y las comprobaciones son orientativas. Pruebe la consulta antes de usarla en producción y adapte rutas y nombres de proceso a su instalación. Este análisis se basa en la información pública de N-able, Huntress, Tenable, Field Effect y watchTowr y en la cobertura de SecurityWeek, The Hacker News y GovInfoSecurity, con datos a 12 de noviembre de 2026. La situación cambia a diario: compruebe el estado del fabricante antes de actuar. Las afirmaciones del investigador y el detalle de los 33 hallazgos no están verificados de forma independiente, y su descripción aquí no implica que todos sean explotables en cada versión.