safemode.space
← All techniques
EX-0010.04
ST0004Execution
sub-technique

Bootkit

Parent: EX-0010

Description

A bootkit positions itself in the pre-OS boot chain so that it executes before normal integrity checks and can shape what the system subsequently trusts. After seizing early control, the bootkit can redirect image selection, patch kernels or flight binaries in memory, adjust device trees and driver tables, or install hooks that persist across warm resets. Some variants maintain shadow copies of legitimate images and present them to basic verification routines while steering actual execution to a modified payload; others manipulate fallback logic so recovery modes load attacker-controlled code. Because the boot path initializes memory maps, buses, and authentication material, a bootkit can also influence key/counter setup and gateway configurations, creating conditions favorable to later tactics. The central characteristic is precedence: by running first, the implant defines the reality higher layers observe, ensuring that every subsequent component launches under conditions curated by the attacker.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(f)
    addresses
    high
    derived

    Integrity protection on boot artefacts is the manufacturer-side obligation requiring secure boot, measured boot and integrity-verified bootloader chains — the precise defense against bootkit installation.

  • craAnnex I, Part II, (5)
    addresses
    moderate
    direct

    Stack/heap memory exploitation handled via secure update distribution (primary mapping: Part II, (7)) implies an upstream CVD process; (5)'s policy obligation is the procedural intake.

  • craAnnex I, Part II, (7)
    addresses
    moderate
    derived

    Secure update-distribution mechanisms protect boot-stage code paths: the same provenance and integrity requirements that protect runtime updates apply to boot-image updates.

  • craAnnex I, Part II, (8)
    addresses
    moderate
    direct

    Stack/heap-memory exploitation handled via secure update distribution (primary mapping: Part II, (7)) cascades to (8) — the secure-distribution and timely-dissemination obligations work in tandem.

  • eu-space-actArt. 76(4)
    addresses
    moderate
    direct

    Boot-chain integrity is established at 76(4)(b)'s manufacturing and test phases — secure-boot configuration, OTP fuses, and golden-image baselines are decided in this lifecycle stage.

  • eu-space-actArt. 84(2)
    addresses
    high
    direct

    Bootkit attacks the integrity of the boot chain; 84(2)'s requirement that network and information systems comply with Annex VII point 5.1 includes secure-boot and root-of-trust as foundational protections.

  • nis2Art. 21(2)(e)
    addresses
    high
    direct

    Bootloader integrity, image-selection logic, and recovery-mode handling are network-and-information-systems development/maintenance artefacts; Art. 21(2)(e), including disclosed-vulnerability handling on the boot chain, is the obligation that governs them.

  • nis2Art. 21(2)(h)
    addresses
    moderate
    inferred

    Secure boot and anti-rollback enforced from immutable ROM are cryptographic mechanisms, but the operative control against bootkit precedence is protection against malicious and unauthorised software, which the CIR (EU) 2024/2690 Annex assigns to section 6 (6.9; 6.4 change management of software in operation), not to the section 9 cryptography requirements (cryptography policy, algorithm and cipher selection, and key management). At NIS2 Art. 21(2)(h) the relationship is addresses; the mitigation sits at the section-6 control.

  • nis2-implAnnex 12.1.1
    addresses
    moderate
    derived

    Boot images and pre-OS code are top-classification assets whose handling and integrity controls determine whether attacker modification is feasible at all.

  • nis2-implAnnex 6.4.1
    addresses
    moderate
    derived

    Boot-chain artefacts (boot ROM, bootloader, init code) are managed under change-management procedures; the implementing regulation requires the entity to control modifications to these crown-jewel components and bootkit installation must subvert that pipeline.

  • nis2-implAnnex 6.9.1
    addresses
    high
    derived

    A bootkit is malicious software seizing the pre-OS boot chain; the malware-protection obligation requires detection-or-prevention measures appropriate to the boot-chain asset.

ENISA controls

  • ENISA-STL-2025-03-sD.21-i01
    mitigates
    moderate

    Configuration management of boot configuration words, fuses, and image-selection logic detects modifications a bootkit makes to redirect early-boot trust.

  • ENISA-STL-2025-03-sD.22-i02
    addresses
    moderate

    Tamper protection and physical inspection during shipping/integration is relevant to the supply-chain avenue a bootkit uses to modify non-volatile boot storage, governing handling rather than actively defending the boot chain.

  • ENISA-STL-2025-03-sD.25-i10
    addresses
    high

    Integrity checks across mission software and firmware including pre-OS boot artefacts directly defeat bootkit substitution of boot images and image-selection logic.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, EX-0010.04 (SPARTA v3.2).

Built 2026-07-25 from 216 techniques, 334 regulation articles, 125 ENISA controls, 2,610 framework controls, and 90 countermeasures.