NtAllocateVirtualMemory

Prototyp

NTSTATUS NtAllocateVirtualMemory(
  HANDLE    ProcessHandle,
  PVOID    *BaseAddress,
  ULONG_PTR ZeroBits,
  PSIZE_T   RegionSize,
  ULONG     AllocationType,
  ULONG     Protect
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

Die Syscall-Nummer von NtAllocateVirtualMemory ist von Windows 10 1909 bis Windows 11 24H2 bemerkenswert stabil — `0x18`. Bei vielen benachbarten Syscalls (z. B. NtCreateThreadEx) ist das *nicht* der Fall, weshalb dynamische Auflösung über Hell's Gate oder Halo's Gate gegenüber hartkodierten Nummern bevorzugt wird, wenn mehrere Builds anvisiert werden. Die Funktion dispatcht über KiSystemServiceCopyEnd → MmAllocateVirtualMemory innerhalb von ntoskrnl.exe.

Häufige Malware-Nutzung

Grundbaustein nahezu jedes Shellcode-Loaders: RW- oder RWX-Speicher im aktuellen oder Remote-Prozess allokieren, Payload kopieren, dann Schutz mit NtProtectVirtualMemory ändern. Wird verwendet von Cobalt-Strike-Beacon-Spawn, Sliver-Implants, klassischer Injection und den meisten Standard-Droppern. Zusammen mit NtWriteVirtualMemory + NtCreateThreadEx bildet es die kanonische CreateRemoteThread-Entsprechung über direkte Syscalls.

Erkennungs­möglichkeiten

Für sich allein ist NtAllocateVirtualMemory in legitimer Software *äußerst* häufig und kein nützliches Signal. Entscheidend ist *wie* und *wo* der Aufruf erfolgt: RWX-Allokationen, Allokationen in Remote-Prozessen sowie kurze RW→RX→Ausführen-Sequenzen. EDRs hooken NtAllocateVirtualMemory in ntdll.dll; direkte Syscalls umgehen diesen Hook, hinterlassen aber kernelseitig sichtbare Artefakte (VAD-Einträge, ETW-Threat-Intelligence-Events, PsSetCreateProcessNotifyRoutineEx-Callbacks bei Remote-Thread-Erzeugung). Sysmon Event ID 8 (CreateRemoteThread) und Event ID 10 (ProcessAccess mit VM_OPERATION/VM_WRITE) sind die wertvollste Blue-Team-Telemetrie — sie feuern auf die *Folgen* der Allokation, nicht die Allokation selbst.

Direkte Syscall-Beispiele

; Direct syscall stub for NtAllocateVirtualMemory (SSN 0x18, Win10 1909+)
NtAllocateVirtualMemory PROC
    mov  r10, rcx          ; syscall convention
    mov  eax, 18h          ; SSN
    syscall
    ret
NtAllocateVirtualMemory ENDP

// Resolve SSN dynamically from ntdll export at runtime — survives KB updates.
DWORD GetSyscallNumber(PVOID pNtFunction) {
    BYTE* p = (BYTE*)pNtFunction;
    if (p[0] == 0x4C && p[1] == 0x8B && p[2] == 0xD1 && p[3] == 0xB8) {
        return *(DWORD*)(p + 4);
    }
    return 0;
}

// usage
HMODULE hNtdll = GetModuleHandleA("ntdll.dll");
DWORD ssn = GetSyscallNumber(GetProcAddress(hNtdll, "NtAllocateVirtualMemory"));

// Cargo: windows-sys = "0.59"  (Win32_Foundation, Win32_System_Memory)
use std::arch::asm;

#[unsafe(naked)]
unsafe extern "system" fn nt_alloc_virtual_memory_stub() {
    asm!(
        "mov r10, rcx",
        "mov eax, 0x18",
        "syscall",
        "ret",
        options(noreturn),
    );
}

MITRE ATT&CK-Mappings

• T1055Process Injectionmitre ↗
• T1055.002Portable Executable Injectionmitre ↗
• T1620Reflective Code Loadingmitre ↗