Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1495: Firmware Corruption

Adversaries may overwrite or corrupt the flash memory contents of system BIOS or other firmware in devices attached to a system in order to render them inoperable or unable to boot, thus denying the availability to use the devices and/or the system.[1] Firmware is software that is loaded and executed from non-volatile memory on hardware devices in order to initialize and manage device functionality. These devices may include the motherboard, hard drive, or video cards.

In general, adversaries may manipulate, overwrite, or corrupt firmware in order to deny the use of the system or devices. For example, corruption of firmware responsible for loading the operating system for network devices may render the network devices inoperable.[2][3] Depending on the device, this attack may also result in Data Destruction.

EnterpriseT1495TechniqueObject v1.3 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Firmware Corruption is an impact technique where an adversary corrupts BIOS or other device firmware so systems or attached devices cannot boot or operate. For leaders, this matters because recovery may require hardware-level remediation, replacement, or vendor intervention rather than normal endpoint rebuilds. The business risk is highest where network devices, critical workstations, servers, or cyber-physical environments depend on firmware integrity for availability.

Executive priority

Prioritize this as an operational resilience and recovery-readiness issue, not only a malware issue. Executives should ask whether the organization can prove firmware and boot integrity, restrict privileged access capable of firmware changes, maintain current firmware/software, and recover network or endpoint devices that become inoperable. The ATT&CK relationships to destructive malware, network devices, and an energy-infrastructure campaign make this especially relevant to incident response planning, continuity exercises, and audit evidence for privileged access and patch governance.

Technical view

SOC, detection engineering, and IR teams should validate coverage across Linux, macOS, Windows, and network devices where firmware updates or flash operations are possible. MITRE does not provide official detection text for T1495, but the related detection strategy is Firmware Modification via Flash Tool or Corrupted Firmware Upload. Practical validation should focus on privileged execution of firmware flashing utilities, unexpected firmware image uploads to network devices, boot integrity failures, and device boot or availability failures following administrative changes. IR playbooks should account for cases where standard disk imaging or OS rebuilds may not restore service because the affected component is firmware-resident.

Likely telemetry

  • Endpoint process execution and command-line telemetry for firmware or BIOS update utilities
  • Privileged account authentication and administrative session logs
  • Network device management, configuration, and firmware upload logs
  • Boot integrity, secure boot, or hardware-rooted trust measurement results where available
  • Firmware version and update inventory from asset or vulnerability management systems

Detection direction

  • Baseline legitimate firmware update tools, maintenance windows, approved firmware images, and authorized administrators before alerting on flash activity.
  • Tune for unusual firmware modification behavior: unexpected flash tools, firmware uploads outside change windows, privileged access followed by boot or device availability failures, or mismatched firmware versions.
  • For network devices, validate that management-plane logging captures firmware upload, reboot, and administrative actions; this is a common blind spot compared with endpoint telemetry.
  • Correlate with related destructive behavior such as Data Destruction when device inoperability or boot failure follows suspicious administrative activity.
  • Treat alerts cautiously because legitimate vendor updates can resemble the same behavior; change records and asset ownership are important for triage.

Mitigation priorities

  • Enforce Privileged Account Management: least privilege, role-based access, monitoring, and accountability for accounts that can alter firmware or administer network devices.
  • Implement Boot Integrity controls where supported, including secure boot mechanisms, hardware-rooted trust, and integrity checks for boot and firmware-related components.
  • Maintain firmware, drivers, operating systems, and network device software through governed update processes.
  • Keep verified recovery procedures for firmware corruption scenarios, including vendor escalation paths, known-good firmware images, and device replacement planning.
  • Include firmware and network-device recovery assumptions in incident response and business continuity exercises.
Analyst notes and limits

The object is an ATT&CK enterprise impact technique for Linux, macOS, Windows, and network devices. Relationship context links it to mitigations for Privileged Account Management, Boot Integrity, and Update Software, plus a detection strategy focused on flash tools or corrupted firmware uploads. Related software includes TrickBot and Bad Rabbit, and related campaign context includes destructive attacks against Polish energy infrastructure, supporting cyber-physical and availability-focused risk framing without implying current exposure.

