NtReplyWaitReceivePort

Prototyp

NTSTATUS NtReplyWaitReceivePort(
  HANDLE         PortHandle,
  PVOID         *PortContext,
  PPORT_MESSAGE  ReplyMessage,
  PPORT_MESSAGE  ReceiveMessage
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

NtReplyWaitReceivePort ist die kanonische *Server-Hauptschleife* von Legacy-LPC: Sie liefert atomar die Antwort auf die in der vorherigen Iteration behandelte Anfrage und blockiert auf der Eingangs-Queue, bis die nächste Anfrage eintrifft. Der Out-Parameter `PortContext` liefert den bei NtAcceptConnectPort registrierten clientspezifischen Kontextzeiger, sodass ein Server-Thread beliebig viele Clients multiplexen kann. Die SSN `0x0B` ist seit Windows 10 1507 eingefroren — sogar niedriger als NtRequestWaitReplyPort, weil die originalen LPC-Dispatch-Routinen früh in der Tabelle platziert wurden.

Häufige Malware-Nutzung

Ein Angreifer ruft NtReplyWaitReceivePort nur auf, nachdem er via NtCreatePort + NtAcceptConnectPort + NtCompleteConnectPort einen benutzerdefinierten LPC-Server hochgezogen hat. Dieses Muster ist in moderner Malware *verschwindend selten* — praktische IPC für Implants läuft über Named Pipes, ALPC oder Shared Sections. Nur historisches / akademisches Interesse: Pre-Vista-User-Mode-Rootkits nutzten die LPC-Server-Schleife als geräuscharme Intra-Host-C2-Stufe. Jeder Nicht-OS-Prozess, der auf Windows 10/11 in NtReplyWaitReceivePort blockiert sitzt, ist für sich untersuchungswürdig.

Erkennungs­möglichkeiten

Kein dedizierter ETW-Provider für Legacy-LPC; Detektion erfordert Kernel-Callbacks oder Syscall-Hooks auf Treiber-Ebene. Der robusteste Blue-Team-Ansatz ist die Aufzählung lebender `Port`-Objekte unter `\RPC Control` und `\Sessions\<n>\Windows` (SystemInformer / WinObj) und das Markieren von Ownern, die nicht csrss, lsass, smss oder das RPC-Subsystem sind. Ein User-Mode-Thread, der dauerhaft in `ntdll!NtReplyWaitReceivePort` blockiert, ohne ein passendes Microsoft-Binary im Stack, ist hochaussagekräftig.

Direkte Syscall-Beispiele

; Direct syscall stub for NtReplyWaitReceivePort (SSN 0x0B, stable Win10 1507+)
NtReplyWaitReceivePort PROC
    mov  r10, rcx          ; PortHandle
    mov  eax, 0Bh          ; SSN
    syscall
    ret
NtReplyWaitReceivePort ENDP

// Skeleton of a custom LPC server. Error handling elided for brevity.
#include <windows.h>
#include <winternl.h>

typedef NTSTATUS (NTAPI *pNtReplyWaitReceivePort)(
    HANDLE, PVOID*, PVOID /*PPORT_MESSAGE*/, PVOID /*PPORT_MESSAGE*/);

void ServerLoop(HANDLE hServerPort) {
    BYTE reqBuf[0x100], replyBuf[0x100];
    PVOID ctx = NULL;
    BOOL  havePendingReply = FALSE;

    pNtReplyWaitReceivePort fn = (pNtReplyWaitReceivePort)GetProcAddress(
        GetModuleHandleA("ntdll.dll"), "NtReplyWaitReceivePort");

    for (;;) {
        NTSTATUS s = fn(hServerPort, &ctx,
                        havePendingReply ? replyBuf : NULL,
                        reqBuf);
        if (s < 0) break;
        // ... dispatch on reqBuf, populate replyBuf, set havePendingReply = TRUE ...
        havePendingReply = TRUE;
    }
}

// Cargo: ntapi = "0.4"
use ntapi::ntlpcapi::NtReplyWaitReceivePort;
use winapi::shared::ntdef::{HANDLE, NTSTATUS, PVOID};

unsafe fn recv(port: HANDLE, ctx_out: *mut PVOID, reply: *mut u8, recv: *mut u8) -> NTSTATUS {
    NtReplyWaitReceivePort(port, ctx_out, reply as *mut _, recv as *mut _)
}

MITRE ATT&CK-Mappings

• T1559Inter-Process Communicationmitre ↗
• T1106Native APImitre ↗