AI systems are fully capable of carrying out nightmare attacks against infrastructure and nobody's ready

1. Executive summary

Booz Allen Hamilton's OT lab ran two unnamed frontier AI models through eight autonomous attack scenarios against a multi-vendor industrial testbed modelled on a general manufacturing facility. The models met the objective in all eight, including moving a collaborative robot arm within minutes and reaching production-zone actions from a perimeter compromise in just over 16 minutes. No CVE, no exploited vulnerability and no named threat actor is identified in the source, so this is a capability assessment rather than an incident. The risk to EMEA financial services is indirect but concrete: the same agentic tooling lowers the skill floor for attacks on the OT that underpins utilities, data centres and payment infrastructure your operations depend on, and the source reports suspected Iranian actors already using AI-generated exploitation scripts against internet-exposed PLCs in the US. Detection windows measured in minutes leave no room for manual escalation paths.

2. Regulatory framing

No NIS2 or UK NIS article is directly engaged by this item. It reports lab testing, not an incident affecting a client's network and information systems.

3. Technical analysis & attack chain

This is a capability demonstration, not an observed intrusion. The steps below are the confirmed sequence Booz Allen's agents executed inside its own lab. Nothing here is a live attack against a named victim.

1. The agents mapped the testbed environment and identified critical assets without being given source code, engineering documents, or OT-specific guidance.
2. They enumerated security weaknesses across the environment and converted discovered weaknesses into working access paths.
3. They chained multiple weaknesses to move from the enterprise side into systems that run production, crossing the enterprise, industrial DMZ, plant operations and production zones the lab had separated with firewalls and switches.
4. They manipulated multiple controller brands and function codes, forced outputs, and changed the frequency, speed, start and stop state of a connected AC motor.
5. They compromised the SCADA platform, altered operator screens, and controlled connected equipment.
6. They located a collaborative robot arm, discovered its API, gained administrative access, mapped protection zones and motion limits, and moved the arm.

The SCADA scenario is the most instructive. The agents' first attack path failed because they targeted the wrong version of the operator interface. They recovered without human input: they checked active sessions, determined the control room used a different HMI client version, found editable Jython code in the exported SCADA project, rebuilt the payload, and used the administrative interface to push a full-screen takeover of the HMI visible across the control room. The agents also found that the SCADA gateway held live, pre-authenticated sessions to 14 OT devices across both zones, meaning compromise of that single gateway gave write access to every PLC the agents had encountered. The agents' own output described this as the capability to "make the operator screens lie" and a write pathway to every controller.

A second scenario shows unprompted lateral thinking. An agent noticed a safety-critical device at 192.168.25.2 broadcasting an ARP request for 192.168.25.56 once per second for over 45 minutes with no reply, and inferred the peer (a SCADA master, data concentrator or engineering workstation) had been removed from the network. The agent proposed adding 192.168.25.56 as a second address on its own adapter and answering the ARP, so the orphaned device would initiate its configured protocol session to the agent. The stated posture was receive-only: no writes, no service emulation. The agent's stated goal was to learn the protocol, the missing peer's role, and what control relationship the device was offering.

The robotic arm scenario used a lightweight collaborative robot (cobot) of the type deployed in light manufacturing, assembly, logistics, packaging, laboratories and healthcare. These operate without a safety cage, which is why the lab selected one. The agent probed the network for common robotic protocols, identified the robot, discovered its API, gained administrative access, mapped protection zones and motion limits, and moved the arm, all within minutes. It also mapped fallback paths: first testing whether the arm accepted unauthenticated motion commands, and if that failed, breaking in through the web user interface, executing code on the controller, and using that access to reach the motion interface. The agents also identified vendor default credentials for the robot.

Two factors made this possible. The agents were not given OT expertise and acquired it themselves, which removes specialised OT knowledge as a barrier. And many OT devices use no authentication or encryption, so once access exists, command execution is direct.

