MITRE ATT&CK, Reconnaissance

T1592.003
Firmware Enumeration

Adversaries probe your system's deepest layer, the firmware, to discover UEFI/BIOS versions, Secure Boot configuration, and TPM status. What they find determines whether your entire security stack can be bypassed with a single bootkit.

> LIVE BOOT SEQUENCE INTERCEPT, FIRMWARE FINGERPRINTING

AMI UEFI BIOS v4.672, Initializing System Firmware...

CPU: Intel(R) Core(TM) i7-10700K @ 3.80GHz [VERIFIED]

Memory Test: 32768 MB DDR4 [PASS]

UEFI Version: 2.7, BIOS Vendor: AMI

SMBIOS Version: 3.2, Release Date: 2018-11-15

TPM Version: 2.0, Status: Active

Secure Boot: DISABLED

Boot Guard: NOT CONFIGURED

BIOS Write Protection: OFF

Firmware enumeration complete. 3 vulnerabilities identified.

⚠ CRITICAL: Secure Boot is DISABLED, System vulnerable to UEFI bootkit installation. Firmware dated 2018-11-15, 6+ years without update. Multiple known CVEs affect this version.

SYSTEM STACK, ATTACKER TARGETING FIRMWARE LAYER

APPLICATIONS & USER SPACE

OPERATING SYSTEM (KERNEL)

FIRMWARE (UEFI / BIOS / SMM) ◀ TARGET LAYER

HARDWARE (CPU / MEMORY / STORAGE)

> BOOTKIT INSERTION INTO BOOT CHAIN

UEFI FW

→

BOOTMGR

INFECTED

→

KERNEL

→

FIRMWARE EXPOSURE RISK SCORE

RISK LEVEL: CRITICAL (95/100), 3 vulnerabilities, Secure Boot disabled, firmware 6+ years outdated

Understanding the Threat

Why Firmware Enumeration Matters

Firmware is the most privileged software on any computing system, it executes before the operating system loads, operates beneath the kernel, and has unrestricted access to all hardware components including memory, storage devices, network interfaces, and cryptographic processors. Because firmware runs in the highest privilege mode (Ring -2 / SMM), it is invisible to traditional operating system security controls, making compromised firmware extraordinarily difficult to detect, analyze, and remediate. Firmware-level implants survive operating system reinstalls, disk replacements, and even hardware migrations in certain configurations.

When adversaries gather firmware information through techniques like T1592.003, they are performing reconnaissance to identify exploitable attack surfaces at the deepest layer of the system stack. By enumerating BIOS/UEFI versions, firmware vendor details, Secure Boot configuration status, and TPM (Trusted Platform Module) implementation, attackers can match discovered firmware versions against known vulnerability databases to find unpatched firmware with critical security flaws. Systems with disabled Secure Boot, missing TPM protections, outdated BIOS versions, or misconfigured firmware write-protection mechanisms are prime targets for bootkit deployment, malicious firmware modifications that establish persistence invisible to all OS-level security tools.

The real-world impact of firmware-targeting attacks is severe and growing. ESET researchers discovered a UEFI Secure Boot bypass vulnerability affecting the majority of UEFI-based systems worldwide, enabling attackers to install bootkits even on systems believed to be protected. Gigabyte UEFI firmware on over 100 motherboard models was found vulnerable to bootkit installation through a built-in firmware update mechanism that could be weaponized. CERT/CC identified critical SMM (System Management Mode) callout vulnerabilities in Gigabyte UEFI firmware (CVE-2025-7026, CVE-2025-7027, CVE-2025-7029), exposing systems to arbitrary code execution at the highest privilege level. The Hacker News reported new UEFI flaws enabling early-boot DMA attacks across major motherboard manufacturers including ASRock, ASUS, GIGABYTE, and MSI. Ongoing industry audits continue to reveal dozens of PC and enterprise firmware vulnerabilities annually, underscoring that firmware remains one of the most neglected yet most critical attack surfaces in modern cybersecurity.

100+

Gigabyte motherboard models vulnerable to UEFI bootkit installation through firmware update mechanism exploitation

