A Hunting Sheet for Refrigeration Controllers After a Cold-Chain Attack

When an attack on supermarket refrigeration becomes public, the organisations most affected are often not the ones named. A retail chain in another country runs the same controller class, the same monitoring gap, and the same assumption that a control panel has no reason to face the internet. The work that follows is a hunt, and a hunt needs a sheet rather than a narrative.
This sheet is built from the 11 October 2026 incident in France, where cooling systems at hundreds of supermarkets were disrupted and Danfoss confirmed its equipment was targeted.

Step 1: Establish whether the asset class is yours

Before any log query, confirm that you own the equipment being discussed. Danfoss named the AK-SM800 and AK-SC355, which no longer receive security updates, and the AK-SM800A, which does. StoreView is the control panel in front of those controllers. If none of those names appear in your asset register, the rest of the sheet does not apply, and the correct output is a note for the procurement team rather than an investigation.
If they do appear, the asset register is already the most valuable evidence you hold, because it links a serial number to a site, a contract and a maintenance provider.

Step 2: Measure external reachability before touching logs

An incident hunt that starts in the SIEM starts in the wrong place when the question is whether a device is exposed. The external view is faster and independent, and it produces a number that can be re-checked after a change.
The ZoomEye header query run on 22 October 2026 gives the shape of that measurement:
| Query | Result |
| --- | --- |
| http.header="Danfoss" | 260 |
| http.header="Danfoss" && port="80" | 120 |
| http.header="Danfoss" && port="443" | 132 |
| http.header="Danfoss" && is_ipv4=true | 138 |
| http.header="Danfoss" && is_domain=true | 122 |
| http.header="Danfoss" && country="NL" | 54 |
| http.header="Danfoss" && country="US" | 28 |
| http.header="Danfoss" && country="DE" | 25 |
| http.header="Danfoss" && country="FR" | 1 |
The count is not a vulnerability count and not a compromise count. It answers one question: does a public address respond with this vendor string? Record the query, the date and the count, because that record becomes the baseline against which every later claim is checked.
A country filter narrows the set but does not assign ownership. Fifty-four Dutch assets are not fifty-four Dutch operators, and the presence of a panel in a country does not mean a local entity controls it.

Step 3: Build the log queries the attack would leave

External exposure tells you where to look. The incident tells you what a compromise would have left behind. Danfoss did not confirm the initial access vector, so the hunt has to cover several plausible paths without asserting one.
The log questions worth answering, in order of evidentiary value:

1. Did the controller panel accept a connection from an address outside the operator's known ranges? Start with the panel's own access log if it has one, then the firewall in front of it.
2. Did the panel's firmware version change, or did the device reboot outside a maintenance window? A reboot before the incident is a weak signal; a reboot combined with an unusual source address is a strong one.
3. Did temperature telemetry diverge from the physical record? The Claroty demonstration showed that CVE-2025-41450 and CVE-2025-41451 could be chained to disable cooling while falsifying readings. A refrigeration log that reports normal temperature during a known disruption is the single most interesting artefact in this incident class.
4. Did anyone use remote support access around the incident window? Third-party maintenance is a legitimate and frequent path into these panels, and it is also the path least likely to be reviewed.

Step 4: Separate what you know from what you inferred

A hunt sheet is only useful if it keeps the epistemic layers apart. In this incident the layers are:
| Layer | Status |
| --- | --- |
| Attack on French supermarket cooling | Confirmed by Danfoss |
| Affected models and firmware state | Stated by Danfoss |
| Chained RCE against two CVEs | Demonstrated by Claroty |
| Initial access vector | Not confirmed |
| Mass disconnection as the response | Inferred by Censys from version-category shrinkage |
An investigation that promotes the last two rows to fact will produce a report nobody can defend. An investigation that keeps them as inferences can still act on them, because disconnection is cheap and the version question is answerable internally.

Step 5: Close with evidence, not intent

The final row of any hunt sheet is the one most often skipped. Three artefacts close a refrigeration hunt credibly:

1. A dated external measurement before and after any change, using the same query string.
2. A firmware version read from the device, matched against the 4.3.1 boundary that covers all three 2025 CVEs.
3. A named owner for each panel, with a documented decision to keep it internet-facing or not. ZoomEye contributes to the first artefact and nothing else. It cannot read firmware, cannot see a private-range panel and cannot confirm that a restored device was patched. A sheet that says so is more useful than one that implies a search engine closed the case.

The sheet in one line

Measure reachability from outside, then read firmware from the device, then reconcile the two against a named owner. Everything else in this incident, including the 71% drop that followed, is context for that sequence.

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