Caveats. Booz Allen declined to name the two models, describing them only as "latest frontier models from the leading AI providers", so the capability cannot be tied to a specific product or version. The lab set guardrails: agents required human approval before exploiting a security issue or taking any action with physical impact, and were instructed to use extra caution around devices they judged safety-critical. The reported results therefore describe what the agents planned and were authorised to execute, not fully unsupervised action. The testbed is a lab model of a manufacturing facility, not a production network, and Booz Allen states it was configured to closely mimic real systems. The 16-minute perimeter-to-production figure and the "minutes" figure for the robot arm are single-sourced to Booz Allen via The Register and have not been independently reproduced.

The source also cites real-world context that is not detailed enough to act on: suspected Chinese operators using AI agents against South Korean financial institutions and Taiwanese government websites, and suspected Iranian attackers using AI-generated exploitation scripts against internet-exposed PLCs at US water, manufacturing and energy facilities. These are described in a single sentence with no indicators, victim names, or technical detail. Treat them as unconfirmed and do not build detection from them.

4. Mitigation & containment

The source gives no vendor fix, no CVE and no patch. The actions below address the specific weaknesses the agents exploited in the lab.

P1 (within 24 hours)

• Inventory every SCADA gateway and HMI server that holds persistent pre-authenticated sessions to field devices. The lab gateway held live sessions to 14 OT devices; each such session is a write path to every device behind it. Where the platform supports it, disable session persistence and require re-authentication per device.
• Search for orphaned devices broadcasting ARP or protocol requests to peers that no longer exist. The lab agent exploited a device calling for 192.168.25.56 once per second for over 45 minutes. Any device repeatedly ARPing an unanswered address is a candidate for impersonation. Either restore the peer or reconfigure the device to remove the dead dependency.
• Change vendor default credentials on every robot, cobot, HMI and controller reachable from the plant network. The agents used vendor defaults to gain administrative access to the robot.
• Block unauthenticated motion and control commands at the network layer where the device cannot enforce authentication itself.

P2 (within 72 hours)

• Audit exported SCADA projects for editable script content, specifically Jython. The agents rebuilt their payload from editable Jython in an exported project and distributed it through the administrative interface. Restrict write access to project exports and the SCADA administrative interface to named accounts on a management VLAN.
• Verify segmentation between enterprise, industrial DMZ, plant operations and production zones with actual traffic captures, not firewall rulesets. The lab deliberately reproduced "imperfect segmentation" and the agents crossed zones.
• Restrict outbound and lateral access from engineering and operator workstations. The agents moved from perimeter compromise to production actions in just over 16 minutes, which is faster than most manual escalation and approval processes.

P3 (within 7 days)

• Run an OT-specific tabletop or live exercise covering loss of a SCADA HMI, falsified operator screens, and unauthorised motion of automated equipment. DORA Art. 24 testing should include these scenarios where OT-dependent facilities support your critical services.
• Extend third-party dependency mapping to the OT layer of utility, data centre and facilities providers under DORA Art. 28, and record which of your critical or important functions depend on industrial control systems you do not own.
• Where you operate cobots or automated handling equipment, review whether safety limits are enforced in hardware or only in software. The agents mapped protection zones and motion limits before moving the arm; software-only limits are reachable once the controller is compromised.

5. Indicators of compromise

No indicators of compromise available in the source material. The source describes a lab exercise and names no malicious file, domain, IP address or hash. The IP addresses 192.168.25.2 and 192.168.25.56 appear in the source as addresses inside Booz Allen's own test network, not as threat infrastructure, and are not reproduced here as indicators.

Behavioural indicators

6. Detection

The source contains no file hashes, no malware strings, no command lines and no filenames. It does contain distinctive network and host behaviours, so a Sigma rule is appropriate. A YARA rule is not: there is no malicious file artefact to match against, and a rule keyed on product names or the phrase "make the operator screens lie" would detect reporting about the exercise rather than the activity.

