NtRevertContainerImpersonation

Prototype

NTSTATUS NtRevertContainerImpersonation(VOID);

Arguments

Syscall IDs by Windows version

Syscall stub

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

NtRevertContainerImpersonation undoes a prior container-side impersonation of the host token inside a Server Silo (also called an Argon container — the Windows 10+ kernel primitive that backs Windows Server Containers and the process-isolated mode of Docker on Windows). The reverse operation — entering the host impersonation — is performed implicitly when a silo-aware service crosses the silo boundary. There is no public Win32 wrapper; the call surface is consumed almost exclusively by the Host Compute Service (vmcompute.exe), hcsshim, and a handful of Container Manager components. The syscall takes zero arguments and operates on the calling thread's impersonation token.

Common malware usage

Very low malware signal. The syscall is only meaningful when the caller is running inside a Server Silo, which is a narrow deployment shape. There has been academic and red-team interest in container-escape research targeting hcsshim and vmcompute (notably Palo Alto Unit 42's 'Siloscape' write-up in 2021, which abused legitimate container-management APIs rather than this syscall directly), but no in-the-wild commodity malware family is known to invoke NtRevertContainerImpersonation. Document it for completeness of the silo attack surface rather than for IOC value.

Detection opportunities

Telemetry is sparse. ETW provider Microsoft-Windows-Containers-CCG and Microsoft-Windows-Hyper-V-Compute emit silo-lifecycle events but do not directly surface this syscall. From a defender's perspective the meaningful question is 'did an unexpected process inside a container manipulate its silo impersonation state?' — answerable by correlating container ID (PsGetSiloMonitorContextSlot) with parent image and command line via Defender for Containers or Sysmon ImageLoad events on vmcompute/hcs* DLLs. Kernel-mode ETW provider Microsoft-Windows-Kernel-Process surfaces token-impersonation transitions that can be filtered for silo-bound threads.

Direct syscall examples

; Direct syscall stub for NtRevertContainerImpersonation (SSN 0x18B, Win11 24H2)
NtRevertContainerImpersonation PROC
    mov  r10, rcx          ; syscall convention
    mov  eax, 18Bh         ; SSN
    syscall
    ret
NtRevertContainerImpersonation ENDP

// No Win32 wrapper exists; resolve from ntdll directly.
typedef NTSTATUS (NTAPI *PFN_NtRevertContainerImpersonation)(VOID);

HMODULE hNtdll = GetModuleHandleW(L"ntdll.dll");
PFN_NtRevertContainerImpersonation pNtRevert =
    (PFN_NtRevertContainerImpersonation)GetProcAddress(
        hNtdll, "NtRevertContainerImpersonation");

if (pNtRevert) {
    NTSTATUS s = pNtRevert();
    // STATUS_SUCCESS only when called from inside a Server Silo with
    // an active container-side host impersonation.
    if (!NT_SUCCESS(s)) {
        // STATUS_INVALID_PARAMETER outside a silo.
    }
}

MITRE ATT&CK mappings

• T1611Escape to Hostmitre ↗
• T1134Access Token Manipulationmitre ↗