Incident Analysis6 min read

France’s Supermarket Attack: How 1-SEC Can Stop Unauthorized Access Earlier

The refrigeration attacks in France show how exposed management interfaces can become a route to physical disruption. 1-SEC v0.4.24 adds a general access decision that trusted gateways can enforce before forwarding management requests.

Download this release on GitHub →
1S

Threat Intelligence Team

France supermarket attackIoT securityOT securitymanagement accessaccess controlattack preventionv0.4.24

A Remote Login Can Become a Physical Incident

Cyberattacks disrupted supermarket refrigeration in France this week. Associated Press reported that attackers forced continuous defrost cycles and settings as high as 50°C, with spoiled stock and reported fires under investigation. Refrigeration management had become a route to disruption on the shop floor.

France’s CERT-FR confirmed compromises affecting Danfoss AK-SM and AK-SC systems and Copeland/Dixell xweb controllers. Its advice includes removing public management exposure, protecting remote access, and securing supported equipment. Claroty’s October 13 research states that the precise entry method used in the France attacks remains unconfirmed. Known controller vulnerabilities are relevant background, but naming one as the proven cause would go beyond the available evidence.

Protect the Administration Path Before Settings Can Change

An administration interface gives someone the ability to change how a system behaves. That could mean refrigeration settings, building controls, an industrial process, a network appliance, or a hosted service. The security question is the same: who is being admitted, from where, and through which verified access path?

General access controls can interrupt an attacker before any equipment-specific command is issued. A controller’s vulnerable login should sit behind a protected management path with independent identity verification. Direct public access must be removed so an attacker cannot simply go around that protection.

This incident prompted a concrete enhancement to 1-SEC’s general management-access controls. It applies across connected equipment and management services.

What v0.4.24 Adds

1-SEC now provides an authenticated access decision that a trusted gateway can consult before forwarding a management request. Access requires three things together: the original client address belongs to a configured IP or network range, the operator’s exact verified identity appears on the configured list, and the gateway confirms that it independently authenticated that identity.

An empty policy denies every request. Outside-network addresses, unknown operators, unverified identities, and missing context receive a deny decision. Read-only API credentials cannot use this authorization endpoint. Invalid addresses, ambiguous identity text, oversized requests, and malformed request fields are rejected or denied.

The gateway owns identity verification and forwarding. An end user cannot be allowed to supply their own verification flag or impersonate an allowed address through an arbitrary forwarding header. The integration must derive those values from its trusted authentication and connection context, and keep its 1-SEC write credential private.

How an Attack Could Be Interrupted

Consider a controller whose management interface is accessible only through a trusted gateway. An attacker connects from outside the permitted management network and attempts to open its administration interface. The gateway checks with 1-SEC first. The source does not match the policy, so the gateway rejects the request before it reaches the controller.

If an attacker reaches the permitted network but presents an unverified or forged operator session, the independent identity requirement provides another rejection point. Exploiting the controller’s own login does not remove the need to pass that separate gateway check.

Those paths could prevent unauthorized management access before an attacker changes operational settings. This is a deployment scenario, not a finding about the actual intruders’ route in France. It requires the gateway to be mandatory, correctly integrated, and protected from compromise.

Make Exposed Management Visible

IoT Shield also gains alerts for publicly reachable management interfaces reported by a trusted inventory integration. Network-flow observations from the internet into OT, SCADA, PLC, safety, management, or IoT zones now violate its segmentation policy. These controls can help teams identify a dangerous administration path before an incident escalates.

The configured access policy also applies to management-access and OT command telemetry. Failed checks produce critical alerts through the existing pipeline. Public exposure, network-zone classification, and command identity need to come from trustworthy integrations; 1-SEC does not automatically discover every controller or decode each vendor’s administration protocol.

We corrected existing dangerous-command alert wording to say that a command was detected. An alert does not prove a packet was rejected. Request prevention happens when the gateway enforces the decision, while response actions depend on the configured integration and enforcement mode.

Verified Before We Describe It as Protection

The regression suite includes a simulated management gateway using the real authenticated 1-SEC API handler. An outside-network attempt and a forged-session attempt are rejected without touching its protected backend. An authorized operator’s request succeeds. When the policy API is unavailable, the gateway does not forward another request.

Additional tests cover IPv4 and IPv6 network boundaries, misleading address strings, exact operator matching, strict verification types, API credential scope, unavailable policies, public exposure events, segmentation checks, and policy changes that require restart. The Go suite passes with race detection, and the engine build, static checks, security scan, and dependency checks pass.

These are controlled access-path tests. We did not replay the France exploit, test against affected refrigeration hardware, or establish that 1-SEC was present in the affected supermarkets. The new controls were implemented after the incident.

Deploy the Gate Where Access Happens

Upgrade to v0.4.24, configure the permitted management sources and operators, and connect a trusted management gateway to the access decision endpoint. Keep protected equipment unreachable around that gateway. Forward each protected request only after an explicit allow; failures, timeouts, and invalid replies must deny access. Use TLS when the gateway calls 1-SEC across a network.

The gateway or identity service still handles session validity, MFA where required, and permissions for individual resources and actions. The operator list controls admission to the protected management surface; it is not a complete role-based permission model. An already authorized compromised account, an exposed alternate route, or a compromised gateway remains a risk.

This update does not add refrigeration temperature limits or defrost rules. Equipment operating limits and independent physical safeguards remain important. The prevention claim is specific: correctly deployed general access controls can stop unauthorized management requests before they reach the system that changes those settings.

Sources and implementation

Try 1-SEC Today

Open source, single binary, 16 security modules. Download and run in under 60 seconds.