Blog
/
AI
/
June 10, 2026

Cómo proteger la IA en la empresa: un marco práctico para modelos, datos y agentes

La IA avanza a un ritmo más rápido del que la gobernanza puede seguir, lo que amplía las superficies de ataque y genera riesgos hasta ahora desconocidos. Desde los datos y los modelos hasta los agentes de IA y las integraciones, la seguridad comienza por saber qué hay que proteger. Descubra cómo identificar los riesgos derivados de la IA, de modo que pueda establecer marcos de gobernanza y controles que protejan la innovación sin exponer a la empresa a nuevas superficies de ataque. 
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

Conclusiones clave

  • La seguridad de la IA en la empresa va más allá de proteger los modelos de IA: también implica proteger los agentes de IA, los datos empresariales, las identidades, las API y las integraciones de terceros. Las organizaciones necesitan visibilidad sobre dónde se implementa la IA, a qué puede acceder y cómo se comporta para gestionar eficazmente el riesgo de la IA.
  • Un marco eficaz de seguridad de la IA combina la gobernanza, la gestión de identidades y accesos, la protección de datos, la supervisión en tiempo de ejecución y la seguridad de la cadena de suministro de software. Ningún control ni ninguna salvaguarda de IA bastan por sí solos para proteger la IA empresarial.
  • La adopción y la seguridad de la IA deben evolucionar a la par. Integrar controles de seguridad en todo el ciclo de vida de la IA permite a las organizaciones reducir el ciberriesgo, respaldar el cumplimiento normativo y escalar las iniciativas de IA con mayor confianza.

¿Por qué es ahora prioritaria la seguridad de la IA en la empresa?

Proteger la IA empresarial es ahora una prioridad porque su adopción avanza más rápido que la gobernanza, la asignación de responsabilidades y los controles técnicos. Las herramientas de IA generativa, las funciones de IA integradas y los agentes autónomos pueden acceder a datos confidenciales, tomar decisiones y conectarse a sistemas externos, lo que genera riesgos relacionados con la seguridad, la privacidad, el cumplimiento normativo y las operaciones. Para muchas organizaciones, el primer reto no es si deben proteger la IA, sino qué significa realmente «proteger la IA» en la práctica. ¿Se trata de proteger los modelos? ¿Gobernar los datos? ¿Supervisar los resultados? ¿O controlar cómo se comportan los agentes de IA una vez implementados?  

Mientras aumenta la demanda de adopción, proteger el uso de la IA en la empresa sigue siendo un concepto abstracto para muchos, y poner en práctica su uso va mucho más allá de tener visibilidad. Los profesionales también deben tener en cuenta cómo se adquiere, desarrolla, implementa, utiliza y gobierna la IA en toda la empresa.

El objetivo de los equipos de seguridad: implementar un marco de seguridad de la IA basado en el ciclo de vida. Esta entrada de blog mostrará la variedad de casos de uso de la IA que deben tenerse en cuenta al desarrollar este marco y cómo plantear esta conversación a públicos no técnicos.  

¿Qué significa proteger la IA en la empresa?

Proteger la IA implica mantener la visibilidad y el control sobre dónde se utiliza, a qué datos accede, cómo se comportan los modelos y los agentes, y si sus acciones se ajustan a los objetivos empresariales. Abarca aplicaciones, identidades, infraestructura, datos, flujos de trabajo de desarrollo y terceros, por lo que la responsabilidad no puede recaer únicamente en una función de seguridad.

La seguridad de la IA suele plantearse como una extensión de las disciplinas de seguridad existentes. En la práctica, esta suposición puede generar confusión.

Las funciones de seguridad tradicionales se basan en límites relativamente estables. La seguridad de las aplicaciones se centra en el código y la lógica. La seguridad en la nube gestiona la infraestructura y la identidad. La seguridad de los datos protege la información confidencial tanto en reposo como en tránsito. La seguridad de la identidad controla quién puede acceder a los sistemas y servicios. Cada función cuenta con responsabilidades claramente definidas, herramientas establecidas y modos de fallo bien conocidos.

La IA no encaja perfectamente en ninguna de estas categorías. Un sistema de IA es, a la vez:

  • Una aplicación que ejecuta lógica
  • Un procesador de datos que recopila y genera información confidencial
  • Una capa de toma de decisiones que influye en las acciones o las automatiza
  • Un sistema dinámico que cambia su comportamiento con el tiempo

Por consiguiente, los riesgos de seguridad que introduce la IA abarcan varios ámbitos a la vez. Una sola interacción con IA puede implicar un uso indebido de identidades, exposición de datos, abuso de la lógica de las aplicaciones y riesgos en la cadena de suministro, todo dentro del mismo flujo de trabajo. Es aquí donde empiezan a difuminarse las líneas tradicionales entre las funciones de seguridad.

