La empresa N-able ha confirmado la explotación activa de vulnerabilidades críticas de bypass de autenticación en la plataforma N-central, un sistema de monitorización y gestión remotas (RMM) utilizado por proveedores de servicios gestionados (MSP) y equipos de TI para administrar los endpoints de los clientes. Los atacantes obtenían acceso administrativo remoto a los servidores N-central y, a través de ellos, alcanzaban los sistemas de clientes gestionados. El primer parche resultó incompleto: la corrección de uno de los vectores de ataque (CVE-2026-18556) no bloqueó una vía alternativa de explotación, que recibió el identificador independiente CVE-2026-18577. La única versión protegida es la build 2026.3.1.7, publicada el 2 de agosto de 2026. Todos los usuarios de N-central deben actualizar de inmediato a esta versión y buscar indicios de compromiso en los endpoints gestionados.
Cronología y detalles técnicos de las vulnerabilidades
N-able inició una investigación el 31 de julio de 2026 tras detectar un volumen anómalo de errores de licenciamiento procedentes de servidores locales de clientes. La investigación determinó que los atacantes obtenían de forma remota acceso administrativo a servidores que ejecutaban las versiones 2026.1 y anteriores.
La primera vulnerabilidad, CVE-2026-18556, se ha clasificado como «toma de control no autenticada de una cuenta administrativa» (CWE-288 — bypass de autenticación mediante una ruta o canal alternativo). N-able declaró que había mitigado este vector en la versión 2026.2. Sin embargo, posteriormente se identificó un método alternativo de explotación de la misma vulnerabilidad que el parche anterior no bloqueaba. Este camino de explotación recibió el identificador CVE-2026-18577 y amplió el rango de versiones afectadas a todas las builds anteriores a la 2026.3.1.7.
N-able ha valorado ambas vulnerabilidades en 8.2 según CVSS 4.0. Ninguno de los registros CVE revela el endpoint vulnerable, la secuencia de peticiones ni detalles a nivel de código. El Centro Nacional de Ciberseguridad de Finlandia, en su recomendación del 2 de agosto, confirmó que todas las versiones disponibles antes de la publicación del parche de emergencia eran vulnerables.
Tácticas de los atacantes: del compromiso del servidor a la persistencia
Tras comprometer un servidor N-central, los atacantes utilizaban la funcionalidad integrada Take Control para acceder a los endpoints gestionados. Después, según N-able, los atacantes registraban túneles de Cloudflare como servicios de sistema en los dispositivos. Estos túneles establecen una conexión saliente con la infraestructura perimetral de Cloudflare y no requieren reglas entrantes de firewall ni puertos abiertos. El registro como servicios garantizaba que sobrevivieran a los reinicios, y los propios túneles mantenían el acceso de los atacantes incluso después de que se revocara la ruta a través del servidor N-central comprometido.
Es fundamental: la actualización de N-central no elimina los mecanismos de persistencia instalados en los endpoints gestionados. Esto significa que, incluso después de parchear el servidor, los atacantes pueden conservar el acceso a los dispositivos de los clientes mediante los túneles previamente desplegados.
Cabe señalar que el servicio Cloudflare no se ha visto comprometido: los atacantes abusaron de una funcionalidad legítima de tunelización.
Divergencias en las observaciones: N-able y Huntress
La empresa Huntress, en un informe de 3 de agosto, confirmó haber observado la explotación en una organización de su base de clientes. Según Huntress, la actividad estaba vinculada a una instancia autoalojada de N-central dentro de una única cuenta de partner. De acuerdo con los investigadores, la actividad post-explotación observada se limitó al listado de procesos en ejecución en los endpoints, tras lo cual los atacantes se desconectaban.
Existe una discrepancia importante: Huntress no observó la instalación de túneles de Cloudflare descrita por N-able en sus notificaciones a los clientes afectados. Esto puede indicar fases distintas del ataque en diferentes entornos o que Huntress registró una etapa temprana de reconocimiento previa al despliegue de mecanismos de persistencia. La investigación continúa.
Según Huntress, cuatro de las seis direcciones IP publicadas por N-able son presuntamente nodos de salida de los servicios VPN Mullvad o NordVPN, lo que complica la atribución.
Indicadores de compromiso
N-able ha publicado las siguientes direcciones IP asociadas a los ataques:
- 173[.]249[.]252[.]200
- 87[.]249[.]138[.]34
- 37[.]19[.]210[.]32
- 37[.]153[.]90[.]88
- 92[.]118[.]112[.]181
- 68[.]235[.]46[.]214
Huntress publicó además tres dominios utilizados por los atacantes:
- mousears.synology[.]me
- wagoosh.direct.quickconnect[.]to
- who-ripped-one.direct.quickconnect[.]to
N-able ha recomendado buscar en los endpoints los siguientes indicios de compromiso:
- El archivo svchost.exe en la carpeta «Documentos» de los usuarios
- Un servicio con el nombre Cloudflared
- Tráfico de red hacia las direcciones IP publicadas
Evaluación del impacto
N-central es una plataforma de tipo RMM y, por su naturaleza, su compromiso constituye un ataque a la cadena de suministro: un único servidor de un MSP comprometido potencialmente abre el acceso a todos los entornos de clientes gestionados. N-able indicó que ha identificado y notificado a un «número limitado» de clientes afectados, pero no ha revelado ni el número de organizaciones impactadas, ni la cantidad de dispositivos de nivel inferior comprometidos, ni el momento en que comenzó la explotación, ni la atribución de los atacantes, ni si se ha producido exfiltración de datos.
La incompletitud del primer parche agrava la situación: las organizaciones que hayan actualizado a la versión 2026.2 o incluso a la 2026.3, pero no a la 2026.3.1.7, siguen siendo vulnerables. Según la notificación de N-able, las instancias en la nube de NCOD se actualizarán automáticamente según el calendario comunicado directamente a los partners, mientras que los servidores autoalojados deberán ser actualizados por el propio cliente.
Recomendaciones de respuesta
- Actualizar de inmediato todas las instancias de N-central a la build 2026.3.1.7; es la única versión no vulnerable. Una actualización solo a la 2026.3 no es suficiente.
- Buscar mecanismos de persistencia en todos los endpoints gestionados: comprobar la existencia del servicio Cloudflared, del archivo svchost.exe en las carpetas «Documentos» de los usuarios y de conexiones de red con las direcciones IP publicadas.
- Revisar los logs de Take Control: el archivo ui_access_control.log y los registros
C:\ProgramData\GetSupportService_N-Central\Logs\BASupSrvc_*.log.gzen Windows. Huntress advierte que estos logs también se generan durante el uso legítimo de Take Control, por lo que su mera existencia no constituye prueba de compromiso; es necesaria correlación adicional. - Revisar las sesiones asociadas a identificadores de soporte de N-able, en particular [email protected].
- Correlacionar las direcciones IP y dominios publicados con los logs de la interfaz de N-central, los registros de red y los logs de los endpoints.
- Si se detecta cualquier indicador de compromiso, eliminar los servicios de tunelización maliciosos, ponerse en contacto con el soporte de N-able y activar a un equipo de respuesta a incidentes.
La situación de N-central ilustra un riesgo característico de las plataformas de gestión remota: un único punto de compromiso se amplifica a todos los entornos gestionados, y un parche incompleto genera una falsa sensación de seguridad. La prioridad para cada usuario de N-central ahora mismo es verificar que tiene instalada exactamente la build 2026.3.1.7 y, a continuación, realizar una auditoría completa de los endpoints gestionados en busca de túneles desplegados y servicios no autorizados, ya que la actualización del servidor no elimina la persistencia ya implantada en los dispositivos de los clientes.