MITRE provides no official detection text for this technique in the supplied object. Specific detection logic, supported boot integrity evidence, firmware update mechanisms, and recovery options depend heavily on local hardware, network device models, operating systems, logging depth, and change-management maturity.

Official MITRE ATT&CK definition

Firmware Corruption

Adversaries may overwrite or corrupt the flash memory contents of system BIOS or other firmware in devices attached to a system in order to render them inoperable or unable to boot, thus denying the availability to use the devices and/or the system.[1] Firmware is software that is loaded and executed from non-volatile memory on hardware devices in order to initialize and manage device functionality. These devices may include the motherboard, hard drive, or video cards.

In general, adversaries may manipulate, overwrite, or corrupt firmware in order to deny the use of the system or devices. For example, corruption of firmware responsible for loading the operating system for network devices may render the network devices inoperable.[2][3] Depending on the device, this attack may also result in Data Destruction.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Associated objects

Groups, software, and campaigns

Malware Enterprise

S0266: TrickBot

TrickBot is a Trojan spyware program written in C++ that first emerged in September 2016 as a possible successor to Dyre. TrickBot was developed and initially used by Wizard Spider for targeting banking sites in North America, Australia, and throughout Europe; it has since been used against all sectors worldwide as part of "big game hunting" ransomware campaigns.[1][2][3][4]

Windows
Campaign Enterprise

C0063: 2025 Poland Wiper Attacks

2025 Poland Wiper Attacks is a Russian state-sponsored campaign that conducted destructive cyberattacks against Polish energy infrastructure in December 2025. Targets included more than 30 wind and photovoltaic farms, a combined heat and power (CHP) plant, and a manufacturing sector company. The attacks on the distributed energy resources (DER) disrupted communications between affected facilities and the distribution system operator, but did not impact electricity generation or heat supply. Across the campaign, threat actors deployed two previously undocumented wiper tools, DynoWiper, a Windows-based wiper and LazyWiper, a PowerShell wiper, distributed via malicious Group Policy Objects. At the CHP plant, threat actors had maintained access since at least March 2025, using that foothold to obtain credentials and move laterally before attempting wiper deployment. Some reporting has assessed the activity to be consistent with Russian Federal Security Service (FSB) threat activity group Dragonfly, also tracked as STATIC TUNDRA, while other reporting attributes the destructive wiper activities to the Russian General Staff Main Intelligence Directorate (GRU) threat activity group ELECTRUM, also tracked as Sandworm Team.[1][2][3][4]

Relationship explorer

All related ATT&CK context

uses · Malware S0606: Bad Rabbit Enterprise mitigates · Mitigation M1051: Update Software Enterprise detects · Detection Strategy DET0167: Firmware Modification via Flash Tool or Corrupted Firmware Upload Enterprise uses · Campaign C0063: 2025 Poland Wiper Attacks Enterprise uses · Malware S0266: TrickBot Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise mitigates · Mitigation M1046: Boot Integrity Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1051: Update Software

Software updates ensure systems are protected against known vulnerabilities by applying patches and upgrades provided by vendors. Regular updates reduce the attack surface and prevent adversaries from exploiting known security gaps. This includes patching operating systems, applications, drivers, and firmware. This mitigation can be implemented through the following measures:

Regular Operating System Updates

- Implementation: Apply the latest Windows security updates monthly using WSUS (Windows Server Update Services) or a similar patch management solution. Configure systems to check for updates automatically and schedule reboots during maintenance windows. - Use Case: Prevents exploitation of OS vulnerabilities such as privilege escalation or remote code execution.

Application Patching

- Implementation: Monitor Apache's update release notes for security patches addressing vulnerabilities. Schedule updates for off-peak hours to avoid downtime while maintaining security compliance. - Use Case: Prevents exploitation of web application vulnerabilities, such as those leading to unauthorized access or data breaches.

