Written by: Asher Davila Loranca
Technical Editors: Edwin Menor, Royce Lu, Prerna Shankar, Sean Morgan, Sam Kaplan, and Aryn Pedowitz
The Cybersecurity and Infrastructure Security Agency (CISA) detected an apparent backdoor in the firmware of the Contec CMS8000, a device used to monitor patient vital signs in the Healthcare and Public Health sector. After analyzing three versions of the firmware, they found an embedded backdoor feature with a hard-coded IP address, referenced as Hidden Functionality: CVE-2025-0626. Additionally, they identified a risk of patient data exposure to unauthorized individuals, described as Exposure of Private Personal Information to an Unauthorized Actor: CVE-2025-0683.
However, upon further analysis, it was determined that the issue is not due to the presence of the “backdoor” itself. Instead, the problem lies in the potential abuse of this functionality in conjunction with other previously reported vulnerabilities present in this monitor, which could lead to remote code execution (RCE) or the external control of configuration settings.
Contec Medical Systems is an international healthcare solutions and medical device company based in China. Their medical equipment is utilized in hospitals, clinics, home healthcare settings, and veterinary hospitals across the European Union and the United States primarily. The device can monitor electrocardiograms, heart rates, blood oxygen saturation levels, non-invasive blood pressure, temperature, and respiration rates.
The CISA research team examined three Contec firmware packages to validate the mitigation of a vulnerability identified by an external researcher through CISA’s Coordinated Vulnerability Disclosure Process: Version 2.0.6; a pre-release image with an unknown version number; and a pre-release image of Version 2.0.8. During this validation, the team analyzed unusual network traffic provided by a security researcher. Through this investigation, the research team discovered what appears to be a backdoor in all three firmware packages. The CISA report released on January 30th, 2025, included a screenshot of decompiled firmware, where the IP address of the suspected backdoor was obscured. To further investigate this firmware and uncover the IP address of the server along with additional details, we created and deployed the following retrohunt rule on January 31st, 2025, based on the strings displayed in the screenshot from the report:
rule VT_Retrohunt_NFS_Monitoring
{
meta:
author = "Asher Davila - Principal Security Researcher, Palo Alto Networks"
description = "CONTEC CMS8000 Backdoor"
reference = "https://www.cisa.gov/sites/default/files/2025-01/fact-sheet-contec-cms8000-contains-a-backdoor-508c.pdf"
date = "2025-01-31"
strings:
$s1 = "ifconfig eth0 up" nocase
$s3 = "/mnt/monitor" ascii
$s4 = "cp -rf /mnt/* /opt/bin" ascii
$s5 = "cp -f /opt/bin/start /opt/startmonitor" ascii
// Regex pattern to match "mount -o nolock -t nfs [IPv4]:/pm /mnt"
$regex_mount_nfs = /mount -o nolock -t nfs [0-9]{1,3}(\.[0-9]{1,3}){3}:\/pm \/mnt/
condition:
(
uint32be(0) == 0x7f454c46 or
uint32(0) == 0x7F454C46
) and
(
(3 of ($s*) and $regex_mount_nfs) or all of($s*)
)
}
After the Retrohunt finished running, we found 1 match that looked identical to what the CISA report described: 4e42d3b131bd10d8f192d2d15c23bd68164c1bf3daf3c33803b8e81cb4d896ad
Figure 1. Retrohunt hit
Figure 2. VirusTotal sample details
Once the sample was obtained, we proceeded to use radare2 and Binary Ninja to analyze the firmware. It was possible to observe that it is an ARM 32 ELF binary.
Figure 3. Binary information
The focus of this analysis was to find the command ifconfig eth0 up mentioned in the CISA’s report and find if there were other hardcoded IP addresses. Something that stood out was the verbosity when validating the execution of the write_cmd commands. If this were a hidden functionality or a malicious backdoor, it wouldn’t be as evident as it is by printing if there was an error with the mount or NFS service:
Figure 4. mount NFS share command
This faulty implementation, as explained in other reports, could allow attackers to impersonate a server, push malicious configurations to the device, and even execute arbitrary code.
Next, we used a regex to find all the IP addresses embedded within this firmware:
Figure 5. Regex to find all the IP addresses present in the binary
By looking into references for the IP address 202.114.4[.]115 we found the function start_routine_275bb8. The function start_routine_275bb8 is a thread routine designed to configure a network interface, establish a connection to a server, and handle various events and errors in a loop. It begins by calling sub_27595c to configure the network interface eth0 with the hardcoded IP address 202.114.4[.]115, the netmask 255.255.255[.]0, and broadcast address. Following this, it invokes sub_2757cc to further configure the interface or add a route using the broadcast address 202.114.4[.]255. The function then calls sub_275618, which resolves the server IP address ServerIP, creates a TCP socket, and attempts to connect to the server on port 515 (0x203), which is the port assigned for CMS communication. If the connection is successful, the socket descriptor is stored, and a success flag is set; otherwise, an error flag is set, and the socket is closed. After these initialization steps, the function enters a loop to handle events such as communication errors, keyboard input, and periodic tasks. The loop exits if the global variable data_5aafd8 exceeds 5000 (0x1388) or if an error occurs, at which point the function returns the result of a cleanup or error-handling function:
Figure 6. Network interface configuration referencing 202.114.4[.]115
Figure 7. Function sub_275618. Communication on port 515
Another interesting function is sub_24edac which manages a TCP connection over a wireless interface to a server at 202.114.4[.]119. It Initializes variables and references iwconfig to configure the wireless interface. Then, it creates a TCP socket, connects to the server with a 20-second delay and 60-second timeout, and monitors the connection using select. Likely transmits patient monitoring data or retrieves configuration updates wirelessly:
Figure 8. Function sub_24edac used for Wireless network interfaces
Later, this same function uses gethostbyname("202.114.4.119") resolves the hardcoded IP address 202.114.4[.]119 into a struct hostent for the sockaddr_in structure used by connect (though unusual for a static IP address):
Figure 9. Another reference to a hardcoded IP address
Additionally, we found the function sub_249d1c, which checks whether the domain www[.]163[.]com can be resolved to an IP address using the gethostbyname function (whether the host www[.]163[.]com is reachable via DNS resolution). This domain is a popular email domain in China managed by NetEase. However, we didn’t find this function being called:
Figure 10. Reference to www[.]163[.]com
We also noticed that the IP addresses contained within the firmware were related to a range of IP addresses allocated for research purposes by China (CERNET):
Figure 11. Whois record
By using search engine dorks it was possible to find the IP addresses present in the firmware being referenced in multiple user manuals from Contec and OEM devices, which means this hardcoded IP address is not intended to be routable but instead the device is defective designed to use that IP address to configure a Central Monitoring System (CMS) server:
Figure 12. Results from the internet based on the dorks (I)
Figure 13. Results from the internet based on the dorks (II)
Figure 14. Mindray Patient Data Share Solution Guide
By correlating these IP addresses and the obtained firmware using VirusTotal, we were able to find another interesting binary 447a3b7a4b549fd237e31b4a833466690dfa75c12104e6d5bdac80d6c321336a which is detected by many scanners as malicious:
Figure 15. New binary found related to the Contec firmware
This binary is a Windows PE packed with UPX that has embedded IP addresses from the segment 202.114.4.0/24 as shown in Figure 16. It also seems to be used for CMS communication and references Contec and Mindray as observed in Figure 17. It even drops a file C:\Users\user\Desktop\Rdata_MINDRAY_CMS.exe.exe.
Figure 16. Embedded IP addresses
Figure 17. References to Contec, Mindray, and CMS
It is important to note that the entire segment of IP addresses 202.114.4.0/24 could be used for to configure the CMS server, depending on the brand/rebrand of the device and even some user manuals advert not to use it in a public network environment :
Figure 18. Installation instructions of the Vista CMS by Dräger
This defective design introduces multiple issues, for example: An attacker could use this range of IP addresses to impersonate a CMS server and maliciously communicate with the patient monitor to execute arbitrary code, overwrite device configurations, or leak patient information. Finally, according to EMBA analyzer, the firmware is based on Linux Kernel 2.4.20, and is full of potential known vulnerabilities, from Low to Critical that could result in Denial of Service and even Remote Code Execution:
Figure 19. EMBA CVE matching results
In conclusion, this is not a deliberate backdoor but a flawed design that does not consider modern security practices. This shows why secure coding standards, regular firmware updates, and thorough security testing are essential for medical devices to prevent vulnerabilities from being exploited in healthcare environments.
Organizations using this patient monitor should block all access to the subnet 202.114.4[.]0/24 within their internal network. This will stop devices from connecting to external servers for firmware updates or leaking patient information. It’s also a good idea to set up static routes and network segmentation to make sure traffic only goes to the designated CMS server within the internal network. That way, it won’t accidentally reach external networks, lowering the risk of unauthorized setting changes or further exploitation.
It is important to mention that this medical device only monitors vital signs, so even if it is compromised, it does not directly put the patient’s life at risk. However, it could still cause medical staff to take the wrong actions, which makes this design flaw a serious issue.
The Palo Alto Networks Medical IoT Security solution is designed specifically for healthcare and provides full visibility and built-in security for all connected devices. Our solution enables network security teams in healthcare to define and enforce Zero Trust policies to help safeguard their IoT/OT & IoMT devices comprehensively. The Palo Alto Networks Medical IoT Security solution provides the following capabilities::
Next-Generation Firewall (NGFW) Security Policies Implementing NGFW security policies takes your defense a step further by:
By leveraging our Medical IoT Security and NGFW solutions, your organization can:
