A Dish Served Lukewarm: The Refrigerator Botnet

Attacks on supermarket refrigeration are back in the news, and SecurityScorecard’s STRIKE Threat Intelligence Team has found exposed refrigeration controllers being used for abuse. We discovered scan data that led us to exposed control panels, network flow data that pointed to a suspected spam botnet, and examined which checks confirmed that these devices are real refrigerators.

According to CNBC, hackers remotely raised the temperatures of refrigerators and freezers at supermarkets in at least six European countries (including Belgium, Sweden, Finland, Ireland, Luxembourg, and Estonia), in some cases to 50°C (122°F). European Commissioner for Agriculture and Food Christophe Hansen called the attacks “a deliberate attempt to disrupt” EU food supplies and undermine public confidence. This followed a similar attack in France about three weeks earlier that forced stores to discard large amounts of spoiled food.

The Guardian reported that no one has claimed responsibility or demanded money. Rafe Pilling, director of threat intelligence at Sophos, told the Guardian the most plausible explanations are a government demonstrating its capabilities or a lone hacker. No malware was reportedly used, which makes the attacks challenging to trace.

Refrigeration control software is internet-connected but often goes without security updates, either because updates require taking equipment offline or because the risk is overlooked. STRIKE has not linked the October attacks in France or the November 2 attacks across Europe to the activity described in this report; we include them as context for why these devices matter.

SecurityScorecard’s STRIKE Threat Intelligence Team is tracking abuse of Dixell/Copeland XWEB PRO controllers, the systems that run refrigeration at supermarkets and cold storage facilities. Many of these devices remain exposed to the public internet with unpatched vulnerabilities, and attackers are already turning compromised units into infrastructure for suspected criminal activity. We identified a suspected SMTP botnet: nine IPs, three of them confirmed XWEB controllers, act as outbound-only mail senders with no inbound mail. 508 of 1,041 targets were hit by two or more nodes, and the top three share about 47% of their target lists. That overlap is the strongest coordination signal.

The result is a dual risk for owners and operators: threats to the cold chain, and devices being used as tools for abuse.

This is a live investigation, and we are sharing indicators to help defenders act.

The SMTP cluster consists of nine IP addresses, three of them confirmed XWEB controllers. Of the mail targets observed, 508 were hit by at least two of these nodes. The three most active nodes share roughly 47% of their target lists. Separately, the XWEB advisory covers 23 CVEs.

XWEB PRO is a supervisory controller for commercial refrigeration, made by Dixell, now sold under the Copeland brand (Copeland was formerly Emerson’s climate technologies business). It is installed above the freezer and chiller racks in supermarkets and cold storage warehouses, where it communicates with the individual refrigerated cases over Modbus. It also hosts a web interface on ports 8015 and 443, allowing technicians to monitor temperatures and adjust setpoints remotely.

That remote-access convenience, along with the many owners and operators who have skipped patching, is part of why so many of these controllers are exposed to the public internet and why attackers keep returning to them. The firmware on exposed units is old enough to carry CVE-2026-25085 and its related vulnerabilities, so an unauthenticated attacker can reach the box.

Once reachable, it is a small Linux computer with a stable IP and nobody watching it. This means no security team, logging, or routine monitoring is in place to notice if the device has been compromised, so an attacker can use it for weeks or months without being detected. This creates raw material for abuse.

STRIKE first identified this activity on November 2, 2026, when flow data from exposed XWEB panels showed outbound SMTP traffic from nine IPs, three of them confirmed refrigeration controllers.

To identify the scope of the current refrigerator campaign, we started from SecurityScorecard’s Driftnet internet-wide scan data. The export is a per-host summary: one row per IP with its open ports, product, and banner tags, HTTP titles / server banners, and mapped Common Vulnerabilities and Exposures (CVEs) and Known Exploited Vulnerabilities (KEVs). We filtered it down to hosts whose banner or page title identifies an XWEB controller (the UI title tag and the cert CN are the reliable tells) on :8015 / :443.