6+ Yrs

Average age of outdated firmware discovered during enterprise security assessments, missing critical security patches

Ring -2

Firmware executes at System Management Mode (SMM), a privilege level below the OS kernel, invisible to all OS security tools

Detection rate of firmware-level bootkits by traditional antivirus solutions that only operate at the OS layer

Authoritative Sources & References

Core Concepts

Key Terms & Concepts

Simple Definition

Firmware (T1592.003) is a sub-technique within the MITRE ATT&CK framework where adversaries gather detailed information about a victim's system firmware, including BIOS/UEFI versions, firmware vendor identities, Secure Boot status, TPM (Trusted Platform Module) configuration and version, boot component versions, SMM (System Management Mode) implementation details, and firmware update mechanism configurations. This reconnaissance intelligence reveals whether a target system can be compromised at the firmware level to install persistent bootkits, malicious code that embeds itself in the boot process, which survive operating system reinstalls, disk replacements, and are completely invisible to traditional antivirus and endpoint detection solutions. Firmware enumeration is typically performed during the initial reconnaissance phase of an attack, using tools and techniques that query system management interfaces, parse firmware structures, and cross-reference discovered versions against public vulnerability databases.

Everyday Analogy

Think of firmware as the instruction manual that tells your computer's hardware how to start up before Windows, Linux, or any operating system even begins to load. It is the first piece of software that runs when you press the power button, it initializes your CPU, tests your memory, finds your storage drive, and hands control to your operating system. If someone can tamper with that instruction manual, they control everything that happens afterward. It is like someone secretly replacing the ignition system of your car before you even turn the key, no matter how good your door locks are (antivirus, firewall, encryption), if the ignition itself is compromised, the car is theirs. They can disable the alarm, steer wherever they want, and you would never know until it is too late. Firmware attacks are exactly like this: they bypass every security measure you have installed because they execute before those measures even exist. A firmware bootkit is the equivalent of a hidden spare key that survives even if you change every lock in your house, reinstalling your operating system, replacing your hard drive, or updating your antivirus does nothing because the compromised firmware simply re-infects the new OS on the next boot.

Related Terms

UEFI (Unified Extensible Firmware Interface), The modern replacement for legacy BIOS that provides a standardized interface between firmware and the operating system. Secure Boot, A UEFI feature that verifies the digital signature of the bootloader and kernel before execution, preventing unsigned malware from loading at boot time. TPM (Trusted Platform Module), A dedicated hardware chip that stores cryptographic keys and measurements for system integrity verification. SMM (System Management Mode), The highest privilege execution mode on x86 processors, accessible only by firmware, often called "Ring -2." Bootkit, Malicious software designed to load before the operating system by infecting the boot chain, typically targeting the Master Boot Record (MBR), Volume Boot Record (VBR), or UEFI bootloader.

Case Study

Real-World Scenario: The Silent Breach

BEFORE, The Vulnerable State

Dr. Elena Vasquez, Chief Information Security Officer (CISO) at AeroTech Defense Systems, a mid-tier defense contractor handling classified engineering schematics for aerospace components, discovered that her organization's firmware security posture was essentially nonexistent. AeroTech's server infrastructure, a mix of Dell PowerEdge servers and custom-built workstations, was running outdated UEFI firmware, with some systems still operating on BIOS versions from 2018. Secure Boot was disabled across 73% of endpoints, a configuration inherited from legacy compatibility requirements that were never revisited after migration. TPM 2.0 modules were present on newer hardware but remained unprovisioned and inactive. During a routine security assessment, an external red team identified that firmware enumeration queries via WMI and SMBIOS parsing revealed exploitable UEFI vulnerabilities on over 40 systems. A nation-state APT group (attributed to a foreign intelligence service) had already discovered this same information through passive reconnaissance, exploiting a known UEFI privilege escalation vulnerability to install a sophisticated bootkit. The implant maintained persistent unauthorized access for 14 months, surviving multiple OS reboots, full antivirus signature updates, a disk wipe performed during an internal security audit, and even a partial system replacement. The breach ultimately exposed 2,400+ classified engineering documents containing proprietary defense technology designs and resulted in a $50 million government contract cancellation when the compromised systems were discovered during a compliance audit. The forensic investigation revealed that the bootkit had been communicating with command-and-control infrastructure via firmware-level network stack hooks that were completely invisible to the organization's endpoint detection and response (EDR) platform.

