NtConnectPort

Prototype

NTSTATUS NtConnectPort(
  PHANDLE                       PortHandle,
  PUNICODE_STRING               PortName,
  PSECURITY_QUALITY_OF_SERVICE  SecurityQos,
  PPORT_VIEW                    ClientView,
  PREMOTE_PORT_VIEW             ServerView,
  PULONG                        MaxMessageLength,
  PVOID                         ConnectionInformation,
  PULONG                        ConnectionInformationLength
);

Arguments

Syscall IDs by Windows version

Syscall stub

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

NtConnectPort is the client-side counterpart of NtAcceptConnectPort and the legacy (pre-Vista) sibling of NtAlpcConnectPort. The 8-argument shape is documented by phnt and the Windows Internals book; the kernel implementation lives in `LpcpConnectPort` inside ntoskrnl.exe. Although ALPC superseded LPC functionally on Vista+, the LPC dispatch path was never removed — these SSNs are still wired and still resolve to working code on Windows 11 24H2. Note the SSN drifts across builds (unlike NtAcceptConnectPort), so direct-syscall stubs must resolve dynamically.

Common malware usage

Modern malware rarely picks LPC over ALPC or named pipes, but the surface remains a viable IPC primitive for components that want to avoid the better-instrumented ALPC paths. Historically (XP / 2003 era) some user-mode rootkit families used LPC for inter-module communication between a loader and an injected payload, since no Win32 wrapper existed and traffic stayed entirely in-kernel. Today the practical relevance is mostly *historical and educational*; treat any user-mode caller as suspicious because nearly nothing legitimately uses raw LPC on contemporary Windows.

Detection opportunities

There is no `Microsoft-Windows-Kernel-LPC` ETW provider analogous to the ALPC one; defenders rely on syscall-table hooks (kernel-mode EDR) or user-mode hooks on `ntdll!NtConnectPort`. The base-rate is so low on Windows 10/11 that *any* hit on NtConnectPort from a non-system process is worth alerting on. SystemInformer enumerates both LPC and ALPC ports per process — unexpected LPC port handles in a sandboxed app or in an unsigned binary are a high-confidence indicator. PORT_VIEW shared sections also create VAD entries that survive the connection.

Direct syscall examples

; Direct syscall stub for NtConnectPort (SSN 0xA4 on Win11 24H2 — drifts per build)
NtConnectPort PROC
    mov  r10, rcx          ; PortHandle
    mov  eax, 0A4h         ; SSN
    syscall
    ret
NtConnectPort ENDP

// Connect to a legacy LPC server port; minimal connect message, no shared view.
#include <windows.h>
#include <winternl.h>

typedef NTSTATUS (NTAPI *pNtConnectPort)(
    PHANDLE, PUNICODE_STRING, PVOID /*PSECURITY_QOS*/,
    PVOID, PVOID, PULONG, PVOID, PULONG);

HANDLE LpcConnect(LPCWSTR name) {
    UNICODE_STRING us; RtlInitUnicodeString(&us, name);
    SECURITY_QUALITY_OF_SERVICE qos = {
        sizeof(qos), SecurityIdentification, SECURITY_DYNAMIC_TRACKING, FALSE
    };
    HANDLE h = NULL; ULONG maxLen = 0, cinfoLen = 0;
    pNtConnectPort fn = (pNtConnectPort)GetProcAddress(
        GetModuleHandleA("ntdll.dll"), "NtConnectPort");
    fn(&h, &us, &qos, NULL, NULL, &maxLen, NULL, &cinfoLen);
    return h;
}

// Cargo: windows-sys = "0.59"
use std::ffi::c_void;
use windows_sys::Win32::System::LibraryLoader::{GetModuleHandleA, GetProcAddress};

type NtConnectPortFn = unsafe extern "system" fn(
    *mut *mut c_void, *const c_void, *const c_void,
    *mut c_void, *mut c_void, *mut u32, *mut c_void, *mut u32,
) -> i32;

unsafe fn resolve() -> Option<NtConnectPortFn> {
    let h = GetModuleHandleA(b"ntdll.dll\0".as_ptr());
    let p = GetProcAddress(h, b"NtConnectPort\0".as_ptr())?;
    Some(std::mem::transmute(p))
}

MITRE ATT&CK mappings

• T1559Inter-Process Communicationmitre ↗
• T1106Native APImitre ↗