Blog
/
AI
/
June 10, 2026

Comment sécuriser l’IA en entreprise : cadre pratique pour modèles, données et agents

L’IA évolue à un rythme effréné que la gouvernance ne peut suivre, causant l’élargissement des surfaces d’attaque et l’invisibilisation de certains risques. Des données et modèles aux agents et intégrations d’IA, savoir ce qu’il faut protéger est une étape primordiale à tout effort de sécurité. Découvrez comment identifier les risques liés à l’IA, afin d’établir des cadres de gouvernance et des contrôles qui sécurisent l’innovation sans exposer de nouvelles surfaces d’attaque dans l’entreprise. 
Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Brittany Woodsmall
Senior Product Marketing Manager, AI
Written by
Simon Fellows
Senior Vice President, Product Strategy
How to secure AI in the enterprise: A practical framework for models, data, and agents Default blog image
10
Jun 2026

Points clés à retenir

  • La sécurité de l’IA en entreprise ne se limite pas à protéger les modèles d’IA : elle consiste également à sécuriser les agents IA, les données d’entreprise, les identités, les API et les intégrations tierces. Pour gérer efficacement les risques liés à l’IA, les organisations doivent savoir où l’IA est déployée, à quoi elle peut accéder et comment elle se comporte.
  • Un cadre efficace de sécurité de l’IA rassemble nécessairement gouvernance, gestion des identités et des accès, protection des données, surveillance de l’exécution et sécurité de la chaîne d’approvisionnement logicielle. Aucun contrôle ni garde-fou de l’IA ne suffit à lui seul à protéger l’IA d’entreprise.
  • L’adoption de l’IA et la sécurité de l’IA doivent évoluer de concert. L’intégration de contrôles de sécurité tout au long du cycle de vie de l’IA permet aux organisations de réduire les cyberrisques, de favoriser la conformité réglementaire et de développer leurs initiatives en matière d’IA à plus grande échelle avec davantage de confiance.

Pourquoi la sécurité de l’IA en entreprise est-elle désormais une priorité ?

La sécurisation de l’IA en entreprise est désormais une priorité, car son adoption progresse plus vite que la gouvernance, la propriété et les contrôles techniques. Les outils d’IA générative, les fonctionnalités d’IA intégrées et les agents autonomes peuvent accéder à des données sensibles, prendre des décisions et se connecter à des systèmes externes, créant ainsi des risques en matière de sécurité, de confidentialité, de conformité et au niveau des opérations. Pour de nombreuses organisations, le premier défi n’est pas de savoir s’il faut sécuriser l’IA, mais ce que signifie concrètement « sécuriser l’IA ». S’agit-il de protéger les modèles ? Régir les données ? Surveiller les réponses ? Ou contrôler le comportement des agents IA une fois déployés ?  

Alors que la demande d’adoption augmente, sécuriser l’utilisation de l’IA en entreprise reste une notion abstraite pour beaucoup, et rendre son utilisation opérationnelle va bien au-delà de la simple visibilité. Les professionnels doivent également prendre en compte la manière dont l’IA est acquise, développée, déployée, utilisée et encadrée dans l’ensemble de l’entreprise.

L’objectif pour les équipes de sécurité : mettre en œuvre un cadre clair de sécurité de l’IA articulé autour du cycle de vie. Ce blog présentera la diversité des cas d’usage de l’IA à prendre en compte lors de l’élaboration de ce cadre et la manière d’aborder ce sujet auprès d’un public non technique.  

Que signifie sécuriser l’IA en entreprise ?

Sécuriser l’IA consiste à maintenir une visibilité et un contrôle sur les domaines où l’IA est utilisée, les données auxquelles elle accède, le comportement des modèles et des agents, et la conformité de leurs actions aux objectifs de l’entreprise. Cela englobe les applications, les identités, l’infrastructure, les données, les processus de développement et les tiers, si bien que la responsabilité ne peut incomber à une seule fonction de sécurité.

La sécurisation de l’IA est souvent présentée comme un prolongement des disciplines de sécurité existantes. En pratique, cette hypothèse peut prêter à confusion.

Les fonctions de sécurité traditionnelles s’articulent autour de périmètres relativement stables. La sécurité des applications se concentre sur le code et la logique. La sécurité du cloud régit l’infrastructure et l’identité. La sécurité des données protège les informations sensibles au repos et en transit. La sécurité des identités contrôle qui peut accéder aux systèmes et aux services. Chaque fonction dispose d’une responsabilité clairement définie, d’outils établis, et de modes de défaillance bien compris.

