MITRE ATT&CK T1495 Firmware Corruption: Detecting and Limiting Damage

When firmware is overwritten or erased, a device does not get slower or noisier: it stops booting, and reimaging the disk does not bring it back. MITRE ATT&CK T1495 Firmware Corruption is an Impact (TA0040) technique in which an adversary overwrites or corrupts the flash memory contents of system BIOS or other firmware, in the motherboard, drives, video cards or network devices, to make them inoperable or unable to boot. ATT&CK v20 lists it for Linux, macOS, Network Devices and Windows, with no sub-techniques. This guide covers the ATT&CK technique view: the recorded cases, the v20 detection strategy, the three listed mitigations and how to test that a corrupted device can be recovered. It is for detection engineers, infrastructure owners and OT engineers. For Secure Boot, measured boot and the boot chain itself, see the Firmware and Boot Security Guide; for incident handling, see the Firmware and Bootkit Compromise Playbook.

Key takeaways

• The goal is denial, not stealth. T1495 is about making hardware unusable. Implants that hide in firmware for persistence are a different technique, T1542.001 System Firmware.
• Edge and OT devices are the recent targets. In the 2025 attacks on Polish energy sites, CERT Polska reports corrupted firmware uploaded to RTUs through a default account, causing a reboot loop, and factory resets of firewalls and serial servers.
• Write protection and signed updates are the main barriers. TrickBoot's first action was to check whether the BIOS region was writable; secure update would have refused the corrupted RTU images.
• Privilege is the precondition. Flashing needs administrator, root, a kernel driver or a device management account; ATT&CK lists M1026 Privileged Account Management for this reason.
• Recovery has to be designed in advance. Spare hardware, known-good images, out-of-band reflashing and offline configuration backups decide whether the outage lasts hours or weeks.

What T1495 describes and what it does not

ATT&CK describes firmware as software loaded and executed from non-volatile memory on hardware devices to initialise and manage them, and notes that corruption of the firmware that loads the operating system on network devices may render them inoperable. Depending on the device, it may also result in Data Destruction (T1485).

How adversaries use it

• TrickBot (S0266) and its TrickBoot module: ATT&CK records that the module can write or erase UEFI/BIOS firmware. Eclypsium and AdvIntel, who published the research in December 2020, report that it identifies the platform, reads the SPI flash controller's BIOS Control and Protected Range registers to check whether the BIOS region is writable, and attempts to disable write protection, using an embedded copy of the RWEverything driver RwDrv.sys loaded as a service. At the time it only performed reconnaissance, but the researchers note that the code already contained erase functions that could render a device unusable.
• Bad Rabbit (S0606): ATT&CK records an executable that installs a modified bootloader to prevent normal boot-up.
• 2025 Poland Wiper Attacks (C0063): ATT&CK records that adversaries performed a factory reset on compromised devices, which hampered forensic investigations. CERT Polska's report on the attacks of 29 December 2025 against at least 30 wind and solar farms, a combined heat and power plant and a manufacturer gives the detail: Hitachi RTU560 controllers were accessed with a default account and had corrupted firmware uploaded, causing a reboot loop, and secure update was not enabled on any device that supported it; Moxa NPort serial device servers were factory-reset through default credentials and given unreachable IP addresses; FortiGate devices were factory-reset. The farms lost communication with distribution system operators and remote control, while generation continued.

The common thread is not exotic tooling. TrickBoot depended on unprotected flash regions; the Polish RTU and serial server cases depended on default device accounts and unsigned updates. These are configuration states defenders can measure. See the Default Credential Breaches Lessons Guide and the Pro-Russia Hacktivists Targeting OT Guide.

Signing keys are part of the attack surface

Write protection and signed updates only hold while the signing keys stay private. The MSI signing keys leak exposed firmware image signing keys for 57 products and Intel Boot Guard keys for 116, according to Binarly's analysis of the leaked data. No malicious firmware signed with them has been confirmed, but a leaked key means the platform's own verification can no longer tell a corrupted image from a genuine one. Firmware signing keys are non-human credentials of the highest value: keep them in hardware security modules, sign through a logged service and design for rotation.

What to detect and where

ATT&CK v20 maps one detection strategy, DET0167 "Firmware Modification via Flash Tool or Corrupted Firmware Upload", with one analytic per platform.

Detections to build first

