NtAlpcDeleteSecurityContext

Prototype

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

Arguments

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

Undocumented notes

ALPC supports a *cached* `SECURITY_QUALITY_OF_SERVICE` model: a client (or server) calls `NtAlpcCreateSecurityContext` once to materialise a QoS context with a frozen client token, then references that context by `ALPC_HANDLE` in subsequent `NtAlpcImpersonateClientOfPort` calls instead of re-snapshotting the token every time. `NtAlpcDeleteSecurityContext` releases the context permanently — the snapshot token is dereferenced, the per-port context table slot is freed, and any in-flight impersonation referencing the context will start receiving `STATUS_INVALID_HANDLE`. This is paired with `NtAlpcRevokeSecurityContext`, which keeps the context entry but invalidates it; deletion is the destructor.

Common malware usage

Defensive housekeeping primitive — limited offensive interest. The only realistic abuse is a **race-condition use-after-free** where an attacker forces a server to delete a security context while another thread on the same port is mid-impersonation. The kernel ref-counts the underlying QoS object, so a clean UAF is hard to construct, but a few historic ALPC port bugs (`AlpcpCleanupPort`, ca. 2017-2019) involved improper ordering between `NtAlpcDeleteSecurityContext` and concurrent send/receive — fixed in cumulative updates. Offensively, the call may also be used by ALPC fuzzers to verify that a server's per-context state is properly torn down (a leak detector).

Detection opportunities

Not a useful detection signal in isolation — every long-lived ALPC server (RPCSS, LSASS, spoolsv, sihost) calls it routinely as connections come and go. The only worthwhile signal is *anomalous order*: deletion followed shortly by a server crash, or deletion preceded by an unusual burst of `NtAlpcImpersonateClientOfPort` against the same context handle — both suggest someone is poking at a TOCTOU. Defenders should focus on the lifetime correlation in ETW rather than on this syscall directly.

Direct syscall examples

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