Microsoft Defender for IoT passively monitors Operational Technology (OT) networks — the PLCs, RTUs, HMIs, engineering workstations and SCADA servers that run physical processes in manufacturing, utilities, energy and building management. When its network sensor sees a controller reprogrammed, a CPU switched to STOP, an illegal industrial-protocol command, an OT device reaching the internet, or a signature match for known ICS malware, it raises an alert that lands in Sentinel via the CommonSecurityLog (CEF from the OT sensor) and the SecurityAlert table (cloud-connected sensor).
These alerts are unlike IT alerts in one decisive way: the affected asset controls something in the physical world. An attacker who reprograms a safety controller or forces a CPU to STOP can cause equipment damage, process shutdown, or a safety event. That means triage must be fast, but containment must never be reflexive — you do not "isolate" or power-off a live PLC without the OT/plant engineering team in the loop. This SOP treats any confirmed unauthorized programming, mode-change, or ICS-malware match as a SEV1 event, and hands all physical-process containment decisions to the OT owner.
☰ Table of Contents
01 — BACKGROUND
TECHNIQUE OVERVIEWDefender for IoT sensors sit on a SPAN/mirror port of the OT network and passively decode industrial protocols (Modbus, DNP3, S7comm/S7Plus, EtherNet/IP-CIP, BACnet, OPC-UA, IEC 60870-5-104, PROFINET and others). They build a behavioural baseline of every asset and every command, then raise alerts from five engines when reality deviates from that baseline. Understanding which engine fired tells you how urgent the alert is.
| Detection Engine | What it fires on | Typical urgency |
|---|---|---|
| Protocol Violation | Malformed or illegal protocol field/function code — a command the protocol spec does not permit | SEV2–SEV1 |
| Policy Violation (Baseline) | A permitted command from an asset that has never issued it before — new programming, new connection, new device | SEV1 if programming |
| Anomaly | Statistical deviation — traffic volume, scan pattern, timing outside the learned norm | SEV2 |
| Malware | Signature/behaviour match for known ICS malware or IT malware seen on OT (e.g. TRITON, Industroyer, EternalBlue lateral spread) | SEV1 |
| Operational | Device health / operational events — PLC stopped, firmware changed, comms lost | SEV2–SEV1 |
The four incident classes a SOC covering OT actually sees behind these engines:
- A1Unauthorized PLC programming / mode change — an engineering command (program download, logic write, RUN→STOP) from an unexpected host or outside a maintenance window. This is the highest-consequence class: it can halt or manipulate a physical process. Maps to MITRE ICS T0843 Program Download, T0889 Modify Program, T0858 Change Operating Mode.
- A2Illegal / anomalous ICS protocol operation — an illegal Modbus function code, an unexpected S7 stop-CPU, a write to a register that is normally read-only. Maps to T0855 Unauthorized Command Message, T0836 Modify Parameter, T0831 Manipulation of Control.
- A3OT-to-internet or IT→OT boundary crossing — an OT asset that should be air-gapped or DMZ-fronted reaching an external IP, or a new IT-side host talking directly to a controller. Maps to T0883 Internet Accessible Device and reconnaissance T0846 Remote System Discovery.
- A4Known ICS malware / IT malware on OT — signature hit for ICS-targeting malware, or a commodity worm (SMB/EternalBlue) spreading onto the OT VLAN from a compromised engineering workstation.
| Field | Value |
|---|---|
| Primary Log Source | CommonSecurityLog (CEF from OT sensor: DeviceVendor="Microsoft", DeviceProduct contains "Defender for IoT"), SecurityAlert (cloud-connected sensor, ProductName "Azure Defender for IoT" / "Microsoft Defender for IoT") |
| Secondary Log Sources | DeviceNetworkEvents / SecurityEvent from the engineering workstation (IT side), Syslog from the OT firewall, AzureActivity if the sensor is cloud-managed |
| Key MITRE ICS Techniques | T0843, T0889, T0858, T0855, T0836, T0831, T0883, T0846, T0842 |
| Default Severity | SEV1 for programming / mode-change / ICS malware; SEV2 for anomaly / new-asset / boundary alerts pending scope |
| Detection Window | Query last 24h for the alert; extend to 7d when reconstructing an engineering-change timeline |
OT containment is NOT IT containment. Isolating or powering off a controller that is actively running a process can itself cause a safety or availability incident. Every physical-process action in Section 03 is a JOINT decision with the OT/plant engineering owner — the SOC investigates and advises, the process owner executes.
02 — IDENTIFICATION
5 INDICATORSAnswer these five questions in the first minutes. Any single YES to Q1–Q3 makes this SEV1 and starts the parallel OT-owner engagement in Section 03 — you do NOT wait for the full investigation to finish.
| # | Question | If YES |
|---|---|---|
| Q1 | Did the alert report a program download, logic write, firmware change, or RUN→STOP/PROGRAM mode change on a PLC/RTU/safety controller? | SEV1 → I1 |
| Q2 | Is it an illegal/unauthorized protocol command or a write to a normally read-only control register? | SEV1 → I2 |
| Q3 | Does the alert match a known ICS-malware / worm signature on an OT asset? | SEV1 → I4 |
| Q4 | Is an OT asset talking to the internet, or is a new IT host talking to a controller? | SEV2 → I3 |
| Q5 | Is there an approved change ticket / maintenance window that names THIS device, THIS change, in THIS time window? | Candidate FP → I5 gate |
Know your source asset before you judge urgency. Pull the device role from the Defender for IoT device inventory — a "Safety Instrumented System (SIS)" or "PLC" firing I1/I2 is categorically more severe than an HMI or a printer. Asset criticality is the multiplier on every severity call in this SOP.
Downloading new logic, writing firmware, or switching a controller to STOP/PROGRAM mode changes what the physical process does. Outside a documented maintenance window this has no legitimate cause and is the single most consequential OT event — it can halt a line, defeat a safety interlock, or manipulate a setpoint. Confirm the engineering source and whether a change ticket exists.
- 1Open the incident in Microsoft Sentinel → Incidents. Note the alert Name, Source/Destination IP entities and the sensor that raised it.
- 2Pivot to the OT sensor: Defender for IoT → Device inventory (or the on-prem sensor console) and open the source device — record its role (PLC / RTU / SIS / Engineering Workstation), vendor, and firmware.
- 3Open the Event timeline for the target controller and read the exact protocol operation — program download, memory write, or mode change — and the source host that issued it.
- 4Check the change-management system for an approved ticket that names this controller, this change, in this window. No ticket = treat as SEV1 and begin OT-owner engagement (Section 03) in parallel.
- 5Run the KQL/SPL below to pull every programming/mode-change alert for correlation and to spot whether multiple controllers were touched (indicates a campaign, not a single maintenance action).
| Alert Signal / Operation | Meaning | Severity |
|---|---|---|
| PLC operating mode changed (RUN → STOP) | Controller halted — process stop / denial of control | CRITICAL |
| PLC operating mode changed (→ PROGRAM/REMOTE) | Controller put into a state that accepts logic writes | CRITICAL |
| Program / project download to controller | New ladder/logic pushed — process behaviour redefined | CRITICAL |
| Firmware change / update detected | Controller firmware altered — persistence / backdoor risk | CRITICAL |
| Unauthorized PLC configuration read | Logic/config exfil — often reconnaissance before a write | HIGH |
Do NOT ask the OT team to "just reboot the PLC" to clear the state. A controller in STOP or holding attacker-modified logic is evidence AND a live safety state. Capture the current logic/project first (via the OT owner) and let the process engineer decide the safe recovery sequence.
Industrial protocols were designed without authentication — anyone who can reach a controller on the wire can command it. An illegal Modbus function code, an unexpected S7 stop, or a write to a register that is normally only read is a direct manipulation-of-control attempt. The Protocol Violation and Policy Violation engines surface these; you confirm the command target and whether it changed a live setpoint.
- 1In the OT sensor console open Event timeline and filter to the target device and the alert time. Read the decoded protocol payload — function code, register/coil address, and value written.
- 2Compare the operation against the device's learned baseline (the sensor flags "new" operations). A write to a register the asset has only ever been read from is high-fidelity malicious.
- 3Identify the source host. A legitimate write normally comes from a known HMI or SCADA server; a write from an engineering workstation, laptop, or unknown IP is the tell.
- 4Cross-reference I1 — an illegal write immediately after a mode change to PROGRAM is a confirmed attack chain, not two coincidences.
- 5Run the KQL/SPL below to enumerate protocol-violation alerts and group by source to separate one probing host from routine noise.
| Protocol Signal | Meaning | Severity |
|---|---|---|
| Illegal Modbus function code | Command outside the Modbus spec — probing or exploit attempt | HIGH |
| Unauthorized write to holding register / coil | Setpoint / actuator manipulation — Manipulation of Control | CRITICAL |
| S7 CPU stop / unexpected S7comm command | Siemens controller stop or unlearned command | CRITICAL |
| DNP3 / IEC-104 control command from new master | Unexpected control-station issuing operate commands | CRITICAL |
| Function-code / address scan across many registers | Enumeration of controller memory map — recon | HIGH |
Write vs read is the whole game in ICS triage. Read/poll traffic is normal SCADA behaviour and floods the sensor. Filter to write/control operations (write coil, write register, operate, program) first — that is where manipulation lives.
OT networks are supposed to be segmented behind a DMZ (the Purdue model). An OT asset reaching an external IP suggests either a misconfiguration, an unauthorized remote-access tool, or live C2 from a compromised controller/workstation. A brand-new IT-side host talking directly to a PLC is the classic pivot from a breached engineering workstation into the process network.
- 1From the alert, get the OT asset IP and the external/peer IP. Confirm the external IP is genuinely outside the OT/DMZ ranges (not an internal historian or update server that lives in the DMZ).
- 2In the Defender for IoT Device map, trace the connection path — did traffic cross the IT→OT boundary, and through which conduit/firewall?
- 3Pivot to the IT side: if the peer is an engineering workstation, query DeviceNetworkEvents / SecurityEvent for that host to check for a foothold (SOP-24/25/60 pivot).
- 4If the external IP is reachable in threat intel, treat the OT asset as potentially C2-controlled and pivot to SOP-65 (TI IOC match) for the network-indicator workflow.
- 5Run the KQL/SPL below to list OT assets with external connectivity and any new IT→OT flows.
| Boundary Signal | Meaning | Severity |
|---|---|---|
| Internet connectivity detected (OT asset) | Air-gapped/DMZ asset reaching a public IP — exposure or C2 | HIGH |
| New connection to controller from IT subnet | Possible pivot from a compromised engineering workstation | HIGH |
| Unauthorized remote-access protocol (RDP/VNC/TeamViewer) to OT | Interactive access into the process network | HIGH |
| Network scan / host sweep on OT VLAN | Remote System Discovery — mapping controllers | MEDIUM |
A "new IT→OT connection" is only benign if it maps to an approved conduit in the segmentation design. Never dismiss it as "probably a new SCADA client" — confirm the source host, the account, and that the firewall rule permitting it was intended.
The Malware engine matches signatures/behaviour for ICS-targeting malware and for commodity worms that spread over SMB onto flat OT networks. A hit here means code — not just a command — is present on the process network. Confirm the affected host, the propagation method, and whether it has reached any controller.
- 1Read the malware alert's family/signature name and the affected asset. If the asset is a Windows engineering workstation or HMI, pivot to Defender XDR → Advanced Hunting for endpoint telemetry on that host.
- 2Determine propagation: SMB/EternalBlue lateral movement, USB, or a malicious project file. The sensor's connection view shows which OT hosts the infected node has since contacted.
- 3Check whether the infected host has issued any programming/protocol commands to a controller (correlate with I1/I2) — this is the difference between a contained IT infection on the OT VLAN and an active process attack.
- 4Extract file hashes / IOCs from the endpoint side and hand them to the TI hash workflow (SOP-66) for tenant-wide scoping.
- 5Run the KQL/SPL below to list malware-engine alerts and, where the affected host has EDR coverage, correlate the process activity.
| Malware Signal | Meaning | Severity |
|---|---|---|
| Known ICS malware signature match | ICS-targeting malware present on the OT network | CRITICAL |
| Suspicion of malicious activity (SMB exploit) | Worm-style lateral movement (e.g. EternalBlue) onto OT | CRITICAL |
| Malicious DNS / C2 pattern from OT asset | Command-and-control beaconing from the process network | HIGH |
| Suspicious file transfer to controller | Payload / project file pushed toward a PLC | HIGH |
Before escalating, lock down what you know and make an explicit call. OT alerts have a high benign rate driven by legitimate maintenance and engineering work — but "it was probably an engineer" is a hypothesis, not a verdict. Close as FP only when a change record actually names the device, the change, and the window.
Extract and record before you move to containment:
- 1Source host — IP, hostname, MAC, and asset role (engineering WS / laptop / unknown) that issued the command.
- 2Target asset — controller IP, vendor/model, firmware, site/zone, and its process criticality.
- 3Operation — the exact protocol command (program download, register write + value, mode change), timestamp, and protocol.
- 4External IOCs — any external IP/domain/hash from I3/I4, plus the account/credential used if identifiable.
- 5Scope — how many controllers/assets were touched, and whether the source also appears in IT-side logs.
| True-Positive Signals | False-Positive Signals |
|---|---|
| Programming / mode-change with NO change ticket for this device+window | Change ticket names this exact controller, change and maintenance window |
| Command source is an unknown host, laptop, or IT-subnet IP | Source is the sanctioned engineering workstation, from the OT network, during business hours |
| Write to a normally read-only control register / illegal function code | Read/poll operation matching the asset's learned baseline |
| OT asset reaching the internet or an external TI-matched IP | Destination is an approved DMZ historian/update server in the segmentation design |
| Multiple controllers touched, or correlated IT-side foothold present | Single asset, sensor still learning (recent deployment / new device onboarding) |
A newly deployed Defender for IoT sensor generates baseline-learning noise for its first weeks — "new operation" alerts flood in as it learns normal. That is a tuning problem, not a licence to auto-close programming or mode-change alerts. Q1–Q3 SEV1 signals are never dismissed as "just learning."
03 — CONTAINMENT
SAFETY-FIRST ACTIONEvery physical-process action from here is a JOINT call with the OT/plant engineering owner and follows the site's OT incident-response and safety plan. The SOC advises and provides evidence; the process owner authorizes and executes anything that touches a running controller. Never unilaterally isolate or stop OT equipment.
- 1Cut the attacker path, not the process. Block the malicious source host / external IP at the IT→OT firewall or DMZ conduit so it can no longer reach controllers — this stops further commands without touching the running PLC.
- 2If the source is an IT-side engineering workstation with EDR, isolate that host in Defender for Endpoint (Assets → Devices → Isolate). Isolating the IT foothold is safe; isolating the controller is not.
- 3With the OT owner, decide on controller state: if a controller was switched to STOP or is holding modified logic, the process engineer determines the safe hold/failover state — the SOC does not command the PLC.
- 4Disable or reset the credential/account used to issue the commands (engineering account, shared HMI login). Coordinate so operators are not locked out of a running process.
- 5Preserve evidence: capture the current PLC project/logic (via the OT owner), export the sensor PCAP/event timeline around the alert, and snapshot the affected engineering workstation before any cleanup.
- 6Sweep for scope: check whether the same source touched other controllers/zones and whether the malicious IP is blocked on every conduit, not just the one that alerted.
The fastest safe containment for most OT intrusions is a boundary block plus an IT-side isolation — you sever the attacker's reach to the process network while leaving the physical process running under the plant team's control. Reserve any controller-level action for the process owner.
- 1Block all extracted IOCs (external IPs/domains/hashes) at the perimeter, the OT firewall, and via MDE indicators for any Windows OT/IT hosts.
- 2Verify the IT→OT boundary: confirm no other unauthorized conduit rule permits the same reach, and remove any temporary/legacy allow rule the attacker may have used.
- 3Disable unauthorized remote-access to OT (RDP/VNC/vendor tools) discovered in I3; route all legitimate remote access through the approved jump host only.
- 4Raise the affected assets' monitoring: add a focused Defender for IoT / Sentinel watchlist for the source, target controllers, and IOCs so any recurrence pages immediately.
If a controller's logic or firmware was confirmed modified, treat the device as compromised until the process engineer restores a known-good project from offline engineering backups. A reboot does NOT remove attacker-written logic or firmware.
04 — ERADICATION
CLEANUP- 1Restore controller integrity (OT owner). For any PLC/RTU with modified logic or firmware, the process engineer re-loads the verified known-good project from offline engineering backups and confirms the running logic matches the master copy — during a planned, safe process state.
- 2Eradicate the IT foothold. On the compromised engineering workstation/HMI, remove malware and persistence (scheduled tasks, run keys, services, rogue remote-access tools) — cross-reference SOP-26 and SOP-30; re-image if integrity cannot be assured.
- 3Rotate credentials. Reset the engineering/HMI accounts and any shared OT credentials used in the intrusion; remove any accounts the attacker added.
- 4Close the entry vector. Fix the specific gap — a flat IT/OT segment, an exposed remote-access service, an unpatched engineering workstation, or a permissive firewall conduit — so the same path cannot be reused.
- 5Verify clean state. Re-run the I1, I2 and I3 queries over the incident window and forward — expected result is 0 new unauthorized programming, illegal-command, or boundary-crossing hits from the source.
- 6Reconstruct the timeline. Document first access → pivot into OT → commands issued → controllers touched → containment, and assess any physical-process impact with the plant team.
- All affected controllers verified running known-good logic/firmware from offline backup
- IT foothold (engineering WS / HMI) cleaned or re-imaged and back under EDR coverage
- Engineering / HMI / shared OT credentials rotated; attacker-added accounts removed
- Entry vector closed — segmentation, remote-access, or patch gap remediated and verified
- I1 / I2 / I3 re-run returns 0 new unauthorized activity from the source
- All IOCs blocked at perimeter + OT boundary + MDE; recurrence watchlist active
- Timeline reconstructed and physical-process impact assessed with the OT owner
Do not return an OT asset to normal service until the process engineer confirms the running logic is trusted AND the entry vector is closed. Attackers who retain a network path re-enter the process network within hours.
05 — ESCALATION
ESCALATION PATHS| Tier | Trigger Condition | Who to Notify | Action |
|---|---|---|---|
| L1 → L2 | Cannot determine TP/FP within 30 min; any programming/mode-change/malware alert; source not identified | L2 SOC + OT security liaison | Hand over with source/target/operation captured |
| L2 → IR + OT Owner | Confirmed unauthorized programming, illegal control write, or ICS malware; boundary crossing with IT foothold | IR team + plant/OT engineering owner | Joint containment; safety-plan invoked; war room |
| IR → CISO / Plant Mgmt | Physical-process impact possible or occurred; safety system (SIS) touched; multiple controllers affected | CISO + plant management + safety officer | Business-continuity + safety response; regulator readiness |
| External | Critical-infrastructure impact, safety event, or regulated sector (energy/water/utilities); nation-state indicators | ICS vendor, sector CERT/CISA, regulator, law enforcement | Coordinated disclosure per sector obligations |
Bring to every escalation:
- 1Incident / alert ID, sensor name, and Defender for IoT engine that fired.
- 2Source host and target controller(s) — IP, role, vendor/model, site/zone, criticality.
- 3The exact operation (command, register/value, mode change) and full timeline.
- 4Containment actions already taken (boundary block, IT-side isolation, credential reset).
- 5Current confidence (TP confirmed / suspected / unverified) and assessed or potential physical-process impact.
Any confirmed attack on a Safety Instrumented System (SIS) is a life-safety matter, not just a cyber incident. Escalate to the safety officer and plant management in parallel with IR — do not let it sit in a SOC queue.
Stay Threat-Ready
Follow CyberHawk Threat Intel for daily SOC analyst playbooks, detection engineering guides, and threat intelligence.