SC-066: UEFI Firmware Rootkit Persistence¶

Scenario Overview¶

Narrative¶

VaultTech Industries, a multinational semiconductor manufacturer headquartered in the United States, discovers anomalous outbound DNS traffic from executive workstations during a routine threat hunt. The DNS queries resolve to 203.0.113.78 and contain encoded payloads in subdomain labels — a classic DNS tunneling pattern. However, what makes this discovery alarming is that the affected workstations had been recently reimaged as part of a scheduled hardware refresh, yet the malicious traffic persisted across the reimage.

The incident response team, led by Senior Analyst Marcus Webb, initially suspects a compromised deployment image. After verifying the golden image integrity against known-good hashes, the team pivots to examining the UEFI firmware of affected endpoints. Using the CHIPSEC framework, they discover a modified UEFI DXE (Driver Execution Environment) driver implanted in the SPI flash memory of 23 executive workstations. The implant, designated internally as PHANTOM BRIDGE, is a sophisticated firmware rootkit that:

1. Executes before the operating system loads, making it invisible to all OS-level security tools
2. Patches the Windows kernel in memory during boot to inject a userland payload
3. Survives OS reinstallation, disk replacement, and even BIOS updates (through a reflash mechanism)
4. Communicates via DNS over HTTPS (DoH) to blend with legitimate encrypted DNS traffic

Attribution analysis links PHANTOM BRIDGE to the threat actor JADE SPECTER, a nation-state group known to target semiconductor intellectual property. The firmware implant has been active for an estimated 9 months, during which time JADE SPECTER had persistent access to VaultTech Industries' most sensitive chip design files, manufacturing processes, and customer contracts. The implant was delivered through a compromised firmware update package distributed via a trojanized vendor support portal at support.firmware-vendor.example.com.

Attack Flow¶

graph TD
    A[Phase 1: Supply Chain Compromise<br/>Trojanize vendor firmware update portal] --> B[Phase 2: Firmware Update Delivery<br/>Distribute modified UEFI image]
    B --> C[Phase 3: SPI Flash Implant<br/>Write rootkit to DXE driver volume]
    C --> D[Phase 4: Secure Boot Bypass<br/>Patch Secure Boot verification]
    D --> E[Phase 5: OS Kernel Patching<br/>Inject payload during boot sequence]
    E --> F[Phase 6: Userland Payload Deployment<br/>Establish C2 via DNS-over-HTTPS]
    F --> G[Phase 7: Data Collection and Exfiltration<br/>Steal IP and design documents]
    G --> H[Phase 8: Self-Preservation<br/>Reflash mechanism survives BIOS updates]

Phase Details¶

Phase 1: Supply Chain Compromise¶

ATT&CK Technique: T1195.002 (Supply Chain Compromise: Compromise Software Supply Chain)

JADE SPECTER compromises the firmware update distribution portal of a legitimate BIOS/UEFI vendor used by VaultTech Industries. The attacker gains access to the portal's content management system at support.firmware-vendor.example.com through credential stuffing of a developer account (testuser/REDACTED). Once inside, they modify the firmware update package for VaultTech's specific workstation model (Model VT-X9000), injecting a malicious DXE driver into the UEFI volume.

The modified firmware image maintains valid file structure and metadata. However, the digital signature is handled through a subtle attack: JADE SPECTER does not attempt to forge the vendor's code signing certificate. Instead, they modify the UEFI image in a way that exploits a known vulnerability in the signature verification logic of the specific UEFI implementation — the verification function returns success for images where the signature section is present but zeroed out (a variant of the "BootHole" class of Secure Boot bypasses).

# Simulated firmware image analysis (educational only)
$ python chipsec_util.py uefi decode firmware_update_vt-x9000_v2.4.1.bin

UEFI Volume: 8C8CE578-8A3D-4F1C-9935-896185C32DD3
  DXE Drivers Found: 47
  [OK]  SecurityStubDxe.efi         SHA256: a1b2c3d4...  (vendor signed)
  [OK]  PciHostBridgeDxe.efi        SHA256: e5f6a7b8...  (vendor signed)
  [!!!] PlatformHelperDxe.efi       SHA256: 9f8e7d6c...  (UNKNOWN - not in baseline)
  [OK]  NetworkStackDxe.efi         SHA256: 1a2b3c4d...  (vendor signed)
  ...

