While most cybersecurity efforts focus on protecting applications and operating systems, sophisticated attackers increasingly target the foundational layers that exist beneath the OS—the firmware, BIOS, and hardware components that initialize before any operating system code executes.
These below-the-OS attacks can completely bypass traditional security controls, persist across system reinstalls, and operate invisibly to conventional detection tools. Understanding how below-the-OS security protections work is essential for security professionals seeking to defend against these advanced threats and establish truly robust cybersecurity foundations.
Understanding below-the-OS security basics
Below-the-OS security refers to protective measures that operate at the foundational layers of a computer system—beneath the operating system level. These layers include firmware, BIOS/UEFI, hardware components, and the critical boot process that initializes before any operating system code executes.
Understanding below-the-OS security requires visualizing the full computing stack—from applications (the traditional focus of security) down through the operating system, hypervisor, firmware (BIOS/UEFI), and finally the hardware platform, which anchors the system’s root of trust.
Traditional security models focus on protecting applications and operating systems, but this approach has fundamental limitations. The traditional security model assumes the hardware and firmware layers are trustworthy and focuses defensive efforts on protecting applications, data, and network perimeters. This creates a critical blind spot: if the foundational layers are compromised, all higher-level protections become ineffective. Traditional endpoint detection and response (EDR) solutions, antivirus software, and network security tools operate at the OS level or above, making them unable to detect or prevent attacks that execute before the OS loads.
If an attacker compromises the firmware or hardware layers, they can:
- Bypass all OS-level security controls since malicious code executes before the OS loads
- Persist across system reinstalls because firmware modifications survive OS replacements
- Operate invisibly to traditional antivirus and endpoint detection tools
- Establish a permanent foothold that's extremely difficult to detect and remove
According to Microsoft's Digital Defense Report, 90% of successful ransomware attacks originate from unmanaged devices, and firmware vulnerabilities have increased five-fold over the last three years. This makes below-the-OS security critical for establishing a trustworthy foundation for all higher-level protections.
How firmware and the boot process impact system integrity
The boot process represents the most critical security boundary in any system. Each stage must verify the integrity of the next component before transferring control:
A secure boot environment establishes what security experts call a "chain of trust"—each component cryptographically verifies the next before executing it. This process starts with:
- Hardware root of trust: Immutable code stored in hardware (often in CPU microcode or secure elements)
- Firmware verification: The hardware verifies firmware signatures using keys burned into hardware fuses
- Boot component validation: Each subsequent component validates the next using digital certificates
- OS loader authentication: The final firmware component verifies the OS loader before transfer
Before any operating system code runs, firmware performs critical security-sensitive operations:
- Hardware inventory and configuration: Detecting and configuring all system components
- Memory controller setup: Establishing secure memory regions and access controls
- Cryptographic subsystem initialization: Activating TPM, secure enclaves, and key storage
- Security policy enforcement: Implementing manufacturer and enterprise security settings
- Platform measurement: Recording system state for later attestation
When firmware is compromised, attackers gain control over all these fundamental operations, allowing them to subvert any protections the OS might later implement.
Common threats targeting the firmware layer
1. Bootkits
Bootkits represent an evolution of rootkit technology, specifically designed to infect the boot process before OS security mechanisms activate. Unlike traditional rootkits that operate within an already-running OS, bootkits modify the boot sequence itself.
Key characteristics of bootkit attacks:
- Pre-OS execution: Code runs before any OS security controls activate
- Persistence across reinstalls: Survive complete OS reinstallation since they reside in firmware
- Stealth operation: Invisible to OS-based detection tools
- Full system control: Can modify or monitor all subsequent OS operations
Real-world examples include:
- LoJax (2018): The first UEFI bootkit found in the wild, linked to APT28 (Fancy Bear). It implanted malicious code into the system's UEFI firmware, surviving OS reinstalls and disk replacements. The attack specifically targeted government and diplomatic entities, demonstrating how firmware-level persistence can support long-term espionage operations.
- MoonBounce (2022): A UEFI firmware bootkit attributed to APT41, found persisting inside SPI flash memory. This attack showed how sophisticated threat actors can leverage firmware implants to maintain access across security updates and system rebuilds.
- CosmicStrand (2022): A UEFI rootkit found in modified motherboard firmware, believed to originate from Chinese threat actors. This case highlighted supply chain risks, as the malicious firmware was embedded during the manufacturing process."
2. BIOS or UEFI compromises
Firmware compromises target the fundamental system initialization code, providing attackers with unprecedented system access:
Attack vectors include:
- Physical access attacks: Direct firmware modification via hardware programming tools
- Software-based updates: Exploiting legitimate firmware update mechanisms
- Supply chain insertion: Compromising firmware during manufacturing or distribution
- Privilege escalation: Using OS-level access to modify firmware
Persistence and stealth advantages:
- Modifications persist across OS reinstalls and disk replacements
- Most security tools cannot scan or verify firmware integrity
- Changes are nearly impossible to detect without specialized forensic tools
- Can modify system behavior at the most fundamental level
3. Firmware rootkits
Firmware rootkits operate by embedding malicious code directly into system firmware, providing attackers with persistent, low-level access:
Attack vectors:
- SMM (System Management Mode) injection: Exploiting the highly privileged SMM—a special operating mode in x86 processors—to inject persistent code
- UEFI module replacement: Replacing legitimate UEFI drivers with malicious versions
- Option ROM modification: Infecting expansion card firmware to gain system access
Hardware manipulation capabilities:
- Direct memory access bypassing OS protections
- Network traffic interception and modification
- Keystroke and data capture before encryption
- Hardware component control (cameras, microphones, storage)
The most significant characteristic of firmware rootkits is their ability to survive OS reinstallation and even disk replacement, making them extremely difficult to eradicate once installed.
Key hardware measures for below-the-OS security
1. UEFI Secure Boot
UEFI Secure Boot provides cryptographic verification of all boot components before execution, establishing a chain of trust from firmware to OS:
Digital signature verification process:
- Boot components must be signed with certificates trusted by the platform
- Platform maintains databases of trusted certificates and revoked signatures
- Each component's signature is verified before execution proceeds
- Unsigned or improperly signed components are blocked from executing
Platform keys and signature databases:
- Platform Key (PK): Top-level key that controls access to other key databases
- Key Exchange Key (KEK): Intermediate keys for managing signature databases
- Authorized Signature Database (db): Contains certificates of trusted software
- Forbidden Signature Database (dbx): Contains hashes and certificates of known malicious software
Prevention capabilities:
- Blocks execution of unsigned boot loaders and OS kernels
- Prevents loading of known malicious firmware components
- Provides tamper evidence if secure boot has been disabled
- Supports remote attestation of boot integrity
2. Hardware-Based Isolation
Modern processors implement hardware isolation technologies that create secure execution environments protected from software attacks:
*deprecated in 2021, though it remains available in some server processor
Trusted Execution Environments (TEEs) provide:
- Memory encryption: Automatic encryption of sensitive code and data
- Attestation capabilities: Cryptographic proof of code integrity and platform state
- Sealed storage: Encryption keys tied to specific platform and software states
- Secure communication: Protected channels between trusted and untrusted components
3. Root of trust
The hardware root of trust serves as the foundational security anchor for the entire system, providing an immutable basis for all security operations:
Hardware root of trust characteristics:
- Immutable: Cannot be modified by software, including malware
- Unique per device: Each platform has unique cryptographic identities
- Tamper-resistant: Physical attacks are detectable and can trigger security responses
- Authenticated: Provides cryptographic proof of platform identity and state
Trusted Platform Module (TPM) functions:
- Cryptographic key generation and storage: Hardware-protected key creation and storage
- Platform measurement: Recording and verifying system configuration
- Attestation services: Providing cryptographic proof of platform state to remote parties
- Sealed storage: Encrypting data that can only be accessed in specific platform states
Measured boot and attestation processes:
- Platform measurements: TPM records cryptographic hashes of each boot component
- Reference values: Legitimate measurements are stored for comparison
- Attestation reporting: Platform can provide signed reports of its measured state
- Remote verification: External parties can verify platform integrity before trusting it
4. Hypervisor-level security
Hypervisor security creates an additional layer of protection by implementing security controls at the virtualization layer, below the OS but above the hardware:
Virtual machine isolation:
- Memory separation: Hardware-enforced memory protection between VMs
- CPU resource partitioning: Preventing VMs from interfering with each other's execution
- I/O device isolation: Controlled access to hardware resources
- Network segmentation: Isolated virtual networks for different security domains
Hypervisor security monitoring:
- Guest OS introspection: Monitoring VM behavior from outside the guest OS
- Memory scanning: Detecting malicious code patterns in guest memory
- System call monitoring: Tracking and analyzing guest OS system calls
- Network traffic analysis: Inspecting VM network communications
Hardware virtualization technologies:
- Intel VT-x/EPT: Extended page tables for memory isolation and monitoring
- AMD-V/RVI: Rapid virtualization indexing for performance and security
- IOMMU support: Hardware-enforced device access controls
- Nested virtualization: Supporting security solutions that require hypervisor-level access
Continuous validation and monitoring of firmware security
Traditional security assessments often rely on periodic audits and point-in-time evaluations. This approach is insufficient for below-the-OS security because:
- Dynamic threat landscape: New firmware vulnerabilities emerge continuously
- Configuration drift: System settings can change unexpectedly due to updates or attacks
- Persistent threats: Firmware-level compromises can remain dormant for extended periods
- Complex interdependencies: Changes in one firmware component can affect overall security posture
According to Gartner research, by 2029, an estimated 60% of security incidents will be tracked back to misconfigured security controls. This statistic underscores why continuous validation is essential as static configurations inevitably drift from their baselines, creating vulnerabilities that attackers can exploit. At Prelude, we've worked closely with Intel to develop a continuous monitoring solution for Intel hardware security functions, including below-the-OS protections that while available across many modern devices, are not easily reviewed or configured without additional visibility. What we've built for Intel enables organizations to quickly visualize what security options are available to them with their existing Intel fleet, and how to configure those capabilities that may currently be disabled.
Below-the-OS security represents a critical evolution in cybersecurity, addressing threats that traditional OS-level protections cannot counter. By implementing hardware-rooted trust, continuous monitoring, and comprehensive firmware protection, organizations can establish a security foundation that remains trustworthy even when higher-level systems are compromised.
