NtCreateProcess

Prototipo

NTSTATUS NtCreateProcess(
  PHANDLE            ProcessHandle,
  ACCESS_MASK        DesiredAccess,
  POBJECT_ATTRIBUTES ObjectAttributes,
  HANDLE             ParentProcess,
  BOOLEAN            InheritObjectTable,
  HANDLE             SectionHandle,
  HANDLE             DebugPort,
  HANDLE             ExceptionPort
);

Argumentos

IDs de syscalls por versión de Windows

Stub del syscall

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

El syscall *original* de creación de procesos NT — presente desde Windows NT 3.1. Es la primitiva de más bajo nivel: el llamante debe haber creado ya la section de imagen (`NtCreateSection(SEC_IMAGE, …)`), y el kernel solo construye el EPROCESS/KPROCESS, copia el esqueleto de PEB del padre y clona el espacio de direcciones. **No** crea el hilo inicial (debe seguir con `NtCreateThread`), **no** carga ninguna DLL más allá de la imagen principal, y **no** invoca a CSRSS para registrar el nuevo proceso — lo que significa que el proceso resultante **aún no es un proceso Win32**. Para obtener un proceso consola/Win32 visible debe llamar `CsrClientCallServer(BasepCreateProcess)` manualmente. `NtCreateProcessEx` (Windows XP+) añadió `JobMemberLevel` y la creación sin section; `NtCreateUserProcess` (Vista+) reemplazó ambos como la implementación one-shot de CreateProcess que maneja section, hilo, PEB, CSRSS, AppContainer y policies de mitigación en un único syscall. El `kernel32!CreateProcessW` moderno llama exclusivamente `NtCreateUserProcess` — `NtCreateProcess` solo es alcanzable por invocación directa.

Uso común por malware

Usado históricamente (pre-2010s) en cadenas de **process hollowing manual** que querían control máximo sobre la inicialización del PEB, bypass de policy de mitigación o evasión contra herramientas que hookeaban `CreateProcessW` pero no la capa NT inferior. El patrón canónico: `NtCreateSection(SEC_IMAGE)` sobre un binario objetivo benigno → `NtCreateProcess` con esa section como imagen → `NtCreateThread` en el entry point de la nueva imagen. Como el proceso resultante nunca habla con CSRSS, carece de una entrada en el subsistema consola, no aparece en `EnumProcesses` hasta notificación CSRSS, y en sistemas legacy era efectivamente invisible al Task Manager durante una breve ventana. Los callbacks modernos `Process Notify Routine` (`PsSetCreateProcessNotifyRoutineEx`) disparan desde `PspInsertProcess` independientemente del wrapper user-mode que llamó, así que el beneficio de evasión de visibilidad se acabó, y `NtCreateUserProcess` se prefiere universalmente. Hoy, los llamados a `NtCreateProcess` desde cualquier cosa salvo un puñado de binarios de test MS y ciertas emulaciones Cygwin/MSYS2 de `fork()` son esencialmente una huella de malware.

Oportunidades de detección

La señal más fuerte es *cualquier* invocación fuera de una allowlist conocida — `cygwin1.dll` de Cygwin, `msys-2.0.dll` de MSYS2, la capa LXSS de WSL1 y las herramientas de test del subsistema NT de Microsoft. Los callbacks kernel `PsSetCreateProcessNotifyRoutineEx` reciben un `PS_CREATE_NOTIFY_INFO` con `FileObject != NULL` solo cuando la imagen fue abierta por el kernel — los llamantes de `NtCreateProcess` proveen la section ellos mismos, así que el `ImageFileName` es el archivo fuente de la section y el contexto *llamante* dice quién la construyó. El evento ETW `Microsoft-Windows-Kernel-Process` ID 1 dispara uniformemente; correlacione el campo `CreateRoutine` (visible en el stack de kernel de la vista de hilos) para distinguir `NtCreateUserProcess` de `NtCreateProcessEx` / `NtCreateProcess`. Cualquier evento Sysmon 1 cuyo ParentImage sea inusual y cuyo `OriginalFileName` no coincida con `ImageFileName` es alta señal.

Ejemplos de syscalls directos

// Minimal legacy-style hollow. Modern EDR sees the PspInsertProcess callback
// regardless, so this is documented for reverse-engineers, not as a working
// evasion in 2026.
#include <windows.h>
#include <winternl.h>

typedef NTSTATUS (NTAPI* pNtCreateProcess)(
    PHANDLE, ACCESS_MASK, POBJECT_ATTRIBUTES, HANDLE, BOOLEAN,
    HANDLE, HANDLE, HANDLE);

void legacy_hollow(HANDLE hImageSection) {
    pNtCreateProcess NtCreateProcess = (pNtCreateProcess)GetProcAddress(
        GetModuleHandleA("ntdll.dll"), "NtCreateProcess");

    HANDLE hProc = NULL;
    NTSTATUS st = NtCreateProcess(
        &hProc,
        PROCESS_ALL_ACCESS,
        NULL,
        NtCurrentProcess(),   // parent = self → inherits address-space template
        FALSE,                // do not inherit handles
        hImageSection,        // SEC_IMAGE backing
        NULL,                 // no debug port
        NULL);                // no exception port

    // At this point the process exists but has zero threads and has not been
    // announced to CSRSS. Caller now creates the initial thread at the image
    // entry point with NtCreateThread.
}

NtCreateProcess PROC
    mov  r10, rcx
    mov  eax, 0C0h
    syscall
    ret
NtCreateProcess ENDP

// Hardcoded SSNs drift; resolve at runtime by walking ntdll exports.
use windows_sys::Win32::Foundation::HANDLE;
use windows_sys::Win32::System::LibraryLoader::{GetModuleHandleA, GetProcAddress};

unsafe fn nt_create_process_ssn() -> u32 {
    let h = GetModuleHandleA(b"ntdll.dll\0".as_ptr());
    let p = GetProcAddress(h, b"NtCreateProcess\0".as_ptr()) as *const u8;
    // mov r10, rcx ; mov eax, IMM32 ; ...
    if p.read() == 0x4C && p.add(1).read() == 0x8B && p.add(2).read() == 0xD1 && p.add(3).read() == 0xB8 {
        u32::from_le_bytes([p.add(4).read(), p.add(5).read(), p.add(6).read(), p.add(7).read()])
    } else { 0 }
}

Mapeos MITRE ATT&CK

• T1055.012Process Injection: Process Hollowingmitre ↗
• T1055Process Injectionmitre ↗
• T1106Native APImitre ↗