NtAlpcDisconnectPort

Prototype

NTSTATUS NtAlpcDisconnectPort(
  HANDLE  PortHandle,
  ULONG   Flags
);

Arguments

Syscall IDs by Windows version

Syscall stub

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

`NtAlpcDisconnectPort` is the polite goodbye on an ALPC connection — it sends a `LPC_PORT_CLOSED` message to the server's queue and tears down the connection-port pair. `NtClose` on the same handle would *also* terminate the connection, but without the in-band notification, leaving the server to discover the dead client only when it next tries to reply. Most user-mode callers go through `NtClose` directly; explicit `NtAlpcDisconnectPort` is mainly used by the RPC runtime (`rpcrt4.dll`) when an LRPC binding is shut down with `RpcBindingFree`. Per-connection ALPC views, security contexts and message reservations are released as part of the disconnect.

Common malware usage

Low offensive interest — this is housekeeping. The one notable usage is *exploit cleanup*: ALPC LPE PoCs that abused server-side state typically call `NtAlpcDisconnectPort` (or close the handle) immediately after winning the race, so the server's view of the exchange looks normal and crash dumps don't keep the malicious connection-port object resident. The `ALPC_DISCONNECT_FLAG_NO_DISCONNECT_MESSAGE` flag can be used to deliberately starve a server of a `LPC_PORT_CLOSED` notification — useful if the server only cleans up per-connection state on receipt of that message; a fuzzer or a CVE PoC may use it to leak server-side state across runs.

Detection opportunities

Not a useful detection signal on its own. Disconnects are the dominant ALPC traffic on any active workstation. The only fruitful angle is *correlation*: a client process that issues a flurry of `NtAlpcConnectPort` … `NtAlpcSendWaitReceivePort` … `NtAlpcDisconnectPort` cycles against the same server in quick succession is a candidate for ALPC fuzzing or exploit triggering. ETW provider `Microsoft-Windows-Kernel-ALPC` (when enabled) logs disconnects; the corresponding RPC tear-down shows up in `Microsoft-Windows-RPC`.

Direct syscall examples

// Cleanly close an LRPC client port. The server receives an LPC_PORT_CLOSED message
// before the handle is freed, allowing prompt per-connection cleanup on its side.
#include <windows.h>
#include <winternl.h>

NTSTATUS NTAPI NtAlpcDisconnectPort(HANDLE, ULONG);

void CloseLrpcClient(HANDLE hPort) {
    NtAlpcDisconnectPort(hPort, 0); // 0 = send the courtesy LPC_PORT_CLOSED
    NtClose(hPort);                  // release the handle table entry
}

; Direct syscall stub for NtAlpcDisconnectPort (SSN 0x86 on Win11 24H2 / Server 2025)
NtAlpcDisconnectPort PROC
    mov  r10, rcx          ; PortHandle
    mov  eax, 86h          ; SSN
    syscall
    ret
NtAlpcDisconnectPort ENDP

MITRE ATT&CK mappings

• T1559Inter-Process Communicationmitre ↗
• T1106Native APImitre ↗