✓

AFTER, The Remediated State

Following the breach disclosure and the devastating contract loss, Dr. Vasquez led a comprehensive firmware security transformation across AeroTech's entire infrastructure. The remediation program encompassed multiple layers of defense: Secure Boot was enabled and enforced on 100% of systems, with a centralized management solution ensuring new systems automatically inherit the correct configuration. A formal firmware update management process was established, requiring monthly firmware version checks across all assets with automated alerts for any system running firmware older than 90 days. TPM 2.0 was provisioned and activated on all compatible hardware, and remote attestation was implemented to cryptographically verify firmware integrity at each boot sequence. The organization deployed specialized firmware integrity monitoring tools that measure and log UEFI boot measurements against known-good baselines, alerting security operations personnel to any unauthorized firmware modifications within minutes of occurrence. New hardware procurement policies were updated to require TPM 2.0, Secure Boot support, and firmware update automation as mandatory specifications. Within eight months of implementation, the organization passed its next compliance audit with zero firmware-related findings and regained eligibility for classified contract work. The total investment in firmware security was approximately $320,000, a fraction of the $50 million lost from the single contract cancellation caused by the firmware-level breach.

Action Plan

Step-by-Step Firmware Security Guide

Inventory All Firmware Versions Across Assets

Deploy automated firmware discovery tools across all endpoints, servers, and network devices using WMI queries (Windows), dmidecode (Linux), and system_profiler (macOS) to enumerate SMBIOS and UEFI firmware data.
Collect BIOS/UEFI version numbers, firmware release dates, vendor information (AMI, Phoenix, Insyde), motherboard model identifiers, and current firmware configuration settings into a centralized asset inventory database.
Map each discovered firmware version against vendor security bulletins and public CVE databases (NVD, MITRE CVE) to identify systems running firmware with known vulnerabilities.
Document which systems have Secure Boot enabled, TPM provisioned, and firmware write-protection configured, creating a prioritized remediation backlog based on risk severity.

Enable Secure Boot and Measured Boot

Verify Secure Boot status on every system and develop a deployment plan to enable it systematically, starting with the highest-value assets and servers handling sensitive data or classified workloads.
Enroll organization-specific Platform Key (PK), Key Exchange Key (KEK), and Signature Database (db) certificates to establish a chain of trust for authorized bootloaders, kernels, and drivers.
Enable Measured Boot (TCG PC Client Platform Firmware Profile) to record cryptographic measurements of each boot component into the TPM, creating an immutable audit trail of the boot sequence.
Test Secure Boot configuration in a staging environment first to identify any legacy drivers, boot utilities, or diagnostic tools that require signed updates before production deployment.

Implement TPM 2.0 Across All Systems

Verify TPM presence and version (1.2 vs 2.0) on all hardware assets, prioritizing replacement or upgrade of systems that lack TPM 2.0 support entirely.
Enable TPM in firmware settings (often disabled by default), initialize the TPM with a strong owner password, and configure anti-hammering protection to prevent brute-force attacks against the TPM.
Provision TPM for key storage and attestation, enabling features like BitLocker drive encryption, virtual smart card credentials, and measured boot attestation.
Implement Remote Attestation services to centrally verify that client systems are booting with known-good firmware and have not been tampered with by firmware-level implants.

Establish a Firmware Update Management Process

Subscribe to security advisories from all firmware vendors relevant to your hardware fleet (motherboard manufacturers, OEM vendors, peripheral firmware providers) and monitor NVD for new firmware CVEs.
Develop and document a firmware update policy that defines maximum firmware age thresholds (e.g., no system should run firmware older than 90 days from the latest available secure version).
Implement automated firmware update tools where vendor support allows (Dell Command Update, Lenovo Update Retriever, HP Client Management) with staged rollout procedures to minimize operational disruption.
Create a firmware update testing workflow that validates each new firmware version in a non-production environment before enterprise-wide deployment to prevent firmware-induced instability.

