When I try to WinRM into a Windows host (with a tool like
evil-winrm) into the and when I do
qwinsta, it says "No sessions exists for *", however, when I do
RunasCs.exe x x "qwinsta" -l 9 it lists out the sessions correctly.
Note that the command is literally
x x, i.e. I typed
x as username and
x as password. As apparently logon type 9 is like
runas.exe /netonly which doesn't check the credentials immediately, it works. Thus, I did not supply the process with any new information (such as how people typically solve the "PS Remoting double hopping problem" by using
Invoke-Command with a plaintext password). However, suddenly now it is working.
Is this some sort of special situation with WinRM where the access token is "dumbed down", or how can I approach understanding this one? As discussed, I didn't have to supply any new information here so it seems like some sort of nuisance or Windows API quirks? I merely changed from Network logon type to
NewCredentials logon type without supplying any new credentials.
(For more context and for this one particular machine,
net view didn't work with WinRM (system error 1223) but worked when
RunasCs.exe -l 9. When I'm trying to run
KrbRelay on the box it got access denied with the WinRM session but works when run through
RunasCs.exe -l 9)
What's the working mechanism behind this?