SimpleHelp: 14.000 servidores RMM caen por un bypass de OIDC (CVE-2026-48558)

Contexto del incidente

El 29 de junio de 2026, CISA agregó CVE-2026-48558 a su catálogo Known Exploited Vulnerabilities (KEV) con fecha de remediación federal 2 de julio. La vulnerabilidad reside en la plataforma SimpleHelp, una solución de Remote Monitoring and Management (RMM) usada por proveedores de servicios gestionados (MSPs) y departamentos de IT corporativos para administrar remotamente flotas de equipos.

El puntaje es contundente: CVSS 4.0 = 9.5 (CRITICAL) según la CNA VulnCheck, con vector AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. La versión CVSS 3.1 publicada en NVD escala directamente a 10.0. La clase de falla es CWE-347 (Improper Verification of Cryptographic Signature): cuando SimpleHelp tiene configurada la autenticación vía OpenID Connect, el servidor acepta los tokens de identidad enviados en el callback sin verificar la firma criptográfica que debería atarlos al proveedor (IdP) declarado.

En la práctica, eso significa que un atacante remoto, sin credenciales, sin token válido y sin que nadie del otro lado haga un click, puede construir un JSON con los claims de identidad que quiera (incluyendo un email arbitrario asociado a un TechnicianGroup existente) y enviarlo al endpoint de callback. SimpleHelp lo trata como una sesión autenticada. Si el Tenant tiene habilitado el setting "Allow group authenticated logins", el atacante arranca como Technician privilegiado con la capacidad de iniciar sesiones remotas contra los endpoints administrados, ejecutar scripts y mover archivos.

Lo más grave: el bypass esquiva el MFA. Como en muchas configuraciones los técnicos pueden auto-registrar su propio método MFA en el primer login, el atacante crea el método en ese mismo paso y queda dentro con un canal válido para los próximos ingresos. El equipo de Adversary Pursuit Group de BlackPoint Cyber documentó una intrusión real en la que, partiendo únicamente de este bypass, terminaron robando credenciales de plataformas cloud, repositorios de código, registros de paquetes y billeteras cripto en una misma corrida.

Un RMM es, por diseño, la cuenta más poderosa del ambiente: el que la controla controla todo lo que el RMM administra. Tratarla como un servidor más es un error de modelo.

¿Por qué este caso es distinto al RCE clásico?

La mayoría de los CVEs recientes contra RMM y herramientas de administración remota (ConnectWise, Kaseya, ScreenConnect, N-able) son inyecciones de comandos o deserializaciones que requieren que el atacante cargue un payload. Lo interesante de CVE-2026-48558 es que no hay payload: la credencial forjada es el ataque. No queda un archivo "sospechoso" colgado en el servidor en el momento de la intrusión, no hay un comando ejecutado, no hay ningún log de "intrusión" como lo entienden los SIEM tradicionales. Lo que hay es una sesión legítima, creada contra la API por el flujo de OIDC, firmada con un token que la propia aplicación debió haber descartado.

El efecto operativo es doble. Por un lado, los RMM suelen ser el eslabón lateral más productivo de la cadena de ataque: desde un Technician es trivial pasar a un endpoint final vía el remote viewer, y desde ahí pivotar a Active Directory, M365 o cualquier VPN que el endpoint autenticara. Por el otro, en despliegues MSP, el SimpleHelp de un proveedor maneja los endpoints de decenas de clientes al mismo tiempo: comprometer al MSP compromete a todos sus clientes en simultáneo. El reporte de BlackPoint muestra exactamente esa propagación: las credenciales robadas incluían tokens para servicios donde el MSP prestaba servicio, no solo para su propia infraestructura.

Para dimensionar el riesgo: cuando Horizon3.ai publicó el advisory el 12 de junio, los escaneos a internet identificaron ~14.000 servidores SimpleHelp expuestos, contra ~3.400 en enero de 2025. De los muestreados, alrededor de un 7,2% usaban alguna variante de autenticación OIDC potencialmente vulnerable. Es un número enorme de servidores que cumplen exactamente las tres condiciones que la falla necesita para ser explotada.

¿Cómo proteger tu infraestructura?

1. Aplicá el parche a 5.5.16 o 6.0 estable, sin demora

SimpleHelp liberó el fix el 9 de junio, antes incluso de la divulgación coordinada. Para servidores en la rama 5.5.x la versión remediada es 5.5.16 (verificá el SHA256 publicado en el advisory oficial: b0e129ce1e05b19c8c5ce2331ca1c7f91b79bb78806a2d5af80a6d506ea39192 para el instalador Windows 64-bit). Para la rama 6.0 pre-release, hay que migrar a la 6.0 estable. Si administrás un MSP con decenas de instancias, mandá la actualización en simultáneo: el script de SimpleSetup acepta la URL de update remoto y permite forzar el rollout. Asumí que cualquier SimpleHelp sin parche instalado antes del 9 de junio está potencialmente comprometido hasta que demuestres lo contrario.

2. Si no podés parchear hoy, deshabilitá el flujo OIDC

El vector explotable es específicamente el login vía OIDC. Como mitigación de emergencia, en Administration → Login Security dejá la autenticación OIDC deshabilitada y forzá el login local de Technician (usuario + contraseña + MFA) hasta tanto la versión parchada esté en producción. Adicionalmente, aplicá IP allowlist a la pantalla de login de Technician: en la mayoría de los despliegues los técnicos se conectan desde un rango acotado de IPs del MSP, no desde cualquier punto de internet, así que la lista blanca de origen es un control barato y efectivo. El mismo panel tiene filtros opcionales que, según el reporte de Horizon3, casi nunca están activados en clientes del mundo real.

