NtReplyWaitReceivePort

Prototipo

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

Argumentos

IDs de syscalls por versión de Windows

Stub del syscall

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

Notas no documentadas

NtReplyWaitReceivePort es el *bucle principal del servidor* canónico del LPC heredado: entrega atómicamente la respuesta a la petición tratada en la iteración previa y bloquea en la cola entrante hasta que llegue la siguiente petición. El parámetro de salida `PortContext` proporciona el puntero de contexto por cliente registrado en NtAcceptConnectPort, permitiendo a un hilo servidor multiplexar cualquier número de clientes. El SSN `0x0B` está congelado desde Windows 10 1507 — incluso más bajo que NtRequestWaitReplyPort porque las rutinas originales de dispatch LPC se ubicaron temprano en la tabla.

Uso común por malware

Un atacante invocará NtReplyWaitReceivePort solo tras levantar un servidor LPC custom vía NtCreatePort + NtAcceptConnectPort + NtCompleteConnectPort. Ese patrón es *muy raro* en malware moderno — la IPC práctica para implantes pasa por named pipes, ALPC o secciones compartidas. Interés histórico / académico únicamente: los rootkits user-mode pre-Vista usaban el bucle servidor LPC como etapa C2 intra-host de bajo ruido. Cualquier proceso no del SO bloqueado en NtReplyWaitReceivePort en Windows 10/11 merece investigación.

Oportunidades de detección

Sin proveedor ETW dedicado a LPC heredado; la detección requiere callbacks de kernel o hook de syscall a nivel driver. El enfoque blue-team más sólido es enumerar objetos `Port` vivos bajo `\RPC Control` y `\Sessions\<n>\Windows` (SystemInformer / WinObj) y marcar a los propietarios que no sean csrss, lsass, smss o el subsistema RPC. Un hilo user-mode permanentemente bloqueado en `ntdll!NtReplyWaitReceivePort` sin un binario Microsoft correspondiente en su pila es de alta señal.

Ejemplos de syscalls directos

; 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 _)
}

Mapeos MITRE ATT&CK

• T1559Inter-Process Communicationmitre ↗
• T1106Native APImitre ↗