Firmware Updates

- Implementation: Regularly check the vendor’s website for firmware updates addressing vulnerabilities. Plan for update deployment during scheduled maintenance to minimize business disruption. - Use Case: Protects against vulnerabilities that adversaries could exploit to gain access to network devices or inject malicious traffic.

Emergency Patch Deployment

- Implementation: Use the emergency patch deployment feature of the organization's patch management tool to apply updates to all affected Exchange servers within 24 hours. - Use Case: Reduces the risk of exploitation by rapidly addressing critical vulnerabilities.

Centralized Patch Management

- Implementation: Implement a centralized patch management system, such as SCCM or ManageEngine, to automate and track patch deployment across all environments. Generate regular compliance reports to ensure all systems are updated. - Use Case: Streamlines patching processes and ensures no critical systems are missed.

*Tools for Implementation*

Patch Management Tools:

- WSUS: Manage and deploy Microsoft updates across the organization. - ManageEngine Patch Manager Plus: Automate patch deployment for OS and third-party apps. - Ansible: Automate updates across multiple platforms, including Linux and Windows.

Vulnerability Scanning Tools:

- OpenVAS: Open-source vulnerability scanning to identify missing patches.

Mitigation Enterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Mitigation Enterprise

M1046: Boot Integrity

Boot Integrity ensures that a system starts securely by verifying the integrity of its boot process, operating system, and associated components. This mitigation focuses on leveraging secure boot mechanisms, hardware-rooted trust, and runtime integrity checks to prevent tampering during the boot sequence. It is designed to thwart adversaries attempting to modify system firmware, bootloaders, or critical OS components. This mitigation can be implemented through the following measures:

Implementation of Secure Boot:

- Implementation: Enable UEFI Secure Boot on all systems and configure it to allow only signed bootloaders and operating systems. - Use Case: An adversary attempts to replace the system’s bootloader with a malicious version to gain persistence. Secure Boot prevents the untrusted bootloader from executing, halting the attack.

Utilization of TPMs:

- Implementation: Configure systems to use TPM-based attestation for boot integrity, ensuring that any modification to the firmware, bootloader, or OS is detected. - Use Case: A compromised firmware component alters the boot sequence. The TPM detects the change and triggers an alert, allowing the organization to respond before further damage.

Enable Bootloader Passwords:

- Implementation: Protect BIOS/UEFI settings with a strong password and limit physical access to devices. - Use Case: An attacker with physical access attempts to disable Secure Boot or modify the boot sequence. The password prevents unauthorized changes.

Runtime Integrity Monitoring:

- Implementation: Deploy solutions to verify the integrity of critical files and processes after boot. - Use Case: A malware infection modifies kernel modules post-boot. Runtime integrity monitoring detects the modification and prevents the malicious module from loading.

Change history

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 .

ATT&CK release
19.1
Object version
1.3
Created
Modified
Raw hash
848b931f3a29bc26...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.3 Current bundle 848b931f3a29…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Symantec Chernobyl W95.CIH

    Yamamura, M. (2002, April 25). W95.CIH. Retrieved April 12, 2019.

    Open source URL
  2. [2]
    dhs_threat_to_net_devices

    U.S. Department of Homeland Security. (2016, August 30). The Increasing Threat to Network Infrastructure Devices and Recommended Mitigations. Retrieved July 29, 2022.

    Open source URL
  3. [3]
    cisa_malware_orgs_ukraine

    CISA. (2022, April 28). Alert (AA22-057A) Update: Destructive Malware Targeting Organizations in Ukraine. Retrieved July 29, 2022.

    Open source URL
  4. [4]
    MITRE Trustworthy Firmware Measurement

    Upham, K. (2014, March). Going Deep into the BIOS with MITRE Firmware Security Research. Retrieved January 5, 2016.

    Open source URL
  5. [5]
    mitre-attack T1495
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use