NtCreatePort

Prototyp

NTSTATUS NtCreatePort(
  PHANDLE             PortHandle,
  POBJECT_ATTRIBUTES  ObjectAttributes,
  ULONG               MaxConnectionInfoLength,
  ULONG               MaxMessageLength,
  ULONG               MaxPoolUsage
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

NtCreatePort ist die *Server*-Seite des Legacy-**LPC**-IPC-Mechanismus (vor Vista). Sie registriert ein benanntes Port-Objekt — typischerweise unter `\RPC Control\` — das Clients via NtConnectPort erreichen. Nach Annahme der Verbindung mit NtAcceptConnectPort und Abschluss des Handshakes via NtCompleteConnectPort tritt der Server über NtReplyWaitReceivePort in seine Empfangsschleife ein. Seit Vista exponiert der Kernel die reichere **ALPC**-API (NtAlpcCreatePort etc.) und Microsoft hat fast den gesamten Inbox-RPC-Verkehr auf ALPC migriert. LPC verbleibt in der SSDT für Abwärtskompatibilität, wird aber von heutigem Inbox-Code kaum noch genutzt.

Häufige Malware-Nutzung

Modernes offensives Verwenden von NtCreatePort ist *selten*. Das relevante historische Muster ist ein Kernel- oder User-Mode-Implant, das einen LPC-Port-Namen registriert, der einen legitimen Kernelkomponenten-Namen imitiert (z. B. etwas ähnlich `\SeLsaCommandPort`), und es als verdeckten Intra-Host-C2-Kanal nutzt, der weder Winsock noch Named-Pipe-APIs berührt. Heute greift ein Angreifer für Intra-Host-IPC fast immer auf ALPC, Named Pipes, Mailslots oder Shared Sections zurück. Jeder nicht von Microsoft signierte Prozess, der NtCreatePort aufruft, ist als anomal zu werten.

Erkennungs­möglichkeiten

Es gibt keinen dedizierten ETW-Provider für Legacy-LPC analog zu `Microsoft-Windows-Kernel-ALPC`. Detektion stützt sich daher auf Kernel-Callbacks (ObCreateObject-Hooks des Object Managers via ObRegisterCallbacks für Typ `Port`) oder Syscall-Hooks auf Treiber-Ebene. SystemInformer und WinObj listen lebende Port-Objekte unter `\RPC Control` und `\Sessions\<n>\Windows` auf. Jeder neue Port-Name, der nicht zu einer bekannten Microsoft-Komponente passt (csrss, lsass, smss, RPC-Subsystem), ist untersuchungswürdig.

Direkte Syscall-Beispiele

; Direct syscall stub for NtCreatePort (SSN 0xBE on Win11 24H2)
NtCreatePort PROC
    mov  r10, rcx          ; PortHandle
    mov  eax, 0BEh         ; SSN — verify per-build before deploying
    syscall
    ret
NtCreatePort ENDP

// Create an LPC server port under \RPC Control.
#include <windows.h>
#include <winternl.h>

typedef NTSTATUS (NTAPI *pNtCreatePort)(
    PHANDLE, POBJECT_ATTRIBUTES, ULONG, ULONG, ULONG);

NTSTATUS CreateLpcPort(HANDLE *outHandle, PCWSTR ntName) {
    UNICODE_STRING name;
    OBJECT_ATTRIBUTES oa;
    RtlInitUnicodeString(&name, ntName);
    InitializeObjectAttributes(&oa, &name, OBJ_CASE_INSENSITIVE, NULL, NULL);

    pNtCreatePort fn = (pNtCreatePort)GetProcAddress(
        GetModuleHandleA("ntdll.dll"), "NtCreatePort");
    return fn(outHandle, &oa, 0x100, 0x100, 0x2000);
}

MITRE ATT&CK-Mappings

• T1559Inter-Process Communicationmitre ↗
• T1106Native APImitre ↗