There is a saying you will hear from veterans in the Black Hat Network Operations Center (NOC): “Threat hunting on the Black Hat network is like trying to find a needle in a stack of needles." With dozens of training classes running live exploit chains, capture-the-flag traffic, and researchers probing every corner of the internet, our Corelight sensors generate a rich set of Zeek logs, many of which can look suspicious in varying degrees.
But sometimes the most revealing discoveries aren't sophisticated zero-days. They're the quiet, routine IoT traffic generated by people checking in on their lives or work back home, exposing cleartext vulnerabilities that no amount of endpoint security will catch. We'll describe two interesting cases from Black Hat Asia 2026: a smart cat feeder (!) and an industrial-scale solar farm, both observable and controllable by anyone on the internet path.
Part 1: "Wait, did you say cat feeder?!"
At previous Black Hat shows, we developed an agentic AI system for hunting through HTTP POST bodies. The agent decodes, triages, and classifies cleartext traffic while looking for security issues. For Black Hat Asia 2026, we extended this approach to WebSocket message content. Why WebSockets? Because modern C2 frameworks can use WebSocket channels for command and control, making WebSocket inspection an important hunting surface. Together with a custom Zeek package installed on our sensor, this functionality inspects decoded WebSocket messages for tokens, credentials, C2 indicators, and sensitive data patterns that would otherwise require manual review across millions of connections.
Separately, the data that feeds this agentic system is also available for us to hunt in Investigator, where we have several Black Hat-specific dashboards that filter traffic and raise potential issues.
It was this system that flagged connections from an attendee's phone to an API endpoint on port 8888. What caught our eye was the HTTP request initiating a WebSocket upgrade:
The server then responded with 101 Switching Protocols, and the connection was upgraded from HTTP to WebSockets. Here's the problem: none of this was over TLS. The authentication token sits right there in the URL, in the clear, as shown on the top line above.
There is a common misconception that WebSocket traffic is somehow encrypted. By itself, it is NOT encrypted unless it's running over wss:// (WebSocket Secure, i.e. TLS). While the protocol applies a per-message XOR mask, this key is transmitted in cleartext as part of the WebSocket frame header. Anyone on the network path can simply read the masking key and unmask the payload in a single XOR pass, exactly as the legitimate server does. From a network observer's perspective, WebSocket over HTTP is effectively plaintext with one additional trivial arithmetic step. The masking mechanism was designed for cache-busting, not confidentiality.
We surfaced this finding using our custom websocket-messages Zeek package, which handles this unmasking automatically in real time and logs the decoded WebSocket message content to broaden our threat hunting landscape. We see many WebSocket messages, but in this case, what piqued our interest was a series of “probe” messages in the decoded stream. The screenshot below shows how they appear to us in Investigator.
After a few pivots, we retrieved the PCAP—which was trivial thanks to the Corelight Sensor’s SmartPCAP functionality—and now we can review the traffic in greater detail.
Based on our analysis, we believe this activity very likely originated from a remote IoT pet feeder made by a particular manufacturer we have chosen not to publicly identify in this blog. Accordingly, you will see wherever the manufacturer’s name or user credentials are evident.
The screenshot below shows the full progression in Wireshark of the HTTP-to-WebSocket connection where these probes in the unmasked WebSocket traffic are sent:
- The API host over HTTP
- The HTTP GET with the token exposed in the URI
- The server responds
101 Switching Protocols, upgrading to WebSocket - The decoded WebSocket messages flowing over the connection; the message corresponds to API commands
The okhttp/4.11.0 User-Agent suggests the traffic originated from an Android app, and we believe we have identified this smart pet feeder companion app, though we will not name it in this blog.
Our research revealed that the app communicates with a cloud API hosted on Alibaba Cloud, which in turn relays commands to the physical feeder wherever it is located. The cat itself could be anywhere in the world, the attendee's home country, a pet-sitter's house, it doesn't matter. The cloud-relay architecture means an attacker doesn't need to be anywhere near the pet or the feeder; they only need to be somewhere on the network path between the phone and the API server.
The takeaway here is that any actor on that path (a rogue access point or a compromised upstream router) could capture that token and replay feeding commands. They could literally feed someone's cat at home. It's absurd and alarming in equal measure, but a powerful demonstration of both the prevalence of IoT devices in our ever-connected world and the value of network monitoring.
Part 2: "That is a BIG solar farm"
Our second finding escalates the stakes from home pet care to industrial infrastructure.
Given the critical nature of this infrastructure, we are heavily redacting software details and the country of origin in this blog.
While hunting for rare Server headers (a technique that often uncovers bespoke or security-related items) we found a header clearly related to the solar power industry, revealing that an attendee was logging into a solar power system via their iPhone. The entire web interface of the Solar array management was being served over cleartext HTTP on port 8888 across the public internet, even though the farm was far away on a different continent.
Note the web browser has included the Upgrade-Insecure-Requests:1 HTTP header, which is essentially the browser telling the website, "Hey, if you have any old, insecure HTTP links on this page, please automatically load them over secure HTTPS instead." This request header is meant to help secure the browsing experience; however, in this case, the server ignores it and continues serving up the HTTP in the clear.
The server presents a login form with four escalating access levels. Recall that the POST login was the “SERVICE”-level role.
An actor on the network path doesn't just gain visibility into power-generation telemetry. They gain credentials. With Installer- or Service-level access, they could likely modify inverter parameters, alter grid feed-in settings, or even disrupt a megawatt-scale energy system entirely.
The Server also returned real-time power-generation data in the clear:
With that in mind, we did some rough calculations. Based on the power-generation and total yield-figures, we estimated this was a commercial- or industrial-scale solar installation, approximately 100x the size of a home system and roughly 10 years old.
Even the password itself (as strong as it was) suggested a system of a certain vintage, which also aligned with our estimate of its age.
We also researched the server software, and found that the provider had dropped support for it over a decade ago and no longer offers firmware updates. This is a decade-old piece of energy infrastructure that will never receive firmware updates, yet it is still being managed over the open internet.
Why this matters
These aren't theoretical scenarios. We observed real authentication material traversing the open internet, captured passively by our Corelight sensors as part of standard network monitoring. No exploitation required, just observation.
The pattern is the same in both cases:
- No TLS. The IoT vendor chose HTTP, possibly to reduce complexity, because the device hardware can't handle TLS handshakes, or as a downgrade option in case HTTPS was blocked, or certificates expired.
- Tokens and credentials in the clear. Authentication material was visible to any observer on the path.
- Endpoint-invisible. It’s unlikely that an EDR agent will ever see this traffic. The phone has no idea its communications are exposed. The cat feeder and solar power system very likely don’t support EDR at all. The only place this activity is visible is on the network.
This is one of the important reasons why Network Detection and Response exists. These devices don't run agents. They can't be patched on a schedule. Many are legacy hardware that will never receive a firmware update. The network is the only place you can see what they're doing.
The network path is longer than most people think. When an attendee connects to conference Wi-Fi and opens their pet feeder app, they likely believe the risk is limited to the local network. In reality, the network path includes every hop from the remote user (in our case in Singapore at the Black Hat conference) to the cloud server in China, and then back to the device in the user’s home country. That's potentially dozens of autonomous systems, any of which could observe and/or manipulate the traffic.
Key takeaways
- Assume your home IoT traffic is observed. If the app doesn't show a lock icon, and/or if your device’s traffic is unencrypted, someone on the path can see and modify your commands. Furthermore, some apps and devices don't have an indication (a lock or otherwise), and there's no way to tell if the communications are secured besides sniffing the traffic to validate it yourself.
- Legacy devices are permanent liabilities. That solar inverter will outlive its vendor's security support by decades.
- Network visibility is non-negotiable. When devices can't run agents, network detection and response (NDR) provides the only forensic record and highlights risks that endpoint security can miss.
- Public Wi-Fi amplifies the risk. Conference networks, airports, hotels, and anywhere else you share infrastructure with strangers can expose your cleartext IoT traffic.
The Black Hat NOC remains one of the best proving grounds for demonstrating why network evidence matters. Sometimes the most illuminating findings aren't nation-state implants, but everyday essential IoT devices like cat feeders and solar infrastructure.
For more on threat hunting with Zeek and Suricata, see the Corelight Threat Hunting Guide.