WARNING: PlatformHelperDxe.efi is not present in the vendor baseline image
WARNING: Module size (847 KB) exceeds expected range for platform helper drivers
WARNING: Module contains suspicious API imports: gRT->SetVariable, gBS->LocateProtocol

Phase 2: Firmware Update Delivery¶

ATT&CK Technique: T1072 (Software Deployment Tools)

VaultTech Industries' IT operations team downloads the compromised firmware update package as part of their quarterly firmware maintenance cycle. The update is distributed to 23 executive-tier workstations via the internal Systems Center Configuration Manager (SCCM) infrastructure at 10.20.1.50. The IT team verifies the download hash against the vendor portal — which matches, because the portal itself serves the trojanized image.

The firmware update is applied during a scheduled maintenance window. The UEFI update utility flashes the modified image to the SPI flash chip on each workstation's motherboard. At this point, the PHANTOM BRIDGE rootkit is embedded at the hardware level, below the operating system and all security software.

Phase 3: SPI Flash Implant Installation¶

ATT&CK Technique: T1542.001 (Pre-OS Boot: System Firmware)

The malicious DXE driver PlatformHelperDxe.efi is written to the SPI flash chip alongside legitimate UEFI drivers. During the DXE phase of the UEFI boot process (after SEC and PEI, before BDS), the implant executes with full system privileges in the pre-OS environment:

UEFI Boot Sequence:
1. SEC (Security Phase)        — CPU initialization, root of trust
2. PEI (Pre-EFI Initialization) — Memory initialization
3. DXE (Driver Execution Env)  — [PHANTOM BRIDGE EXECUTES HERE]
4. BDS (Boot Device Selection)  — Select boot device
5. TSL (Transient System Load)  — Load bootloader
6. RT  (Runtime)               — OS running, UEFI runtime services available

The implant performs the following actions during DXE:

1. Self-verification: Checks integrity of its own code in SPI flash
2. NVRAM variable creation: Stores configuration data in UEFI variables (visible only to firmware-level tools)
3. Boot service hook: Registers an event notification for EFI_EVENT_GROUP_READY_TO_BOOT to intercept the OS boot process
4. Anti-analysis: Detects if CHIPSEC or UEFI Shell is running and suppresses malicious behavior

# Simulated NVRAM variable analysis
$ python chipsec_util.py uefi var-list

Variable: PlatformConfig-{8BE4DF61-93CA-11D2-AA0D-00E098032B8C}
  Size: 4096 bytes
  Attributes: NV, BS, RT
  Content: [ENCRYPTED CONFIGURATION BLOB]
  Note: Variable name mimics legitimate platform configuration
  Note: Not present in clean firmware baseline

Phase 4: Secure Boot Bypass¶

ATT&CK Technique: T1553.006 (Subvert Trust Controls: Code Signing Policy Modification)

PHANTOM BRIDGE must ensure that the Windows bootloader does not detect the firmware-level modifications. The implant achieves this by hooking the EFI_SECURITY2_ARCH_PROTOCOL — the UEFI protocol responsible for verifying Secure Boot signatures. The hook function intercepts verification calls for the implant's own components and returns EFI_SUCCESS regardless of signature validity:

// Pseudocode of Secure Boot bypass (educational only)
// Original verification flow:
//   SecurityStub->FileAuthentication(file) → Verify signature → PASS/FAIL

// Hooked verification flow:
//   SecurityStub->FileAuthentication(file)
//     if (file matches implant pattern) → return EFI_SUCCESS  // bypass
//     else → call original verification → PASS/FAIL           // legitimate check

This targeted bypass means Secure Boot continues to function normally for all legitimate components — the OS bootloader, kernel, and drivers are still verified. Only the implant's components bypass verification, making the attack invisible to Secure Boot status checks.

Phase 5: OS Kernel Patching¶

ATT&CK Technique: T1014 (Rootkit), T1106 (Native API)

