NtRequestWaitReplyPort

Prototype

NTSTATUS NtRequestWaitReplyPort(
  HANDLE         PortHandle,
  PPORT_MESSAGE  Request,
  PPORT_MESSAGE  Reply
);

Arguments

IDs de syscalls par version de Windows

Stub du syscall

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

Notes non documentées

NtRequestWaitReplyPort est la primitive request/response synchrone du sous-système **LPC** historique — conceptuellement équivalente à `NtAlpcSendWaitReceivePort` avec `ALPC_MSGFLG_SYNC_REQUEST`. Elle envoie un PORT_MESSAGE et bloque le thread appelant jusqu'à ce que le serveur réponde via `NtReplyPort` ou `NtReplyWaitReceivePort`. Le SSN `0x22` est gelé depuis Windows 10 1507, reflétant le statut legacy de LPC dans la table. Le payload inline est plafonné à PORT_MAXIMUM_MESSAGE_LENGTH (256 octets) ; au-delà il faut une PORT_VIEW partagée échangée au connect.

Usage courant par les malwares

Sur Windows contemporain, l'usage pratique de NtRequestWaitReplyPort par les malwares est essentiellement *historique* : les rootkits user-mode pré-Vista et les premiers droppers IPC-aware l'utilisaient comme C2 furtif intra-host entre un loader et un payload injecté car aucun wrapper Win32 n'existait et le trafic ne touchait jamais la pile réseau. Les attaquants modernes préfèrent largement ALPC, les named pipes ou les sections partagées — toute observation de trafic LPC brut request/reply est donc en soi anormale et mérite enquête.

Opportunités de détection

Pas de provider ETW dédié au LPC historique équivalent à `Microsoft-Windows-Kernel-ALPC`. Les EDR kernel peuvent hooker le syscall directement ; les EDR user-mode hookent `ntdll!NtRequestWaitReplyPort`. Comme la baseline d'appelants légitimes sur Windows 10/11 est quasi nulle (presque rien dans l'OS n'utilise plus de LPC brut pour RPC), *tout* hit depuis un processus non signé ou sandboxé est à fort signal. La vue de ports par processus de SystemInformer affiche les handles LPC distinctement des handles ALPC.

Exemples de syscalls directs

; Direct syscall stub for NtRequestWaitReplyPort (SSN 0x22, stable Win10 1507+)
NtRequestWaitReplyPort PROC
    mov  r10, rcx          ; PortHandle
    mov  eax, 22h          ; SSN
    syscall
    ret
NtRequestWaitReplyPort ENDP

// Send a request and wait for the reply on a connected LPC port.
#include <windows.h>
#include <winternl.h>

#define PORT_MAXIMUM_MESSAGE_LENGTH 256

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

NTSTATUS LpcCall(HANDLE hPort, void *reqBuf, void *replyBuf) {
    pNtRequestWaitReplyPort fn = (pNtRequestWaitReplyPort)GetProcAddress(
        GetModuleHandleA("ntdll.dll"), "NtRequestWaitReplyPort");
    return fn(hPort, reqBuf, replyBuf);
}

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

unsafe fn lpc_call(port: HANDLE, req: *mut u8, reply: *mut u8) -> NTSTATUS {
    NtRequestWaitReplyPort(port, req as *mut _, reply as *mut _)
}

Mappings MITRE ATT&CK

• T1559Inter-Process Communicationmitre ↗
• T1106Native APImitre ↗