title: OT Device ARPing Unanswered Peer Address Repeatedly
id: 8f3c1a72-4d5e-4b91-a6c2-7e0d9b1f4a38
status: experimental
description: Detects an OT or industrial device repeatedly ARPing for a peer address that never answers, the orphaned-peer condition an autonomous agent exploited in Booz Allen's OT lab to impersonate a missing SCADA master or engineering workstation.
author: Adverse Trace
date: 2026-10-11
references:

  - https://www.theregister.com/security/2026/10/11/ai-systems-are-fully-capable-of-carrying-out-nightmare-attacks-against-infrastructure-and-nobodys-ready/5302450
logsource:
  category: network_connection
  product: zeek
detection:
  selection:
    proto: arp
    operation: request
  timeframe: 5m
  condition: selection | count() by src_ip, query > 60
falsepositives:

  - Device legitimately configured to talk to a peer that is temporarily offline for maintenance
  - Network reconfiguration in progress
level: medium

title: Second IP Address Added to Adapter on OT Engineering Workstation
id: 2b7e5c94-1a83-4f60-9d2e-6c4a8f0b3e17
status: experimental
description: Detects addition of a secondary IP address to a network adapter on an OT engineering or operator workstation, the technique an autonomous agent proposed to answer an orphaned device's ARP request and receive its protocol session.
author: Adverse Trace
date: 2026-10-11
references:

  - https://www.theregister.com/security/2026/10/11/ai-systems-are-fully-capable-of-carrying-out-nightmare-attacks-against-infrastructure-and-nobodys-ready/5302450
logsource:
  category: process_creation
  product: windows
detection:
  selection_netsh:
    Image|endswith: '\netsh.exe'
    CommandLine|contains|all:

      - 'interface ip add address'
  selection_powershell:
    Image|endswith:

      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains|all:

      - 'New-NetIPAddress'
      - '-InterfaceIndex'
  condition: selection_netsh or selection_powershell
falsepositives:

  - Legitimate network reconfiguration by OT engineering staff
  - Failover or redundancy configuration changes
level: medium

Both rules detect the behaviour, not the actor. The orphaned-peer ARP pattern in particular will fire on legitimate maintenance windows, so tune the threshold against your own baseline before alerting.

7. Sources

• The Register, "AI systems are fully capable of carrying out nightmare attacks against infrastructure and nobody's ready", https://www.theregister.com/security/2026/10/11/ai-systems-are-fully-capable-of-carrying-out-nightmare-attacks-against-infrastructure-and-nobodys-ready/5302450, 2026-10-11. Reporting on a Booz Allen Hamilton OT lab study. The underlying Booz Allen report is not linked in the source and Adverse Trace has not reviewed it directly; all technical detail here derives from The Register's account and the quotes it carries from Kyle Miller, VP of infrastructure cybersecurity at Booz Allen.

8. Adverse Trace position

Adverse Trace assesses this as a capability finding with no immediate exploitation against our client base, and we are not raising a sector alert on it. There is no CVE, no KEV entry, no named actor and no indicator set, so it does not meet the threshold for a P1 advisory. The material point for EMEA financial services is dependency, not direct exposure: the OT weaknesses the agents exploited (pre-authenticated SCADA gateway sessions, orphaned devices accepting impersonated peers, vendor default credentials on robots, editable Jython in exported SCADA projects, unauthenticated motion commands) are the same weaknesses present in the utility, data centre and facilities infrastructure your critical services rely on, and the source reports suspected Iranian actors already using AI-generated exploitation scripts against internet-exposed PLCs. We treat the 16-minute and "minutes" figures as single-sourced to Booz Allen and not independently reproduced, and we note the lab ran with human approval gates on exploitation and physical impact, so the results describe authorised execution rather than fully unsupervised action. We will track whether Booz Allen publishes the underlying report with model names and technical detail, and whether the cited South Korean and Taiwanese incidents are corroborated by a second source with indicators. Clients with OT-dependent critical or important functions should complete the P1 actions in §4 this week and use the two Sigma rules to establish whether orphaned-peer ARP behaviour exists on their own industrial segments.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.