Complete technique description
Firmware is low-level software embedded in hardware that enables systems and devices to function properly and is commonly found in ICS environments. Adversaries may modify firmware on a system or device by installing malicious or vulnerable versions that enable them to achieve objectives such as Persistence, Impair Process Control, and Inhibit Response Function.
Adversaries may modify system and device firmware by using the built-in firmware update functionality which may support local or remote installation. The malicious or vulnerable firmware may be delivered via Replication Through Removable Media, Supply Chain Compromise, or Remote Services. Once installed, the malicious or vulnerable firmware could be used to provide Rootkit and Hooking functionality, Exploitation for Privilege Escalation, or Denial of Service.[Basnight, Zachry, et al.]
Official technique definition · Open in the interactive matrix
Parent and sub-techniques
Related pages are navigation context. Their tools, rules and lab results are not automatically inherited.
Detection telemetry and configuration
These contracts are selected through exact technique-to-data-component relationships or explicitly labelled planning overrides. Configure a collector at the relevant observation point; a telemetry name alone is not coverage.
Device Alarm · source-mapped
DC0108 collection page — Subscribe to supported device alarm/audit channels; retain code, severity, source asset and acknowledgement/clear times.
Providers and collection configuration
- Agree the measurement points, read-only interfaces, sampling intervals and safety boundary with the process owner. Use a simulator or non-production fixture.
- Subscribe to supported audit/alarm events or approved historian exports. Preserve source timestamp, quality, engineering units, asset/tag identity and clock offset.
- Compare independent measurements and record gaps/latency. Do not enable intrusive polling, change controller logic or alter safety setpoints merely to generate logs.
Required normalized fields: asset_id, alarm_code, severity, active.
Illustrative collection event
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0108",
"collector": "illustrative-lab-collector",
"observation": {
"asset_id": "lab-controller-1",
"alarm_code": "LAB_COMM_LOSS",
"severity": "warning",
"active": true
}
}
Visibility limits: There is no universal PLC event ID or configuration command. Visibility depends on vendor, protocol and process. An alarm or process deviation demonstrates an effect, not necessarily a cyberattack.
Firmware Modification · source-mapped
DC0004 collection page — Collect approved OEM firmware inventory/update audit and compare version or measured hashes against a known baseline. Use read-only vendor-supported interfaces.
Providers and collection configuration
- osquery: Scheduled host-state queries; supported tables and privileges vary by OS. Select a table that actually exposes the required object.
- Linux Audit plus inventory snapshots: Events explain changes; snapshots describe state at collection time.
- Define the inventory query, allowed host set, interval and least-privileged reader. Store a stable asset ID, observation time and collector version.
- Keep successive snapshots and calculate additions, removals and changed attributes. Pair state changes with audit events when available.
- Export collector health and missed-poll counts so a missing snapshot is not misclassified as a missing asset.
Required normalized fields: asset_id, firmware_before, firmware_after, change_ticket.
Illustrative collection event
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0004",
"collector": "illustrative-lab-collector",
"observation": {
"asset_id": "lab-device-1",
"firmware_before": "1.0-lab",
"firmware_after": "1.1-lab",
"change_ticket": "LAB-42"
}
}
Visibility limits: Snapshots miss short-lived objects and do not identify who caused a change. A generic inventory agent is not guaranteed to expose firmware or kernel-level details.
Network Traffic Content · source-mapped
DC0085 collection page — Scope approved packet capture/protocol content collection to the lab flow; retain capture provenance and truncation indicators.
Providers and collection configuration
- Zeek: Connection and protocol metadata from traffic visible to the sensor.
- Suricata EVE: Configured flow, alert, DNS, HTTP, TLS and protocol records.
- Use an authorized lab TAP/SPAN, virtual mirror or gateway interface. Define which traffic crosses it; avoid assuming visibility into every segment.
- Enable the required Zeek analyzers or Suricata EVE event types. Export logs with sensor identity, clock synchronization and flow correlation identifiers.
- Monitor capture loss, truncation and exporter sampling. Capture payload only with approval and restrictive retention; encryption normally prevents plaintext inspection.
Required normalized fields: flow_id, protocol, method, path, payload_excerpt.
Illustrative collection event
Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.
{
"schema": "1200km.telemetry.example.v1",
"synthetic": true,
"timestamp": "2026-09-27T12:00:00Z",
"telemetry_id": "DC0085",
"collector": "illustrative-lab-collector",
"observation": {
"flow_id": "lab-flow-1",
"protocol": "http",
"method": "GET",
"path": "/lab-check",
"payload_excerpt": "LAB_TELEMETRY_CHECK"
}
}
Visibility limits: Flows are not packet payloads. NAT, asymmetric routes, encryption, missing mirrors and sampling can hide attribution or content. A destination connection alone does not prove malicious intent.
Simulation design and documented procedures
Atomic evidence: no compatible candidate in this snapshot. Live lab status: not run for these imported procedures.
Use a process simulator or isolated test rig with no connection to production controllers or physical actuators. Preserve safety interlocks; destructive effects require synthetic evidence, not real equipment damage.
No compatible Atomic procedure is present in this pinned evidence set. Technical feasibility has not been ruled out. A custom procedure must define the behavior, target, collection point, success observable and rollback before execution.
Technique-specific experiment contract
- Choose one procedure implementing T1693 Modify Firmware; identify the observable behavior in the source definition, not just its tactic.
- Record exact target, tool/version, inputs, privileges, network limits and approval. Never run an imported default target automatically.
- Enable the collection sources above and verify a benign baseline reaches the detector.
- Run only the approved isolated scenario; capture native events and an independent behavior observable.
- Evaluate the exact rule/model, restore the lab, and preserve configuration, event hashes, alerts, controls and misses.