La plataforma de monitorización y administración remota N-central ha vuelto a estar en el foco de la ciberseguridad. Según N-able, un grupo de atacantes explotó un bypass de autenticación para obtener acceso administrativo remoto a servidores que ejecutaban versiones vulnerables. Desde ahí, los atacantes pudieron llegar a los equipos de los clientes gestionados a través de esos servidores, manteniendo la presencia incluso después de cambios de ruta.
Lo más importante para los equipos de TI y los proveedores que usan este tipo de servicios de administración es que los N-central parches deben aplicarse correctamente. N-able explica que su corrección inicial no fue suficiente y que la actualización a la versión indicada ahora es la medida que todos los clientes deberían completar.
Qué pasó con N-central: acceso remoto tras un bypass
De acuerdo con el aviso de N-able, los atacantes aprovecharon una debilidad que permitía evitar el proceso de autenticación. Con ese acceso, obtuvieron capacidad de administración remota sobre servidores N-central.
Luego, mediante la función Take Control, los atacantes alcanzaron endpoints gestionados. Además, registraron túneles de Cloudflare como servicios en los dispositivos, lo que contribuyó a mantener el control a lo largo del tiempo.
Por qué el primer parche quedó incompleto
El punto crítico del incidente es que N-able indica que su primer fix no bloqueó todo lo explotable. Se identificó que la corrección inicial afectaba de forma parcial al comportamiento vulnerable.
En este contexto aparecen dos identificadores de vulnerabilidad:
- CVE-2026-18556: cubre lanzamientos hasta 2026.1. N-able afirma que el camino correspondiente quedó corregido en la 2026.2, pero más tarde detectó una vía alternativa que seguía siendo explotable.
- CVE-2026-18577: amplía el rango de riesgo a builds anteriores a 2026.3.1.7, porque un método alternativo no estaba bloqueado por el fix inicial.
N-able distribuyó como primera versión “no afectada” la 2026.3.1.7 el 2 de agosto. Por eso, las N-central parches que se completen deben alinearse con esa actualización: actualizar solo a 2026.3 ya no es suficiente.
Cómo los atacantes mantuvieron el acceso
Una vez comprometido un servidor, N-able describe el uso de túneles de Cloudflare como servicios instalados en los equipos administrados. Estos túneles establecen conectividad de salida hacia la infraestructura de Cloudflare, por lo que normalmente no se requiere abrir puertos de escucha entrante ni añadir reglas específicas de firewall para entradas directas.
Según la explicación proporcionada, ejecutar los túneles como servicios también les permitió seguir activos tras reinicios. Además, N-able afirma que esos túneles conservaron el acceso aun cuando se revocó la ruta a través del servidor N-central.
Es relevante aclarar que el aviso no sugiere que Cloudflare haya sido comprometido. La premisa es que el problema se basa en el abuso de un mecanismo de conectividad (el servicio de túneles) para conservar persistencia, no en un fallo dentro de Cloudflare.
Qué deben hacer los clientes: actualizar a 2026.3.1.7
N-able recomienda que toda instancia de N-central se actualice a 2026.3.1.7. También detalla que una actualización a 2026.3 ya no cumple el objetivo por la existencia del método alternativo asociado a CVE-2026-18577.
La guía operativa cambia según el modelo de despliegue:
- Instancias alojadas (hosted NCOD): N-able indica que se actualizarán automáticamente en un calendario comunicado a los partners.
- Instancias autoalojadas (self-hosted): el responsable debe actualizar el servidor por cuenta propia.
Buscar persistencia: actualizar no siempre elimina lo instalado en endpoints
Un riesgo adicional señalado por N-able es que la actualización de N-central no basta para limpiar persistencias que ya se hayan instalado en otras máquinas. En otras palabras: aunque arregles la parte del servidor de administración, puede quedar actividad maliciosa en los endpoints.
Por ello, N-able indica que los clientes que encuentren evidencia de compromiso deben:
- Realizar una búsqueda de servicios de túneles maliciosos u otros artefactos instalados en los equipos administrados.
- Coordinarse con sus equipos de seguridad para una eliminación completa y validación posterior.
Indicadores y señales de compromiso mencionadas
Además de la actualización, N-able y otros investigadores han compartido indicadores para facilitar la revisión. La orientación no pretende demostrar por sí sola una intrusión, sino ayudar a priorizar el análisis.
Señales relacionadas con Cloudflare y procesos
N-able sugiere que se revisen elementos como:
- la presencia de svchost.exe en la carpeta Documents de los usuarios;
- un servicio con el nombre Cloudflared (según el aviso);
- tráfico asociado con las direcciones IP publicadas por N-able.
Ante la detección de cualquiera de estos indicadores, el consejo es contactar a soporte y activar los procesos internos de respuesta con el equipo de seguridad.
Lista de IPs observadas
N-able publicó seis direcciones IP que, según su análisis, se observaron en 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
Posteriormente, Huntress relacionó cuatro de esas direcciones con nodos de salida de Mullvad o NordVPN. Huntress recomendó contrastar cualquier coincidencia con los registros de la interfaz de N-central, así como con registros de red y de los endpoints.
Revisar logs de Take Control
Para identificar actividad no autorizada vinculada a Take Control, Huntress propone revisar:
- el archivo ui_access_control.log;
- y correlacionar con C:\ProgramData\GetSupportService_N-Central\Logs\BASupSrvc_*.log.gz en endpoints Windows.
Importante: Huntress advierte que estos logs también aparecen durante usos legítimos de Take Control, de modo que su presencia por sí sola no confirma compromiso.
También menciona la necesidad de investigar sesiones asociadas a identidades aparentes de soporte, por ejemplo mspsupport@n-able.com.
Qué se observó en la actividad posterior al compromiso
N-able comenzó a investigar el incidente el 31 de julio, después de recibir un volumen inusual de errores de licenciamiento en clientes con despliegue on-premises. En ese proceso, N-able detectó que un atacante había obtenido acceso administrativo remoto a servidores que ejecutaban 2026.1 y versiones anteriores.
La compañía indicó que contactó a un número limitado de clientes afectados, pero no compartió cifras públicas sobre el alcance total ni sobre identidades concretas de las organizaciones impactadas.
En cuanto a la actividad post-compromiso, Huntress aclaró que su observación se centró en un caso de instancia autoalojada dentro de una cuenta de partner. Según esa información, los atacantes accedieron a nueve organizaciones bajo esa cuenta, alcanzando un endpoint en cada una.
Con el material disponible, Huntress señaló que la actividad se limitó a enumerar procesos en ejecución y que los atacantes se desconectaron posteriormente. Aun así, Huntress continúa revisando si existen otros indicadores de compromiso o técnicas adicionales.
Señales que no se observaron según Huntress
En contraste con la notificación inicial de N-able, Huntress indicó que no observó la actividad asociada a la instalación de Cloudflare como la describió N-able en su primer aviso a clientes.
Este tipo de diferencia puede reflejar variaciones entre incidentes, entornos o etapas de análisis, por lo que la recomendación práctica sigue siendo la misma: combinar actualización con verificación en endpoints.
Recomendaciones finales para seguridad y continuidad
Este caso deja una lección clara: cuando se trata de plataformas de administración remota, no basta con aplicar un parche una única vez o asumir que una versión cercana es equivalente. Por eso, los N-central parches recomendados por N-able se centran en la actualización a 2026.3.1.7.
Además, si tu organización detecta señales de intrusión, el trabajo no termina con el servidor. Debes buscar y retirar persistencia instalada en endpoints, revisar logs relevantes de Take Control y contrastar indicios con los registros de interfaz, red y sistemas.
Si necesitas una acción inmediata, el orden lógico es: actualizar a 2026.3.1.7, evaluar la presencia de servicios o procesos sospechosos en endpoints y luego validar con tu equipo de seguridad si hubo abuso adicional.
Fuente: https://thehackernews.com/2026/08/n-able-says-attackers-take-over-n.html