When the Windows bootloader begins execution, PHANTOM BRIDGE uses the UEFI Runtime Services interface to inject code into the kernel's memory space. The implant hooks ExitBootServices() — the UEFI function called by the bootloader when transferring control from firmware to OS — to perform the following kernel modifications:

1. Patch PatchGuard (KPP): Disable Kernel Patch Protection to prevent blue screens from kernel modifications
2. Install kernel callback: Register a PsSetCreateProcessNotifyRoutine callback that monitors for specific system processes
3. Deploy userland injector: When svchost.exe starts, inject a reflective DLL that establishes the C2 channel

The kernel patching occurs entirely in memory and leaves no artifacts on disk. The injected DLL exists only in process memory, never touching the filesystem.

Phase 6: Command and Control via DNS-over-HTTPS¶

ATT&CK Technique: T1071.004 (Application Layer Protocol: DNS), T1573.002 (Encrypted Channel: Asymmetric Cryptography)

The userland payload establishes a command-and-control channel using DNS-over-HTTPS (DoH) to 203.0.113.78, disguised as queries to a legitimate-appearing resolver. Commands and data are encoded in DNS TXT record queries:

# Simulated C2 DNS-over-HTTPS traffic
POST https://resolver.example.com/dns-query
Content-Type: application/dns-message
Accept: application/dns-message

# Encoded query: aGVhcnRiZWF0.c2Vzc2lvbi1pZA.phantom.example.com
# Decoded: heartbeat.session-id.phantom.example.com
# Response TXT record contains encrypted tasking

The C2 channel operates with the following characteristics:

Phase 7: Data Collection and Exfiltration¶

ATT&CK Technique: T1005 (Data from Local System), T1567.002 (Exfiltration Over Web Service: Exfiltration to Cloud Storage)

With persistent kernel-level access, JADE SPECTER collects intellectual property from VaultTech Industries executive workstations:

• Chip design files (GDSII format) from engineering shared drives at \\10.20.5.100\engineering
• Manufacturing process documentation from \\10.20.5.101\fabrication
• Customer contracts and pricing from local Outlook PST files
• Authentication credentials harvested from LSASS memory

Data is exfiltrated in small chunks (under 50 KB per DNS session) through the DoH channel. Larger files are compressed, encrypted, and staged to a cloud storage endpoint at storage.example.org before retrieval.

Phase 8: Self-Preservation and Anti-Forensics¶

ATT&CK Technique: T1542.003 (Pre-OS Boot: Bootkit), T1070 (Indicator Removal)

PHANTOM BRIDGE includes a self-preservation mechanism that monitors for BIOS update attempts. When a firmware update is initiated, the implant:

1. Intercepts the SPI flash write operation
2. Injects itself into the new firmware image before it is written
3. Allows the update to proceed with the re-implanted image

This ensures persistence even when the organization attempts to remediate by reflashing the firmware. The only reliable remediation is external SPI flash reprogramming using a hardware programmer (SPI clip) with a known-good firmware image verified against the vendor's offline signing database.

Detection Opportunities¶

KQL Detection — DNS-over-HTTPS Anomalies¶

// Detect potential DNS-over-HTTPS C2 traffic
DeviceNetworkEvents
| where RemotePort == 443
| where RemoteUrl has "dns-query" or RemoteUrl has "resolve"
| where RemoteIP in ("203.0.113.78", "198.51.100.22")
| summarize ConnectionCount = count(),
    UniqueProcesses = dcount(InitiatingProcessFileName),
    TotalBytesSent = sum(SentBytes)
    by DeviceName, RemoteIP, RemoteUrl, bin(Timestamp, 1h)
| where ConnectionCount > 10
| sort by ConnectionCount desc

KQL Detection — Firmware Integrity Anomaly¶

// Detect CHIPSEC or firmware analysis tool findings
DeviceEvents
| where ActionType == "AntivirusDetection" or ActionType == "AlertTriggered"
| where AdditionalFields has_any ("firmware", "UEFI", "SPI", "DXE", "bootkit")
| project Timestamp, DeviceName, ActionType, AdditionalFields
| sort by Timestamp desc

