Closed ufrisk closed 4 years ago
Hey Ulf. That's really strange. I haven't been able to reproduce this issue on my host or target, both Win10 2004 19041.450 testing against PCILeech v4.7 with a privileged and unprivileged accounts. I am trying to update another host to 2004 and I'll keep researching on my end.
If you run the wx64_pscmd from cmd line what happens? I call it like this "cmd /c pcileech.exe wx64_pscmd -kmd kmdaddress".
I was in part wrong it seems like.
It's working when the computer is locked. It does not work when the computer user is logged in. I found this to be a bit strange since I thought you used lsass and not logonui as entry point for the system shell.
anyway; I dunno how much use there is to spawn a system shell while the user is logged in and have the screen unlocked. feel free to close the issue :)
Right, I noticed this in the past and accepted it as normal behavior in PCILeech? I get the same NTSTATUS 0x8007139F error in the CLI with a user logged in using wx64_pscmd. I'm surprised you captured it spawned from the GUI as it closes so quickly.
There might be a use case where someone wants SYSTEM access while logged in as a USER but I suspect they can live without it. The ability to push and execute code while logged in as USER still works, so its a win.
The lsass PID is used for wx64_pscreate so its something deeper. lsass is not my favorite process to abuse for a variety of reasons but it appears to be incredibly resilient. Eventually I'll hook into your MemProcFS API and expand the options in this GUI.
I don't believe I can resolve this with my current C language/shellcode programming abilities. :) Closing this one out and thanks for reporting this!
I noticed that the system shell does not work in my tested Windows 10 2004 system. I've tried it 3 times in a row after 3 reboots - all fail with the same error message. The user shell and the other functionality works just fine.