Imagine you're trying to install a trusted program, like a medical image viewer, and everything seems fine. But there's a twist: hackers have tricked you into downloading a malicious version instead. That's exactly what happened for two medical organizations.
The ĢTV SOC detected some strange activity involving secure connections (SSH) that started from a DICOM viewer installer, which is a program used to view medical images. While the viewer itself seemed genuine, the SSH activity raised suspicions. This incident highlights the importance of being cautious, even when things look legitimate.
The Incident
On July 16, 2024, ĢTV found a suspicious connection via SSH on a partner's host. ĢTV analysts responded to this threat by isolating the endpoint to prevent this tunnel from being exploited by adversaries. This SSH tunnel traced back to an installer that was run moments before. The installer was for a MicroDicom viewer, a common application for medical software imaging that’s frequently used for interactions with patient healthcare information. The software supply chain is wide in scope, and often-benign applications can be found implementing creative solutions that draw the attention of security analysts. In fact, this application was installed to respond to a common vulnerability and exploit (CVE) in the software that was discovered just a month prior.
The ĢTV SOC began researching this application in earnest after several other endpoints displayed the same behavior. Initial assertions were that it’s unusual that:
- a medical imaging application would utilize SSH tunneling to connect directly to an IP address as opposed to a fully qualified domain
- the perceived malicious installer cannot be found on the official website
When ĢTV analysts initially reported this to one of our partners, they communicated that their customer believed the installer was safe, saying, "The customer installed this DICOM viewer and thinks it's legit, so we released the host."
To double-check, ĢTV contacted another partner who had seen similar activity. They also confirmed that their customer installed the DICOM viewer and provided the link to the legitimate website. However, we noticed something odd: the genuine installer was only 13MB, while the one we found was a massive 178MB. Something was wrong, especially since both suspicious installations connected to the same SSH server using the same username.
ĢTV SOC analysts dug deeper and discovered that the attackers had cloned the legitimate DICOM viewer website.
They created a fake site that looked almost identical to the real one and used it to distribute a malicious installer. This fake installer included an "updater" that established a secret connection back to the attackers. The real website was [.highlight]microdicom[.]com[.highlight], but the fake one was [.highlight]mlcrodlcom[.]info[.highlight].
Interestingly, on June 11, 2024, there was an advisory from CISA about the legitimate DICOM viewer, warning users to update it. ĢTV believes the attackers took advantage of this advisory to send phishing emails, urging users to download their fake "patched" version from the malicious site, which was registered on July 1, 2024.
Technical Analysis
Utilizing interactive dynamic analysis, a technical term for the rather trivial idea of "running it in a safe space," ĢTV SOC analysts were able to execute both the official MicroDicom application and the malicious version of the same application and compare the difference in execution between both. On local systems, the malicious version of the application created the SSH tunnel to the same server, with the same private keys. This is highly uncommon. It can be presumed that any application that handles patient healthcare information would not share the same private key, and would not share connection parameters to the same host.
The malicious MicroDicom installer was further analyzed. The application itself was 178MB in size, whereas the typical installation of MicroDicom is on the scale of 15 to 25MB (depending on the version). This strongly implies that the malicious version of the software possessed additional files that weren’t present in the original version of the software. In local sandboxed execution, we were able to confirm this hypothesis––the malicious version indeed contained OpenSSH bundled in the application, along with another binary responsible for initiating the malicious behavior.
To elaborate further on the technical details found in the malicious DICOM installer, the application forks into the execution of a dropped temporary file, which is responsible for installing OpenSSH as well as the installation and registration of the [.highlight]UpdaterSvc.exe[.highlight] binary. This service represents the primary adversarial foothold, and the nature of this service is such that it’ll start itself upon the start-up of the host system. This application runs [.highlight]7655.bat[.highlight], a batch file ultimately responsible for creating the SSH tunnel. This tunnel can be used by adversaries to access the hosts on which it’s installed and facilitate remote shell access to threat actors. Footholds like this are often abused to exfiltrate sensitive information such as patient information or user credentials. Or to stage more threatening malware and ransomware.
Utilizing static properties analysis tools, we're able to extract code certificate information, and note that the malicious installer has a signature from “Helping Businesses Limited.” This isn’t the original creator of this application. In fact, Helping Businesses Limited has absolutely nothing to do with MicroDicom at all!
With all of this in mind, we've started to create a fairly threatening narrative for this application, but we're still left with some unknowns. Is the developer of the original MicroDicom application compromised and serving backdoors? Why can't we find this 178MB application anywhere on the manufacturer's website?
Open Source Intelligence (OSINT)
ĢTV began to search for information regarding this application on the Internet. Starting with the user manual and changelog notes, an attempt was made to understand the use of this software, and the changes introduced in the latest version. Of note, MicroDicom 2024.2 is being released following ICS medical advisory ICSMA-24-163-01, which was released by the on June 11, 2024.
This advisory mitigates two CVEs:
- CVE-2024-33606 (Improper Authorization Handler)
- CVE-2024-28877 (Stack-Based Buffer Overflow)
These are both significant threats to the security of the application. Furthermore, these CISA bulletins tend to travel fast and gather significant attention, as they indicate potential exploitability for adversaries.
Continuing the research, analysts were also able to confirm the presence of several websites with similar names to MicroDicom that may indicate an attempt to phish those who are looking to update their applications. In fact, of the four sites that we noted, all were registered as domains just following the release of this CISA bulletin.
- [.highlight]mLcrodLcom[.]info[.highlight]
- [.highlight]macrodicom[.]info[.highlight]
- [.highlight]mLcrodicom[.]info[.highlight]
- [.highlight]microdLcom[.]info[.highlight]
Equipped with this hypothesis, the search pivoted to the acquisition of this software by the end-user. Utilizing forensics artifacts that are maintained in the browser history on endpoints interacting with the affected systems, ĢTV was able to locate the source of the malicious binary. This application was being installed by an Amazon S3 bucket named to blend in with the MicroDicom application. Furthermore, utilizing the “referrer,” or the page responsible for the user navigating to the download page, we were able to determine that [.highlight]mLcrodLcom[.]info[.highlight] was the site responsible for serving our malicious installer.
The malicious [.highlight]mlcrodlcom[.]info[.highlight] website is a direct clone of the original software manufacturer's website, with a subtle modification—the download page is slightly different. Upon interacting with the downloads page of the malicious website, we were able to find our malicious binary, offering supporting evidence to our initial hypothesis.
Conclusion
This incident serves as a reminder to remain vigilant and double-check even the most trustworthy sources, especially when something feels off. This is also a testament to why ĢTV is among the highest-rated managed endpoint detection and response providers for small- and medium-sized businesses.
We specialize in identifying these hidden threats and don't just accept things at face value—we investigate, dig deeper, and ensure that our clients are protected from sophisticated attacks.
Want to see how ĢTV Managed EDR can save you from similar situations? Book a demo with us today
Big thanks to Wes Hutcherson and Michael Tigges for their contribution to the analysis and writing of this article.
Sign Up for Blog Updates
Subscribe today and you’ll be the first to know when new content hits the blog.