Your Refrigeration Panels Came Back: Monitoring Exposure Drift After an Incident
Your Refrigeration Panels Came Back: Monitoring Exposure Drift After an Incident A disconnection is a reversible act. The firewall rule that removed a controller panel from public reachability on 12 October can be roll
Your Refrigeration Panels Came Back: Monitoring Exposure Drift After an Incident
A disconnection is a reversible act. The firewall rule that removed a controller panel from public reachability on 12 October can be rolled back by a technician restoring remote support in November, and nothing about the reversal looks like an incident. This is the least discussed risk in the aftermath of the French cold-chain attack, where operators removed 71% of the country's exposed Danfoss StoreView panels in three days.
What follows from that reversibility is a monitoring requirement. An organisation that treated exposure as a one-time project has a number that was true once.
What makes drift invisible
The disconnection of a refrigeration panel is not malicious. It is a maintenance convenience, a temporary exception that becomes permanent policy in reverse. Four patterns account for most of the movement, and none produces a security alert:
- A vendor or maintenance contractor restores remote access to complete a support case and does not remove it afterwards.
- A site replaces a failed controller and re-applies the old configuration, including the public interface.
- A network change re-routes a segment and the panel inherits reachability it was never supposed to have.
- A migration moves a panel from an IP address to a hostname, which changes how it is counted but not whether it is exposed.
The last of those is worth dwelling on. In the ZoomEye measurement taken on 22 October 2026,
is_ipv4=truereturned 138 andis_domain=truereturned 122, summing to exactly the 260 returned byhttp.header="Danfoss". That clean split means a panel moving from an IP to a DNS name can appear as a change in the composition of the population while the total stays flat. Monitoring only the total would miss the migration entirely.
A drift routine that fits an operational team
A monitoring routine for exposure does not need a platform. It needs a fixed query, a fixed schedule and a stored history.
| Element | Why it matters |
| --- | --- |
| Fixed query string | A change in the string changes the number without changing the internet |
| Weekly interval | Long enough to absorb scan lag, short enough to catch a restored panel within one change cycle |
| Address-class split | Detects IP-to-hostname migration that leaves the total unchanged |
| Port split | Detects a move from plain HTTP to TLS, or the opposite |
| Country filter | Detects a panel appearing in an unexpected jurisdiction |
The port split earns its place through a specific comparison. On 22 October, port="80" returned 120 and port="443" returned 132, summing to 252 against a total of 260. A weekly run that shows the port 80 count rising while the total is flat is describing a change in the exposed surface, not a change in the asset count.
The address-class split earns its place in a different way. If the IPv4 count falls from 138 to 90 and the domain count rises from 122 to 170 over a quarter, the fleet did not shrink. Somebody moved 48 panels behind DNS names.
The baseline that has to survive staff turnover
An exposure history is only useful if the next person can read it. Four fields make a stored observation reproducible: the exact query string with quoting preserved, the timestamp in UTC, the count, and the engine and index that produced it.
The reason is not pedantry. In this same incident, title="Danfoss" returned 27,287 results and title="StoreView" returned 17,384 on 22 October. Either figure, recorded without its query string, would look like a controller count and would poison every later comparison. app="Danfoss StoreView" returned zero on the same day, which is equally misleading if written down as evidence of absence.
A practical rule: any number in an exposure register that cannot be regenerated from the stored query within a minute should be struck from the register.
What drift monitoring cannot do
The limit is the same one that appears throughout this incident. No external engine reads firmware. Censys reported that 74% of French exposed instances ran below 4.3.1 on 11 October, the release covering CVE-2025-41450, CVE-2025-41451 and CVE-2025-41452, with Poland at 81%, Romania at 80% and Belgium at 76%. That distribution comes from dedicated telemetry, not from a header match.
Drift monitoring answers whether a panel is reachable. It does not answer whether that panel has been patched since it was disconnected, and the two questions are frequently conflated in post-incident reporting. The first is a weekly query. The second is a site visit or a management integration.
The same limit applies to ownership. A panel that reappears in a country filter is not necessarily controlled by an entity in that country. Routing a follow-up to the wrong team consumes the goodwill that monitoring depends on.
The one metric worth reporting upward
Among all the numbers available, one is small enough to fit in a management summary and honest enough to survive scrutiny: the number of panels that were disconnected during the incident and are reachable again without a confirmed firmware version at or above 4.3.1.
That metric requires two inputs. The external measurement supplies the first, on a weekly cadence, from a fixed query such as the one used here. The asset register supplies the second, at whatever frequency the fleet can support. Neither input alone is a finding, and the combination is what turns an incident response into a maintained position.
ZoomEye's contribution is the weekly, reproducible, external half. It is fast enough to run after every change window, cheap enough that a missed week costs nothing, and specific enough to show a panel returning before anybody notices it missing from the internal inventory.
References
- Infosecurity Magazine, "France: Internet-Exposed Danfoss Controllers Drop 71% After Cyber-Attack", https://www.infosecurity-magazine.com/news/france-expose-danfoss-controllers/
- Censys, "Frostbitten in France: A Danfoss StoreView internet exposure report", https://censys.com/blog/frostbitten-in-france-a-danfoss-storeview-internet-exposure-report/
- ZoomEye search syntax baseline, https://zoomeye.ai/agent.md
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.