Hunt playbook
Unauthorized Firmware Change
Identify devices whose firmware version or integrity state changed without an approved work order.
AdvancedT0857T0839
Hypothesis
One or more devices may be running firmware that was not installed through the approved process.
Why this hunt matters
Firmware persists beneath the application layer and can survive normal recovery activity.
Scope
Assets: plc, ied, industrial-switch, vfd, protective-relay
Protocols: ethercat, ethernet-ip, iec-61850
Data sources required
- Asset inventory firmware fields
- Passive discovery version data
- Device logs
- Work orders
- Vendor tooling reports
Baseline needed first
- A firmware version register per device, refreshed on a schedule
Hunt steps
- 01Export current firmware versions from passive discovery or vendor tooling
- 02Diff against the last recorded baseline
- 03For every difference, find the work order and engineer
- 04Check for firmware transfer protocol activity (e.g. file transfer services) in the period
- 05Confirm the running version matches a vendor-published release
Indicators of interest
- Version changes with no work order
- Versions that do not match vendor release notes
- File transfer activity to devices outside maintenance
Triage
- Was the device replaced rather than updated?
- Who had physical or network access?
- Does the vendor publish that version?
Likely false positives
- Hardware replacement with a different factory version
- Vendor service visits
- Inventory data quality issues
Escalation
- A version that does not exist publicly
- Safety or protection device involved
Containment options
- Plan any reflash with engineering; unexpected device reboots can trip the process
Validation
- Firmware register updated
- Change control reinforced
- Detection for device file transfer activity
Why should I care?
Containment in OT is a joint decision. Isolating a device can be the safest action or the one that stops production — operations decides, security advises.