---
name: harden-iot
description: "Harden IoT and embedded devices against firmware tampering, hardware-interface abuse, and RTOS/ICS compromise: firmware replacement, root shells on open UART or JTAG/SWD ports, unlocked bootloader consoles, default credentials, and unauthorized commands or program downloads over Modbus, DNP3, S7comm, and MQTT (MITRE ATT&CK T1542, T1542.001, T1495, T1200, T1078.001; ICS T0857, T0839, T0812, T0843, T0855, T0848). Signals: firmware and boot telemetry (verified boot, OTA signature checks, TPM attestation), device console syslog, OT network monitoring (Zeek, Mosquitto), and Microsoft Defender for IoT alerts. Gives a hunt and a hardening plan mapped to ISO 27001, NIST CSF, and the Essential Eight. Use when hardening an IoT or embedded fleet, locking down debug ports and bootloader consoles, enforcing signed firmware and secure boot, hunting unauthorized PLC program downloads or rogue Modbus writes, or triaging Defender for IoT alerts."
---

# IoT, Embedded, and ICS Hardening - Defensive Methodology

> **Tier 2 - methodology skill.** No bespoke UMBRASEC detection rule ships with this skill yet. It gives the defender's method, the log sources and signals, the hunt, and the hardening, and points to public rule sources. Promotion to Tier 1 (a sourced, tuned UMBRASEC rule) is tracked in [COVERAGE.md](https://github.com/umbrasec-labs/umbra-blue/blob/main/COVERAGE.md). Do not treat the content below as citing a UMBRASEC rule; there is none for this threat yet.

## TL;DR

IoT and embedded security fails at three seams: the firmware image, the physical debug interface, and the control protocols an RTOS or PLC speaks. An attacker who cannot break AES still gets far by replacing or downgrading firmware, dropping a root shell on an open serial or JTAG header, stopping at an unlocked bootloader console, logging in with a default credential, or sending control commands as a rogue master. You rarely watch the attacker at the pins; you watch the device report an unexpected firmware version, a boot measurement that does not match, a root login on a console that should have none, and a write or program-download command from a host that is not the engineering workstation. The durable defenses are prevention: sign firmware and enforce verified boot with anti-rollback, fuse off or readout-protect the debug ports, strip the bootloader console and the root getty from production builds, replace default credentials with unique per-device secrets, and segment and allowlist the OT protocols. Ship the boot, OTA, console, and OT-network telemetry to your SIEM so the failures above become alerts rather than silent events. No single signal is conclusive; layer them.

## What it looks like, defender view

Firmware tampering surfaces as a device that boots an image it should not: a verified-boot step that fails and falls back, an anti-rollback counter rejecting a downgrade, an OTA server logging a signature-check failure, or a fleet member reporting a firmware version that drifts from the signed manifest. Hardware-interface abuse is physical and therefore nearly invisible at the moment it happens; what you see afterward is a `root` login on a serial console (`ttyS0`/`ttyAMA0`) or a telnet/dropbear session that production should never allow, a tamper switch tripping, or a device whose firmware or configuration changed with no authorized OTA behind it. A bootloader console left enabled on the serial header lets anyone with the enclosure open change boot arguments; the trace is the device coming up in an unexpected state, not the keystrokes. RTOS and ICS compromise shows on the wire: a new master issuing Modbus write function codes, a PLC program download from a non-engineering host, an OPC-UA session negotiated with no security policy, or an MQTT client connecting anonymously with an unfamiliar client ID. None of this requires broken crypto; it requires an unsigned image, an open port, a default password, or a permissive protocol configuration.

## Log sources and signals

The telemetry lives at the boot chain, the device console, the OTA service, and the OT network. Ship these to your SIEM.

