NtAlpcAcceptConnectPort

Prototipo

NTSTATUS NtAlpcAcceptConnectPort(
  PHANDLE                  PortHandle,
  HANDLE                   ConnectionPortHandle,
  ULONG                    Flags,
  POBJECT_ATTRIBUTES       ObjectAttributes,
  PALPC_PORT_ATTRIBUTES    PortAttributes,
  PVOID                    PortContext,
  PPORT_MESSAGE            ConnectionRequest,
  PALPC_MESSAGE_ATTRIBUTES ConnectionMessageAttributes,
  BOOLEAN                  AcceptConnection
);

Argumentos

IDs de syscalls por versión de Windows

Stub del syscall

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

Notas no documentadas

`NtAlpcAcceptConnectPort` es la contraparte exacta de `NtAlpcConnectPort`: el lado servidor del handshake de tres pasos de ALPC. El patrón canónico es `NtAlpcCreatePort` (bind/listen) → `NtAlpcSendWaitReceivePort` (recv `LPC_CONNECTION_REQUEST`) → `NtAlpcAcceptConnectPort` (accept o reject). Un accept exitoso devuelve un puerto de comunicación por cliente; el tráfico posterior pasa por ese handle, no por el puerto de conexión. Todo servicio RPC de Windows que expone un endpoint `ncalrpc` ejecuta este bucle, casi siempre vía el wrapper `RPCRT4!RpcServerListen` en lugar de invocar la rutina Nt directamente. No hay superficie Win32 pública.

Uso común por malware

Por sí solo, llamar a `NtAlpcAcceptConnectPort` desde malware es inusual — implica que el malware *hospeda* él mismo un endpoint servidor ALPC para coordinar otros componentes (loader ↔ DLL inyectada ↔ servicio de persistencia). Algunos implantes modulares de larga duración hacen exactamente esto porque ALPC es invisible a la telemetría de red de Sysmon y sobrevive incluso sin red de salida. Más comúnmente, el syscall es interesante en sentido *inverso*: las cadenas de exploit ALPC LPE (CVE-2018-8440 Task Scheduler, varios bugs de Print Spooler) terminan engañando al bucle de accept de un servidor *privilegiado* con un `PORT_MESSAGE` LPC_CONNECTION_REQUEST forjado — el bug está en quien llama a `NtAlpcAcceptConnectPort`, no en el syscall.

Oportunidades de detección

Detección asimétrica: dominado por todos los servicios legítimos del equipo. La señal reside en *qué* proceso lo invoca. Ejecutar `handle.exe -a -p <pid>` (o equivalente) sobre un binario no-servicio / no-Microsoft y encontrar un endpoint servidor `ALPC Port \RPC Control\…` es anómalo. El ETW `Microsoft-Windows-Kernel-ALPC` expone eventos accept por puerto pero rara vez está activo a escala. La pestaña ALPC de SystemInformer enumera puertos servidor por proceso — herramienta más útil en post-incidente.

Ejemplos de syscalls directos

; Direct syscall stub for NtAlpcAcceptConnectPort (SSN 0x79 on Win11 24H2)
NtAlpcAcceptConnectPort PROC
    mov  r10, rcx          ; PortHandle
    mov  eax, 79h          ; SSN — drifts per build
    syscall
    ret
NtAlpcAcceptConnectPort ENDP

// Skeleton of the canonical create → recv-connreq → accept loop.
#include <windows.h>
#include <winternl.h>

typedef NTSTATUS (NTAPI *pNtAlpcAcceptConnectPort)(
    PHANDLE, HANDLE, ULONG, POBJECT_ATTRIBUTES, PVOID,
    PVOID, PPORT_MESSAGE, PVOID, BOOLEAN);

static pNtAlpcAcceptConnectPort g_accept;

NTSTATUS HandleConnReq(HANDLE hConnectionPort,
                       PPORT_MESSAGE pConnReq) {
    HANDLE hClient = NULL;
    // Per-client context — survives across receives.
    PVOID ctx = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 64);
    NTSTATUS st = g_accept(&hClient, hConnectionPort, 0,
                           NULL, NULL, ctx, pConnReq, NULL,
                           TRUE /* accept */);
    // hClient is now the per-client comm port — pump it with
    // NtAlpcSendWaitReceivePort in a worker thread.
    return st;
}

Mapeos MITRE ATT&CK

• T1559Inter-Process Communicationmitre ↗
• T1106Native APImitre ↗