NtReplyPort
Sends a reply on a server-side LPC port to a previously received request, without waiting.
Prototype
NTSTATUS NtReplyPort( HANDLE PortHandle, PPORT_MESSAGE ReplyMessage );
Arguments
| Name | Type | Dir | Description |
|---|---|---|---|
| PortHandle | HANDLE | in | Handle to the server-side communication port for the client whose request is being answered. |
| ReplyMessage | PPORT_MESSAGE | in | PORT_MESSAGE whose MessageId / ClientId fields match the original request being answered. |
Syscall IDs by Windows version
| Windows version | Syscall ID | Build |
|---|---|---|
| Win10 1507 | 0xC | win10-1507 |
| Win10 1607 | 0xC | win10-1607 |
| Win10 1703 | 0xC | win10-1703 |
| Win10 1709 | 0xC | win10-1709 |
| Win10 1803 | 0xC | win10-1803 |
| Win10 1809 | 0xC | win10-1809 |
| Win10 1903 | 0xC | win10-1903 |
| Win10 1909 | 0xC | win10-1909 |
| Win10 2004 | 0xC | win10-2004 |
| Win10 20H2 | 0xC | win10-20h2 |
| Win10 21H1 | 0xC | win10-21h1 |
| Win10 21H2 | 0xC | win10-21h2 |
| Win10 22H2 | 0xC | win10-22h2 |
| Win11 21H2 | 0xC | win11-21h2 |
| Win11 22H2 | 0xC | win11-22h2 |
| Win11 23H2 | 0xC | win11-23h2 |
| Win11 24H2 | 0xC | win11-24h2 |
| Server 2016 | 0xC | winserver-2016 |
| Server 2019 | 0xC | winserver-2019 |
| Server 2022 | 0xC | winserver-2022 |
| Server 2025 | 0xC | winserver-2025 |
Kernel module
Related APIs
Syscall stub
4C 8B D1 mov r10, rcx B8 0C 00 00 00 mov eax, 0x0C 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
NtReplyPort completes the server half of a synchronous LPC exchange initiated by a client via NtRequestWaitReplyPort. The matching `MessageId` in the reply lets the kernel deliver the response to the right caller. A server normally does *not* call NtReplyPort directly inside a hot loop — it uses NtReplyWaitReceivePort, which atomically replies to the previous request and waits for the next. The SSN `0x0C` has been frozen across every Windows 10/11 build, reflecting LPC's status as a legacy, low-numbered table entry that is essentially untouched by Microsoft.
Common malware usage
Malware use of NtReplyPort specifically is *very rare* and almost always co-occurs with a custom LPC server registered via NtCreatePort. Historical interest only: pre-Vista user-mode rootkits that exposed a fake kernel port to receive commands from a co-resident component then replied through NtReplyPort. Modern offensive code overwhelmingly chooses ALPC or named pipes for this pattern.
Detection opportunities
No dedicated ETW provider for legacy LPC. The strongest signal is upstream: any non-Microsoft-signed process that holds an LPC server port (visible via SystemInformer / WinObj or a kernel ObRegisterCallbacks filter for type `Port`) and reaches NtReplyPort is highly anomalous on Windows 10/11. Correlate the calling thread's stack with a previously-observed NtCreatePort to identify the server.
Direct syscall examples
asmx64 direct stub
; Direct syscall stub for NtReplyPort (SSN 0x0C, stable Win10 1507+)
NtReplyPort PROC
mov r10, rcx ; PortHandle
mov eax, 0Ch ; SSN
syscall
ret
NtReplyPort ENDPcReply to a single LPC request
// Send a one-shot reply to an LPC request whose MessageId we've stashed.
#include <windows.h>
#include <winternl.h>
typedef NTSTATUS (NTAPI *pNtReplyPort)(HANDLE, PVOID /*PPORT_MESSAGE*/);
NTSTATUS LpcReply(HANDLE serverPort, void *replyMsg) {
pNtReplyPort fn = (pNtReplyPort)GetProcAddress(
GetModuleHandleA("ntdll.dll"), "NtReplyPort");
return fn(serverPort, replyMsg);
}MITRE ATT&CK mappings
Last verified: 2026-05-20