Working with the EPA to Secure Exposed Water HMIs

Executive Summary

• In October 2024, Censys researchers discovered nearly 400 web-based HMIs for U.S. water facilities exposed online. These were identified via TLS certificate analysis and confirmed through screenshot extraction.
• All systems used the same browser-based HMI/SCADA software and were found in one of three states:
  • Authenticated (credentials required)
  • Read-only (viewable without control)
  • Unauthenticated (full access without credentials)
• 40 systems were fully unauthenticated and controllable by anyone with a browser.
• Censys shared these findings with the EPA and the vendor in question for coordinated remediation. Within nine days, 24% of the systems had been secured, and a few weeks later, this rose to 58%. As of May 2025, fewer than 6% of systems remain online in a read-only or unauthenticated state.

Introduction

Context can be any number of things, but it’s often not found in the specific ICS protocol, as those datapoints rarely have any discernible information; instead, you would look for hints in the TLS certificates, service banners, metadata in HTML on a webserver, or even the screenshots of any exposed remote desktop service. To be quite frank, discovering critical infrastructure exposed on the internet is far less common than sensational blogs and press releases may have you believe. It’s super easy to uncover hosts running protocols like Ethernet/IP or BACNet, but it’s much harder to assess whether those systems pose a real risk, or if they even qualify as critical infrastructure in the first place. 

This is probably why internet-exposed Human-Machine Interfaces (HMIs) are such valuable and compelling targets. An HMI doesn’t just provide access to an ICS network, it also offers the context and visibility needed to determine whether a system is genuinely part of critical infrastructure. These interfaces act as literal viewports into live industrial processes. You may have seen screenshots of them before: low-color-count screens with lots of text and numbers that look like they were designed in 1982.

HMI monitoring brewery operations.

However, HMIs can also be misleading. The screenshot above displays a range of different valves, pumps, temperature readings, set points, and various indicators, indicating that this must be a highly valuable target, right? No, this is a brewery. It monitors beer. That may be important to some, but it’s certainly not critical infrastructure. 

This is all just a long-winded way of saying: you don’t just stumble across insecure critical infrastructure every day, and when you do, it’s usually just a one-off host with a misconfiguration, and not an issue that affects a large number of hosts. But if you do find yourself in a situation where there seems to be some widespread security issue in actual critical infrastructure, you should be encouraged to reevaluate and reassess because in all probability, it’s not what you think it is.

And that was exactly our mindset when we first came across around 400 internet-connected hosts that were so on-the-nose and obviously critical infrastructure, we initially assumed someone was playing a prank on us…

Investigating Further

While conducting some routine analysis of ICS hosts using our tool Censeye we came across an interesting certificate running on some web servers that seemed to be running on a bunch of unlabeled hosts that included the word “SCADA”. The term “SCADA” in this certificate caught our attention because it often means “Supervisory Control and Data Acquisition”: a component in larger industrial control systems used for monitoring and administration. And when we visited the HTTP service with that certificate, we were greeted with a very simple message like the one below:

HTTP service displaying the software name, along with information about the owner/operator of the instance.

While there wasn’t much information to go on at first, we were able to collect a few key details: the host was running PHP (index.php), and the web interface appeared to be part of a browser-based HMI system (after searching the internet for the product name). 

Knowing this, we knew these hosts could be very valuable, even if we didn’t have the full picture. We kicked things off with some general data collection and aggregation. Each of these web servers returned a response body that was similarly structured, typically formatted like “PRODUCT—OWNER—LOCATION.” We wrote a quick script to extract that info into a spreadsheet for further analysis.

Even at this early stage, it was clear we were onto something. Responses like “WTP-Server” and “County Regional WTP” immediately stood out since we recognized “WTP” as shorthand for “Water Treatment Plant”.

Data extracted from hosts with the specific TLS certificate. The "metadata" field represents the HTML title, which contains descriptive information about the location / municipality of the WTP.

A view of "/System.php," where we are presented with various monitoring options for the system in question.

Example HMI found in the "Graphic Screens" section on "/System.php".

After pulling down screenshots from every single exposed device, we were met with hundreds of visual confirmations that we were dealing with water treatment facilities all across the United States.

Before we started to raise alarms, we wanted to make one last assessment into whether these devices were in fact completely open and insecure, or is there some authentication process needed in order to actually control these devices. We found that this software could be in one of three states:

1. Authenticated: We could not control the device or view any of the information on the service. We determined that if the “/System.php” source included the div class “<div class='navtitle' style='width: 260px'>Login</div>”, then the device was authenticated.
2. Read-Only: We could view the alerts and HMI display but not control the HMI or manipulate settings. We found that if “/System.php” included the HTML element ““<div class='login'>”, then the device was running in this mode.
3. Unauthenticated: In this mode, we had complete control over both the settings and the HMI without having to authenticate. To make this determination, the “/System.php” body did not include either of the last two conditions. 

At the time, we found only 95 of the hosts were running with authentication enabled, 264 of which allowed us to read information from the devices, and 40 hosts that had no authentication at all (meaning that hypothetically, we could control the devices connected to the HMI).