Por ejemplo, un prompt malicioso enviado por un usuario autorizado no constituye una vulneración de identidad clásica, pero puede provocar una filtración de datos o acciones no autorizadas. Un agente de IA que llama a un servicio externo puede parecer una acción legítima de una aplicación, aunque infrinja la soberanía de los datos o los requisitos de cumplimiento normativo. El código generado por IA puede superar las comprobaciones de desarrollo estándar y, aun así, introducir vulnerabilidades sutiles o dependencias comprometidas.

En ninguno de estos casos el riesgo «pertenece» por completo a un solo equipo de seguridad.

Por eso, la protección de la IA no puede limitarse a la seguridad de los modelos, las políticas de gobernanza o los controles perimetrales. Requiere una perspectiva de seguridad compartida que abarque el desarrollo, las operaciones, el tratamiento de datos y la interacción con los usuarios. Proteger la IA significa comprender no solo si se accede a los sistemas de forma segura, sino también si se utilizan, se entrenan y se les permite actuar de maneras que se ajusten a los objetivos empresariales y a la tolerancia al riesgo.

En esencia, proteger la IA consiste en recuperar la claridad en entornos donde la rendición de cuentas puede difuminarse rápidamente. Se trata de saber dónde está presente la IA, cómo se comporta, qué tiene permitido hacer y cómo afectan sus decisiones al conjunto de la empresa. Sin esta claridad, la IA se convierte en un multiplicador tanto de la productividad como del riesgo.

¿Qué debe abarcar un marco de seguridad de la IA empresarial?

Un marco de seguridad de la IA empresarial debe abordar el uso indebido y el comportamiento emergente, la supervisión en tiempo de ejecución, el desarrollo y la infraestructura, la IA en la sombra y las cadenas de suministro de terceros, así como la preparación organizativa. En conjunto, estas áreas abarcan cómo se adquiere, desarrolla, implementa, supervisa y gobierna la IA a lo largo de su ciclo de vida, y cómo se accede a ella.

Hay cinco áreas clave para proteger la IA en la empresa:

  • Prevención del uso indebido y de los comportamientos emergentes de la IA
  • Supervisión y control de la IA en funcionamiento
  • Protección del desarrollo e infraestructura de la IA
  • Seguridad de la cadena de suministro de IA
  • Fortalecimiento de la preparación y la supervisión

En conjunto, estas categorías ofrecen un enfoque estructurado para comprender cómo se manifiesta el riesgo de la IA y dónde deben centrar sus esfuerzos los equipos de seguridad.

1. Prevención del uso indebido y de los comportamientos emergentes de la IA

Los sistemas y agentes de IA generativa pueden manipularse de formas que eluden los controles tradicionales. Aunque el acceso esté autorizado, se puede hacer un uso indebido de la IA, reutilizarla para otros fines o influir en ella mediante prompts e interacciones cuidadosamente elaborados.

Entre los principales riesgos se incluyen:

  • Inyección maliciosa de prompts diseñada para forzar acciones no deseadas
  • Casos de uso no autorizados o no intencionados que eluden las salvaguardas
  • Exposición de datos confidenciales a través de los historiales de prompts
  • Alucinaciones o resultados maliciosos que influyen en el comportamiento humano

A diferencia de las aplicaciones tradicionales, los sistemas de IA pueden generar resultados perjudiciales sin estar explícitamente comprometidos. Proteger esta capa requiere supervisar la intención, no solo el acceso. Los equipos de seguridad necesitan visibilidad sobre cómo se envían prompts a los sistemas de IA, cómo se consumen los resultados y si el uso se ajusta a los fines empresariales aprobados

2. Supervisión y control de la IA en funcionamiento

Una vez implementados, los agentes de IA operan a velocidad y escala de máquina. Pueden iniciar acciones, intercambiar datos e interactuar con otros sistemas con poca supervisión humana. Por ello, la visibilidad en tiempo de ejecución resulta fundamental.

Los riesgos operativos de la IA incluyen:

  • Agentes que utilizan permisos de formas no previstas
  • Conexiones salientes no controladas a servicios o agentes externos
  • Pérdida de visibilidad forense sobre componentes efímeros de IA
  • Transmisión de datos entre jurisdicciones que incumple la normativa

Proteger la IA en funcionamiento requiere la supervisión en tiempo real del comportamiento de los agentes, puntos de control centralizados como gateways de IA y la capacidad de capturar el estado del agente para su investigación. Sin estas capacidades, los equipos de seguridad pueden carecer de visibilidad sobre cómo se comportan los sistemas de IA una vez en funcionamiento, especialmente en entornos nativos de la nube o regulados.

3. Protección del desarrollo e infraestructura de la IA

Muchos riesgos de la IA surgen mucho antes de la implementación. Las canalizaciones de desarrollo, las configuraciones de infraestructura y las decisiones arquitectónicas influyen en la postura de seguridad de los sistemas de IA.