KQL Detection — Anomalous SVCHOST Behavior¶

// Detect svchost.exe with suspicious network connections (potential injected DLL)
DeviceNetworkEvents
| where InitiatingProcessFileName == "svchost.exe"
| where RemotePort == 443
| where RemoteIP startswith "203.0.113." or RemoteIP startswith "198.51.100."
| summarize ConnectionCount = count(),
    BytesSent = sum(SentBytes),
    BytesReceived = sum(ReceivedBytes)
    by DeviceName, InitiatingProcessId, RemoteIP, bin(Timestamp, 1h)
| where ConnectionCount > 5
| sort by BytesSent desc

SPL Detection — Firmware Update Anomalies¶

index=endpoint sourcetype=sysmon EventCode=1
| where (process_name="FWUpdateTool.exe" OR process_name="UEFIFlash.exe" OR process_name="flashrom*")
| eval hour=strftime(_time, "%H")
| where hour < "06" OR hour > "22"
| stats count by host, process_name, process_path, parent_process_name, user, _time
| where count > 0
| sort -_time
| rename host as "Endpoint", process_name as "Firmware Tool", user as "Executing User"

SPL Detection — DNS Tunneling via DoH¶

index=proxy sourcetype=bluecoat OR sourcetype=squid
| where url="*dns-query*" OR url="*resolve?*"
| where dest_ip IN ("203.0.113.78", "198.51.100.22")
| stats count as requests, sum(bytes_out) as total_bytes_out, dc(src_ip) as unique_sources by dest_ip, url
| where requests > 20
| eval avg_payload_bytes = round(total_bytes_out / requests, 0)
| where avg_payload_bytes > 500
| sort -requests
| table dest_ip, url, requests, total_bytes_out, avg_payload_bytes, unique_sources

Sigma Rule — UEFI Firmware Modification¶

title: Suspicious UEFI Firmware Modification Tool Execution
id: 2d3e4f5a-6b7c-8d9e-0f1a-2b3c4d5e6f7a
status: experimental
description: Detects execution of firmware flashing tools outside of approved maintenance windows or by unauthorized users
author: Nexus SecOps
date: 2026/04/03
references:
    - https://attack.mitre.org/techniques/T1542/001/
    - https://attack.mitre.org/techniques/T1542/003/
logsource:
    category: process_creation
    product: windows
detection:
    selection_tools:
        Image|endswith:
            - '\flashrom.exe'
            - '\FWUpdateTool.exe'
            - '\FPT.exe'
            - '\AFUWINx64.exe'
            - '\H2OFFT.exe'
            - '\UEFIFlash.exe'
    selection_chipsec:
        Image|contains: 'chipsec'
        CommandLine|contains:
            - 'spi write'
            - 'spi erase'
    filter_maintenance:
        User|contains:
            - 'fw-admin'
            - 'SYSTEM'
            - 'sccm-svc'
    condition: (selection_tools or selection_chipsec) and not filter_maintenance
falsepositives:
    - Scheduled firmware updates by IT operations
    - Security team running CHIPSEC for integrity verification
level: critical
tags:
    - attack.persistence
    - attack.t1542.001
    - attack.t1542.003

Sigma Rule — Suspicious Kernel Callback Registration¶

title: Suspicious Kernel Callback Registration via Driver Load
id: 8a9b0c1d-2e3f-4a5b-6c7d-8e9f0a1b2c3d
status: experimental
description: Detects loading of unsigned or suspicious kernel drivers that may register rootkit callbacks
author: Nexus SecOps
date: 2026/04/03
references:
    - https://attack.mitre.org/techniques/T1014/
logsource:
    category: driver_load
    product: windows
detection:
    selection:
        Signed: 'false'
    selection_suspicious_name:
        ImageLoaded|contains:
            - 'PlatformHelper'
            - 'SystemMonitor'
            - 'HardwareAccess'
    condition: selection or selection_suspicious_name
falsepositives:
    - Legitimate unsigned drivers during development
    - Hardware vendor diagnostic tools
level: high
tags:
    - attack.persistence
    - attack.defense_evasion
    - attack.t1014
    - attack.t1547.001