L’IA ne correspond parfaitement à aucune de ces catégories. Un système d’IA est à la fois :

  • Une application qui exécute une logique
  • Un processeur de données qui ingère et génère des informations sensibles
  • Une couche de prise de décision qui influence ou automatise les actions
  • Un système dynamique qui change de comportement au fil du temps

Par conséquent, les risques de sécurité induits par l’IA concernent simultanément plusieurs domaines. Une seule interaction avec l’IA peut impliquer une utilisation abusive d’identités, une exposition des données, un détournement de la logique des applications et des risques liés à la chaîne d’approvisionnement, le tout au sein d’un même flux de travail. C’est à ce stade que les frontières traditionnelles entre les fonctions de sécurité commencent à s’estomper.

Par exemple, un prompt malveillant envoyé par un utilisateur autorisé ne constitue pas une compromission d’identité classique, mais il peut entraîner une fuite de données ou des actions non autorisées. Un agent IA qui appelle un service externe peut sembler relever d’un comportement légitime d’une application, alors même qu’il enfreint les exigences en matière de souveraineté des données ou de conformité. Le code généré par l’IA peut passer les contrôles de développement standard tout en introduisant des vulnérabilités subtiles ou des dépendances compromises.

Dans chaque cas de figure, aucune équipe de sécurité n’assume à elle seule la responsabilité du risque.

C’est pourquoi la sécurisation de l’IA ne peut se limiter à la sécurité des modèles, aux politiques de gouvernance ou aux seuls contrôles périmétriques. Cela nécessite une approche commune de la sécurité couvrant le développement, les opérations, le traitement des données et les interactions avec les utilisateurs. Sécuriser l’IA, c’est comprendre non seulement si l’accès aux systèmes est sécurisé, mais aussi s’ils sont utilisés, entraînés et autorisés à agir conformément aux objectifs de l’entreprise et à sa tolérance au risque.

Au fond, sécuriser l’IA consiste à rétablir la clarté dans des environnements où la responsabilité peut rapidement devenir floue. Il s’agit de savoir où l’IA est présente, comment elle se comporte, ce qu’elle est autorisée à faire et comment ses décisions affectent l’ensemble de l’entreprise. Sans cette clarté, l’IA devient un facteur d’amplification tant de la productivité que des risques.

Que doit couvrir un cadre de sécurité de l’IA en entreprise ?

Un cadre de sécurité de l’IA en entreprise doit prendre en compte les utilisations abusives et les comportements émergents, la surveillance au moment de l’exécution, le développement et l’infrastructure, l’IA fantôme et les chaînes d’approvisionnement tierces, ainsi que la préparation organisationnelle. Ensemble, ces domaines couvrent la manière dont l’IA est acquise, développée, déployée, utilisée, surveillée et gouvernée tout au long de son cycle de vie.

Il existe cinq domaines clés pour sécuriser l’IA en entreprise :

  • Se défendre contre les utilisations abusives et les comportements émergents de l’IA
  • Surveiller et contrôler l’IA en fonctionnement
  • Protéger le développement et l’infrastructure de l’IA
  • Sécuriser la chaîne d’approvisionnement de l’IA
  • Renforcer la préparation et la supervision

Ensemble, ces catégories offrent un cadre structuré pour comprendre comment les risques liés à l’IA se manifestent et où les équipes de sécurité devraient concentrer leurs efforts.

1. Se défendre contre les utilisations abusives et les comportements émergents de l’IA

Les systèmes et agents d’IA générative peuvent être manipulés de manière à contourner les contrôles traditionnels. Même lorsque l’accès est autorisé, l’IA peut faire l’objet d’une utilisation abusive, être détournée ou être influencée par des prompts et des interactions soigneusement conçus.

Les principaux risques comprennent :

  • Injection de prompt malveillant conçue pour contraindre à des actions indésirables
  • Cas d’usage non autorisés ou non prévus qui contournent les garde-fous
  • Exposition de données sensibles par le biais des historiques de prompts
  • Des réponses issues d‘hallucination ou malveillantes qui influencent le comportement humain