Entre los riesgos habituales se incluyen:

  • Permisos y mecanismos de control mal configurados
  • Arquitecturas de agentes inseguras o excesivamente complejas
  • Infraestructura como código que introduce configuraciones incorrectas silenciosas
  • Vulnerabilidades en el código generado por IA y en las dependencias

El código generado por IA añade una nueva dimensión de riesgo, ya que los paquetes alucinados o la lógica poco segura pueden ser más difíciles de detectar y depurar que el código escrito por personas. Proteger el desarrollo de la IA implica aplicar controles de seguridad desde el principio, incluidos el análisis estático, la revisión de la arquitectura y la supervisión continua de la configuración a lo largo de todo el proceso de compilación.

4. Seguridad de la cadena de suministro de IA

Las cadenas de suministro de IA suelen ser opacas. Los modelos, conjuntos de datos, dependencias y servicios pueden proceder de terceros con distintos niveles de transparencia y garantías.

Riesgos clave de la cadena de suministro:

  • Herramientas de IA en la sombra utilizadas fuera de los controles aprobados
  • Agentes de IA externos con acceso interno
  • Proveedores que aplican IA a datos empresariales sin informar de ello
  • Modelos, datos de entrenamiento o dependencias comprometidos

Proteger la cadena de suministro de IA requiere descubrir dónde se utiliza la IA, validar la procedencia y las licencias de los modelos y los datos, y evaluar cómo procesan y protegen los proveedores la información de la empresa. Sin esta visibilidad, las organizaciones se exponen a fugas de datos, a riesgos regulatorios y a la vulneración de sistemas posteriores a través de integraciones de confianza.

5. Fortalecimiento de la preparación y la supervisión

Aunque existan controles técnicos sólidos, la seguridad de la IA falla sin gobernanza, pruebas y equipos formados. La IA plantea nuevos escenarios de incidentes que muchos equipos de seguridad aún no están preparados para gestionar.

Los riesgos de supervisión incluyen:

  • Falta de informes significativos sobre los riesgos de la IA
  • Sistemas de IA no probados en producción
  • Equipos de seguridad sin formación sobre amenazas específicas de la IA

Las organizaciones necesitan informes que tengan en cuenta la IA, ejercicios de equipos rojos y morados que incluyan sistemas de IA y formación continua para desarrollar la preparación operativa. Estas capacidades garantizan que los riesgos de la IA se comprendan, se pongan a prueba y se gestionen cada vez mejor, en lugar de descubrirse en pleno incidente.

Un nuevo enfoque de la seguridad de la IA para los consejos de administración

La seguridad de la IA no es solo una cuestión técnica. Es una cuestión de confianza, responsabilidad y resiliencia. Los consejos de administración quieren tener la garantía de que las decisiones basadas en IA son fiables, explicables y están protegidas contra manipulaciones.

La comunicación eficaz con la dirección se centra en:

  • Confianza: certeza sobre la integridad de los datos, el comportamiento de los modelos y los resultados
  • Rendición de cuentas: responsabilidades claramente definidas entre equipos y proveedores
  • Resiliencia: la capacidad de operar, auditar y adaptarse ante un ataque o una regulación

Vincular los esfuerzos de seguridad de la IA a marcos reconocidos, como la ISO/IEC 42001 y el Marco de Gestión de Riesgos de la IA del NIST, ayuda a demostrar madurez y alinea la seguridad de la IA con objetivos de gobernanza más amplios.

Conclusión: proteger la IA es un desafío que abarca todo el ciclo de vida

Las mismas características que hacen que la IA sea transformadora también dificultan su protección. Los sistemas de IA difuminan los límites tradicionales entre el software, los usuarios y la toma de decisiones, lo que amplía la superficie de ataque de formas sutiles pero significativas.

Garantizar la seguridad de la IA requiere recuperar la claridad. Saber dónde está presente la IA, cómo se comporta, quién la controla y cómo se gobierna. Un enfoque basado en marcos de trabajo permite a las organizaciones innovar con IA y, al mismo tiempo, mantener la confianza, la rendición de cuentas y el control.

El camino hacia una IA segura es un proceso continuo, pero comienza por comprender los riesgos a lo largo de todo el ciclo de vida de la IA y desarrollar prácticas de seguridad que evolucionen junto con la tecnología.

Darktrace / SECURE AI respalda este enfoque del ciclo de vida al reunir visibilidad en toda la empresa, supervisión del comportamiento y control en tiempo real, lo que ayuda a los equipos de seguridad a identificar actividades de riesgo y adoptar la IA de forma más segura.

[related-resource]

Descargue el marco de trabajo completo

Descubra cómo identificar los riesgos de la IA para establecer marcos de gobernanza y controles en su organización.

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