safemode.space
← All techniques
DE-0008
ST0006Defense Evasion

Evasion via Bootkit

Description

A bootkit hides activity by running first and shaping what higher layers will later observe. Positioned in boot ROM handoff or early loaders, it can select or patch images in memory, alter device trees and driver tables, seed forged counters and timestamps, and preconfigure telemetry/crypto modes so subsequent components launch into a reality curated by the attacker. Because integrity and logging mechanisms are initialized afterward, the resulting view of processes, files, and histories reflects the bootkit’s choices, allowing long-term evasion that persists across resets and mode transitions.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(b)
    relates to
    moderate
    direct

    Secure boot, root-of-trust, and verified boot chain are the (2)(b) 'secure by default configuration' realization that bootkit attacks specifically target.

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

    A bootkit patches boot ROM handoff, early loaders, and device tables — unauthorized modification of programs and configuration during the most privileged phase of the product, within (2)(f)'s scope.

  • craAnnex I, Part I, (2)(k)
    addresses
    moderate
    direct

    Pre-OS persistence is exactly the long-lived high-privilege impact (2)(k)'s exploitation-mitigation mechanisms are meant to reduce.

  • craAnnex I, Part II, (3)
    addresses
    high
    direct

    Bootkit evasion (primary mapping: Annex I, Part I, (2)(k)) cascades to (3) — secure-boot and root-of-trust mitigations require regular boot-chain integrity testing to validate that bootkit attacks remain detected.

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

    Art. 76(4)(b)'s manufacturing-and-test-phase coverage is domain-relevant to bootkit insertion, but scopes lifecycle risk management to those phases without naming an interdicting mechanism; secure boot would be the interdiction.

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

    Bootkit risk (primary: Art. 76(4) manufacturing/test phases) requires ISMS-level lifecycle treatment under 76(5).

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

    Bootkit attacks the boot-chain integrity covered by 84(2)'s Annex VII point 5.1 — secure-boot, root-of-trust, and verified-boot are the foundational integrity protections.

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

    Bootloader integrity, image-selection logic, device-tree handling, and recovery-mode images 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 signature verification and anti-rollback 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 protect against and detect or prevent the use of malicious or unauthorised software; 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), use of cryptography, the relationship to this technique is addresses; the mitigation sits at the section-6 control.

  • nis2-implAnnex 12.1.1
    addresses
    moderate
    derived

    Boot-stage code and pre-OS images are top-classification assets whose classification governs the strict storage and integrity controls that prevent malicious modification.

  • nis2-implAnnex 6.4.1
    addresses
    moderate
    derived

    Boot-chain modification is change-managed; documented change procedures detect unauthorized alteration of boot ROM, early loaders and device-tree initialization.

  • nis2-implAnnex 6.9.1
    addresses
    high
    derived

    Bootkit evasion is malicious software running before higher-layer integrity checks; the malware-protection obligation extends to the boot chain through pre-boot integrity verification and measured-boot mechanisms.

ENISA controls

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

    Configuration management of boot configuration words, image-selection logic, and device trees detects bootkit-installed hooks that persist across resets.

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

    Tamper protection during shipping and receiving, with physical inspection of hardware, is relevant to the supply-chain hardware-implant route that could preconfigure a bootkit in non-volatile boot storage.

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

    Integrity checking covering pre-OS boot artefacts directly defeats bootkit shaping of what subsequent components observe.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, DE-0008 (SPARTA v3.2).

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