{ "id": "5cecc18d-025f-4469-9355-abd17afa04e9", "created_at": "2026-04-06T00:08:27.047014Z", "updated_at": "2026-04-10T03:31:51.280251Z", "deleted_at": null, "sha1_hash": "8e4938c2ec31857dc4a26dc740bf6ae7bf66c217", "title": "Measuring the Potential Impact of PIPEDREAM Malware OPC UA Module, MOUSEHOLE", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 678946, "plain_text": "Measuring the Potential Impact of PIPEDREAM Malware OPC\r\nUA Module, MOUSEHOLE\r\nBy Sam Hanson\r\nPublished: 2023-10-25 · Archived: 2026-04-05 18:48:32 UTC\r\nThis is the second posting in our two-part blog series on PIPEDREAM’s OPC UA Module, MOUSEHOLE. To\r\nview our first blog in this series, see: Deep Dive Into PIPEDREAM’s OPC UA Module, MOUSEHOLE\r\nIn April of 2022, Dragos published a whitepaper and hosted a webinar to alert and inform the industrial\r\ncybersecurity community of a sophisticated new malware, PIPEDREAM, the seventh known industrial control\r\nsystems (ICS)-specific malware developed by the CHERNOVITE threat group. Dragos Threat Intelligence\r\nfollowed up with a blog titled, Analyzing PIPEDREAM: Results from Runtime Testing. Continuing this research,\r\nwe are releasing additional information on the Open Platform Communications Unified Architecture (OPC UA)\r\nmodule, MOUSEHOLE, focusing on further analysis and runtime testing results.\r\nIn the final installment of this two-part blog series, Dragos Threat Intelligence analysts present runtime testing\r\nresults on an experiment named MOUSELAB, a derivation of MOUSEHOLE developed by Dragos to assess the\r\nimpacts of the tool’s capabilities. We also provide OPC UA server security settings and best practice\r\nrecommendations for ICS/OT defenders.\r\nDynamic Analysis and Infrastructure Setup\r\nDragos first analyzed MOUSEHOLE statically, that is, purely by reading the code. However, Dragos quickly\r\ndetermined that dynamic analysis was necessary to test the limitations and full functionality of the malware.\r\nhttps://www.dragos.com/blog/potential-impact-of-pipedream-malware-module-mousehole/\r\nPage 1 of 5\n\nDragos set up a system on our cyber range, as demonstrated in Figure 1, functioning as a mock water pipeline to\r\ntest against MOUSEHOLE. During testing, it became apparent that each step of the attack required user\r\ninteraction. While successful in impacting our mock pipeline by increasing the pressure to unsafe conditions,\r\nDragos researchers hypothesized that most of the interaction with the OPC UA server would be automated in a\r\nreal-world scenario.\r\nA More Realistic Attack Scenario\r\nThe following is solely a hypothetical scenario created by Dragos to describe how CHERNOVITE may\r\ndeploy MOUSEHOLE.\r\nTo accomplish an effect on any given industrial process, the operator is required to execute a MOUSEHOLE\r\ncommand at nearly every step: scanning the network; enumerating the endpoints; reading node attributes; and\r\nwriting node attributes. In a more realistic attack scenario, the adversary deploys and executes MOUSEHOLE to\r\nconduct reconnaissance against the OPC UA server. The adversary collects intelligence, such as what nodes map\r\nto operational-impacting process values. Once the OPC UA address space is understood, the adversary hardcodes\r\nall node identifiers and values they want to modify into a new, automated version of MOUSEHOLE.\r\nhttps://www.dragos.com/blog/potential-impact-of-pipedream-malware-module-mousehole/\r\nPage 2 of 5\n\nDeveloping an automated version allows the adversary to use MOUSEHOLE as a reconnaissance tool without\r\ncompletely “burning” the capability. Once reconnaissance in the adversary’s target environment is complete, then\r\nthe automated capability would be deployed and “burned.”\r\nAnalyst note: When an adversary’s capability is discovered (colloquially referred to as “burned”) defenders will\r\ncreate detections and produce recommendations to help mitigate the threat. Adversaries never want to burn a\r\ncapability unnecessarily – custom malware takes time, resources, and expertise to develop.\r\nTo simulate a more realistic attack tool, Dragos researchers experimented with an automated, victim-specific\r\nversion of MOUSEHOLE nicknamed MOUSELAB. The goal of this experiment was to create unsafe conditions\r\nin the water pipeline by increasing the water pressure. The results of this experiment would provide a better\r\nunderstanding of MOUSEHOLE’s effectiveness and help us, as defenders, to create more effective detections and\r\nmitigation strategies.\r\nThe MOUSELAB Experiment\r\nMOUSELAB consists of two major steps – the first, reconnaissance, authentication requirements, and access\r\ncontrols; the second, writing malicious data to node value attributes.\r\nStep 1: Reconnaissance, Authentication Requirements, and Access Controls\r\nMOUSELAB first scans the network looking for OPC UA servers. Once servers are found, it obtains server\r\nendpoints using OPC UA’s discovery service and identifies which servers are set up with weak security modes\r\nenabled (in this case, a security mode of “none”). MOUSELAB then attempts “anonymous login,” that is, a login\r\nwithout any user credentials. If credentials are required, MOUSELAB asks the user for the username and\r\npassword list and begins brute-forcing the server. Once the username and password are successfully found,\r\nMOUSELAB obtains the server structure and enumerates the address space looking for nodes with read or write\r\naccess enabled. This information is returned to the operator, who must then analyze these nodes and determine\r\nwhich could have an operational impact.\r\nStep 2: Writing Malicious Data to Node Value Attributes\r\nAfter performing initial reconnaissance on the target OPC UA server, the operator hardcodes the node’s identifiers\r\nand values to be overwritten into MOUSELAB. Finally, they execute the program, writing the new values to the\r\nserver and directly impacting operational conditions.\r\nTo achieve the goal of creating unsafe conditions in the pipeline, a few OPC UA node values must be modified in\r\nthe server’s address space representing various process information. First, the solenoid valve, represented as a\r\nnode with a Boolean datatype, must be set to false. This blocks the water from escaping and relieves pressure in\r\nthe pipe. Next, the water flow rate node value is increased to 100%, pumping water into the pipeline as fast as\r\npossible.\r\nHowever, if we attempt to increase the pressure by only modifying the flow rate and closing the solenoid valve,\r\nwe will trigger a safety shutdown once the pressure reaches our high-pressure set point node value, currently set to\r\n15 PSI. When a safety shutdown is triggered, the system relieves the pipeline pressure and issues an over-pressure\r\nreset. Once the alarm is cleared, the process is ready to resume normal behavior. The safety shutdown can be seen\r\nhttps://www.dragos.com/blog/potential-impact-of-pipedream-malware-module-mousehole/\r\nPage 3 of 5\n\nin our first execution of MOUSELAB as demonstrated in our DEF CON presentation recording: view time stamp:\r\n9:31.\r\nNext, we ran the experiment again, this time increasing the high-pressure set point to 100 PSI, far beyond the\r\nmaximum safe pressure within the pipeline, as well as closing the solenoid valve and maximizing our flow rate.\r\nSetting the high-pressure set point to such a high value effectively disables it, allowing pressure to reach unsafe\r\nlevels while still staying below the set point. The unsafe conditions shutdown can be seen in the same DEF CON\r\npresentation recording referenced above: view time stamp: 11:43.\r\nAnalyst note: Our pipeline is set up in such a way that the pump is not physically capable of increasing the\r\npressure to a point of physical destruction. This small-scale experiment was designed to only test MOUSEHOLE’s\r\nfunctionality with legitimate OPC UA servers. Whether a MOUSEHOLE-like tool can cause physical disruption\r\nor destruction depends on numerous factors in the target environment.\r\nDragos researchers set up the infrastructure to test MOUSELAB. A threat group such as CHERNOVITE would\r\nnot have the luxury of such in-depth knowledge. Significant reconnaissance is required to fully understand what\r\nnodes would lead to operational impact and unsafe system conditions.\r\nDragos assesses with high confidence that MOUSEHOLE could impact operations. While MOUSELAB contains\r\nvarious enhancements that improved the attack from the adversary’s perspective, these enhancements are not\r\nnecessary for MOUSEHOLE to achieve an impact and should not be viewed as a limitation. MOUSEHOLE, in its\r\ncurrent form, already contains all the functionality required to disrupt industrial processes.\r\nOPC UA Server Security and Best Practices\r\nWhile it’s important to understand how MOUSEHOLE can impact an industrial process, the biggest takeaway for\r\ndefenders is how to secure OPC UA servers.\r\nResearchers from Germany’s Federal Office for Information Security found that, unlike many industrial protocols,\r\nOPC UA has security built into its architecture and design, greatly increasing confidentiality, integrity, and\r\navailability. However, the security of OPC UA relies on proper setup, configuration, and deployment of the OPC\r\nUA server, which can be difficult depending on the configuration software used.\r\nIn fact, a significant number of OPC UA deployments have security issues. Researchers from the CISPA Helmholz\r\nCenter for Information Security and Saarland University scanned the internet for public-facing OPC UA servers\r\nand published their results in a paper titled Security Analysis of Vendor Implementation of the OPC UA Protocol\r\nfor Industrial Control Systems. They found that “…92% of the deployments show issues with security\r\nconfigurations. Among those, 44% of the servers are accessible without any authentication requirements.” That is,\r\nanonymous access was enabled by default allowing any authenticated client to connect and interact with the OPC\r\nUA server.\r\nWhile OPC UA has security baked into the design of the protocol, proper configuration and deployment by the OT\r\nasset owner and security practitioner must be taken seriously. Ensuring the security recommendations below are\r\nfollowed helps mitigate the threat of rogue OPC UA clients such as MOUSEHOLE.\r\nhttps://www.dragos.com/blog/potential-impact-of-pipedream-malware-module-mousehole/\r\nPage 4 of 5\n\nSecurity Setting Recommendations for OPC UA Server Deployments\r\nUtilizing OPC UA’s “Sign-only” security mode is preferred for ICS environments with network monitoring\r\nsolutions such as the Dragos Platform. Sign-only security mode sends messages unencrypted with an\r\nauthentication code that allows receivers to be sure the message came from a trusted sender, protecting\r\nagainst rogue OPC UA clients such as MOUSEHOLE, while still allowing the packets to be inspected by\r\nnetwork monitoring solutions.\r\nEnsure private keys and certificates are stored in a secure location.\r\nEnsure server utilizes explicit trust lists for certificates and monitor trust list over time.\r\nIf application authentication is enabled (UserNameIdentityToken), ensure long, complex passwords or\r\npassphrases are used.\r\nEnsure the server’s Security Policy is Basic256Sha256. If your server uses a weaker Security Policy\r\nalgorithm, change the policy immediately.\r\nVerify anonymous authentication is disabled. OPC UA server implementations often include an anonymous\r\nauthentication option, sometimes enabled by default.\r\nDisable client read or write access for OPC UA nodes that do not require it. Monitor for unnecessarily\r\nlenient access controls on a node-by-node basis.\r\nMOUSEHOLE and the other modules contained in PIPEDREAM represent a serious escalation in adversarial\r\ncapabilities. Defenders must respond to these threats by ensuring assets are properly configured and secured.\r\nDragos researchers hope the insights and intelligence gained from this research and presented in this blog helps\r\npush the industry towards a more secure future.\r\nGet the Complete Analysis\r\nLearn more about the discovery and capabilities of CHERNOVITE’s PIPEDREAM malware in our whitepaper.\r\nDOWNLOAD WHITEPAPER\r\nSam Hanson is a Vulnerability Analyst on the Intelligence Research Team. Sam graduated from the University of\r\nMinnesota – Twin Cities in 2020 with a Computer Science degree and a focus on Computer Security.\r\nSource: https://www.dragos.com/blog/potential-impact-of-pipedream-malware-module-mousehole/\r\nhttps://www.dragos.com/blog/potential-impact-of-pipedream-malware-module-mousehole/\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA" ], "references": [ "https://www.dragos.com/blog/potential-impact-of-pipedream-malware-module-mousehole/" ], "report_names": [ "potential-impact-of-pipedream-malware-module-mousehole" ], "threat_actors": [ { "id": "091dc6fb-2650-4646-894a-41de0d463f94", "created_at": "2023-11-17T02:00:07.594612Z", "updated_at": "2026-04-10T02:00:03.455179Z", "deleted_at": null, "main_name": "Chernovite", "aliases": [], "source_name": "MISPGALAXY:Chernovite", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434107, "ts_updated_at": 1775791911, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/8e4938c2ec31857dc4a26dc740bf6ae7bf66c217.pdf", "text": "https://archive.orkl.eu/8e4938c2ec31857dc4a26dc740bf6ae7bf66c217.txt", "img": "https://archive.orkl.eu/8e4938c2ec31857dc4a26dc740bf6ae7bf66c217.jpg" } }