T1693.002: Module Firmware
Adversaries may install malicious or vulnerable firmware onto modular hardware devices. Control system devices often contain modular hardware devices. These devices may have their own set of firmware that is separate from the firmware of the main control system equipment.
This technique is similar to System Firmware, but is conducted on other system components that may not have the same capabilities or level of integrity checking. Although it results in a device re-image, malicious device firmware may provide persistent access to remaining devices.[1]
An easy point of access for an adversary is the Ethernet card, which may have its own CPU, RAM, and operating system. The adversary may attack and likely exploit the computer on an Ethernet card. Exploitation of the Ethernet card computer may enable the adversary to accomplish additional attacks, such as the following:[1]
* Delayed Attack - The adversary may stage an attack in advance and choose when to launch it, such as at a particularly damaging time. * Brick the Ethernet Card - Malicious firmware may be programmed to result in an Ethernet card failure, requiring a factory return. * Random Attack or Failure - The adversary may load malicious firmware onto multiple field devices. Execution of an attack and the time it occurs is generated by a pseudo-random number generator. * A Field Device Worm - The adversary may choose to identify all field devices of the same model, with the end goal of performing a device-wide compromise. * Attack Other Cards on the Field Device - Although it is not the most important module in a field device, the Ethernet card is most accessible to the adversary and malware. Compromise of the Ethernet card may provide a more direct route to compromising other modules, such as the CPU module.
Analyst context for executives and security teams
Module Firmware matters because an ICS device may rely on add-on modules, such as communication cards, that run their own firmware separate from the main controller. If that module firmware is malicious or vulnerable, a device can be re-imaged in a way that creates persistence, causes module failure, or provides a path toward other components. For business leaders, the risk is not just an IT compromise; it can affect PLCs, safety controllers, DCS controllers, and PACs that support operational continuity and safety-critical processes.
Executive priority
Prioritize this where modular controllers support critical production, safety, or continuous process operations. Leaders should ask whether firmware integrity, access control, network segmentation, and audit evidence extend to controller modules—not only to the main device. This is also a compliance and resilience issue: incident responders need known-good firmware baselines, asset/module inventories, and evidence of who can access or update field devices before an outage or suspected tampering event.
Technical view
SOC, OT engineering, and IR teams should validate coverage around modular embedded assets targeted by this technique: PLCs, safety controllers, DCS controllers, and PACs. MITRE provides no platform or tactic values and no official detection text, but the relationship to DET0790 indicates a detection strategy exists for Module Firmware. Practical validation should focus on whether teams can observe firmware changes, module reboots or failures, unauthorized network access to field devices, and deviations from known-good firmware states. Treat Ethernet or communications modules as separate attack surfaces with their own firmware, authentication, and integrity requirements.
Likely telemetry
- ICS asset and module inventory, including firmware versions for controller modules
- Known-good firmware hashes, signatures, or baseline integrity records
- Engineering workstation, maintenance, or gateway logs showing access to field devices
- Network traffic between engineering/management systems and PLC, PAC, DCS, or safety controller modules
- Authentication and authorization logs for users, devices, software processes, and gateways
Detection direction
- Confirm whether DET0790-aligned logic is implemented locally; the supplied ATT&CK object does not include detection details.
- Baseline module firmware versions and compare after device reboots, program downloads, program restarts, maintenance windows, or communication-card failures.
- Tune alerts for unexpected firmware changes, unauthorized access attempts, unusual management connections, or module behavior inconsistent with expected operational sequences.
- Reduce false positives by correlating with approved maintenance work orders, authorized engineering sessions, and planned firmware updates.
- Check blind spots around Ethernet cards and other modules that may not expose the same logs, integrity checks, or authentication controls as the main controller.
Mitigation priorities
- Start with asset and firmware audit practices: maintain module inventories and known-good firmware integrity records, supported by periodic checks.
- Restrict access to field devices using Access Management, Human User Authentication, and Software Process and Device Authentication where feasible in the ICS environment.
- Use Network Segmentation, Network Allowlists, and Filter Network Traffic to limit which systems can communicate with controller modules and which protocols or message patterns are allowed.
- Apply Communication Authenticity and encryption controls for untrusted networks where supported, recognizing that legacy ICS constraints may limit options.
- Prefer Code Signing and Boot Integrity capabilities for firmware and module startup validation when available from the device ecosystem.
Analyst notes and limits
This is a sub-technique of Modify Firmware and supersedes the revoked T0839 Module Firmware object. The supplied relationships make the cyber-physical relevance clear: targeted assets include PLCs, safety controllers, DCS controllers, and PACs, all embedded ICS assets. The practical emphasis should be on module-level visibility and control, especially for communications modules that may be more exposed than the main controller.
The official ATT&CK object does not specify tactics, platforms, aliases, or detection text. The assessment therefore cannot assert active exploitation, adversary attribution, guaranteed detection coverage, or specific vendor behavior. Local architecture, device capabilities, maintenance practices, and available OT telemetry determine actual exposure and control effectiveness.
Module Firmware
Adversaries may install malicious or vulnerable firmware onto modular hardware devices. Control system devices often contain modular hardware devices. These devices may have their own set of firmware that is separate from the firmware of the main control system equipment.
This technique is similar to System Firmware, but is conducted on other system components that may not have the same capabilities or level of integrity checking. Although it results in a device re-image, malicious device firmware may provide persistent access to remaining devices.[1]
An easy point of access for an adversary is the Ethernet card, which may have its own CPU, RAM, and operating system. The adversary may attack and likely exploit the computer on an Ethernet card. Exploitation of the Ethernet card computer may enable the adversary to accomplish additional attacks, such as the following:[1]
* Delayed Attack - The adversary may stage an attack in advance and choose when to launch it, such as at a particularly damaging time. * Brick the Ethernet Card - Malicious firmware may be programmed to result in an Ethernet card failure, requiring a factory return. * Random Attack or Failure - The adversary may load malicious firmware onto multiple field devices. Execution of an attack and the time it occurs is generated by a pseudo-random number generator. * A Field Device Worm - The adversary may choose to identify all field devices of the same model, with the end goal of performing a device-wide compromise. * Attack Other Cards on the Field Device - Although it is not the most important module in a field device, the Ethernet card is most accessible to the adversary and malware. Compromise of the Ethernet card may provide a more direct route to compromising other modules, such as the CPU module.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0839 | Module Firmware | Module Firmware revoked by this object. |
| ICS | T1693 | Modify Firmware | This object subtechnique of Modify Firmware. |
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 8036148d042b… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Daniel Peck, Dale Peterson January 2009
Daniel Peck, Dale Peterson 2009, January 28 Leveraging Ethernet Card Vulnerabilities in Field Devices Retrieved. 2017/12/19
Open source URL -
[2]
mitre-attack T1693.002Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.