NtAcceptConnectPort

Prototype

NTSTATUS NtAcceptConnectPort(
  PHANDLE            PortHandle,
  PVOID              PortContext,
  PPORT_MESSAGE      ConnectionRequest,
  BOOLEAN            AcceptConnection,
  PPORT_VIEW         ServerView,
  PREMOTE_PORT_VIEW  ClientView
);

Arguments

Syscall IDs by Windows version

Syscall stub

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

NtAcceptConnectPort is the server half of the legacy **LPC** (Local Procedure Call) handshake — the pre-Vista predecessor of ALPC. It is still present in ntoskrnl.exe for backward compatibility and is still reachable from user mode, but virtually all modern RPC traffic now flows over ALPC (`NtAlpc*`). The SSN has been frozen at `0x2` since the introduction of the table, which itself is an artifact of LPC's age. The companion calls are NtCreatePort (server), NtListenPort, NtReplyWaitReceivePort, NtCompleteConnectPort, and NtConnectPort (client).

Common malware usage

Direct abuse of LPC by modern malware is rare; the surface has been largely supplanted by ALPC and named pipes. Historically (Windows XP / 2003 era) LPC was occasionally used by user-mode rootkits as an intra-process or intra-host C2 channel between cooperating components because no Win32 API existed and traffic was invisible to network monitors. Today the relevance is mostly *historical and educational* — knowing the legacy interface helps red teamers recognize it in old codebases and helps defenders avoid blind spots on long-tail Windows installs where the LPC tables are still wired up.

Detection opportunities

There is no dedicated ETW provider for legacy LPC the way `Microsoft-Windows-Kernel-ALPC` exists for ALPC; the most reliable signal is the *absence* of legitimate callers — almost no in-box Windows component uses raw LPC on Windows 10/11. EDRs that hook the syscall table in the kernel can flag any user-mode process calling NtAcceptConnectPort outside of a handful of legacy components (a few CSRSS / SMSS paths still touch it). Forensically, SystemInformer's port enumeration shows LPC ports alongside ALPC ports — unexpected named LPC ports in `\RPC Control\` or `\BaseNamedObjects\` warrant investigation.

Direct syscall examples

; Direct syscall stub for NtAcceptConnectPort (SSN 0x2, stable since Win10 1507)
NtAcceptConnectPort PROC
    mov  r10, rcx          ; PortHandle
    mov  eax, 02h          ; SSN
    syscall
    ret
NtAcceptConnectPort ENDP

// Educational LPC server skeleton — modern code should use ALPC instead.
#include <windows.h>
#include <winternl.h>

typedef NTSTATUS (NTAPI *pNtAcceptConnectPort)(
    PHANDLE, PVOID, PVOID /*PPORT_MESSAGE*/, BOOLEAN, PVOID, PVOID);

NTSTATUS AcceptOrReject(PVOID connReq, BOOL allow) {
    HANDLE hComm = NULL;
    pNtAcceptConnectPort fn = (pNtAcceptConnectPort)GetProcAddress(
        GetModuleHandleA("ntdll.dll"), "NtAcceptConnectPort");
    // PortContext = NULL, no shared views
    return fn(&hComm, NULL, connReq, allow ? TRUE : FALSE, NULL, NULL);
}

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

unsafe fn accept(req: *mut u8) -> Result<HANDLE, NTSTATUS> {
    let mut h: HANDLE = std::ptr::null_mut();
    let s = NtAcceptConnectPort(
        &mut h,
        std::ptr::null_mut(),
        req as *mut _,
        1 as BOOLEAN,
        std::ptr::null_mut(),
        std::ptr::null_mut(),
    );
    if s == 0 { Ok(h) } else { Err(s) }
}

MITRE ATT&CK mappings

• T1559Inter-Process Communicationmitre ↗
• T1106Native APImitre ↗