NtReplyWaitReceivePort

Prototype

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

Arguments

Syscall IDs by 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

Undocumented notes

NtReplyWaitReceivePort is the canonical *server main loop* of legacy LPC: it atomically delivers the reply to the request handled in the previous iteration and blocks on the incoming queue until the next request arrives. The `PortContext` out-param yields the per-client context pointer registered at NtAcceptConnectPort, letting one server thread multiplex any number of clients. The SSN `0x0B` is frozen since Windows 10 1507 — even lower than NtRequestWaitReplyPort because the original LPC dispatch routines were placed early in the table.

Common malware usage

An attacker would call NtReplyWaitReceivePort only after standing up a custom LPC server via NtCreatePort + NtAcceptConnectPort + NtCompleteConnectPort. That pattern is *vanishingly rare* in modern malware — practical IPC for implants is named-pipes, ALPC, or shared sections. Historical / academic interest only: pre-Vista user-mode rootkits used the LPC server loop as a low-noise in-host C2 stage. Any non-OS process sitting in NtReplyWaitReceivePort on Windows 10/11 is itself worth investigating.

Detection opportunities

No dedicated ETW provider for legacy LPC; detection requires kernel callbacks or driver-level syscall hooks. The strongest blue-team approach is enumerating live `Port` objects under `\RPC Control` and `\Sessions\<n>\Windows` (SystemInformer / WinObj) and flagging owners that aren't csrss, lsass, smss or the RPC subsystem. A user-mode thread permanently blocked inside `ntdll!NtReplyWaitReceivePort` with no matching Microsoft binary on its stack is high signal.

Direct syscall examples

; 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 ↗