AI-Assisted OT Lab: Equipment Control in Just Over 16 Minutes from a Breached Perimeter; Robotic Arm Moved in a Separate Test

In an isolated OT lab, Booz Allen tested a frontier AI agent across eight scenarios and found it reached controller output operations just over 16 minutes after starting from an already-breached perimeter, and in a separate test physically operated an industrial robotic arm. The agent also identified the control room's actual SCADA version from active session data after initially targeting the wrong one, uncovering pre-authenticated connections to 14 OT devices. All exploit executions and operations with physical impact required human approval, and the lab intentionally left known unpatched vulnerabilities in place, so the work does not demonstrate fully automated external intrusion.

1. Basic Information - Article Title: AI Takes Control of Robotic Arm in 16 Minutes Flat - Source: Dark Reading - Publication Date: 2026-10-16 - Updated Date: None - Original Article: Dark Reading https://www.darkreading.com/ics-ot-security/ai-takes-control-robotic-arm-16-minutes - Related Information Sources: Booz Allen: Frontier AI Reaches OT Systems https://www.boozallen.com/insights/cyber/frontier-si-reaches-ot-systems.html - Related Malware: None - Related Threat Groups: None - Related CVEs: None - Related Products: Frontier AI agents, SCADA, industrial robotic arm, OT controllers - Severity: High This is not a real-world exploitation report, but rather the evaluation results of eight scenarios conducted in an isolated lab environment. Human approval was involved in all exploit executions and operations with physical impacts. All test objectives were achieved under the assumption that known unpatched vulnerabilities and existing connections were already present, and this experiment does not demonstrate fully automated unauthorized intrusion from an external source. 2. Quick Summary In an isolated Booz Allen OT lab, an AI model explored known vulnerabilities and existing sessions, attempting to operate control equipment under human approval. In one test, it reached OT device output operations just over 16 minutes after a breached boundary, and in another test, it physically operated an industrial robotic arm. 3. Attack Flow Below are the individual test contents reported from across all eight scenarios. These did not run continuously as a single attack path, and human approval was included for all exploit executions and operations with physical impacts in every test. | Test Scenario | Starting Point & Prerequisites | Targets Checked & Tried | Result & Duration | | Path 1: Time Measurement to OT Output Operation | Boundary already breached state known unpatched vulnerabilities intentionally left in place | Matching reachable assets and firmware info against known vulnerabilities | Reached controller output operations under human approval just over 16 minutes | | Path 2: Exploration of Existing SCADA Connections | Environment with active SCADA sessions present | Identifying the SCADA version in use within the control room and investigating connection destinations | Discovered existing pre-authenticated connections leading to 14 OT devices | | Path 3: Robotic Arm Operation Test | Independent scenario separate from the 16-minute boundary test | Understanding the safety zones and operational range of the robotic arm | Physically operated the robotic arm under human approval | Path 1: Test Measuring Time from Breached Perimeter to OT Operation 1. Starting from a state where the isolated lab perimeter is already breached, the AI model explores reachable assets and services. The time required to gain the initial point of entry from the external network is not included in the measurement. 2. The collected asset and firmware information is matched against known vulnerabilities to attempt a path from the IT side to the OT side. Note that the initial test environment intentionally left unpatched known vulnerabilities. 3. After human approval for each exploit execution and operation with physical impacts, the test ultimately reached controller output operations. The time required in this test was just over 16 minutes. Path 2: Test Investigating Existing SCADA Connections 1. The AI model initially targeted the wrong SCADA version, but identified the version actually used in the control room from active session information and corrected its process. 2. As a result, it discovered existing pre-authenticated connections leading to 14 OT devices. The term pre-authenticated in the source material refers to existing connections where authentication has already been established, and does not mean that access was gained without authentication or that an authentication bypass succeeded. Path 3: Robotic Arm Operation Test 1. The AI model discovered the robotic arm on the network and investigated its safety zones and operational range. 2. It physically moved the robotic arm under human approval. This test was conducted as a separate scenario from the test that reached the target just over 16 minutes after the breached boundary. 4. Attacker Position and Execution Location - Operates as an AI model inside a controlled lab, simulating an attacker who has already partially reached the inside of the network. The duration of "just over 16 minutes" is measured from the point after the boundary breach. - Utilized IT/OT communication paths and existing pre-authenticated SCADA sessions. This does not demonstrate unauthenticated external intrusion or fully automated real attacks without human intervention. 5. Perspective of Victims and Administrators - Victims and Users: On-site impacts may appear as unexpected movements of robotic arms or motors, switching of operating modes, or process delays. - Administrators: Observed as asset discovery, version probe traffic, suspicious session usage against SCADA, command transmission to multiple control devices, and retries following command rejections. 6. Success and Failure Conditions Success Conditions - Each test starts with the initial access specified for that scenario and relevant conditions, such as known unpatched vulnerabilities or reachable IT/OT communication paths. - In tests targeting SCADA, existing pre-authenticated connections leading to 14 OT devices were available. However, this is not a prerequisite common to all eight scenarios. - In this research, humans approved each exploit and physical operation. Note that local mode settings on the equipment side and command validation functions prevented certain operations. Failure Conditions and Countermeasures - Inference: Combine IT/OT network segmentation, the elimination of dual-homed devices spanning both networks, and session- and operation-level permission controls with human approval processes. The presence of human approval screens alone does not guarantee operational safety. - Prevent dangerous physical operations by setting control devices to local manual mode, validating commands on the controller side, and maintaining independent safety interlocks. 7. What Happens Upon Success - Unexpected operation of OT controllers, stoppage of manufacturing processes or degradation of quality, and on-site safety risks may occur. - Because asset structure mapping and the testing of known vulnerabilities are performed continuously in a short time, the time window available for defenders to respond may be reduced. 8. Observable Logs Below are candidates for investigation within your own organization. Availability depends on products, permissions, log settings, and retention periods, and the absence of records does not prove an uncompromised state. - Email: There is no email origin specific to this case. - Proxy / SWG / DNS: Check for rapid probe traffic to multiple services against perimeter assets or requests targeting known vulnerabilities. - Endpoint / EDR: Check execution logs of discovery tools and scripts, remote sessions, and access history to configuration files on jump hosts or SCADA servers. - Identity / IdP: Check whether shared accounts, service accounts, and existing sessions are used from unusual connection sources. - SaaS / Cloud: When using cloud-managed OT gateways or remote maintenance paths, check API and management console sessions and configuration change history. - Network: Check for discovery traffic crossing the IT/OT boundary, operations on SCADA protocols, changes in operating modes, program writes, and commands sent from a single source to multiple control devices. 9. Attack Success Determination Confirmed in Public Information - Subsequent Compromise Confirmed : - Public Information: Achievement of objectives was confirmed in all eight managed test scenarios under human approval. Reaching OT output operations just over 16 minutes after boundary breach and robotic arm operation in a separate scenario were reported. This is not an attack on an actual organization or execution without human intervention. - Scope: Booz Allen multi-vendor OT lab environment Separate contact, execution, persistence, information acquisition, and exfiltration; do not infer unconfirmed success from a single alert. 10. Investigation Playbook - Investigation Starting Point: Initiate investigations based on high-speed reconnaissance activity at the perimeter, suspicious use of SCADA sessions, operation mode changes, program writes, or unexpected command transmission to control devices. - Initial Verification: Distinguish whether the event stems from testing/exercises or actual operational environments, and check the source host, account, sessions, target OT assets, and the presence of authorized work approvals. - Endpoint and Server Investigation: Preserve traces related to processes, scripts, and sessions on jump hosts, SCADA servers, and engineering workstations. - Authentication and Cloud Investigation: Track usage history of shared accounts, service accounts, remote access sessions, and API tokens. - Subsequent Operations: Reconstruct the sequence of paths from asset discovery to command transmission to control devices, and alternative procedures attempted after command rejections. - Containment: Disconnect suspicious sessions to isolate IT/OT boundary communications, transition target devices to a safe local control state, and compare current settings against engineering backups. - Judgment Classification: Evaluate asset discovery, abuse of authentication and sessions, IT/OT boundary crossing, command transmission to control devices, and physical impacts in separate stages. 11. Defense and Detection Ideas - Single Event: Detect high-priority command transmissions, operating mode changes, and program writes performed in a short time from SCADA or engineering terminals to multiple control devices. - Time-Series Correlation: Perform time-series correlation analysis on perimeter scans, version matching, reuse of existing sessions, command transmission to multiple devices, and physical state changes. - Threat Hunting: Inventory dual-homed devices, shared SCADA sessions, persistently connected authenticated consoles, and non-expiring tokens. - Log Limitations: When authentication logs or command audit functions are absent on OT control devices, packet capture and SCADA historians may be the only means to reconstruct operation history. - Priority Countermeasures: Maintain multi-layered network segmentation, session separation, human approval for critical operations, local safety mechanisms, and offline backups. 12. Facts / Inference / Hypothesis Facts - Booz Allen conducted eight scenarios in a controlled lab simulating a multi-vendor manufacturing environment, and the AI agent achieved the objectives in all scenarios. - In one test, it reached OT device output operations in just over 16 minutes from a state following a boundary breach. Finding the robotic arm, understanding its operational range, and physical operation were part of a separate test scenario. - The agent was not provided with source code, design documents, or advanced OT-specific manuals, and instead performed asset discovery, firmware version matching, selection of known vulnerabilities, and trial-and-error upon errors. - Although it initially tested incorrect SCADA versions, it identified the correct target from active sessions and discovered existing pre-authenticated connections leading to 14 OT devices. This does not mean unauthenticated access was confirmed. - Stop commands refused by controllers and motors set to local mode prevented certain operations. Additionally, network segmentation, firewalls, and endpoint controls slowed progress, but the agent attempted alternative procedures. - The initial test intentionally left known vulnerabilities unpatched, and the time required to discover and develop zero-day vulnerabilities was not included in the evaluation. - Booz Allen explicitly stated that humans approved all exploit executions and operations with physical impacts. Inference - While the processing speed of the AI agent cannot be directly applied to general OT environments as-is, in environments where trust bridges such as dual-homed devices, shared sessions, and existing authenticated console connections remain, the time from discovery to trial-and-error may be significantly shortened. Hypothesis No additional hypotheses. Unconfirmed items are listed in "Unknowns and Additional Investigation." 13. MITRE ATT&CK Mapping | ID | Technique | Confidence | Basis | | T1046 | Network Service Discovery | high | The AI agent discovered reachable assets, versions, and available services. Source https://www.darkreading.com/ics-ot-security/ai-takes-control-robotic-arm-16-minutes | | T1692.001 | Unauthorized Message: Command Message | medium | Attempted control device operations simulating an intruder inside the controlled lab. This is an attack simulation approved by humans, not an observation of unauthorized operations in an operational environment. Source https://attack.mitre.org/techniques/T1692/001/ | Because specific exploitation paths for public applications were not shown, T1190 is not assigned. Former T0855 maps to current T1692.001. 14. Unknowns and Additional Investigation - The specific AI models used in each scenario, initial permissions, tool execution privileges, token consumption and costs, all CVEs attempted, breakdowns of human approval wait times, and reproducibility across repeated tests cannot be determined solely from the reviewed public pages and interview articles. The fact that human approval intervened has been confirmed. 15. Impact on SOCs and Organizations In OT environments such as manufacturing and logistics, countermeasures against AI-driven attacks should not be limited to behavioral detection of new models. Instead, practical defense involves reducing dual-homed devices spanning the IT/OT boundary, shared SCADA sessions, and persistently maintained authenticated console connections. It is important to log operating mode changes, program writes, SCADA import operations, and suspicious use of trusted interfaces, while maintaining local safety mechanisms on the physical side and network controls as independent layers. 16. Summary by Target Audience - For SOCs: Correlate and monitor activities ranging from boundary reconnaissance to SCADA session usage, operating mode changes, and command transmission to control devices under the same entity and time window. - For Administrators: Reduce dual-homed devices and shared sessions, and maintain human approval for OT operations, local mode settings, and independent safety interlocks. - For Users: If you confirm unexpected behavior of physical equipment or switching of operating modes, safely stop operations according to prescribed procedures and contact administrators.