- **Boot and firmware integrity.** U-Boot FIT verified-boot console output distinguishes a good image (`Verifying Hash Integrity ... sha256,rsa2048:dev+ OK`) from a bad one (`Bad Data Hash`, `signature check failed`). Anti-rollback version counters reject a downgrade and should log it. On embedded Linux, the IMA measurement list (`/sys/kernel/security/ima/ascii_runtime_measurements`) and, where a TPM is present, the TPM event log and PCR 0 to 7 values plus remote-attestation pass/fail are the measured-boot signal. A PCR mismatch or an attestation failure means the boot chain is not what it was.
- **OTA update service.** The update server or device-management platform logs each image offered and the device's reported result: signature-verification failures, hash mismatches against the signed manifest, and version downgrades. Fleet-wide firmware-version drift (a handful of devices on an image the manifest does not list) is one of the strongest firmware signals you have.
- **Device console and OS logs.** BusyBox `syslogd` and the kernel ring buffer (`dmesg`) from the device; the util-linux/BusyBox `login` writing a root login on `ttyS0`, and dropbear or telnetd session lines. Any interactive root session on a production device console is high interest.
- **OT and RTOS network monitoring.** Zeek emits native `modbus.log`, `dnp3.log`, and MQTT logs (`mqtt_connect.log`, `mqtt_publish.log`, `mqtt_subscribe.log`); the CISA ICSNPP parsers at [github.com/cisagov/icsnpp](https://github.com/cisagov/icsnpp) add s7comm, EtherNet/IP and CIP, BACnet, and OPC-UA binary. Key signals: Modbus write function codes `5`, `6`, `15`, `16` from a source that is not the known master; DNP3 OPERATE / DIRECT_OPERATE (and DIRECT_OPERATE_NR) function codes from a new master station; S7comm or EtherNet/IP program-download function codes; OPC-UA sessions using `SecurityPolicy#None`; MQTT anonymous connects and new client IDs. The Mosquitto broker log records `New client connected from ...` and authentication failures when `allow_anonymous false` is set.
- **Managed OT sensors.** Microsoft Defender for IoT and equivalent passive monitors raise alert classes for firmware change, unauthorized PLC programming, PLC stop, new asset discovered, and unauthorized internet connectivity from an OT device. Treat each as a lead, not a verdict; see the Microsoft Defender for IoT alert reference.

What normal looks like, so the anomaly is legible: a device boots the manifest firmware with every verified-boot step passing and a stable PCR set; firmware changes only during an authorized OTA window; production consoles present no interactive root session; writes and program downloads over OT protocols originate only from the known engineering workstation or SCADA master; MQTT clients authenticate with known identities. Steady-state signature failures, attestation mismatches, and console root logins should be at or near zero.

## Detection approach

Alert on the integrity and authorization failures, because that is where tampering becomes visible and false positives are lowest.

1. **Firmware integrity and rollback.** Alert on any OTA signature-check failure, hash mismatch against the signed manifest, anti-rollback rejection, or a device reporting a firmware version the manifest does not contain. Correlate version drift across the fleet rather than trusting a single device's self-report.
2. **Boot-chain attestation.** Alert on a verified-boot failure or fallback in U-Boot output, an IMA measurement that changes unexpectedly, or a TPM PCR mismatch or remote-attestation failure. Baseline the known-good PCR set first.
3. **Debug interface and console access.** Alert on any interactive root login on a device serial console and on telnet or dropbear sessions to devices that production should not expose. Pair with tamper-switch and chassis-intrusion events where the hardware provides them.
4. **ICS and RTOS protocol anomalies.** Alert on Modbus write function codes and DNP3 operate commands from a source other than the sanctioned master (rogue master, T0848, T0855), on PLC program downloads over S7comm or EtherNet/IP from a non-engineering host (T0843), and on OPC-UA sessions negotiated with no security policy.
5. **Egress anomaly.** Alert when an embedded or OT device that should talk only to its gateway or broker suddenly reaches the internet or a new destination.

There is no widely maintained public Sigma ruleset dedicated to embedded firmware tampering or ICS protocol abuse, so this skill does not point you at one that does not exist. The practical path is to normalize the boot, OTA, console-syslog, and Zeek/ICSNPP OT streams into your SIEM and author the correlations above against those fields. Use the public SigmaHQ repository ([github.com/SigmaHQ/sigma](https://github.com/SigmaHQ/sigma)) as the format and category reference (its Linux and network categories cover the console-login and egress cases), the CISA ICSNPP Zeek parsers ([github.com/cisagov/icsnpp](https://github.com/cisagov/icsnpp)) for the exact OT fields your sensors emit, the Microsoft Defender for IoT alert reference for its managed analytics, and MITRE D3FEND ([d3fend.mitre.org](https://d3fend.mitre.org/)) for the countermeasure framing. A tuned UMBRASEC rule for this threat is not yet shipped; see the Tier 2 banner above.

## Threat hunt

Hypothesis: an attacker has tampered with device firmware, used a debug interface, or is issuing unauthorized control commands.

1. Pull the fleet firmware inventory and compare each device's reported version and, where available, image hash against the signed manifest. Flag any device on an off-manifest version, any anti-rollback rejection, and any OTA signature-check failure in the window.
2. Pull boot-chain evidence for flagged devices: verified-boot output, IMA measurement lists, and TPM PCR values. A device whose PCR set or IMA list diverges from its known-good baseline without an authorized update is a strong candidate.
3. Pull device console and auth logs and search for interactive root logins on serial consoles and for telnet/dropbear sessions. Correlate any hit with tamper-switch events and with the timing of the firmware or configuration change.
4. Pull OT network logs (Zeek `modbus.log`, `dnp3.log`, MQTT logs, ICSNPP s7comm/enip/opcua) and group write and program-download commands by source. Flag any write or program download from a host that is not the sanctioned master or engineering workstation, and any OPC-UA session with no security policy.
5. Rank by blast radius: a tampered device or rogue write against a safety-instrumented controller, a medical device, or a physical actuator outranks a benign sensor, because the consequence is physical. Weigh the evidence together; no single signal proves compromise.

## Hardening

Shrink the firmware, debug-interface, and control-protocol attack surface. Mappings below use control codes grounded in the UMBRASEC [foundation guide](https://umbrasec.dev/guide/foundation.html), [identity and access guide](https://umbrasec.dev/guide/identity-and-access.html), [detection and response guide](https://umbrasec.dev/guide/detection-and-response.html), and [governance and maturity guide](https://umbrasec.dev/guide/governance-and-maturity.html); a cell is left blank where no single control maps cleanly. The ASD Essential Eight is Windows-estate oriented and maps poorly to embedded and OT devices, so most of its column is blank by design, which is honest rather than a gap.

| Control | What it does | Essential Eight | ISO 27001:2022 | NIST CSF 2.0 |
|---|---|---|---|---|
| Signed firmware and verified boot with anti-rollback | Rejects unsigned, modified, or downgraded images at boot, closing the firmware-replacement path | Patch operating systems (firmware) | A.8.8 Technical vulnerabilities; A.8.19 Software on systems | PR.PS |
| Measured boot and attestation (TPM/secure element) | Produces a boot measurement a verifier can check, so tampering with the boot chain is detectable | - | A.8.16 Monitoring activities | DE.CM; PR.PS |
| Disable or readout-protect debug interfaces | Fuses off or locks JTAG/SWD and removes the bootloader console and root getty from production builds, so an open header yields nothing | - | A.8.2 Privileged access rights | PR.AA; PR.PS |
| Replace default and hardcoded credentials | Unique per-device secrets with no shared or vendor default, so credential reuse does not scale across a fleet | - | A.5.17 Authentication information; A.8.5 Secure authentication | PR.AA-01 |
| Least privilege on device services | Removes root consoles and unneeded services and drops service privileges, shrinking what a shell can reach | Restrict administrative privileges | A.8.2 Privileged access rights | PR.AA-05 |
| Patch embedded components | Updates BusyBox, the kernel, and bundled libraries carrying known CVEs | Patch operating systems; Patch applications | A.8.8 Technical vulnerabilities | PR.PS |
| Firmware and device inventory | Tracks every device, its firmware version, and its key set, so off-manifest versions and unknown devices are visible | - | A.5.9 Inventory of assets; A.8.19 Software on systems | ID.AM |
| Supplier and SBOM assurance | Requires signed vendor images and a software bill of materials, so supply-chain tampering and vulnerable components are surfaced before deployment | - | A.5.19-5.22 Supplier relationships | GV.SC |
| OT segmentation and protocol allowlisting | Confines control protocols to a segmented network and permits writes and program downloads only from the sanctioned master | - | - | PR.AA-05 |
| OT network logging and monitoring | Turns the protocol and boot failures above into alerts rather than silent events | - | A.8.15 Logging; A.8.16 Monitoring activities | DE.CM; DE.AE |

## Honest limitations

Hardware-interface abuse is the thin spot: debug-port and chip-off attacks are physical, and a device that is dumped or glitched on a bench leaves no live telemetry at all. The defender's visibility there is indirect (a later console root login, a tamper switch, or firmware-version drift after the device returns) and the real control is prevention: fused-off JTAG/SWD, readout protection, a stripped bootloader console, and non-extractable key storage, not detection. A passive firmware dump that is never flashed back also leaves no trace; encryption and secure key storage, not logging, defend against it. Measured boot and attestation depend on a root of trust the device actually has; many low-cost IoT parts have no TPM or secure element, so the attestation signal is simply absent. OT protocols like Modbus and DNP3 have no authentication in the base specification, so a well-placed rogue master can be indistinguishable from the real one without strict source allowlisting and segmentation. Benign causes trip these signals too: an authorized firmware rollback, a maintenance engineer on the console, or a scanner probing a broker. Baseline in report-only mode, treat every signal as evidence to weigh rather than an automated block, and leave the final call to the defender.

## ATT&CK and D3FEND

- MITRE ATT&CK (Enterprise): [T1542 Pre-OS Boot](https://attack.mitre.org/techniques/T1542/) and [T1542.001 System Firmware](https://attack.mitre.org/techniques/T1542/001/), [T1495 Firmware Corruption](https://attack.mitre.org/techniques/T1495/), [T1200 Hardware Additions](https://attack.mitre.org/techniques/T1200/), [T1078.001 Default Accounts](https://attack.mitre.org/techniques/T1078/001/).
- MITRE ATT&CK (ICS): [T0857 System Firmware](https://attack.mitre.org/techniques/T0857/), [T0839 Module Firmware](https://attack.mitre.org/techniques/T0839/), [T0812 Default Credentials](https://attack.mitre.org/techniques/T0812/), [T0843 Program Download](https://attack.mitre.org/techniques/T0843/), [T0855 Unauthorized Command Message](https://attack.mitre.org/techniques/T0855/), [T0848 Rogue Master](https://attack.mitre.org/techniques/T0848/).
- MITRE D3FEND: Firmware Verification (D3-FV) and its children System Firmware Verification (D3-SFV) and Peripheral Firmware Verification (D3-PFV); Bootloader Authentication (D3-BA); TPM Boot Integrity (D3-TBI); plus Network Traffic Analysis over the OT event stream. See [d3fend.mitre.org](https://d3fend.mitre.org/).
- Standards and vendor sources: NIST SP 800-193 (Platform Firmware Resiliency: protect, detect, recover), NIST IR 8259A (IoT device cybersecurity core baseline), NIST SP 800-82 Rev 3 (Guide to OT Security), IEC 62443-4-2 (component security), and ETSI EN 303 645 (consumer IoT baseline, including no universal default passwords); CISA ICSNPP Zeek parsers at [github.com/cisagov/icsnpp](https://github.com/cisagov/icsnpp); public rule format reference at [github.com/SigmaHQ/sigma](https://github.com/SigmaHQ/sigma); Microsoft Defender for IoT alert reference documentation.

**Scope note.** This is a defensive skill. It explains the technique only to the depth needed to detect and mitigate it, ships no firmware-dumping, debug-port, glitching, or control-protocol attack tooling, and leaves the verdict to the defender.