NtModifyDriverEntry

Prototyp

NTSTATUS NtModifyDriverEntry(
  PEFI_DRIVER_ENTRY DriverEntry
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

Undokumentierte Hinweise

Pendant zu NtModifyBootEntry, jedoch für den UEFI-`Driver####`-Namespace. Die ID ist der Primärschlüssel innerhalb der EFI_DRIVER_ENTRY; der Kernel löst sie auf, findet die zugehörige Firmware-Variable und schreibt sie in einem einzigen atomaren SetVariable-Aufruf neu. SeSystemEnvironmentPrivilege ist Pflicht.

Häufige Malware-Nutzung

Wird genutzt, wenn bereits ein legitimer OEM-DXE-Treiber für Diagnose oder Firmware-Update in `DriverOrder` existiert. Statt einen neuen (verdächtigen) Eintrag zu registrieren, patcht Malware den `DriverFilePath` des bestehenden Eintrags, sodass er auf ein vom Angreifer kontrolliertes `.efi`-Binary auf der ESP zeigt, und erbt damit den OEM-Slot in DriverOrder samt plausiblem FriendlyName. Diese Technik ist in den LoJax-/MosaicRegressor-Analysen dokumentiert, wo APT28 die bestehende Firmware-Infrastruktur ausnutzte, statt einen neuen Eintrag zu schnitzen. Verteidiger, die nur unbekannte DRIVER_ENTRY-*Hinzufügungen* suchen, verpassen die Mutation.

Erkennungs­möglichkeiten

Sowohl Modifikation als auch Hinzufügung erscheinen in ETW Microsoft-Windows-Kernel-Boot. Diagnostisches Signal ist hier die **Datei-Inhalts-Drift**: die registrierten `Driver####`-Pfade lassen sich enumerieren und hashen; ein veränderter On-Disk-Hash eines zuvor bekannten DXE-Binaries (ohne entsprechendes signiertes Firmware-Update des OEM) ist starkes Indiz für einen `DriverFilePath`-Hijack. Eclypsium, CHIPSEC und das Tooling von Binarly baselinen DXE-Treiber-Hashes; Microsoft Defender for Endpoint zeigt UEFI-Treiber-Telemetrie in den „Boot driver and firmware"-Berichten.

Direkte Syscall-Beispiele

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),
    );
}

MITRE ATT&CK-Mappings

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