Patchguard: Detection of Hypervisor Based Instrospection [P2]

The LSTAR MSR can be intercepted using a hypervisor to trap on reads and writes. It is the most common and efficient way to hook syscalls in most modern x86 operating systems. However contrary to what I’ve read online, this unfortunately comes at the cost of many potential detection vectors for the hypervisor if not properly dealt with. Using a few clever tricks in privileged code, we can reliably determine if a hook on the LSTAR MSR is present or not, that is, if proper precautions have not already been implemented in the hypervisor. Starting in Windows 10 1903 build 18362, Microsoft added several LSTAR hook detection techniques.

One of the simpler LSTAR hook detections was not given the meme “errata” name, perhaps it was not good enough – so let’s call it KiErrata420Present (possibly not that far off from what Microsoft calls it internally?).

I have outlined the detection below:

KiErrata420Present:
        cli                             ; disable interrupts
        mov     r9d, 0C0000082h         ;
        mov     ecx, r9d                ;
        rdmsr                           ; read LSTAR MSR value
        shl     rdx, 32                 ;
        or      rax, rdx                ; store LSTAR value in rax
        lea     rdx, [rdi+87Ah]         ; store temp LSTAR value in rdx read from pg context
        mov     rbx, rax                ; rbx = original LSTAR value
        mov     rax, rdx                ; rax = temp LSTAR value
        shr     rdx, 32                 ;
        wrmsr                           ; write temporary LSTAR MSR value
        mov     r14d, 20000h            ;
        lea     rax, [rdi+87Ch]         ; rax = stub to execute syscall
        mov     rsi, 0A3A03F5891C8B4E8h ; rsi = constant to obfuscate pg context pointer
        test    [rdi+994h], r14d        ; test if should store pg check data?
        jnz     short trigger_syscall   ; if nz, skip tracing

        mov     r8, gs:KPCR.CurrentPrcb ;
        lea     rdx, [rdi+rsi]          ;
        mov     rcx, [rdi+4C0h]         ;
        mov     [rcx], rdx              ;
        mov     rcx, [rdi+4C8h]         ; store pg check related data
        mov     [rcx], r8               ;
        mov     rcx, [rdi+4D0h]         ;
        mov     [rcx], r9               ;
        mov     rcx, [rdi+4D8h]         ;
        mov     qword ptr [rcx], 112h   ;

trigger_syscall:
        call    KeGuardDispatchICall    ; dispatch call to syscall instruction stub

        test    [rdi+994h], r14d        ; test if pg check should be traced?
        jnz     short restore_lstar     ; if nz, skip tracing

        mov     rax, [rdi+4C0h]         ;
        mov     [rax], rsi              ;
        mov     rax, [rdi+4C8h]         ;
        mov     [rax], r13              ; wipe pg check related data
        mov     rax, [rdi+4D0h]         ;
        mov     [rax], r13              ;
        mov     rax, [rdi+4D8h]         ;
        mov     [rax], r13              ;

restore_lstar:
        mov     rdx, rbx                ; restore original LSTAR value
        mov     rax, rbx                ;
        shr     rdx, 32                 ;
        mov     ecx, 0C0000082h         ;
        wrmsr                           ; write original LSTAR MSR value
        sti                             ; reenable interrupts

This check is indeed very simple. It temporarily overwrites the system’s LSTAR MSR value with its own temporary syscall handler, and restores the original LSTAR MSR value afterwards. How do I know this for sure? Let’s dig in further to find out.

First off let’s figure out what temporary value is written to the LSTAR MSR:

lea     rdx, [rdi+87Ah]         ; store temp LSTAR value in rdx read from pg context
mov     rbx, rax                ; rbx = original LSTAR value
mov     rax, rdx                ; rax = temp LSTAR value
shr     rdx, 32                 ;

As we can see the temporary LSTAR value written is the address at RDI+0x87A . Knowing a little about the patchguard callback we know that the RDI register holds a temporary addresses of the current “patchguard context”. Using this knowledge, we can easily determine where the context+0x87A is written to in the patchguard initialization routine:

mov     byte ptr [r14+87Ah], 0C3h ; store RET instruction