1. Vulnerable or hardware-access driver loads: Sysmon 6 for drivers that expose physical memory or SPI access, matched against a blocklist and against an allowlist of approved vendor tools. See the Bring Your Own Vulnerable Driver and EDR Killers Guide.
2. Flash tool execution outside change windows: flashrom, vendor BIOS update utilities and fwupdmgr run by unexpected users or parent processes.
3. Network and OT device image changes: configuration and firmware change syslog from routers, firewalls, RTUs and serial servers, forwarded off-device, with alerts on uploads and factory resets. CERT Polska notes that factory resets erased most on-device evidence. See the Network Device Syslog and Configuration Change Detection Guide.
4. Logins to device management with default accounts: any successful login with a vendor default user name on a management interface is an incident in itself.
5. Fleet-wide boot failures: several hosts or devices failing to come back after reboot at the same time, correlated with recent privileged activity.

Mitigations

ATT&CK v20 lists three mitigations for T1495. The table expands them and adds NHI Mgmt Group recommendations.

NIST SP 800-193 Platform Firmware Resiliency Guidelines (May 2018) frames the same work as three principles: protection of firmware from tampering, detection of unauthorised changes, and recovery to a known-good state. When buying servers and appliances, ask whether the platform can recover firmware on its own.

Where identity fits

Every T1495 path above ran through an identity: a local administrator or root account able to load a driver, a default account on an RTU, a device management login, or the private key that signs firmware. Treat device management accounts and firmware signing keys as privileged non-human identities: inventory them, remove defaults, rotate them, record who uses them and when, and alert on use outside maintenance windows. See the Edge Device Security Guide.

How to implement

1. Inventory firmware-bearing assets: servers (BIOS, BMC), endpoints, network and security appliances, OT controllers and serial servers, with firmware version, update mechanism and whether signed update is enabled.
2. Close the easy paths first: default credentials and exposed management interfaces. These need no new tooling. Roll back by restoring the previous credential from the vault if an integration breaks.
3. Turn on signed update and write protection: pilot on a small group per device model, confirm vendor updates still apply, then expand.
4. Forward logs off-device: configuration and firmware events from network and OT devices to a central collector, and driver load and flash tool telemetry from endpoints.
5. Run detections in report-only mode: tie hits to the patch calendar for two to four weeks, then alert.
6. Test recovery: in a lab, reflash a spare device from a known-good image and restore its configuration from backup; record the time. Repeat for each critical model.

Choosing controls by size

Detection and measurement

• Signed update coverage: percentage of devices that support signed update where it is enabled. Target 100 percent.
• Default credential count: devices with vendor default accounts still enabled. Target zero.
• Write protection status: percentage of sampled endpoints and servers with firmware write protection confirmed.
• Off-device log coverage: percentage of network and OT devices forwarding configuration and firmware events.
• Recovery time: measured time to reflash and restore a critical device model.

Common failure patterns

• Secure update available but off: the CERT Polska case shows the feature existed and was not used.
• Evidence only on the device: a factory reset erases the logs that would show what happened.
• No spares for single points of failure: a bricked firewall or RTU with a long replacement lead time turns a short attack into a long outage.
• Trusting signatures without protecting keys: signed update is only as strong as the custody of the signing key.
• Reimaging and moving on: rebuilding the disk after an incident without checking firmware integrity leaves corrupted or modified firmware in place.

Framework mapping

Practitioner checklist

• Every firmware-bearing asset is inventoried with its update mechanism and signed update status.
• No vendor default accounts remain enabled on appliances, BMCs or OT devices.
• Signed or secure firmware update is turned on wherever the device supports it.
• Management interfaces sit on isolated networks.
• Endpoints alert on hardware-access driver loads and flash tool use outside patch windows.
• Network and OT device logs are forwarded off-device.
• Firmware signing keys, where you produce firmware, are held in an HSM with logged signing.
• Known-good images, configuration backups and spares exist for critical devices, and a reflash has been tested.

Standards and references

• MITRE ATT&CK: T1495 Firmware Corruption
• MITRE ATT&CK: C0063 2025 Poland Wiper Attacks
• NIST: SP 800-193 Platform Firmware Resiliency Guidelines
• CERT Polska: Energy Sector Incident Report 2025
• Eclypsium: TrickBot Now Offers TrickBoot: Persist, Brick, Profit
• MITRE ATT&CK: M1046 Boot Integrity
• MITRE D3FEND: Firmware Verification

Related NHI Mgmt Group resources: Firmware and Boot Security Guide, Firmware and Bootkit Compromise Playbook, ATT&CK Impact Tactic Guide, Wiper Malware Guide.