NtCompareSigningLevels

Prototype

NTSTATUS NtCompareSigningLevels(
  SE_SIGNING_LEVEL FirstSigningLevel,
  SE_SIGNING_LEVEL SecondSigningLevel
);

Arguments

Syscall IDs by Windows version

Syscall stub

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

A pure comparison helper exposed as a syscall purely so Code Integrity's ordering policy lives in *one* place — the kernel — rather than being re-implemented in every user-mode component that needs it. Returns `STATUS_SUCCESS` (0) when `FirstSigningLevel` is greater than or equal to `SecondSigningLevel` in CI's lattice, and `STATUS_NOT_FOUND` (0xC0000225) otherwise. Importantly, the ordering is *not* numerical: although the constants happen to be monotonic (`0 < 4 < 6 < 8 < 12 < 14`), the kernel routes through `CiCompareSigningLevels` in `ci.dll`, which applies policy-defined equivalence (for example `SE_SIGNING_LEVEL_STORE` and `SE_SIGNING_LEVEL_ANTIMALWARE` may be treated as equivalent under specific WHQL policy flags). Hence the syscall — to centralise that policy. Introduced in Windows 10 1703 alongside the rest of the modern Code-Integrity API surface; not present on Windows 10 1507 / 1607.

Common malware usage

Almost zero offensive value. It is a *pure* function (no side effects, no privileges, no resource access) that takes two integers and returns a status — there is nothing to abuse. The only real-world reason an attacker would call it is bookkeeping: red-team loaders that have constructed a CIG-bypass primitive may call it to double-check that the level they have forged dominates the level the target requires, before committing to the injection. Otherwise no malware family is documented as using it, and EDRs ignore it.

Detection opportunities

Not a meaningful detection point. The function has no observable side effect, ETW does not log per-call events for it, and the volume from legitimate `ci.dll` self-use is high enough that ratio-based hunting is impractical. Detection effort is better spent on its *callers* — anyone calling `NtCompareSigningLevels` from outside `ci.dll`, `wldp.dll`, `lsass.exe`, and a handful of Defender components is unusual but not necessarily malicious. If you have user-mode syscall telemetry, joining `NtCompareSigningLevels` calls with adjacent `NtSetCachedSigningLevel` / `NtGetCachedSigningLevel` calls from the same thread is a much stronger signal than this call in isolation.

Direct syscall examples

// Used internally by ci.dll and by some EDRs to short-circuit policy decisions.
// Returns STATUS_SUCCESS if `have` dominates `need`, STATUS_NOT_FOUND otherwise.
#include <windows.h>
#include <winternl.h>

typedef NTSTATUS (NTAPI* pNtCompareSigningLevels)(UCHAR, UCHAR);

BOOL satisfies(UCHAR have, UCHAR need) {
    pNtCompareSigningLevels f = (pNtCompareSigningLevels)GetProcAddress(
        GetModuleHandleA("ntdll.dll"), "NtCompareSigningLevels");
    return NT_SUCCESS(f(have, need));
}

// Example: do we meet ProcessSignaturePolicy.MicrosoftSignedOnly = 1?
// satisfies(SE_SIGNING_LEVEL_MICROSOFT, SE_SIGNING_LEVEL_MICROSOFT) == TRUE
// satisfies(SE_SIGNING_LEVEL_AUTHENTICODE, SE_SIGNING_LEVEL_MICROSOFT) == FALSE

NtCompareSigningLevels PROC
    mov  r10, rcx
    mov  eax, 0A0h
    syscall
    ret
NtCompareSigningLevels ENDP

MITRE ATT&CK mappings

• T1106Native APImitre ↗
• T1553Subvert Trust Controlsmitre ↗