Deploy Firmware Integrity Monitoring

Implement measured boot logging and analysis by collecting TPM Event Logs (TCGlog) from endpoints and validating them against known-good firmware measurements stored in a secure reference database.
Deploy firmware-specific security scanning tools such as CHIPSEC, Flashrom, or Eclypsium that can detect unauthorized firmware modifications, malicious firmware implants, and unexpected firmware configurations.
Configure SIEM rules and alert thresholds for firmware-related events including unexpected firmware version changes, Secure Boot configuration modifications, and TPM ownership changes.
Establish a firmware incident response procedure that defines escalation paths, forensic collection methods, and containment strategies specific to firmware-level compromise scenarios.

Implement Remote Attestation and Boot Verification

Deploy a centralized attestation service (such as Azure Attestation, Keylime, or open-source alternatives) that receives and validates TPM-based boot measurements from all managed endpoints.
Define known-good boot measurement baselines for each system configuration and create alert policies that trigger when a system reports unexpected firmware or bootloader measurements.
Integrate attestation results with network access control (NAC) systems to quarantine or block network access for systems that fail firmware integrity verification at boot time.
Implement regular automated attestation checks on a continuous basis, not just at boot time, to detect firmware tampering that may occur while a system is running via SMM exploitation.

Create a Hardware/Firmware Security Policy

Document a comprehensive firmware security policy that mandates Secure Boot enforcement, TPM 2.0 provisioning, firmware update compliance, and firmware integrity monitoring as organizational security requirements.
Include firmware security requirements in hardware procurement specifications, requiring vendors to provide firmware vulnerability disclosure timelines, signed firmware updates, and Secure Boot key management capabilities.
Define firmware security roles and responsibilities, including who is authorized to modify firmware settings, how firmware changes are approved and documented, and what audit trail requirements exist.
Conduct annual firmware security reviews and penetration tests that specifically target the firmware layer, testing for bootkit installation feasibility, Secure Boot bypass potential, and SMM exploitation vectors.

Lessons Learned

Common Mistakes & Best Practices

COMMON MISTAKES

Ignoring firmware as an attack surface entirely. Many organizations focus exclusively on OS and application security while completely neglecting firmware, operating under the false assumption that firmware is too complex or too obscure to be targeted. This blind spot leaves the most privileged layer of the system completely unprotected.

Leaving Secure Boot disabled for legacy compatibility. IT teams frequently disable Secure Boot to support older operating systems, bootable diagnostic tools, or unsigned drivers, and then never re-enable it. This single configuration error opens the door to bootkit installation.

Never updating firmware after initial deployment. Unlike operating systems that receive frequent automatic updates, firmware is often installed once during deployment and forgotten for years. This results in systems running firmware with dozens of known, exploitable CVEs.

Trusting that a clean OS reinstall removes all compromise. A fundamental misunderstanding of firmware persistence leads organizations to believe that wiping and reinstalling the operating system eliminates all malware. Firmware bootkits survive this process completely intact.

No firmware inventory or version tracking whatsoever. Organizations that do not know what firmware versions their systems are running cannot possibly determine which systems are vulnerable. This lack of visibility makes firmware-focused threat assessment impossible.

BEST PRACTICES

Enable Secure Boot organization-wide with custom keys. Deploy Secure Boot on 100% of systems with organization-managed Platform Keys, Key Exchange Keys, and Signature Database entries. Maintain a secure key management lifecycle including rotation procedures and revocation capabilities for compromised keys.

Establish automated firmware inventory and update pipelines. Implement continuous firmware version discovery across all assets using tools like WMI, dmidecode, and vendor-specific management agents. Automate the deployment of firmware updates with staged rollout procedures and rollback capabilities.