Contrairement aux applications traditionnelles, les systèmes d’IA peuvent produire des résultats préjudiciables sans être explicitement compromis. La sécurisation de cette couche nécessite de surveiller l’intention, et pas seulement l’accès. Les équipes de sécurité doivent savoir quelles instructions sont données aux systèmes d’IA, comment leurs résultats sont utilisés et si leur utilisation est conforme aux objectifs commerciaux approuvés

2. Surveiller et contrôler l’IA en fonctionnement

Une fois déployés, les agents IA fonctionnent à la vitesse et à l’échelle d’une machine. Ils peuvent lancer des actions, échanger des données, et interagir avec d’autres systèmes avec peu de supervision humaine. Cela rend la visibilité au moment de l’exécution essentielle.

Les risques opérationnels liés à l’IA comprennent :

  • Agents utilisant les autorisations de manière non prévue
  • Connexions sortantes non contrôlées vers des services ou des agents externes
  • Perte de visibilité forensique sur les composants d’IA éphémères
  • Transmission de données non conforme entre juridictions

Garantir la sécurité de l’IA en environnement opérationnel nécessite une surveillance en temps réel du comportement des agents, des points de contrôle centralisés tels que les passerelles IA, et la capacité de relever l’état des agents à des fins d’investigation. Sans ces capacités, les équipes de sécurité peuvent manquer de visibilité sur le comportement des systèmes d’IA une fois en production, en particulier dans des environnements cloud natifs ou réglementés.

3. Protéger le développement et l’infrastructure de l’IA

De nombreux risques liés à l’IA apparaissent bien avant le déploiement. Les pipelines de développement, les configurations d’infrastructure, et les décisions architecturales influencent tous la posture de sécurité des systèmes d’IA.

Les risques courants comprennent :

  • Autorisations et garde-fous mal configurés
  • Architectures d’agents non sécurisées ou trop complexes
  • L’Infrastructure as code (IaC) à l’origine de problèmes de configuration cachés
  • Vulnérabilités du code généré par l’IA et des dépendances

Le code généré par l’IA ajoute une nouvelle dimension au risque, car l‘hallucination de paquets ou le détournement de logique peuvent être plus difficiles à détecter et à déboguer que le code écrit par des humains. Sécuriser le développement de l’IA implique d’appliquer des contrôles de sécurité dès le début, notamment une analyse statique, une revue de l’architecture et une surveillance continue de la configuration tout au long du processus de développement.

4. Sécuriser la chaîne d’approvisionnement de l’IA

Les chaînes d’approvisionnement de l’IA sont souvent opaques. Les modèles, les jeux de données, les dépendances et les services peuvent provenir de tiers offrant des niveaux variables de transparence et de garanties.

Principaux risques liés à la chaîne d’approvisionnement :

  • Outils d’IA fantôme utilisés en dehors des contrôles approuvés
  • Agents IA externes bénéficiant d’un accès interne
  • Prestataires appliquant l’IA aux données d’entreprise sans le déclarer
  • Modèles, données d’entraînement ou dépendances compromis

Sécuriser la chaîne d’approvisionnement de l’IA nécessite de découvrir où l’IA est utilisée, de valider la provenance et les licences des modèles et des données, et d’évaluer la manière dont les fournisseurs traitent et protègent les informations de l’entreprise. Sans cette visibilité, les organisations s’exposent à des fuites de données, à des risques réglementaires et à des compromissions en aval par le biais d’intégrations de confiance.

5. Renforcer la préparation et la supervision

Même avec des contrôles techniques robustes, la sécurité de l’IA échoue en l’absence de gouvernance, de tests et d’équipes formées. L’IA introduit de nouveaux scénarios d’incident auxquels de nombreuses équipes de sécurité ne sont pas encore préparées à faire face.

Les risques liés à la supervision comprennent :

  • Manque de reporting pertinent sur les risques liés à l’IA
  • Systèmes d’IA non testés en production
  • Équipes de sécurité non formées aux menaces spécifiques à l’IA

Les organisations ont besoin de rapports qui tiennent compte de l’IA, d’exercices de red teaming et de purple teaming intégrant les systèmes d’IA, ainsi que de formations continues pour renforcer leur préparation opérationnelle. Ces capacités permettent de comprendre et de tester les risques liés à l’IA, et d’améliorer continuellement leur gestion, plutôt que de les découvrir lors d’un incident en cours.

Repenser la sécurité de l’IA pour les dirigeants

La sécurité de l’IA n’est pas qu’un enjeu technique. C’est une question de confiance, de responsabilité et de résilience. Les conseils d’administration veulent avoir l’assurance que les décisions fondées sur l’IA sont fiables, explicables et protégées contre toute manipulation.

