Cómo abusan los atacantes de herramientas RMM legítimas
Puntos clave
- Los atacantes pueden usar correos de phishing y flujos de documentos engañosos para convencer a los usuarios de que instalen software RMM legítimo.
- La cadena de instalación puede incluir un ejecutable camuflado, un paquete MSI, un servicio de Windows, cambios en el firewall y persistencia en modo seguro.
- Los equipos de seguridad deben diferenciar los despliegues RMM aprobados del software instalado mediante actividad inusual de correo, navegador, scripts o directorios temporales.
- Una detección eficaz combina listas de aplicaciones permitidas con telemetría de correo, creación de procesos, servicios, cambios en el registro, reglas de firewall y conexiones de red.
- Los señuelos y patrones de instalación recurrentes pueden ayudar a agrupar campañas relacionadas.
Tabla de contenido
Del phishing al control remoto
Los analistas de Threat Intelligence Lab han observado una nueva oleada de campañas que usan herramientas legítimas de monitorización y gestión remota como mecanismo final de acceso.
Las plataformas de monitorización y gestión remota (RMM) ayudan a los administradores a dar soporte a equipos a gran escala. Ofrecen control remoto, despliegue de software, inventario de sistemas, transferencia de archivos, ejecución de comandos y mantenimiento automatizado.
Estas capacidades también ofrecen a los atacantes un canal de acceso ya preparado. En lugar de desarrollar una puerta trasera personalizada, un operador puede convencer a un usuario de que instale un agente que ya permite la administración remota. El resultado puede parecer más un despliegue de IT no autorizado que una infección de malware convencional.
Durante 2026, observamos una nueva oleada de campañas que usaban productos RMM legítimos de esta forma. Los señuelos y los instaladores cambiaban, pero la cadena recurrente era clara: generar confianza en la bandeja de entrada, conseguir la ejecución por parte del usuario, instalar el agente RMM, modificar el endpoint y conectarlo a una infraestructura de acceso remoto.
Un señuelo temático de Chase condujo a FleetDeck
En septiembre de 2026, una campaña que suplantaba a Chase distribuyó más de 80 000 mensajes en pocas horas. El correo presentaba un extracto de cuenta seguro y dirigía a los destinatarios a un archivo HTML alojado en la infraestructura de archivos adjuntos de usuarios de GitHub. Al abrir el archivo se descargaba Chase_Statement.Viewer.exe, que después instalaba FleetDeck en el endpoint.
El nombre del archivo sugería que era un visor de documentos. Su comportamiento mostraba otra cosa. Tras la ejecución, el visor creaba un paquete MSI en el directorio temporal del usuario e invocaba msiexec.exe. Los componentes de FleetDeck se instalaban en C:\Program Files (x86)\FleetDeck Agent\ y se registraban como FleetDeck Agent Service. Los comandos de PowerShell creaban reglas de entrada en el Firewall de Windows para el servicio y el ejecutable del agente. La instalación también añadía el servicio bajo la ruta de registro SafeBoot Network, lo que permitía que funcionara en modo seguro con funciones de red.
LA OBSERVACIÓN CLAVE: El producto era legítimo, pero el despliegue no estaba autorizado: una marca de confianza conducía a un flujo de documentos engañoso, un ejecutable de visor, un nuevo servicio y un canal activo de acceso remoto.
La historia de instalación de FleetDeck
Una vez activo, FleetDeck consultaba el host mediante PowerShell y WMI. La recopilación observada incluía dominio, estado del sistema, fabricante y modelo, memoria física, sistema operativo y versión, número de serie de la BIOS, hora del último arranque, procesador, controlador de vídeo, arquitectura, tipo de adaptador de red, dirección MAC, idioma del sistema y dirección IP externa. Después, el agente se comunicaba con la infraestructura legítima de FleetDeck.
La misma cadena abarca varios productos RMM
El caso de Chase no es un ejemplo aislado de atacantes que eligen un producto de acceso remoto. Otras campañas usaron distintos señuelos y mecanismos de entrega, pero siguieron la misma lógica operativa: convencer al usuario de que ejecute un documento, script o instalador y, después, convertir una herramienta legítima de administración en el canal final de acceso.
ScreenConnect apareció detrás de documentos con extractos gubernamentales, actualizaciones de plataformas de colaboración y señuelos de firma de documentos. SimpleHelp se instaló después de que un dropper perfilara el host. Una campaña temática de facturas usó un archivo ZIP y un pequeño descargador por lotes para solicitar un MeshAgent probablemente preconfigurado e iniciar una instalación completa con privilegios administrativos. Remcos, comercializado originalmente como una herramienta legítima de administración remota, se entregó mediante varias cadenas con archivos comprimidos, scripts y ofuscación.
Nuestro análisis anterior describe en detalle una de las cadenas de ataque de Remcos. Lee el análisis de la cadena de ataque de Remcos RAT.
Las herramientas cambiaban, pero la ventaja operativa se mantenía. Los productos RMM aportan capacidades maduras de persistencia, descubrimiento del sistema, ejecución remota, transferencia de archivos y vigilancia. También pueden comunicarse con infraestructura de proveedores que parece legítima, lo que hace que el contexto de comportamiento sea más importante que una simple lista de bloqueo de dominios.
| Producto | Contexto de entrega |
|---|---|
| ScreenConnect | Extractos gubernamentales, actualizaciones de colaboración y señuelos de firma |
| SimpleHelp | Dropper temático de la Seguridad Social entregado como archivo .scr |
| MeshAgent | ZIP temático de factura y descargador por lotes |
| Remcos | Cadenas con archivos comprimidos, scripts y ofuscación |
Detectar la historia de instalación
Las organizaciones deben mantener un inventario del software de gestión remota que tenga un propósito empresarial legítimo. Para cada producto aprobado, conviene documentar el tenant o la cuenta esperados, el método de despliegue, el responsable de soporte y los endpoints. Los productos que no sean necesarios para las operaciones del negocio deben restringirse mediante políticas de control de aplicaciones y seguridad de endpoints.
La detección debe centrarse después en cómo llegó el software, qué lo lanzó y qué cambió justo después. Algunas combinaciones útiles son:
- un nuevo agente RMM iniciado por un cliente de correo, navegador o intérprete de scripts, o iniciado desde un directorio temporal con permisos de escritura para el usuario;
- un instalador descargado en Descargas o Temp y luego copiado en Program Files;
- un nuevo servicio asociado a un producto RMM fuera del proceso de despliegue aprobado;
- cadenas de procesos como wscript.exe seguido de PowerShell y msiexec.exe, o cmd.exe seguido de PowerShell y curl.exe;
- reglas de entrada de firewall creadas por PowerShell poco después de instalar un nuevo agente;
- cambios en SafeBoot, claves Run, carpetas de inicio o COM tras una interacción con un mensaje externo.
Durante la respuesta ante incidentes, hay que correlacionar la telemetría de correo y web con la creación de procesos, la instalación de servicios, la modificación del registro, los cambios en el firewall y las primeras conexiones de red del agente.
Las preguntas clave son: quién instaló el software, cuándo se instaló, qué cadena de procesos lo lanzó, a qué cuenta o tenant se conecta y si el endpoint debería estar administrado por la infraestructura de soporte de la organización.
Agrupar campañas sin sobredimensionar la atribución
Agrupamos campañas recurrentes en clústeres internos de actividad usando temas de phishing repetidos, métodos de entrega, comportamiento del loader, patrones de despliegue RMM y reutilización de infraestructura. Estos clústeres describen tácticas, técnicas y procedimientos observados. No nombran a ningún actor de amenazas.
El software RMM y la infraestructura de alojamiento pueden ser reutilizados por operadores sin relación entre sí, por lo que las evidencias de estos casos no respaldan una atribución a un grupo concreto. La agrupación sigue siendo útil porque conecta incidentes que parecen separados, destaca comportamientos de entrega repetidos y ayuda a los analistas a reconocer cuándo se usa una cadena conocida para desplegar otro producto de acceso remoto.
Conclusión
La campaña de Chase demuestra lo rápido que un señuelo de phishing rutinario puede convertirse en un despliegue de gestión remota no autorizado. En pocos pasos, la suplantación de una marca de confianza llevó al usuario a un archivo HTML, un ejecutable, una instalación MSI, un servicio de Windows, cambios de persistencia y un canal activo de acceso remoto.
La lección más amplia es que la marca del software solo es una parte de la investigación. Una defensa eficaz combina listas de software permitido, despliegues RMM controlados y detección basada en comportamiento alrededor de la historia de instalación. Para los equipos de seguridad, el objetivo es identificar herramientas legítimas usadas fuera de flujos de trabajo legítimos, conectar campañas individuales mediante tácticas recurrentes y convertir esos hallazgos en una detección más temprana y fiable.
Indicadores de compromiso
Los siguientes indicadores están relacionados con la campaña Chase/FleetDeck descrita en este artículo.
| Tipo | Valor | Descripción |
|---|---|---|
| URL | https://github.com/user-attachments/files/31489398/Chase_SecureDocument.html?Voka.com | URL maliciosa que aloja el payload e incrustada en el correo – suplantación de Chase |
| URL | https://github.com/user-attachments/files/31489398/Chase_SecureDocument.html?Vouka.com | URL maliciosa que aloja el payload e incrustada en el correo – suplantación de Chase |
| Correo | [email protected] | Dirección de correo usada para enviar la campaña maliciosa |
| Correo | [email protected] | Dirección de correo usada para enviar la campaña maliciosa |
| IP | 129.159.94.43 | Dirección IP usada para enviar la campaña maliciosa |
| IP | 79.127.222.213 | Dirección IP usada para enviar la campaña maliciosa |
| IP | 23.234.104.111 | Dirección IP usada para enviar la campaña maliciosa |
| SHA256 | 09ccaa4487af73b7f490656e1289acc6f532964498bcaff4cb4b0125384b7093 | Chase_SecureDocument.html / Archivo descargado cuando la víctima hace clic en la URL incrustada en el correo |
| SHA256 | b3d73d532a9b4786dd17b1d1814e9c4fcbc3841f1b4fed1e92a8793ee4980dd6 | Chase_Statement.Viewer.exe / Archivo descargado cuando la víctima abre el archivo HTML |
Cybersecurity Report 2026
La aceleración de las amenazas globales impulsada por la IA