NtAddDriverEntry

Prototipo

NTSTATUS NtAddDriverEntry(
  PEFI_DRIVER_ENTRY DriverEntry,
  PULONG            Id
);

Argumentos

IDs de syscalls por versión de Windows

Stub del syscall

4C 8B D1            mov r10, rcx
B8 6B 00 00 00      mov eax, 0x6B
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

Notas no documentadas

EFI_DRIVER_ENTRY es estructuralmente idéntica a BOOT_ENTRY pero direcciona el espacio de nombres UEFI **DriverOrder** en lugar de BootOrder. UEFI despacha cada variable `Driver####` listada en `DriverOrder` durante la fase DXE/BDS — *antes* de que se ejecute cualquier boot manager. El kernel alcanza el firmware vía `HalSetEnvironmentVariableEx` contra el GUID de proveedor `{8BE4DF61-93CA-11d2-AA0D-00E098032B8C}`. Se requiere SeSystemEnvironmentPrivilege y, en la mayoría de firmwares OEM, la escritura de variable también exige que Secure Boot esté deshabilitado o acepte la firma del binario.

Uso común por malware

Aún más peligroso que la persistencia por boot-entry: un controlador UEFI se ejecuta en el **contexto EFI Boot Services**, en el entorno firmware CPL0 con memoria plana, **antes de ExitBootServices**, antes de que se cargue el kernel de Windows y por tanto antes de PatchGuard, DSE, HVCI o cualquier EDR. Este es el vector de persistencia elegido por MosaicRegressor / LoJax (APT28) que registró un controlador DXE malicioso vía `SetVariable`, y por MoonBounce (APT41) que implantó código en CORE_DXE. ESPecter y el implante SPI CosmicStrand finalmente también persisten como controladores DXE. Una DRIVER_ENTRY registrada con éxito otorga a los atacantes ejecución de código pre-SO permanente que sobrevive a un wipe de disco y reinstalación de Windows.

Oportunidades de detección

ETW Microsoft-Windows-Kernel-Boot registra los cambios DRIVER_ENTRY junto con los BOOT_ENTRY. El control de mayor valor único es **Measured Boot + atestación remota**: cada controlador DXE UEFI despachado extiende PCR[2], por lo que un hash de controlador no visto previamente hará fallar la atestación contra la baseline registrada del dispositivo. `tools.uefi.scan_image` y `common.bios_kbrd_buffer` de CHIPSEC más la monitorización de firmware de Eclypsium detectan binarios DXE maliciosos en disco. El propio Windows registra el Event ID 1035 (Microsoft-Windows-TPM-WMI) en discrepancias PCR cuando se dispara la recuperación BitLocker. Auditar 4673 sobre uso de SeSystemEnvironmentPrivilege para detectar el paso de staging en SO.

Ejemplos de syscalls directos

NtAddDriverEntry PROC
    mov  r10, rcx          ; PEFI_DRIVER_ENTRY
    mov  eax, 6Bh          ; Win11 24H2
    syscall
    ret
NtAddDriverEntry ENDP

// Structurally mirrors NtAddBootEntry but targets DriverOrder.
// Practical use requires SeSystemEnvironmentPrivilege and Secure Boot bypass / disable.
extern NTSTATUS NTAPI NtAddDriverEntry(PEFI_DRIVER_ENTRY, PULONG);

NTSTATUS plant_driver(void) {
    BYTE buf[512] = {0};
    PEFI_DRIVER_ENTRY de = (PEFI_DRIVER_ENTRY)buf;
    de->Version    = 1;
    de->Length     = sizeof(buf);
    de->Attributes = 0;
    de->FriendlyNameOffset = FIELD_OFFSET(EFI_DRIVER_ENTRY, OsOptions);
    wcscpy_s((wchar_t*)(buf + de->FriendlyNameOffset), 32, L"Diagnostic DXE");
    ULONG id = 0;
    return NtAddDriverEntry(de, &id);
}

use std::arch::asm;

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

Mapeos MITRE ATT&CK

• T1542.001Pre-OS Boot: System Firmwaremitre ↗
• T1542.003Pre-OS Boot: Bootkitmitre ↗
• T1014Rootkitmitre ↗