NtAlpcAcceptConnectPort

Prototype

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

Arguments

IDs de syscalls par version de Windows

Stub du 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

Notes non documentées

`NtAlpcAcceptConnectPort` est le pendant exact de `NtAlpcConnectPort` : le côté serveur du handshake à trois temps ALPC. Le pattern canonique est `NtAlpcCreatePort` (bind/listen) → `NtAlpcSendWaitReceivePort` (recv `LPC_CONNECTION_REQUEST`) → `NtAlpcAcceptConnectPort` (accept ou reject). Un accept réussi renvoie un port de communication par client ; le trafic de messages ultérieur passe par ce handle, pas par le port de connexion. Tout service RPC Windows exposant un endpoint `ncalrpc` exécute cette boucle, presque toujours via le wrapper `RPCRT4!RpcServerListen` plutôt qu'en appelant la routine Nt directement. Aucune surface Win32 publique.

Usage courant par les malwares

En soi, appeler `NtAlpcAcceptConnectPort` depuis un malware est inhabituel — cela implique que le malware héberge *lui-même* un endpoint serveur ALPC pour coordonner d'autres composants (loader ↔ DLL injectée ↔ service de persistance). Certains implants modulaires longue durée font exactement cela, ALPC étant invisible à la télémétrie réseau Sysmon et survivant même sans réseau sortant. Plus souvent, le syscall est intéressant en sens *inverse* : les chaînes d'exploits ALPC LPE (CVE-2018-8440 Task Scheduler, multiples bugs Print Spooler) finissent par tromper la boucle d'accept d'un serveur *privilégié* via un `PORT_MESSAGE` LPC_CONNECTION_REQUEST forgé — le bug est dans l'appelant de `NtAlpcAcceptConnectPort`, pas dans le syscall.

Opportunités de détection

Détection asymétrique : ce syscall est dominé par chaque service légitime de la machine. Le signal réside dans *quel* processus l'appelle. Lancer `handle.exe -a -p <pid>` (ou équivalent) sur un binaire non service / non Microsoft et y trouver un endpoint serveur `ALPC Port \RPC Control\…` est anormal. ETW `Microsoft-Windows-Kernel-ALPC` expose des événements d'accept par port mais est rarement actif à grande échelle. L'onglet ALPC de SystemInformer énumère les ports serveur par processus — outil le plus utile en post-incident.

Exemples de syscalls directs

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

Mappings MITRE ATT&CK

• T1559Inter-Process Communicationmitre ↗
• T1106Native APImitre ↗