Une communication efficace avec la direction porte sur :

  • Confiance : assurance quant à l’intégrité des données, le comportement des modèles et les réponses
  • Responsabilité : une attribution claire des responsabilités entre les équipes et les fournisseurs
  • Résilience : la capacité d’opérer, d’auditer, et de s’adapter en cas d’attaque ou face à la réglementation

Calquer les initiatives de sécurité de l’IA sur des référentiels reconnus tels que la norme ISO/IEC 42001 et le NIST AI Risk Management Framework contribue à démontrer la maturité et à aligner la sécurité de l’IA sur des objectifs de gouvernance plus larges.

Conclusion : la sécurisation de l’IA est un défi qui s’étend sur l’ensemble de son cycle de vie

Les mêmes caractéristiques qui font de l’IA une technologie transformatrice la rendent également difficile à sécuriser. Les systèmes d’IA brouillent les frontières traditionnelles entre les logiciels, les utilisateurs et la prise de décision, élargissant ainsi la surface d’attaque de manière subtile, mais significative.

Sécuriser l’IA nécessite de rétablir la clarté. Savoir où l’IA intervient, comment elle se comporte, qui la contrôle et comment elle est régie. Une approche fondée sur un cadre de référence permet aux organisations d’innover avec l’IA tout en maintenant un niveau élevé de confiance, de responsabilité et de contrôle.

La sécurisation de l’IA est un processus continu, mais elle commence par la compréhension des risques sur l’ensemble du cycle de vie de l’IA et par la mise en place de pratiques de sécurité qui évoluent au même rythme que la technologie.

Darktrace / SECURE AI soutient cette approche du cycle de vie en réunissant une visibilité à l’échelle de l’entreprise, une surveillance des comportements et un contrôle en temps réel, ce qui aide les équipes de sécurité à identifier les activités à risque et à adopter l’IA de manière plus sûre.

[related-resource]

Téléchargez le cadre de référence complet

Découvrez comment identifier les risques liés à l’IA afin d’établir des cadres de gouvernance et des contrôles dans votre organisation.

Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Brittany Woodsmall
Senior Product Marketing Manager, AI
Written by
Simon Fellows
Senior Vice President, Product Strategy

More in this series

No items found.

Blog

/

AI

/

October 26, 2026

PHP Vulnerabilities, ARTEX and the Growing Role of AI in Cyber Attacks

Default blog imageDefault blog image

The disclosure of CVE-2026-109618 and CVE-2026-109619 placed immediate pressure on organizations running PHP. Both vulnerabilities can allow unauthenticated remote code execution, including in products and appliances where PHP is embedded, and updates depend on third-party vendors [1].

Early guidance focused on patching internet-facing systems and monitoring for behavior associated with successful exploitation, including unexpected command execution, Webroot changes and outbound connections from PHP servers.

Darktrace observed widespread scanning across monitored environments involving hundreds of distinct source IP addresses that public reporting has associated with activity targeting the PHP vulnerabilities. The volume of scanning was significantly greater than the evidence available for successful exploitation. For analysts, that distinction is important. Scanning demonstrates interest in exposed infrastructure; establishing compromise requires evidence of subsequent behavior on the targeted system, including command execution, file modification or unexpected outbound communication.

PHP is not an isolated example. Imperva subsequently demonstrated remote code execution against a vulnerable Node.js build through malicious Brotli data, reproducing execution through compressed HTTP responses and configured request parsers. The same inputs were rejected by the patched runtime. Imperva linked its Node2Shell and PHP2Shell research to the increasing speed of vulnerability discovery and exploit development. [2]

While Darktrace has not observed direct evidence of CVE-2026-109618 or CVE-2026-109619 exploitation, on October 21st we observed a six-month high in detections consistent with zero-day exploitation activity, representing a 64% increase compared to historic data. This increase has not been confirmed as related to the PHP vulnerabilities. Darktrace’s behavioral approach is designed to detect anomalous activity without relying solely on rules written for a specific exploit. Comparable increases were observed around the Log4j disclosure and other globally significant vulnerability disclosures.

AI-assisted vulnerability research

