Booz Allen Hamilton published research this week that should be on every OT security team's briefing deck. In an isolated operational technology lab, AI agents — given no prior knowledge of the environment — met every objective across eight attack scenarios, navigating unfamiliar OT systems, and in one scenario traversing from a perimeter compromise to the industrial control network in just over 16 minutes. In several scenarios, the agents progressed to the point of issuing commands that moved physical equipment.
Let me be direct about what this means for defenders: the dwell-time assumptions baked into most OT security programs are now obsolete. The traditional comfort of "we'll catch lateral movement in days, not minutes" collapses when an autonomous agent can enumerate, adapt, and act at machine speed. If your SOC's OT detections are tuned for human-paced adversaries — low-and-slow scanning, manual protocol probing, cautious enumeration — you are defending against yesterday's threat model.
This is a research finding, not a confirmed in-the-wild campaign. But nation-state actors and ransomware operators have been targeting OT for years (Volt Typhoon's pre-positioning, FrostyGoop's Modbus abuse in Ukraine, the resurgence of industrial ransomware crews). Autonomous tooling dramatically lowers the skill barrier and compresses the timeline. The defensive lesson is present-day and urgent.
Technical Analysis
What Booz Allen Demonstrated
The Booz Allen team built an isolated OT lab replicating a realistic industrial environment — enterprise perimeter, business network, DMZ, and an industrial control network (ICN) with PLCs and physical equipment. Key findings from the eight scenarios:
- AI agents completed all objectives in all eight scenarios, including scenarios requiring interaction with physical process equipment.
- The fastest full intrusion chain — perimeter compromise to industrial control network — took approximately 16 minutes.
- The agents operated against unfamiliar systems: no pre-loaded network maps, no prior reconnaissance data. They enumerated, identified OT protocols, and adapted their approach autonomously.
- The agents were capable of reaching the point of moving physical equipment, meaning they progressed through the kill chain to the level of manipulating control logic or issuing commands to industrial devices.
Why This Changes the OT Threat Model
Traditional OT intrusions follow a recognizable, human-paced pattern:
- Initial compromise of IT perimeter (phishing, exposed remote access, vulnerable VPN appliance)
- Credential theft and enumeration of the business network
- Discovery of IT/OT boundary crossing points (jump boxes, historian servers, engineering workstations)
- Careful, slow reconnaissance of the OT segment — often passive, to avoid tripping safety systems or protocol-aware monitoring
- Eventual interaction with PLCs/RTUs via native protocols (Modbus, EtherNet/IP, DNP3, S7comm, OPC UA)
An AI agent collapses phases 2 through 4. It can run enumeration, credential spraying, protocol fingerprinting, and lateral movement in parallel, at machine speed, without the operational security caution that slows human operators. The 16-minute perimeter-to-ICN time means detection must be automated and response must be pre-staged — an analyst reading an alert queue 45 minutes after the fact is documenting an incident, not stopping one.
Attack Surface Implications
The scenarios reinforce what many of us in DFIR already observe in OT engagements:
- The IT/OT boundary is the decisive terrain. Historians, engineering workstations (EWS), HMI servers, and jump boxes with dual-homed connectivity remain the primary pivot points.
- OT protocols are unauthenticated by design. Modbus TCP (502), EtherNet/IP (44818), DNP3 (20000), and S7comm (102) accept function codes from any device that can reach them. If an agent lands on a host with OT network access, nothing at the protocol layer stops it from writing coils or uploading logic.
- Speed defeats manual triage. Automated, behavior-based detection on the OT boundary is the only viable control when the adversary operates in minutes.
Exploitation Status
This is published research from a controlled lab environment — not a confirmed in-the-wild campaign. However, the techniques the AI agents used are standard offensive tradecraft (enumeration, lateral movement, native OT protocol interaction), and the trajectory of offensive AI tooling makes operational adoption a matter of when, not if. Treat this as a leading indicator and adjust detection posture now.
Detection & Response
The defensive value here is in detecting the behavioral signatures of machine-speed intrusion: rapid enumeration, compressed lateral movement, and abnormal OT protocol usage from unexpected sources. The detections below are tuned for high fidelity — they're designed to fire on genuinely anomalous behavior in OT environments, which have the enormous advantage of being static and predictable. Unlike IT networks, a well-run OT segment has a known, small set of devices that should ever speak Modbus or EtherNet/IP. Anything outside that baseline is a strong signal.
Sigma Rules
These rules target Windows-based hosts at the IT/OT boundary (engineering workstations, HMI servers, historians) — the systems an agent must control before touching the control network.
---
title: Rapid Port Scanning Activity from IT/OT Boundary Host
id: 3f8c2a41-7b1d-4e59-a2c6-9d4f1e8b2a73
status: experimental
description: Detects execution of network scanning tools on hosts positioned at the IT/OT boundary (engineering workstations, historians, jump boxes). AI-driven intrusions enumerate at machine speed; scanning from these hosts is never legitimate outside maintenance windows.
references:
- https://www.securityweek.com/ai-agents-navigate-unfamiliar-ot-systems-and-move-equipment-in-minutes-booz-allen-finds/
- https://attack.mitre.org/techniques/T1046/
author: Security Arsenal
date: 2026/02/17
tags:
- attack.discovery
- attack.t1046
logsource:
category: process_creation
product: windows
detection:
selection_img:
Image|endswith:
- '\nmap.exe'
- '\ncat.exe'
- '\masscan.exe'
- '\zmap.exe'
- '\rustscan.exe'
selection_cli:
CommandLine|contains:
- '-p 502'
- '-p502'
- '44818'
- '-p 102'
- '-p102'
- '20000'
- '--scan'
- '-sS'
- '-sV'
condition: selection_img or selection_cli
falsepositives:
- Authorized vulnerability scanning during maintenance windows from designated scanner hosts
level: high
---
title: PowerShell Network Enumeration Targeting OT Protocol Ports
id: 8a1e5d92-4c6f-4b38-9e17-2c5a7f3d6b91
status: experimental
description: Detects PowerShell-based TCP connection probing of common ICS protocol ports (Modbus 502, S7comm 102, EtherNet/IP 44818, DNP3 20000, OPC UA 4840). Script-based probing of OT ports from Windows hosts is characteristic of automated/agentic reconnaissance.
references:
- https://www.securityweek.com/ai-agents-navigate-unfamiliar-ot-systems-and-move-equipment-in-minutes-booz-allen-finds/
- https://attack.mitre.org/techniques/T1046/
author: Security Arsenal
date: 2026/02/17
tags:
- attack.discovery
- attack.t1046
- attack.t1059.001
logsource:
category: process_creation
product: windows
detection:
selection_img:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
selection_cli:
CommandLine|contains:
- 'Test-NetConnection'
- 'Net.Sockets.TcpClient'
- 'tnc '
selection_ports:
CommandLine|contains:
- '502'
- '44818'
- '20000'
- '4840'
- ' 102'
condition: selection_img and selection_cli and selection_ports
falsepositives:
- OT engineers running connectivity diagnostics during commissioning
level: high
---
title: Network Connection to ICS Protocol Port from Non-Baseline Process
id: 5b7d3e18-9f24-4a61-b8c3-6e9f2d4a7c85
status: experimental
description: Detects outbound connections to ICS protocol ports (Modbus 502, EtherNet/IP 44818, S7comm 102, DNP3 20000) from processes outside the approved OT application baseline. In a mature OT environment, only known HMI/SCADA/historian binaries should initiate these sessions.
references:
- https://www.securityweek.com/ai-agents-navigate-unfamiliar-ot-systems-and-move-equipment-in-minutes-booz-allen-finds/
- https://attack.mitre.org/techniques/T0885/
author: Security Arsenal
date: 2026/02/17
tags:
- attack.lateral_movement
- attack.ics
logsource:
category: network_connection
product: windows
detection:
selection_ports:
DestinationPort:
- 102
- 502
- 20000
- 44818
- 4840
filter_known_ot_apps:
Image|endswith:
- '\rslinx.exe'
- '\rslinxng.exe'
- '\kepware.exe'
- '\server_runtime.exe'
- '\matrikonopcserver.exe'
- '\Studio5000.exe'
- '\ccservr.exe'
condition: selection_ports and not filter_known_ot_apps
falsepositives:
- Vendor-specific OT applications not yet in the baseline — extend the filter list to match your environment
level: critical
KQL Hunt — Microsoft Sentinel
This query hunts for compressed lateral movement patterns — the telltale sign of machine-speed intrusion — using Sysmon network connection events and firewall/Syslog telemetry ingested into Sentinel. It looks for a single source host touching multiple OT protocol ports across multiple destinations within a short window, which almost never happens legitimately.
// Hunt: Rapid multi-port ICS protocol probing from a single source (agentic reconnaissance pattern)
// Tune OT port list and baseline sources to your environment
let otPorts = dynamic([102, 502, 20000, 44818, 4840]);
let window = 15m;
DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where RemotePort in (otPorts)
| where ActionType == "ConnectionSuccess"
| summarize
DistinctPorts = dcount(RemotePort),
DistinctTargets = dcount(RemoteIP),
Ports = make_set(RemotePort),
Targets = make_set(RemoteIP, 25),
InitiatingProcess = make_set(InitiatingProcessFileName, 10),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by DeviceName, InitiatingProcessFileName, bin(TimeGenerated, window)
| where DistinctTargets >= 3 or DistinctPorts >= 2
| project DeviceName, InitiatingProcessFileName, DistinctPorts, DistinctTargets, Ports, Targets, FirstSeen, LastSeen
| sort by DistinctTargets desc;
// Companion: perimeter device syslog for OT-bound connection spikes (CEF/Syslog ingestion)
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DestinationPort in (otPorts)
| summarize ConnCount = count(), Targets = dcount(DestinationIP) by SourceIP, DeviceVendor, bin(TimeGenerated, 5m)
| where ConnCount > 50 or Targets > 5
| sort by ConnCount desc;
Velociraptor VQL — Endpoint Hunt
For engineering workstations and HMI servers, this artifact hunts for live processes holding connections to ICS protocol ports, joined with process metadata — useful for scoping a suspected agentic intrusion and identifying non-baseline binaries speaking to PLCs.
-- Hunt: Processes holding active connections to ICS protocol ports on OT boundary hosts
-- Flag any process not on the approved OT application baseline
LET ics_ports <= dict(`102`=true, `502`=true, `20000`=true, `44818`=true, `4840`=true)
SELECT Pid,
Name,
Exe,
CommandLine,
Username,
CreateTime,
netstat().RemoteAddress AS RemoteAddr,
netstat().RemotePort AS RemotePort,
netstat().Status AS ConnStatus
FROM pslist()
WHERE netstat().RemotePort IN (102, 502, 20000, 44818, 4840)
AND netstat().Status =~ 'ESTABLISHED'
ORDER BY RemotePort
Hardening & Verification Script
This PowerShell script audits Windows-based OT boundary hosts for the conditions that make rapid AI-driven pivoting possible: excessive local admins, non-baseline processes with OT-port connections, and missing outbound firewall restrictions on ICS protocol ports. Run it on engineering workstations, HMI servers, and historian hosts (test in a lab first — as with everything in OT).
# OT Boundary Host Hardening Audit - Security Arsenal
# Run elevated on engineering workstations / HMI servers / historians
# 1) Enumerate local administrators (should be a short, known list)
Write-Host "=== Local Administrators ===" -ForegroundColor Cyan
Get-LocalGroupMember -Group "Administrators" | Select-Object Name, ObjectClass, PrincipalSource | Format-Table -AutoSize
# 2) Identify processes with established connections to ICS protocol ports
Write-Host "=== Processes with ICS-Port Connections (102/502/20000/44818/4840) ===" -ForegroundColor Cyan
$icsPorts = 102, 502, 20000, 44818, 4840
Get-NetTCPConnection -State Established | Where-Object { $icsPorts -contains $_.RemotePort } | ForEach-Object {
$proc = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
[PSCustomObject]@{
ProcessName = $proc.ProcessName
Path = $proc.Path
PID = $_.OwningProcess
RemoteIP = $_.RemoteAddress
RemotePort = $_.RemotePort
}
} | Format-Table -AutoSize
# 3) Verify outbound firewall rules exist restricting ICS protocol ports to approved destinations
# (Replace the approved remote address ranges with your PLC/RTU subnets)
Write-Host "=== Creating Default-Deny Outbound Rules for ICS Ports (adjust RemoteAddress) ===" -ForegroundColor Cyan
foreach ($port in $icsPorts) {
$ruleName = "OT-Deny-Outbound-Port-$port"
if (-not (Get-NetFirewallRule -DisplayName $ruleName -ErrorAction SilentlyContinue)) {
New-NetFirewallRule -DisplayName $ruleName `
-Direction Outbound -Action Block -Protocol TCP -RemotePort $port `
-RemoteAddress Any -Profile Any -Enabled True | Out-Null
Write-Host "Created block rule: $ruleName" -ForegroundColor Yellow
}
}
# NOTE: Pair each deny rule with explicit ALLOW rules for approved OT application binaries
# to approved PLC subnets only. Example:
# New-NetFirewallRule -DisplayName "OT-Allow-Kepware-Modbus" -Direction Outbound -Action Allow `
# -Program "C:\Program Files (x86)\Kepware\KEPServerEX 6\server_runtime.exe" `
# -Protocol TCP -RemotePort 502 -RemoteAddress 10.10.20.0/24
# 4) Check for common dual-homing red flags (multiple active NICs spanning IT and OT)
Write-Host "=== Active Network Adapters (dual-homing check) ===" -ForegroundColor Cyan
Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name, InterfaceDescription, LinkSpeed | Format-Table -AutoSize
Remediation
There is no patch for this finding — it's a capability demonstration, not a vulnerability. Remediation means closing the structural gaps the AI agents exploited. Prioritize in this order:
1. Enforce IT/OT segmentation that actually holds. The 16-minute perimeter-to-ICN traversal means the segmentation in the lab failed or was bypassed — as it does in most real environments. Audit every IT/OT crossing point: historians, EWS, jump boxes, remote access paths. Implement unidirectional gateways (data diodes) where one-way data flow suffices, and demand brokered, MFA-protected, session-recorded access through a dedicated jump host for everything else. Map your controls against IEC 62443 zones and conduits and NIST SP 800-82 Rev 3.
2. Build and enforce an OT application baseline. This is the single highest-value detection investment. Inventory the exact binaries permitted to communicate on ICS protocol ports from each OT host, then alert on everything else (Sigma rule #3 above). OT environments are static — whitelisting works here in a way it never will in IT.
3. Deploy OT-aware network monitoring. Passive, protocol-aware monitoring (Claroty, Nozomi, Dragos, or open-source Zeek with ICS protocol analyzers) gives you visibility into Modbus function codes, EtherNet/IP CIP objects, and S7comm job requests. An agent issuing write functions from an unrecognized IP should page someone immediately.
4. Automate response for the boundary. When detection-to-response must happen in under 16 minutes, manual triage is not a control. Pre-authorize automated containment actions for OT boundary hosts: network isolation via EDR, switchport shutdown, or firewall rule injection on high-confidence alerts like rule #3.
5. Eliminate standing credentials at the boundary. Remove cached domain admin credentials from OT hosts, enforce LAPS-style unique local admin passwords, and tier administrative accounts so IT credentials can never authenticate to OT systems. Credential theft is the accelerant in every fast intrusion chain.
6. Red-team your own OT lab against agentic tooling. Booz Allen used an isolated lab — you should too. Build a representative test environment (even virtualized PLCs via simulation tools) and measure your detection coverage against automated intrusion scenarios. If your SOC can't catch a scripted agent in a lab, it won't catch a real one in production.
7. Brief leadership on the timeline shift. This research is an effective artifact for budget conversations: the finding that an AI agent reached physical-equipment manipulation in minutes reframes OT security from a compliance checkbox to an operational safety imperative.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.