3. Revisá la lista de Technician y los logs del 21 de mayo en adelante

El advisory de Horizon3 describe un procedimiento de auditoría muy concreto. En la consola web entrá a Administration → Technicians → Gear Icon → "Show Group Authenticated Users" y revisá si hay técnicos que no reconozcas. Después abrí Administration → Server Logs y buscá entradas del tipo Registering technician login for <email sospechoso> / (Technicians) o Configuration save requested (Forged Attacker - <email> [(Technicians)] [New Anon]). Los archivos de log en el host viven en /opt/SimpleHelp/logs/server.log y en subdirectorios con nombre <YYYYMMDD-HHMMSS>/server.log. Si encontrás cuentas creadas después del 21 de mayo de 2026 (fecha de descubrimiento) sin un responsable asignado, asumí compromiso: rotá credenciales del Technician, auditá los endpoints que ese Technician haya tocado y conservá los logs.

4. Vigilá tráfico a trycloudflare y dev-tunnels desde el host SimpleHelp

En la intrusión documentada por BlackPoint, el atacante desplegó TaskWeaver, un loader Node.js ofuscado de 1,08 MB guardado como jquery.js y ejecutado con node.exe <path>\jquery.js. El binario se descargaba desde un subdominio aleatorio de trycloudflare.com (túneles efímeros de Cloudflare Quick Tunnel) y el canal de C2 se montaba contra a[.]dev-tunnels[.]com — un lookalike del legítimo devtunnels.ms de Microsoft — con un patrón POST /api/<base64url>.<base64url>.<base64url>. En tu EDR / proxy / NDR alertá cualquier conexión saliente del host SimpleHelp hacia *.trycloudflare.com, *.dev-tunnels.com o el dominio de lookalike, y cualquier ejecución de node.exe sobre archivos con nombre de librería legítima (jquery, react, lodash, etc.). En un servidor SimpleHelp no debería correr Node.js en operación normal.

Indicadores de compromiso (IoC)

Los IoCs siguientes están extraídos de la divulgación de Horizon3.ai y del análisis de intrusión de BlackPoint Cyber. Sirven para validar exposición y para cazar compromisos que ya estén en curso. Si administrás un SimpleHelp sin parche, asumí que estos IoCs pueden estar presentes.

• Versiones vulnerables: SimpleHelp 5.5.15 y anteriores; todas las versiones 6.0 pre-release (RC y betas previas al lanzamiento estable).
• Versiones parchadas: SimpleHelp 5.5.16; SimpleHelp 6.0 estable. SHA256 publicado por el vendor para validar integridad del binario antes de instalar.
• Patrón en logs (orquestación forjada): entradas que contengan Registering technician login for con emails que no correspondan a tu MSP, o [New Anon] en la columna de Technician. Particularmente en /opt/SimpleHelp/logs/server.log.
• Loader TaskWeaver: archivo JavaScript ofuscado, 1,08 MB, una sola línea, nombrado jquery.js y ejecutado con node.exe <path>\jquery.js desde el host SimpleHelp. Cualquier Node.js corriendo en un host SimpleHelp debe tratarse como malicioso hasta que se demuestre lo contrario.
• Dominio de descarga inicial: subdominios aleatorios de trycloudflare.com (Cloudflare Quick Tunnels). En un RMM legítimo el host no necesita descargar binarios de Internet — bloquear o alertar.
• Canal de C2 (TaskWeaver): a[.]dev-tunnels[.]com, con patrón POST /api/<base64url>.<base64url>.<base64url>, content-type text/plain, cuerpo cifrado con AES-256-GCM y clave envuelta en RSA-2048 OAEP.
• Señales de persistencia operativa: technicians auto-creados vía OIDC, métodos MFA auto-registrados en el primer login, sesiones nuevas desde IPs que no correspondan a la red del MSP, y jobs de remote-control iniciados contra endpoints que ningún técnico legítimo de tu plantilla haya abierto.

# Splunk / SPL: technicians nuevos via OIDC en SimpleHelp
index=simplehelp source="/opt/SimpleHelp/logs/server.log"
| rex "Registering technician login for (?<tech_email>[^ ]+)"
| rex "Configuration save requested \((?<tech_label>[^)]+)\)"
| where isnotnull(tech_email) OR match(tech_label, "\[New Anon\]")
| eval first_seen=_time
| stats min(first_seen) AS first_seen
        values(tech_label) AS labels
        BY tech_email
| where first_seen >= relative_time(now(), "-30d")
| sort - first_seen

# Suricata / Zeek: detectar POST al C2 de TaskWeaver desde un host SimpleHelp
alert http any any -> any any (msg:"SIMPLEHELP TaskWeaver C2 beacon a.dev-tunnels.com";
    http.host; content:"a.dev-tunnels.com"; nocase;
    http.uri; content:"/api/"; http.method; content:"POST";
    sid:2026485581; rev:1;)

# Windows EDR (KQL / MDE): node.exe cargando jquery.js en host SimpleHelp
DeviceFileEvents
| where ActionType == "FileCreated"
| where FileName =~ "jquery.js" or FileName =~ "react.js" or FileName =~ "lodash.js"
| join kind=inner (DeviceProcessEvents
    | where ProcessName =~ "node.exe"
    | where ProcessCommandLine has "jquery.js" or ProcessCommandLine has "react.js")
    on DeviceId
| where timestamp between (ago(30d) .. now())