The PHP disclosure arrives as AI systems have become more capable at vulnerability research [3]. OpenAI launched Daybreak in June 2026, combining GPT-5.5-Cyber, Codex Security and partnerships with security researchers and software maintainers. OpenAI says its models have been applied to discovering and generating patches for vulnerabilities in browsers, network infrastructure, FreeBSD and the Linux kernel. Darktrace joined the OpenAI Daybreak Cyber Partner Program in June to explore how OpenAI's cyber capabilities could be integrated within Darktrace products and services [4][10].

OpenAI reported in August that Codex Security Cloud had analyzed more than 30 million commits across more than 30,000 codebases. According to OpenAI, Cloudflare uses models accessed through Daybreak to investigate customer-authorized code and combines findings with live traffic and security signals to assess whether affected routes are active or receiving suspicious traffic, with proposed mitigations and patches remaining subject to customer review [5][6].

Faster discovery still leaves defenders with the work of locating affected software, testing fixes and completing remediation. The PHP case shows that gap clearly, particularly when vulnerable runtimes are embedded inside other products.

Enterprise agents as an attack surface

Darktrace Signal Labs has also examined how a trusted enterprise agent could be abused after an attacker has already obtained access to an environment. In a controlled simulation, researchers demonstrated that, in that post-compromise scenario, the Claude platform’s memory stores feature could be abused to establish a live C2 channel between an external operator and internal Claude Code agents. The external operator was able to dynamically assign network discovery, credential access, and data exfiltration tasks to the agents via this C2 channel. Detection of the agents’ activities relied on the correlation of process creation and network traffic activity from agent harness processes, alongside behavioral analysis to identify deviations from expected behavior. Darktrace has not claimed it observed this memory-store command-and-control technique in operational attacks [7].

AI-assisted attacks in Japan

Evidence from Japan indicates AI being used for vulnerability scanning and attacks outside controlled research. On 21 October, JPCERT/CC published findings from an investigation into recent unauthorized access incidents affecting organizations in Japan. JPCERT/CC states that it confirmed attackers had used AI to scan for known vulnerabilities and conduct attacks through APIs. According to JPCERT/CC, its examination of attack infrastructure found evidence of Android application analysis, API discovery and testing for weaknesses including server-side request forgery, and the infrastructure also targeted services intended for users outside Japan [8].

JPCERT/CC does not identify ARTEX by name in that publication. The named ARTEX attribution comes from separate investigations, including Microsoft's analysis of Storm-0940.

AI in offensive operations

Microsoft describes ARTEX as an open-source, multi-agent penetration-testing system capable of automating activity with limited human interaction. Microsoft reported that Storm-0940, which it assesses to be a China state-aligned actor active since 2021, used ARTEX against hundreds of organizations, and Microsoft attributed the ConnectWise supply-chain compromise [9].

Microsoft observed ARTEX accelerating scanning, reconnaissance, password spraying and OAuth application abuse. Several ARTEX-driven operations reached privileged cloud access less than three hours after initial targeting. Following the ConnectWise compromise, Storm-0940 attempted to authenticate to more than 2,250 tenants at rates of up to 2,900 attempts per minute [9].

Darktrace Threat Research found activity in its own telemetry involving infrastructure later associated with the campaign. On 13 October, Darktrace recorded failed authentication activity involving 144.172.64[.]128, one of the addresses Microsoft later identified as performing sign-ins and Microsoft Graph activity in ConnectWise customer environments. Darktrace analysis identified 65 failed authentication attempts in around 20 minutes.

Figure 1: Darktrace Advanced Search showing failed authentication events involving 144.172.64[.]128 on 13 October 2026, (customer-identifying information redacted).

The telemetry establishes repeated failed authentication from infrastructure later associated with the campaign. It does not establish ARTEX execution or successful compromise. At the time of observation, Microsoft's later attribution was unavailable. Analysts therefore had the behavior itself: repeated failed authentication from the same source over a short period, together with any related identity, application or network activity inside the environment.

Microsoft documented a wider password-spray campaign against 327 accounts across eight organizations between 10 and 14 October. It recorded more than 151,000 failed logons, including more than 111,000 on 11 October, but no successful authentication, token issuance, Graph call or directory change from that campaign. Microsoft also reported that most Storm-0940 targeting was unsuccessful [9].

Where the actor progressed beyond authentication, Microsoft observed service-principal sign-ins followed by Graph and directory operations. Activity included reconnaissance, application credential changes and attempts to modify privileges. Microsoft recommends correlating service-principal sign-ins with Graph activity, directory changes and resource access [9].

Behavior before attribution