Response Playbook¶

1. Immediate Isolation: Disconnect all suspected compromised workstations from the network. Do not power them off — preserve volatile memory for forensic analysis.
2. Memory Forensics: Capture full physical memory dumps from affected systems using a write-blocked external tool. Analyze for injected DLLs, hooked kernel functions, and anomalous svchost.exe threads.
3. Firmware Extraction: Use an external SPI programmer (e.g., Dediprog SF100, CH341A with SPI clip) to read firmware directly from the SPI flash chip. Do not use OS-level tools, as the rootkit may tamper with firmware reads.
4. Firmware Analysis: Compare extracted firmware against known-good baseline images using CHIPSEC. Identify all DXE drivers not present in the vendor baseline. Submit suspicious modules for reverse engineering.
5. Scope Assessment: Identify all systems that received the compromised firmware update. Check SCCM deployment logs at 10.20.1.50 for the full distribution list.
6. Supply Chain Investigation: Notify the firmware vendor of the portal compromise. Work with the vendor to determine the extent of the supply chain attack and identify other affected customers.
7. Hardware Remediation: For confirmed compromised systems, reflash the SPI chip using a hardware programmer with a verified firmware image obtained directly from the vendor via a secure out-of-band channel. Software-based reflashing is insufficient due to the self-preservation mechanism.
8. Secure Boot Key Rotation: If Secure Boot was bypassed, rotate the Platform Key (PK) and Key Exchange Keys (KEK). Deploy updated Secure Boot databases (db/dbx) to all endpoints.
9. Network IOC Blocking: Block all identified C2 infrastructure (203.0.113.78, 198.51.100.22, resolver.example.com, phantom.example.com) at the DNS, proxy, and firewall layers.
10. Credential Reset: Assume all credentials on affected systems are compromised. Force password resets for all users who authenticated on compromised workstations. Rotate service account credentials.
11. Enhanced Monitoring: Deploy firmware integrity monitoring using CHIPSEC or equivalent tools on a scheduled basis. Implement measured boot with TPM attestation to detect future firmware modifications.
12. Long-Term Architecture: Evaluate Intel Boot Guard or AMD Platform Secure Boot to establish a hardware root of trust that prevents unauthorized firmware modifications.

Lessons Learned¶

• Firmware is the ultimate persistence layer. UEFI rootkits survive OS reinstallation, disk replacement, and software-based BIOS updates. Organizations must include firmware in their threat model and security monitoring strategy.
• Secure Boot is not invulnerable. Implementation vulnerabilities in Secure Boot verification logic can be exploited to bypass signature checks while maintaining the appearance of a healthy Secure Boot state.
• Supply chain attacks on firmware vendors are high-impact. A single compromised firmware update can implant rootkits across an entire fleet of devices. Firmware update integrity verification must include out-of-band validation, not just portal hash matching.
• OS-level security tools cannot detect firmware threats. EDR, antivirus, and HIDS operate within the OS and have no visibility into pre-OS firmware execution. Hardware-based attestation (TPM measured boot) and external firmware analysis are required.
• DNS-over-HTTPS complicates C2 detection. Encrypted DNS channels blend with legitimate privacy-preserving DNS traffic. Detection requires endpoint-level visibility into DoH client behavior, not just network-level DNS monitoring.
• Remediation requires hardware-level intervention. Software-based firmware updates are insufficient when the rootkit includes self-preservation mechanisms. Physical access with SPI programmers is the only reliable remediation path.

Nexus SecOps References¶

• Chapter 6: Endpoint Security — Endpoint protection and firmware security
• Chapter 18: Malware Analysis — Rootkit analysis techniques
• Chapter 23: Advanced Persistent Threats — Nation-state persistence TTPs
• Chapter 24: Supply Chain Attacks — Supply chain compromise patterns
• Chapter 27: Digital Forensics — Firmware forensics and memory analysis
• Chapter 38: Emerging Threats — Hardware and firmware threat landscape
• Lab 07: Malware Analysis Sandbox — Rootkit analysis in isolated environments
• Purple Team Exercise PT-045 — Persistence mechanism detection