Deploy measured boot with centralized attestation. Enable Measured Boot on all TPM 2.0-equipped systems and implement remote attestation services that validate boot measurements against known-good baselines on every system boot, detecting firmware tampering in near real-time.

Use firmware integrity scanning in security assessments. Include firmware-specific scanning tools like CHIPSEC and Eclypsium in your regular security assessment program. Ensure that penetration tests specifically target the firmware layer for bootkit installation feasibility and Secure Boot bypass evaluation.

Include firmware security in hardware procurement requirements. Mandate TPM 2.0 support, Secure Boot capability, firmware update automation, vendor vulnerability disclosure commitments, and firmware write-protection features in all hardware procurement specifications. Reject vendors who cannot provide timely security updates.

Dual Perspective

Red Team vs Blue Team View

Offensive Perspective

Red Team: How Attackers Enumerate Firmware

The red team approaches firmware enumeration as the first step in a chain of exploitation that aims to establish the most persistent and stealthy form of access possible. Attackers begin by querying system management interfaces using WMI (Windows Management Instrumentation), SMBIOS parsing, and direct UEFI runtime service calls to extract firmware version strings, vendor identifiers, Secure Boot configuration, and TPM status. Tools like fwexplorer, custom PowerShell scripts leveraging the Get-WmiObject Win32_BIOS class, and low-level utilities that interface with UEFI firmware tables provide comprehensive firmware intelligence. The attacker cross-references discovered firmware versions against public CVE databases and exploit repositories (Exploit-DB, GitHub PoC collections) to identify unpatched vulnerabilities. Systems with disabled Secure Boot, unprovisioned TPM modules, outdated firmware dates, and missing firmware write-protection are prioritized as high-value targets. The end goal is to identify a firmware vulnerability that enables bootkit installation, implanting malicious code that executes before the OS loads and persists across OS reinstalls, providing a stealthy backdoor that is invisible to all OS-level security controls. Nation-state threat groups have demonstrated particular sophistication in firmware exploitation, using it as the initial access vector for long-term espionage campaigns.

Get-WmiObject Win32_BIOS / Win32_ComputerSystem
SMBIOS table parsing (Type 0: BIOS Info)
UEFI Runtime Services enumeration via NtQuerySystemInformation
CHIPSEC framework for firmware security testing
fwexplorer / FwUpdateScanner for firmware discovery
CVE database cross-referencing automation

Defensive Perspective

Blue Team: Detecting & Defending Firmware Enumeration

The blue team must defend firmware at multiple layers: preventing enumeration where possible, detecting enumeration attempts when prevention fails, and ensuring that even successful enumeration does not lead to exploitation. Detection of firmware enumeration focuses on monitoring WMI queries targeting BIOS and firmware classes, logging access to UEFI runtime services, and tracking SMBIOS access patterns through system event logs. Windows Security Event ID 4688 (process creation) combined with command-line logging can reveal attackers running firmware discovery commands. PowerShell script block logging (Event ID 4104) captures firmware enumeration scripts in transit. SIEM rules should alert on patterns like Get-WmiObject *BIOS*, wmic bios get, or access to \\.\Device\PhysicalMemory which indicates low-level firmware interaction. On the preventive side, organizations should restrict who can query firmware information, enable Secure Boot to prevent bootkit installation even if vulnerabilities are discovered, maintain current firmware to eliminate known exploitable vulnerabilities, and deploy measured boot with remote attestation to detect any unauthorized firmware modifications. Firmware write-protection (BIOS write-protect jumpers or software locks) should be enforced to prevent unauthorized firmware updates. Endpoint detection tools should be supplemented with firmware-specific monitoring solutions that operate outside the OS layer.

Windows Event Log 4688 + PowerShell Script Block Logging (4104)
WMI monitoring for BIOS/Firmware class queries
Measured Boot + TPM Event Log analysis
CHIPSEC for firmware integrity verification
Eclypsium platform for continuous firmware monitoring
UEFI Secure Boot audit and enforcement policies

Detection & Hunting

Threat Hunter's Eye

