bluescreen was trigged

[whitehat9090]

hello! i tested on windows 10 1903 vm, it works as follow result. [+] found low stub at phys addr 11000! [+] PML4 at 1aa000 [+] base of HAL heap at fffff788c0000000 [+] found PML4 self-ref entry 1e7 [+] found HalpInterruptController at fffff788c0000680 [+] found HalpApicRequestInterrupt at fffff80035eb3bb0 [+] built shellcode! [+] KUSER_SHARED_DATA PTE at fffff3fbc0000000 [+] KUSER_SHARED_DATA PTE NX bit cleared! [+] Wrote shellcode at fffff78000000950! [+] Press a key to execute shellcode! [+] overwrote HalpInterruptController pointer, should have execution shortly...

but bluescreen was trigged.i i debuged by using windbg.

hal!HalpApicRequestInterrupt+0xa4: fffff800`35eb3c54 4584e4 test r12b,r12b 3: kd> t KDTARGET: Refreshing KD connection

A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

For analysis of this file, run !analyze -v nt!DbgBreakPointWithStatus: fffff800`355c4580 cc int 3 0: kd> !analyze -v The debuggee is ready to run WARNING: This break is not a step/trace completion. The last command has been cleared to prevent accidental continuation of this unrelated event. Check the event, location and thread before resuming. Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

0: kd> r rax=0000000000000000 rbx=0000000000000003 rcx=0000000000000003 rdx=0000000000000000 rsi=0000000000000000 rdi=fffff80031a5b180 rip=fffff800355c4580 rsp=fffff800386813b8 rbp=fffff80038681520 r8=0000000000000000 r9=0000000000000000 r10=000001539738d27d r11=fffff80038681370 r12=0000000000000003 r13=00000000004f4454 r14=0000000000000000 r15=ffffbf0ce8ca8040 iopl=0 nv up di ng nz na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000086 nt!DbgBreakPointWithStatus:

[wanghualei2]

hello! i tested on windows 10 1903 vm, it works as follow result. [+] found low stub at phys addr 11000! [+] PML4 at 1aa000 [+] base of HAL heap at fffff788c0000000 [+] found PML4 self-ref entry 1e7 [+] found HalpInterruptController at fffff788c0000680 [+] found HalpApicRequestInterrupt at fffff80035eb3bb0 [+] built shellcode! [+] KUSER_SHARED_DATA PTE at fffff3fbc0000000 [+] KUSER_SHARED_DATA PTE NX bit cleared! [+] Wrote shellcode at fffff78000000950! [+] Press a key to execute shellcode! [+] overwrote HalpInterruptController pointer, should have execution shortly...

but bluescreen was trigged.i i debuged by using windbg.

hal!HalpApicRequestInterrupt+0xa4: fffff800`35eb3c54 4584e4 test r12b,r12b 3: kd> t KDTARGET: Refreshing KD connection

A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

For analysis of this file, run !analyze -v nt!DbgBreakPointWithStatus: fffff800`355c4580 cc int 3 0: kd> !analyze -v The debuggee is ready to run WARNING: This break is not a step/trace completion. The last command has been cleared to prevent accidental continuation of this unrelated event. Check the event, location and thread before resuming. Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

0: kd> r rax=0000000000000000 rbx=0000000000000003 rcx=0000000000000003 rdx=0000000000000000 rsi=0000000000000000 rdi=fffff80031a5b180 rip=fffff800355c4580 rsp=fffff800386813b8 rbp=fffff80038681520 r8=0000000000000000 r9=0000000000000000 r10=000001539738d27d r11=fffff80038681370 r12=0000000000000003 r13=00000000004f4454 r14=0000000000000000 r15=ffffbf0ce8ca8040 iopl=0 nv up di ng nz na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000086 nt!DbgBreakPointWithStatus:

I have problem at start! Failed to find low stub in physical memory! can you give me some suggestion!

[whitehat9090]

Did you check if firewall turn off?

[whitehat9090]

hello! i tested on windows 10 1903 vm, it works as follow result. [+] found low stub at phys addr 11000! [+] PML4 at 1aa000 [+] base of HAL heap at fffff788c0000000 [+] found PML4 self-ref entry 1e7 [+] found HalpInterruptController at fffff788c0000680 [+] found HalpApicRequestInterrupt at fffff80035eb3bb0 [+] built shellcode! [+] KUSER_SHARED_DATA PTE at fffff3fbc0000000 [+] KUSER_SHARED_DATA PTE NX bit cleared! [+] Wrote shellcode at fffff78000000950! [+] Press a key to execute shellcode! [+] overwrote HalpInterruptController pointer, should have execution shortly... but bluescreen was trigged.i i debuged by using windbg. hal!HalpApicRequestInterrupt+0xa4: fffff80035eb3c54 4584e4 test r12b,r12b 3: kd> t KDTARGET: Refreshing KD connection A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked. A fatal system error has occurred. For analysis of this file, run !analyze -v nt!DbgBreakPointWithStatus: fffff800355c4580 cc int 3 0: kd> !analyze -v The debuggee is ready to run WARNING: This break is not a step/trace completion. The last command has been cleared to prevent accidental continuation of this unrelated event. Check the event, location and thread before resuming. Break instruction exception - code 80000003 (first chance) A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked. A fatal system error has occurred. 0: kd> r rax=0000000000000000 rbx=0000000000000003 rcx=0000000000000003 rdx=0000000000000000 rsi=0000000000000000 rdi=fffff80031a5b180 rip=fffff800355c4580 rsp=fffff800386813b8 rbp=fffff80038681520 r8=0000000000000000 r9=0000000000000000 r10=000001539738d27d r11=fffff80038681370 r12=0000000000000003 r13=00000000004f4454 r14=0000000000000000 r15=ffffbf0ce8ca8040 iopl=0 nv up di ng nz na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000086 nt!DbgBreakPointWithStatus:

