NtAcceptConnectPort

Prototyp

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

Argumente

Syscall-IDs pro 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

Undokumentierte Hinweise

NtAcceptConnectPort ist die Server-Hälfte des Legacy-**LPC**-Handshakes (Local Procedure Call) — der Pre-Vista-Vorläufer von ALPC. Er existiert weiterhin in ntoskrnl.exe aus Kompatibilitätsgründen und ist aus dem User-Mode aufrufbar, doch praktisch der gesamte moderne RPC-Verkehr läuft inzwischen über ALPC (`NtAlpc*`). Die SSN ist seit Einführung der Tabelle bei `0x2` eingefroren — ein Relikt aus LPC-Zeiten. Verwandte Aufrufe sind NtCreatePort (Server), NtListenPort, NtReplyWaitReceivePort, NtCompleteConnectPort und NtConnectPort (Client).

Häufige Malware-Nutzung

Direkter Missbrauch von LPC durch moderne Malware ist selten; die Fläche wurde weitgehend von ALPC und Named Pipes verdrängt. Historisch (XP / 2003-Ära) wurde LPC gelegentlich von User-Mode-Rootkits als Intra-Process- oder Intra-Host-C2-Kanal zwischen kooperierenden Komponenten genutzt, weil keine Win32-API existierte und der Verkehr für Netzwerk-Monitore unsichtbar war. Heute ist die Relevanz vor allem *historisch und didaktisch* — Kenntnis der Legacy-Schnittstelle hilft Red Teamern, sie in alten Codebasen zu erkennen, und Verteidigern, blinde Flecken auf Long-Tail-Windows-Installationen zu vermeiden, auf denen die LPC-Tabellen noch verdrahtet sind.

Erkennungs­möglichkeiten

Es gibt keinen dedizierten ETW-Provider für Legacy-LPC, wie ihn `Microsoft-Windows-Kernel-ALPC` für ALPC bietet; das verlässlichste Signal ist die *Abwesenheit* legitimer Caller — kaum eine In-Box-Komponente von Windows 10/11 verwendet rohes LPC. EDRs, die die Syscall-Tabelle im Kernel hooken, können jeden User-Mode-Prozess flaggen, der NtAcceptConnectPort außerhalb einer Handvoll Legacy-Komponenten aufruft (einige CSRSS- / SMSS-Pfade berühren ihn noch). Forensisch listet SystemInformers Port-Enumeration LPC-Ports neben ALPC-Ports — unerwartete benannte LPC-Ports in `\RPC Control\` oder `\BaseNamedObjects\` sind ermittlungswürdig.

Direkte Syscall-Beispiele

; 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 ↗