PsExec v2.32

I have two hyper-v vm using Windows 11 Pro. as host on same physical machine.  I'm executing below command and it works for one of the vm but not the other. I can ping the no accessible vm and remote desktop access that vm. The vm do use differnt [virtual] network adapters [1 1GbE & 1 10GbE] with the 10GbE adapter for the vm that fails.

C:\Windows\System32>C:\pstools\PsExec.exe \\[vm] -u "[username]" -p [password] -s -h -c -f j:\CopyW_DriveBackupToIceDrive.bat -d

PsExec v2.43 - Execute processes remotely
Copyright (C) 2001-2023 Mark Russinovich
Sysinternals - http://www.sysinternals.com

Couldn't access vm:
The network name cannot be found.

Make sure that the default admin$ share is enabled on vm-polarbackupb.

I am trying to use PSEXEC v2.4 (the latest version) to run CMD in a remote computer and keep getting "Error communicating with PsExec service on RemoteSystem: No process is on the other end of the pipe.".  Does anyone has any ideas?

For example:

psexec \\RemoteSystem -i -u user -p password cmd.exe

In v2.11 which I have been using, -i has a huge effect for interactive programs, eg cmd.exe :

psexec \\RemoteSystem -u user -p password cmd.exe

without the -i opens cmd.exe with standard input and standard output connected to your current console. So you can type cmd command line commands onto the remote machine and see their output without disturbing a user who's interacting with that PC's windows GUI at the same time.

psexec \\RemoteSystem -i -u user -p password cmd.exe

on the other hand with the -i opens a new cmd window on the GUI display, interrupting the remote user's work. The remote user in front of that computer can interact with cmd.exe, but you can't locally.

They're very different (if the program is interactive). I make use of both modes extensively.

Has this changed?

For reference, from: https://docs.microsoft.com/en-us/sysinternals/downloads/psexec on 01/24/2022 (v2.34 is current):

-i	Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is specified the process runs in the console session. This flag is required when attempting to run console applications interactively (with redirected standard IO).

Agreed with MikeDiack . The -i option is required not only in conjunction with the -h option, but in general always for a successful start.
The only exception is running with a system account (using -s)

CE2Wells can you please email us at mailto:syssite@microsoft.com? We'd like to work together to resolve this, thanks!

Hi, David here. That's correct, PoC can be seen here https://github.com/tenable/poc/blob/master/Microsoft/Sysinternals/PsExecEscalate.cpp.

Thanks, lukekim .  I will email you too, as requested, but just wanted to highlight here that David Wells, the researcher who discovered the LPE vulnerability, says that he confirmed it still exists in the new 2.32 version, but with only a minor modification to his original PoC code.  See his note at top of his blog here:

https://medium.com/tenable-techblog/psexec-local-privilege-escalation-2e8069adc9c8

siegfried_hello the escalation issue should be fixed in the latest release. Please ensure both the client and service are updated and running the latest version. If you believe you are still seeing the issue please email us at mailto:syssite@microsoft.com along with detail reproduction steps. Thanks!

lukekim - are there plans to fix the local privilege escalation issue?  Maybe just as simple as changing the default behavior to add a random suffix to the remote service and pipe name at run time?  Then it no longer needs to allow multiple connections to the existing pipe since each new psexec connection will use a new service and pipe name? 

siegfried_hello 

It looks exactly like that Siegfried.

If I try to run a process on a remote pc that DOES NOT require elevation, with psexec 2.20, I work as before (see my post of 20 Jan) but omit the -h parameter (note the -h is gone now as I don't want demoprogram.exe run elevated).
psexec \\RemoteSystem -u user -p password c:\demoprogram.exe

But with 2.32, if I try that as before:

psexec \\RemoteSystem -u user -p password c:\demoprogram.exe

Again I get a login failure and again I have to use the -i parameter with version 2.32. 😞

psexec \\RemoteSystem -i -u user -p password c:\demoprogram.exe

So in a nutshell it looks like -i is almost always required now in 2.32, and this tends to beg the question why it's an option any more (if it's always required!) instead of silently active in 2.32 to avoid back compatibility problems!!!! Perhaps a question for lukekim and the SysInternals developers?