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?
