NtAlpcDeleteSecurityContext

Prototype

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

Arguments

IDs de syscalls par version de Windows

Stub du syscall

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

Notes non documentées

ALPC supporte un modèle `SECURITY_QUALITY_OF_SERVICE` *en cache* : un client (ou serveur) appelle `NtAlpcCreateSecurityContext` une fois pour matérialiser un contexte QoS avec un token client figé, puis référence ce contexte par `ALPC_HANDLE` dans les `NtAlpcImpersonateClientOfPort` ultérieurs plutôt que de re-snapshoter le token à chaque fois. `NtAlpcDeleteSecurityContext` libère le contexte de façon permanente — le token snapshot est déréférencé, le slot de la table de contextes par-port est libéré, et toute impersonation en vol référençant le contexte commence à recevoir `STATUS_INVALID_HANDLE`. À coupler avec `NtAlpcRevokeSecurityContext`, qui garde l'entrée mais l'invalide ; la suppression est le destructeur.

Usage courant par les malwares

Primitive de ménage défensif — intérêt offensif limité. Le seul abus réaliste est un **use-after-free de race** où un attaquant force un serveur à supprimer un contexte de sécurité pendant qu'un autre thread sur le même port est en pleine impersonation. Le noyau ref-compte l'objet QoS sous-jacent, donc un UAF propre est dur à construire, mais quelques bugs historiques de port ALPC (`AlpcpCleanupPort`, env. 2017-2019) impliquaient un ordonnancement incorrect entre `NtAlpcDeleteSecurityContext` et send/receive concurrents — corrigés dans les cumulatives. Offensivement, l'appel peut aussi servir aux fuzzers ALPC pour vérifier que l'état par-contexte d'un serveur est bien démonté (détecteur de fuite).

Opportunités de détection

Pas un signal de détection utile pris isolément — tout serveur ALPC longue durée (RPCSS, LSASS, spoolsv, sihost) l'appelle de routine au gré des connexions. Le seul signal valable est un *ordre anormal* : suppression peu avant un crash serveur, ou suppression précédée d'une rafale inhabituelle de `NtAlpcImpersonateClientOfPort` contre le même handle de contexte — les deux suggèrent qu'on tâte un TOCTOU. Se concentrer sur la corrélation de cycle de vie en ETW plutôt que sur ce syscall directement.

Exemples de syscalls directs

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

Mappings MITRE ATT&CK

• T1559Inter-Process Communicationmitre ↗
• T1106Native APImitre ↗