The PHP and ARTEX cases begin with different information. PHP defenders knew which software required urgent remediation but initially had limited information about exploitation. Process execution, file modification and outbound communication could still provide evidence of compromise.

The PHP and ARTEX observations also illustrate the difference between volume and impact. Darktrace observed broad scanning around the PHP disclosure, while the ARTEX-associated infrastructure produced concentrated authentication activity. Neither observation independently demonstrates compromise and in each case examining the behavior that follows the initial interaction is the investigative clue.

The Darktrace ARTEX-related observation began with authentication behavior. Microsoft publicly attributed the source infrastructure eight days later. That attribution added context, but it did not change what had originally been recorded in the environment.

AI is now present at several points in this cycle. Daybreak applies models to vulnerability discovery and remediation. Darktrace Signal Labs demonstrated how a trusted enterprise agent could be co-opted in a controlled environment. JPCERT/CC confirmed AI-assisted vulnerability scanning and API attacks in recent incidents. Microsoft documented ARTEX being used by Storm-0940 in active operations [4][7][8][9].

Microsoft's findings also show why scale and impact must be assessed separately. One ARTEX-associated campaign produced more than 151,000 failed logons without successful access, while other operations reached privileged cloud access in less than three hours. Security teams have to distinguish high-volume attempts from activity that progresses through authentication, privilege changes and resource access.

The evidence required to assess these cases remains familiar: authentication records, process execution, application and directory changes, file activity and network communication. AI can increase the rate at which those behaviors occur. Defenders still need to establish their sequence and impact.

Credit to Emma Foulger, Sam Lister, Dylan Evans, Moishe Tajtelbaum

References

[1] NCSC-NL, php2shell vulnerabilities (CVE-2026-109618, CVE-2026-109619), 21 October 2026. https://github.com/NCSC-NL/php2shell

[2] Imperva, https://www.imperva.com/blog/node2shell-from-brotli-data-to-remote-code-execution/

[3] Cyber Security Agency of Singapore, https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-151/

[4] OpenAI, Daybreak: Tools for securing every organization in the world, 22 June 2026. https://openai.com/index/daybreak-securing-the-world/

[5] OpenAI Developers, Scaling cyber defenders with Daybreak, 21 August 2026. https://developers.openai.com/blog/scaling-cyber-defenders-with-daybreak

[6] OpenAI, Cloudflare links vulnerability discovery to defense with OpenAI, 21 October 2026. https://openai.com/index/cloudflare-cyber/

[7] Darktrace Signal Labs, Shared Memories as a Covert C2 Channel, draft research supplied for review.

[8] JPCERT/CC, Recent AI-Assisted Cyber Attacks in Japan: Investigating Attack Infrastructure and Techniques, 21 October 2026. https://blogs.jpcert.or.jp/en/2026/10/web_api_attacks.html

[9] Microsoft Security Research and Microsoft Threat Intelligence, AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise, 21 October 2026. https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/

[10] Darktrace, Advancing the Use of Frontier AI in Cybersecurity: Darktrace Joins the OpenAI Daybreak Cyber Partner Program to Explore Defensive AI Integrations, 22 June 2026. https://www.darktrace.com/blog/advancing-the-use-of-frontier-ai-in-cybersecurity-darktrace-joins-the-openai-daybreak-cyber-partner-program-to-explore-defensive-ai-integrations

Continue reading
About the author
Nathaniel Jones
SVP, Global Threat Intelligence

Blog

/

OT

/

October 23, 2026

Beyond the Fridge: Exposed Industrial Control Systems

Default blog imageDefault blog image

Introduction

In October 2026, hundreds of supermarkets across France were reportedly affected by a cyberattack targeting their refrigeration systems. According to public reports, the attackers gained access to internet-connected controllers and modified their settings, forcing refrigeration units into high and extremely low temperatures and causing significant disruption. Total losses have been reported to reach several million euros.

The incident drew attention to the security of industrial refrigeration systems, particularly older devices with exposed management interfaces and known vulnerabilities.

The exact details of how the attackers gained access have not been confirmed, however it is speculated that the public-facing web server could be accessed with the username “admin” and password being the current date. Researchers from Claroty’s Team82 identified a vulnerability in Danfoss AK-SM 8xxA Series in 2025, “CVE-2025-41450", allowing for administrative access using a time-based “code-of-the-day" for authentication [1].

