NtAlpcRevokeSecurityContext

Prototyp

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

Argumente

Syscall-IDs pro Windows-Version

Syscall-Stub

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

Undokumentierte Hinweise

`NtAlpcRevokeSecurityContext` ist die **Soft-Disable** zum **Destruktor** `NtAlpcDeleteSecurityContext`. Es kippt ein Flag im Context-Eintrag, sodass jede nachfolgende `NtAlpcImpersonateClientOfPort`-Referenz mit `STATUS_ALPC_HANDLE_REVOKED` scheitert; der Eintrag bleibt jedoch bis zur natürlichen Löschung gültig. Zwei Gründe, weshalb ein Server Revoke statt Delete bevorzugen würde: (1) dasselbe Handle wird noch von in-flight `PORT_MESSAGE`s referenziert und ein Delete würde racen; (2) der Server möchte loggen, welche Nachrichten das nun ungültige Token zu nutzen versuchten. Der Kernel setzt `AlpcSecurityContext->Revoked` und lässt den Ref-Count natürlich auf null fallen, woraufhin die zugrundeliegende Token-Referenz freigegeben wird.

Häufige Malware-Nutzung

Fast kein offensives Interesse — *weniger* mächtig als `NtAlpcDeleteSecurityContext` (kein UAF-Risiko, keine sofortige Freigabe). Ein Red-Team-Operator, der einen privilegierten ALPC-Server kompromittiert hat, könnte einen bestehenden Kontext revozieren, um einem spezifischen Client (etwa einem lauten EDR-Agenten) den Dienst zu **verweigern**, ohne die ganze Verbindung zu kappen — chirurgische Degradation statt Teardown. Ansonsten wird der Syscall nur im Rahmen des normalen RPC-Server-Cleanups aufgerufen.

Erkennungs­möglichkeiten

Funktional unsichtbar für Verteidiger — die Revokation hat keinen extern beobachtbaren Effekt, außer dass eine nachfolgende Impersonation mit `STATUS_ALPC_HANDLE_REVOKED` fehlschlägt, was beim Shutdown normal ist. Anomalien wie bei `NtAlpcDeleteSecurityContext` behandeln: das **Muster** anschauen (häufige Revoke-then-Create-Zyklen am selben Port deuten auf einen Fuzzer oder TOCTOU-Prober), nicht den Syscall selbst. Der Microsoft-Windows-Kernel-ALPC-ETW-Provider zeichnet den Call auf, wenn aktiv.

Direkte Syscall-Beispiele

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

MITRE ATT&CK-Mappings

• T1559Inter-Process Communicationmitre ↗
• T1106Native APImitre ↗