Firmware Enumeration Hunt Hypothesis

Threat hunters investigating potential T1592.003 activity should develop hypotheses around unexpected firmware information gathering patterns within their environment. The primary hunting premise is: "An adversary who has gained initial access to a system will enumerate firmware details to determine firmware-level exploitability as a path to persistent, OS-invisible access." Hunters should look for anomalous processes querying BIOS and firmware WMI classes, unexpected access to UEFI runtime services, and SMBIOS table enumeration from non-administrative accounts or from accounts that do not normally perform IT management tasks. Pay particular attention to firmware enumeration commands executed from command-line interfaces, PowerShell sessions, or scheduled tasks running outside normal business hours. Also monitor for unusual network connections to firmware vendor update servers or known vulnerability databases that could indicate an adversary cross-referencing discovered firmware versions against exploit databases. Physical access scenarios should also be considered, as firmware enumeration can be performed via bootable USB devices or external diagnostic hardware that bypasses OS-level logging entirely.

Indicators of Compromise (IOCs), Firmware Enumeration:

WMI queries to Win32_BIOS, Win32_ComputerSystemProduct, or root\wmi namespace from non-IT accounts
PowerShell commands containing "Get-WmiObject" combined with "*BIOS*", "*SMBIOS*", "*UEFI*", or "*firmware*" parameters
Process creation events for tools like msinfo32.exe, wmic.exe (with bios arguments), or custom firmware scanning executables
Access attempts to \\.\Device\PhysicalMemory or \\.\AUXACCESS (low-level firmware interface access)
Unexpected modifications to UEFI NVRAM variables via kernel drivers or UEFI runtime service calls
Network connections to public CVE databases or exploit repositories immediately after firmware information is queried
Scheduled tasks or persistence mechanisms that periodically enumerate firmware (potential automated reconnaissance)

Detection Queries, Splunk / SIEM:

# Detect WMI firmware enumeration via PowerShell
index=windows (EventCode=4104 OR EventCode=4688)
"Win32_BIOS" OR "Win32_ComputerSystemProduct"
OR "SMBIOS" OR "UEFI" OR "fwexplorer"
OR "Get-WmiObject" AND "bios"
OR "wmic" AND "bios"
| stats count by host, user, process_name, command
# Alert if count > threshold OR executed from unusual accounts

# Detect physical memory access attempts (firmware-level interaction)
index=windows (EventCode=4663 OR EventCode=4656)
ObjectName="\\.\Device\PhysicalMemory"
OR ObjectName="\\.\AUXACCESS"
| stats count by host, user, process_name, ObjectName
# High-priority alert: direct hardware access is extremely suspicious

# Detect firmware update/replacement attempts (potential bootkit installation)
index=windows EventCode=4688
(ImageLoaded="*afwinprog*" OR ImageLoaded="*afu*"
OR ImageLoaded="*flashrom*" OR ImageLoaded="*fpt*"
OR ImageLoaded="*insyde*" OR ImageLoaded="*ami*")
| stats count by host, user, process_name, command
# CRITICAL: firmware flashing from non-IT accounts = active exploitation

Continue Exploring

Explore Related Techniques

Dive Deeper into Host Information Gathering

T1592.003 Firmware is one of four sub-techniques under T1592 (Gather Victim Host Information). Understanding the full spectrum of host reconnaissance techniques used by adversaries is essential for building comprehensive defenses. Explore the parent technique and all related sub-techniques to develop a complete picture of how attackers map your infrastructure before launching their assault.

T1592, Parent Technique T1592.001, Hardware T1592.002, Software T1592.004, Client Config

Firmware

MITIGATIONS

Pre-compromise M1056

DETECTION STRATEGY

Detection of Firmware DET0818

DONATE · SUPPORT

We keep threat intelligence free. No paywalls, no ads. Your donation directly funds server infrastructure, research, and tools. Every contribution - no matter the size - makes this platform sustainable.

100% of your support goes to the platform. No corporate sponsors, just the community.

ROOT::DONATE

Cyber Pulse Academy
February 13, 2026
No Comments