NtModifyDriverEntry

Prototipo

NTSTATUS NtModifyDriverEntry(
  PEFI_DRIVER_ENTRY DriverEntry
);

Argumentos

IDs de syscalls por versión de Windows

Stub del syscall

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

Espejo de NtModifyBootEntry pero para el espacio de nombres UEFI `Driver####`. El ID es la clave primaria dentro de la EFI_DRIVER_ENTRY; el kernel lo resuelve, localiza la variable firmware correspondiente y la reescribe en una sola llamada atómica SetVariable. SeSystemEnvironmentPrivilege obligatorio.

Uso común por malware

Se usa cuando ya existe un controlador DXE OEM de diagnóstico o actualización de firmware en `DriverOrder`. En lugar de registrar una entrada nueva (sospechosa), el malware parchea el `DriverFilePath` de la entrada existente para apuntar a un binario `.efi` controlado por el atacante en la ESP, heredando el slot del OEM en DriverOrder y su FriendlyName plausible. Esta es una de las técnicas documentadas en los análisis LoJax / MosaicRegressor donde APT28 aprovechaba la infraestructura firmware existente en lugar de crear una nueva entrada. Los defensores que solo buscan *adiciones* DRIVER_ENTRY desconocidas pierden la mutación.

Oportunidades de detección

Tanto modificación como adición emergen en ETW Microsoft-Windows-Kernel-Boot. La señal diagnóstica aquí es la **deriva de contenido de archivo**: las rutas `Driver####` registradas pueden enumerarse y hashearse; un cambio en el hash en disco de un binario DXE previamente conocido (sin una actualización de firmware firmada correspondiente del OEM) es evidencia de alta confianza de secuestro de `DriverFilePath`. Eclypsium, CHIPSEC y la herramienta de Binarly basenizan los hashes de controladores DXE; Microsoft Defender for Endpoint expone la telemetría de controladores UEFI bajo los informes "Boot driver and firmware".

Ejemplos de syscalls directos

NtModifyDriverEntry PROC
    mov  r10, rcx          ; PEFI_DRIVER_ENTRY (Id inside struct)
    mov  eax, 0120h        ; Win11 24H2
    syscall
    ret
NtModifyDriverEntry ENDP

// Defensive analysis: shows the shape of what LoJax-style attackers do.
NTSTATUS hijack_driver(ULONG id, const wchar_t* shim) {
    BYTE buf[1024] = {0};
    PEFI_DRIVER_ENTRY de = (PEFI_DRIVER_ENTRY)buf;
    de->Version = 1;
    de->Length  = sizeof(buf);
    de->Id      = id;                  // existing OEM diagnostic driver
    de->Attributes = LOAD_OPTION_ACTIVE;
    de->BootFilePathOffset = FIELD_OFFSET(EFI_DRIVER_ENTRY, OsOptions);
    // populate FILE_PATH(shim) into buf[BootFilePathOffset..] (omitted)
    return NtModifyDriverEntry(de);
}

use std::arch::asm;

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

Mapeos MITRE ATT&CK

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