Returning to usermode shellcode from windows kernel (Win10)

Question

I have written a kernel exploit (for the latest Win10 64bit) that executes (or returns to from the kernel) token stealing shellcode, which is placed in the VirtulAlloc'ed memory in the userland.

The problem is, when the exploit is executed by admin user, it works fine but if it is executed by the normal user (medium integrity), it crashes with ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY (fc).

When I check the permission of the usermode shellcode memory,

(standard user)

PXE at FFFF8542A150A010    PPE at FFFF8542A1402DF0    PDE at FFFF8542805BECA0    PTE at FFFF8500B7D94400
contains 8A000000269B1867  contains 0A0000001C4F2867  contains 0A0000002673C867  contains 0000000032E84025
pfn 269b1     ---DA--UW-V  pfn 1c4f2     ---DA--UWEV  pfn 2673c     ---DA--UWEV  pfn 32e84     ----A--UREV

while in admin

PXE at FFFF8944A2512028    PPE at FFFF8944A2405E48    PDE at FFFF894480BC9F28    PTE at FFFF8901793E5800
contains 0A000000060BD867  contains 0A0000003593E867  contains 0A0000000FBAB867  contains 000000001DFF4825
pfn 60bd      ---DA--UWEV  pfn 3593e     ---DA--UWEV  pfn fbab      ---DA--UWEV  pfn 1dff4     ----A--UREV

The difference is at the PXE level, there is no E bit set for standard user while admin user has execution permission on the usermode shellcode.

I tried implementing the shellcode as a function of the exploit(.exe) so it is placed in code segment (which it will probably have execution privilege), but it is same (No E set in PXE level) and crashes although !vad command outputs EXECUTE_WRITECOPY.

I have checked that ProcessMitigationPolicy's ProhibitDynamicCode is set to 0, so I don't think this is the problem.

How do you guys execute shellcode when writing kernel exploit these days? (FYI I have disabled SMEP, SMAP via Kernel ROP).

Thanks in advance!

Answer 1

What I found out until now is that according to the Intel manual, even though SMEP bit is 0, if any entry in the process of going through page tables have execute disable bit set, it won't execute. This is the case when allocating RWX memory from standard user (medium IL).

I didn't figure out whether this is a problem of my testing environment or some kind of mitigation, but manage to finish writing the exploit by mapping executable memory in the kernel and copy the shellcode there.