Below is a small sample of the different unauthenticated HMI interfaces that we were able to view, from simple menu-based systems to visual controls over an entire county's water system; A shocking result from such a simple exposure.

Selection of HMI screens we observed, providing insight into operations of various water facilities around the U.S.

What now?

Following our discovery and quantification of these interfaces, we knew we needed to take action. Based on our previous attempts to notify operators of improperly exposed systems, we thought it unlikely that the utilities running these systems would respond positively to any outreach from us. Instead, we tried a different approach: we contacted both the software manufacturer and the U.S. Environmental Protection Agency (EPA).

Upon sharing our findings with the manufacturer, we were met with a polite but tepid response. They expressed appreciation, but there was no clear indication action would be taken to remediate the exposures. Vulnerability and exposure notifications are often ineffective, so this wasn’t especially surprising.

It may be obvious why we contacted the manufacturer, but may be less so why we reached out to the EPA directly. During the summer of 2024, we compiled a report on exposed water infrastructure in the U.S., and the EPA was interested and engaged in remediating the exposures. We had experience working with them and knew we shared the same goal of removing sensitive water infrastructure from the internet.

On October 8, 2024, we shared raw data for nearly 400 exposed water systems with the EPA, including IP, port, and likely location of the service, pulled from metadata in the HTTP response's HTML title. Using methods outlined above, we also included indications of whether each host was authenticated, read-only, or entirely unauthenticated. The majority of these systems were fully exposed (read-only) or unauthenticated. Upon receipt, our contacts at the EPA prioritized the more than 300 unauthenticated and fully exposed systems and began engaging the EPA Regions for mitigation assistance.

Nine days later, we received confirmation from the EPA that mitigations were in place for 24% of the systems we notified them about. They also contacted the manufacturer, who began assisting their customers with remediation of the exposures.

In mid-November, roughly a month later, 58% of the read-only and unauthenticated systems had been protected and removed from the public internet. The manufacturer also used this incident as an opportunity to strengthen the security posture of affected utilities by helping implement multifactor authentication and other security best practices.

Trust, but Verify

We received regular updates from the EPA regarding mitigation progress, but we wanted to measure mitigations from our perspective as well. Multiple perspectives on the remaining exposures could be useful in identifying any new systems or those that may have been just recently exposed.

We had the original data we'd shared with the EPA, so this may sound like a straightforward task of checking each IP and port combination at some regular interval to determine whether the service is still online. However, the way IP address assignments work introduces a bit of nuance to this task. This is especially important because all but 2 of these systems were only accessible via IP and port combination, not a domain or other URI.

DHCP, or dynamic host configuration protocol, is used to assign IP addresses to devices when they join a network. When a device joins a network, it sends a request to the DHCP server and is assigned an IP address. If the IP address isn't static–that is, an unchanging IP address associated with a specific device–it can change periodically due to circumstances such as DHCP lease expiration, power loss, or connectivity loss. When the device comes back online, it may not be assigned the exact same IP address it had prior.

Simplified illustration of DHCP churn in practice. If we checked the original IP of the “Ann Arbor” instance at Time 0+1, we might think the system was offline. In reality, it now lives on a different IP address and is still very much connected to the internet.

Knowing this, we had to account for DCHP churn, or how often these systems might be assigned new IP addresses. We thought it unlikely that most of them were on static IP addresses, so we couldn't use the IP address and port as the 'primary key' for the systems.

Instead, we relied on a TLS certificate DN containing “SCADA” that led to our initial discovery. We ran ad-hoc scans once per month and then once every two months following our initial scan based not on IP and port, but results of a Censys query for hosts with the specific certificate DN in question. In cases where IP addresses disappeared from subsequent scan results, we referenced the instance’s HTML title to determine if it had simply moved or was actually offline.

Tracking exposed instances of this SCADA software over time.

Conclusions

While exposures of this scope are never ideal, particularly when they affect critical infrastructure, the responses from the EPA and the manufacturer are encouraging. Following contact from the EPA, the manufacturer urgently worked with affected utilities to help them improve their security posture. We see this effort beautifully reflected in the sharp decrease in exposures in just a few months' time. In an industry full of negative news and disheartening remediation timelines (when there is remediation at all), this is an excellent example of how remediation should be.

Historically, much discussion around ICS security has focused on improper exposure of ICS protocols. While these exposures can point to poor security hygiene in critical infrastructure networks, it can be incredibly difficult to determine whether a protocol is part of a critical operation or someone's hobby project in their home. 

HMIs, however, often reveal useful context for determining the criticality of a system. They are also often unfortunately exposed directly to the internet with minimal or no authentication, making them an easy target for threat actors. While exploiting an ICS protocol requires resources and specialized knowledge, unauthorized access to HMIs only requires knowledge of the IP and port where they reside.

To most effectively protect and defend critical infrastructure in the future, we hope to see more collaboration and remediation efforts like the one detailed here.