I have problem at start! Failed to find low stub in physical memory! can you give me some suggestion!

Did you check if firewall turn off?

[chompie1337]

It's hard to see what caused the crash. can you post the full callstack, run bt (with symbols loaded)

[whitehat9090]

It's hard to see what caused the crash. can you post the full callstack, run bt (with symbols loaded)

Sometimes BSOD appears. kernel shellcode works well and BSOD doesn't appear, but user shellcode doesn't work. After exploit run, spoolsv.exe restart. The user shellcode which run calc.exe, tested correctly, and its size is 276 bytes. In kernel shellcode, i modified USER_SHELLCODE_SIZE to 276. I attached my exploit.py. exploit.py.txt I hope your opinion.

[chompie1337]

It's hard to see what caused the crash. can you post the full callstack, run bt (with symbols loaded)

Sometimes BSOD appears. kernel shellcode works well and BSOD doesn't appear, but user shellcode doesn't work. After exploit run, spoolsv.exe restart. The user shellcode which run calc.exe, tested correctly, and its size is 276 bytes. In kernel shellcode, i modified USER_SHELLCODE_SIZE to 276. I attached my exploit.py. exploit.py.txt I hope your opinion.

Hello! Please do not modify USER_SHELLCODE_SIZE in kernel shellcode. The user shellcode consists of a stub found in kernelshellcode.asm plus the payload specified in USER_PAYLOAD. The exploit is configured to work with all payloads under 600 bytes and you do not need to modify anything except USER_PAYLOAD in exploit.py

I tested your USER_PAYLOAD you attached and it does indeed execute. I did not debug your shellcode, but my suspicion is that it causes the process to exit once it is done creating the new process . This is not really a problem with the exploit but with the payload. To see this for yourself, open ProcessMonitor (download here: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon). Once ProcessMonitor is open, run the exploit. Then, click "View Process Tree" . You will see something like this:

Above you can see the process calc.exe was spawned by spoolsv.exe and exited. You will not see a calc.exe window pop up due to the process being in session 0, so you must confirm how I described above.

In my experience most payloads created by msfvenom will call ExitProcess once done executing by default and I think that is what is happening here. If you generate the payload with the parameter -EXITFUNC=thread, the spoolsv process stays alive. The calc.exe process still exits immediately. I'm not really sure why, but again this is beyond the scope of the exploit. My recommendation is to use a reverse shell generated msfvenom if you want to easily demo the exploit.

Thnx

[whitehat9090]

It's hard to see what caused the crash. can you post the full callstack, run bt (with symbols loaded)

Sometimes BSOD appears. kernel shellcode works well and BSOD doesn't appear, but user shellcode doesn't work. After exploit run, spoolsv.exe restart. The user shellcode which run calc.exe, tested correctly, and its size is 276 bytes. In kernel shellcode, i modified USER_SHELLCODE_SIZE to 276. I attached my exploit.py. exploit.py.txt I hope your opinion.

Hello! Please do not modify USER_SHELLCODE_SIZE in kernel shellcode. The user shellcode consists of a stub found in kernelshellcode.asm plus the payload specified in USER_PAYLOAD. The exploit is configured to work with all payloads under 600 bytes and you do not need to modify anything except USER_PAYLOAD in exploit.py

I tested your USER_PAYLOAD you attached and it does indeed execute. I did not debug your shellcode, but my suspicion is that it causes the process to exit once it is done creating the new process . This is not really a problem with the exploit but with the payload. To see this for yourself, open ProcessMonitor (download here: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon). Once ProcessMonitor is open, run the exploit. Then, click "View Process Tree" . You will see something like this:

Above you can see the process calc.exe was spawned by spoolsv.exe and exited. You will not see a calc.exe window pop up due to the process being in session 0, so you must confirm how I described above.

In my experience most payloads created by msfvenom will call ExitProcess once done executing by default and I think that is what is happening here. If you generate the payload with the parameter -EXITFUNC=thread, the spoolsv process stays alive. The calc.exe process still exits immediately. I'm not really sure why, but again this is beyond the scope of the exploit. My recommendation is to use a reverse shell generated msfvenom if you want to easily demo the exploit.

Thnx

hello, chompie1337. thank you for your opinion. I got the follow result in some system. [*]physical read primitive failed! why?

Could you teach me detail about find_low_stub function in exploit.py? I hope your reply.

[whitehat9090]

hello! i want to know why LOWSTUB_JMP is 0x1000600E9. i hope your reply.

[chompie1337]

hello! i want to know why LOWSTUB_JMP is 0x1000600E9. i hope your reply.

Hello, it's used as a signature to use the lowstub. See here: https://github.com/ufrisk/MemProcFS/blob/master/vmm/vmmwininit.c#L560