NtAlpcDeleteSecurityContext

Prototyp

NTSTATUS NtAlpcDeleteSecurityContext(
  HANDLE  PortHandle,
  ULONG   Flags,
  ALPC_HANDLE  ContextHandle
);

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

ALPC unterstützt ein *gecachtes* `SECURITY_QUALITY_OF_SERVICE`-Modell: ein Client (oder Server) ruft `NtAlpcCreateSecurityContext` einmal, um einen QoS-Kontext mit eingefrorenem Client-Token zu materialisieren, und referenziert diesen Kontext dann per `ALPC_HANDLE` in nachfolgenden `NtAlpcImpersonateClientOfPort`-Aufrufen, statt das Token jedes Mal neu zu snapshotten. `NtAlpcDeleteSecurityContext` gibt den Kontext dauerhaft frei — das Snapshot-Token wird dereferenziert, der Slot der per-Port-Kontext-Tabelle freigegeben, und jede laufende Impersonation, die den Kontext referenziert, beginnt `STATUS_INVALID_HANDLE` zu erhalten. Paart sich mit `NtAlpcRevokeSecurityContext`, das den Eintrag behält, aber invalidiert; Löschung ist der Destruktor.

Häufige Malware-Nutzung

Defensive Housekeeping-Primitive — begrenztes offensives Interesse. Der einzige realistische Missbrauch ist ein **Race-Use-after-Free**, bei dem ein Angreifer einen Server zwingt, einen Security-Context zu löschen, während ein anderer Thread am selben Port mitten in einer Impersonation steckt. Der Kernel ref-zählt das zugrundeliegende QoS-Objekt, sodass ein sauberer UAF schwer zu konstruieren ist, aber einige historische ALPC-Port-Bugs (`AlpcpCleanupPort`, ca. 2017-2019) hatten falsche Ordnung zwischen `NtAlpcDeleteSecurityContext` und konkurrentem Send/Receive — in Cumulative Updates gefixt. Offensiv kann der Aufruf auch von ALPC-Fuzzern genutzt werden, um zu prüfen, dass der per-Context-State eines Servers sauber abgebaut wird (Leak-Detector).

Erkennungs­möglichkeiten

Allein kein nützliches Detection-Signal — jeder langlebige ALPC-Server (RPCSS, LSASS, spoolsv, sihost) ruft ihn routinemäßig auf, wenn Verbindungen kommen und gehen. Das einzige lohnende Signal ist *anomale Ordnung*: Löschung kurz vor einem Server-Crash oder Löschung vor einem ungewöhnlichen Burst von `NtAlpcImpersonateClientOfPort` gegen dasselbe Kontext-Handle — beides deutet auf TOCTOU-Probieren. Auf Lebenszyklus-Korrelation in ETW fokussieren, nicht auf diesen Syscall direkt.

Direkte Syscall-Beispiele

// Server tears down a cached impersonation context once a client disconnects.
#include <windows.h>
#include <winternl.h>

typedef PVOID ALPC_HANDLE;
NTSTATUS NTAPI NtAlpcDeleteSecurityContext(HANDLE, ULONG, ALPC_HANDLE);

void ReleaseClientQos(HANDLE serverPort, ALPC_HANDLE ctx) {
    if (ctx) {
        NtAlpcDeleteSecurityContext(serverPort, 0, ctx);
    }
}

; Direct syscall stub for NtAlpcDeleteSecurityContext (SSN 0x85 on Win11 24H2 / Server 2025)
NtAlpcDeleteSecurityContext PROC
    mov  r10, rcx          ; PortHandle
    mov  eax, 85h          ; SSN
    syscall
    ret
NtAlpcDeleteSecurityContext ENDP

MITRE ATT&CK-Mappings

• T1559Inter-Process Communicationmitre ↗
• T1106Native APImitre ↗