NtAlpcRevokeSecurityContext

Prototype

NTSTATUS NtAlpcRevokeSecurityContext(
  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 8D 00 00 00      mov eax, 0x8D
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

`NtAlpcRevokeSecurityContext` est le **désactivement doux** face au **destructeur** `NtAlpcDeleteSecurityContext`. Il bascule un flag sur l'entrée de contexte pour que tout `NtAlpcImpersonateClientOfPort` ultérieur le référençant échoue avec `STATUS_ALPC_HANDLE_REVOKED`, mais l'entrée reste valide jusqu'à la suppression naturelle. Deux raisons pour qu'un serveur préfère la révocation à la suppression : (1) le même handle est encore référencé par des `PORT_MESSAGE` en vol et un delete provoquerait une race ; (2) le serveur veut journaliser quels messages ont tenté d'utiliser le token désormais invalide. Le noyau positionne `AlpcSecurityContext->Revoked` et laisse le ref-count descendre naturellement à zéro, point auquel la référence token sous-jacente est libérée.

Usage courant par les malwares

Quasi aucun intérêt offensif — c'est *moins* puissant que `NtAlpcDeleteSecurityContext` (pas de risque UAF, pas de libération immédiate). Un opérateur red-team qui a compromis un serveur ALPC privilégié pourrait révoquer un contexte existant pour **dénier le service** à un client spécifique (un agent EDR bruyant, par exemple) sans casser toute la connexion — dégradation chirurgicale plutôt que tear-down. Sinon, le syscall n'est invoqué que dans le cadre du cleanup serveur RPC normal.

Opportunités de détection

Fonctionnellement invisible aux défenseurs — la révocation n'a aucun effet externe observable, sauf qu'une impersonation ultérieure échoue avec `STATUS_ALPC_HANDLE_REVOKED`, normal en shutdown. Traiter les anomalies comme pour `NtAlpcDeleteSecurityContext` : regarder le **pattern** (cycles fréquents revoke-puis-create sur le même port suggèrent un fuzzer ou un sondage TOCTOU), pas le syscall lui-même. Le provider ETW Microsoft-Windows-Kernel-ALPC enregistre l'appel s'il est activé.

Exemples de syscalls directs

// Mark a cached client context as revoked without disturbing in-flight messages.
// Later, NtAlpcDeleteSecurityContext finishes the job when the ref-count is zero.
#include <windows.h>
#include <winternl.h>

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

void SoftRevoke(HANDLE serverPort, ALPC_HANDLE ctx) {
    // After this call, NtAlpcImpersonateClientOfPort referencing ctx returns
    // STATUS_ALPC_HANDLE_REVOKED instead of impersonating.
    NtAlpcRevokeSecurityContext(serverPort, 0, ctx);
}

; Direct syscall stub for NtAlpcRevokeSecurityContext (SSN 0x8D on Win11 24H2 / Server 2025)
NtAlpcRevokeSecurityContext PROC
    mov  r10, rcx          ; PortHandle
    mov  eax, 8Dh          ; SSN
    syscall
    ret
NtAlpcRevokeSecurityContext ENDP

Mappings MITRE ATT&CK

• T1559Inter-Process Communicationmitre ↗
• T1106Native APImitre ↗