Default credentials, outdated firmware and publicly accessible administrative interfaces have been an issue for years. And yet these systems continue to appear in internet scans and require little sophistication to gain admin access. A simple search of internet-connected devices shows a range of exposed devices from Programmable Logic Controllers (PLCs) and remote gateways, to, yes, more fridges.

Darktrace malware researchers identified hundreds of IoT and OT devices publicly exposed on the internet, many of which are configured with no authentication, weak credentials, or default credentials. As shown in Figure 1, an exposed Copeland XWEB web interface, used to manage Dixell equipment, including refrigerators, can provide the ability to remotely control connected devices.

‍

Figure 1: Copeland XWEB interface used to control systems including refrigerators and air conditioning.

However, it’s not only fridges; web management interfaces for industrial controls are also publicly accessible, often protected only by weak credentials. Figure 2 shows an example of a publicly exposed WAGO interface. The WAGO management interface is a configuration and administration panel for controllers. Through it, a logged-in user can view device details and diagnostics, manage user accounts and passwords, update firmware, back up or restore the full configuration, set the clock, and manage SD card storage. While it typically doesn’t manage switch outputs or read live process values, someone with access could still disrupt operation by changing network or Modbus settings, loading bad firmware or configurations, or by resetting passwords and enabling insecure services.

‍

Figure 2: WAGO Management interface.

‍

The issue extends beyond management interfaces. During our research, we identified publicly accessible web interfaces belonging to PLCs, including Rockwell Automation Allen-Bradley devices. In each case, the risk arises from how the devices have been deployed and configured, not from a flaw in the vendors’ products.

‍

Figure 3: Web interface for Allen-Bradley CompactLogix controller.

‍

Figure 3 shows the web interface of an Allen-Bradley CompactLogix controller. Unlike the previous examples, this interface provides a view into the controller's operation, including running tasks, network connections, memory usage and diagnostic information. Rockwell Automation's CompactLogix controllers are commonly used to automate industrial processes, from manufacturing and packaging lines to water treatment and material handling systems. Depending on their configuration, these controllers can operate motors, pumps, valves and other physical equipment.

Although in this example the interface shown does not provide direct control over the PLC's logic, it exposes information about the model, firmware, network layout, and connections, which is useful reconnaissance for a bigger attack.

The concern is not necessarily that every exposed interface allows an attacker to immediately manipulate industrial processes. However, these devices are accessible from the public internet in the first place, providing information about systems that may be responsible for controlling physical equipment.

The attacks on refrigeration systems in France highlight the consequences of poorly secured industrial devices. As demonstrated throughout this research, publicly accessible management interfaces are not limited to refrigeration controllers but extend to PLCs and other systems used to manage industrial equipment.

Finding these devices requires little effort. Internet scanners make it possible to identify publicly exposed interfaces quickly, and in some cases these interfaces rely on publicly documented default credentials or have no authentication at all. As attackers increasingly use AI tools, such attacks may be identified and carried out faster and at a greater scale.

The consequences of this access depend on the device and the functionality exposed. While some interfaces provide little more than diagnostic information, others allow users to modify configurations, disrupt communications, or change settings that affect physical equipment. In industrial environments, this can result in operational downtime, damaged equipment and financial losses.

Weak passwords, default credentials and exposed administrative interfaces are not new security issues. Yet their continued presence on internet-connected industrial systems demonstrates how easily preventable weaknesses can leave physical operations vulnerable to attack.

Exposed devices often come from third-party suppliers and contractors, who frequently install refrigeration controllers, gateways and PLCs without the organization ever being aware they are connected to the internet. Asset visibility remains an important foundation, but organizations should assume that some unknown assets and services will exist. Effective security therefore also depends on continuous monitoring, anomaly detection, network segmentation and rapid response, so that risky exposure and unusual activity can be identified and addressed before it becomes disruptive.

Darktrace helps security teams gain visibility across IT and OT and respond to risks: https://www.darktrace.com/products/operational-technology.

Copeland, Dixell, WAGO, Rockwell Automation, Allen-Bradley and CompactLogix are trademarks of their respective owners. Their use here is for identification only and does not imply any affiliation with or endorsement by those owners.

References

1.        https://claroty.com/team82/research/freeze-the-controller-defrost-the-food-uncovering-vulnerabilities-in-danfoss-refrigeration-controllers

‍

Continue reading
About the author
Tara Gould
Malware Research Lead
Your data. Our AI.
Elevate your network security with Darktrace AI