See it on Driftnet here.

Two key notes on conducting this research for defenders:

After we filtered the data, the genuine exposed XWEB controllers carry the known KEVs and pre-auth firmware, confirming the exposure is real and current.

Pivoting from exposed panels to flow data, based on detected IPs, two things surfaced that lead us to believe that we are observing an active botnet.

Panel A: A tunnel gateway. 197.188.223[.]161 (Telecom Namibia). We found that 71% of all flows in the capture pass through it. Approximately 1.24 million outbound sessions go to a single host in South Africa (160.19.119[.]226:443), alongside ICS :8015 traffic and tags for OpenVPN, IPsec, proxyware, and RMM — a Sophos/OpenVPN gateway relaying third-party traffic.

Panel B: A residential-proxy exit. 168.195.122[.]22 (Air Link Communications, TT). The controller at 168.195.122[.]22 (Air Link Communications, TT) is almost entirely device-centric, with 99.6% of its traffic originating from the device itself. It also shows high fan-out, connecting to 10,643 distinct peers within a 17-hour window. Its traffic includes WireGuard, STUN, MQTT, and DNS queries sent directly to 8.8.8.8. Together, these patterns indicate that it is operating as a residential-proxy or proxyware exit, not as a freezer monitor.

We identified that shared C2 appears to still be weak: we found only two common endpoints with few flows (46.255.231[.]42:993, 143.244.202[.]96:2525). The coordination evidence is the target-list overlap, but we can’t yet point to a controller.

The raw data labels IPs by ISP rather than by device, and banners can be faked, so verifying device identity was something we carefully investigated. We confirmed it using passive reads only, including a plain HTTPS GET and a certificate grab, the same thing a browser does when opening the page. We ran no intrusive scans against third-party ICS .

Confirmed XWEB by passive read: 85.29.149[.]211 → cert CN “XWEB PRO” · 95.229.5[.]248 → cert “Dixell” · 78.21.151[.]21 → page title “XWEB EVO”.

A faked SMTP banner would not also present a Dixell-issued TLS certificate and the vendor’s web UI. The cert chain and the live user interface (UI) are hard to spoof together, which is what separates a real panel from a look-alike. The remaining IPs were unreachable from our egress, so they are unverified. Two of the nine sit behind consumer routers (MikroTik, Orange Livebox), so the XWEB box is one hop in, which is consistent with a small-site install, not a reason to drop them from the suspect list.

The likely way in is CVE-2026-25085 (CVSS 8.6), a flaw in the function XWEB uses to check logins (user_authenticate, written in the Lua scripting language). When the function receives a login type it doesn’t recognize, it returns an empty result instead of an explicit failure. In Lua, only an explicit “false” or a missing value counts as a no. Anything else, including that empty result, counts as a yes. So the device treats the check as passed and lets the attacker in without a password. It is one of 23 vulnerabilities that Claroty Team82 reported to CISA (advisory ICSA-26-057-10), which also include an admin password that can be calculated from the device’s MAC address and 19 command-injection flaws. These can be used by security teams and experts to build detection rules.

Early signals in infrastructure research often look more definitive than they are. We tested every claim against device-level evidence and refined our conclusions where the data pointed somewhere different:

Labels in the data, such as an ISP name, SMTP banner, or scrape bucket, are leads, not device identities. Confirm the device first, then make the claim.

Although the investigation is ongoing, our findings indicate that exposed industrial controllers are being used well beyond their original job, and the signals that reveal a compromised unit are straightforward to detect. Two takeaways for defenders:

Reach out to the STRIKE Threat Intelligence Team if you and your team are seeing similar activity or want to compare notes. This investigation is ongoing, and defender input helps us sharpen the picture: threatintel@securityscorecard.io. 

STRIKE’s overall confidence is low to medium. Device behavior and the SMTP coordination are well supported, but full device attribution and the C2 picture are still under investigation. When taking action, treat these IPs as victims or abused infrastructure, not as adversary-owned assets.