PsExec v2.33 was released March 23, 2021. We are recommending that everyone update to this version. You can download it here.
After you download it, make sure to launch it manually one time under the account that you use to run BatchPatch. Also check the file properties to make sure it isn’t being blocked by Windows. If BatchPatch gets stuck “Attempting to initiate…” then you’ll know that Windows is blocking PsExec. More on how to unblock it here: BatchPatch Stuck ‘Attempting to initiate Windows Update’ or ‘Initiating execution’
BatchPatch will look for PsExec in the Windows PATH, so many users simply drop it into C:\Windows, and nothing more is needed. However, you can optionally point BatchPatch directly to your PsExec.exe filepath by going to ‘Tools > Settings > Remote Execution > Use psexec.exe custom filepath‘. This also enables you to name the file whatever you want, which is helpful when you are retaining multiple file versions. We generally recommend hanging on to your older versions of PsExec rather than replacing them outright. This way you can always revert to an older version if needed at any time in the future for testing or whatever.
PsExec Update Details – Why is there a PsExec update? And why do we recommend using it?
The PsExec v2.33 update was released to mitigate a named pipe squatting attack that could be leveraged to elevate from a lower privileged state to system level privilege on the attacked system. On December 9, 2020, a security researcher published an article that describes a novel local privilege elevation (or local privilege escalation – LPE) attack on PsExec through a technique known as pipe squatting. PsExec uses what is called a “Named Pipe” in Windows for inter-process communication between the source computer and target computer. The named pipe acts as a communication channel, and the default name for the pipe is PSEXESVC (this is the same as the default remote service name that PsExec uses when it temporarily installs itself on a given target computer). As he explains in his article…
“Through pipe squatting however (a method in which you create the pipe first), it is possible for a low-privilege application to get access to this pipe. If a local low-privileged application creates the “\PSEXESVC” named pipe before PSEXESVC is executed, then PSEXESVC will obtain a handle to the existing instance rather than creating the named pipe itself, which will have some unexpected consequences.”
Reality check
What does this really mean, in practice? The reason it’s called a *local* privilege elevation attack is because it’s not possible to remotely exploit. A malicious application would have to already have compromised a computer and be actively running for this attack to be possible. If this pipe-squatting attack is successfully executed, it could then enable the malicious application to elevate from a lower-privileged state to having system level privileges on the computer. Due to the nature of this type of attack, Microsoft gave it an exploitability assessment of “Exploitation Less Likely.” We believe this is an accurate assessment of the threat (Note, at the time of this writing, the CVE says it was fixed in v2.32, but it was not actually fixed properly until v2.33) The good news here is that while this is a legitimate potential attack, since it’s a local privilege elevation and not a remote code exploit, malicious code would have to first, through some other means, establish presence on a given system, and then after presence is established would have to run quietly/hidden in the background, squatting on the PSEXESVC named pipe, hoping that at some point someone would come along and run PsExec against that machine, using the default service and pipe name. So, while this attack provides a potential way, under certain circumstances, to take an already compromised system and gain higher level privileges on it, exploitation is probably not too likely due to the nature of the type of attack and the type of payoff, if executed successfully. That said, of course you should still update your PsExec.
Pre-existing mitigation
Both PsExec and BatchPatch already had a built-in mitigation available for this attack at the time the attack was published. PsExec (going back all the way to v2.0 released in 2013) has a -r switch, which enables you to modify the name of the remote service and pipe name from PSEXESVC to the name of your choosing. In BatchPatch (beginning with version 20151130) this setting is located under ‘Tools > Settings > Remote Execution > Use PsExec -r switch to specify remote service name‘. When this setting is enabled, the attack is effectively prevented/mitigated because the pipe name is modified, making it no longer guessable (because it’s now the custom name of your choosing instead of the default PSEXESVC). The attacker can squat all day on PSEXESVC, but if your processes are using SOMEOTHERNAME, the attacker cannot do anything.
BatchPatch January 2021 update / April 2021 update
On January 28, 2021 we released an update to BatchPatch that, in addition to a number of other updates and bug fixes, enabled the ‘Use PsExec -r switch’ setting as the default and for anyone who wasn’t already using it, and also added some additional code in a new optional setting to append a random string to the service/pipe name for each execution, thereby making it virtually impossible to guess in advance since each action would execute with a brand new name (through the appension of a random suffix), essentially eliminating the possibility of this kind of pipe-squatting exploit from being successfully executed. This optional random suffix setting is arguably unnecessary/overkill, but we wanted it to be available to users nonetheless. In the Jan 2021 release of BatchPatch the setting was enabled by default and for existing users. In the April 2021 release it will be disabled by default and for existing users on first launch. If a user wants to keep that setting, he/she will have to manually re-enable it after launching the April 2021 version of BatchPatch.
PsExec 2021 updates
In the meantime Microsoft released 3 updates to PsExec in rapid succession in January (v2.21, v2.30, v2.32), none of which successfully mitigated this attack directly in the PsExec code itself. However, v2.33 released on March 23 properly addresses the issue, so we’re recommending that everyone start using it. You can download it here.
Note, the PsExec update makes a slight change to PsExec’s functionality whereby it now requires use of -i (Interactive) when using alternate credentials (except when using using -s (SYSTEM). These settings are available under ‘Tools > Settings > Remote Execution‘. In most cases these values can either all be set to ‘SYSTEM‘ (without ‘Interactive‘) or can all be set to ‘Elevated token‘ + ‘Interactive‘. Usually either of these options will provide success. For most situations, leaving everything set to ‘SYSTEM‘ (without ‘Interactive‘) should be fine and is what we are currently recommending at the time of this writing, but in cases where you are executing a remote script with alternate credentials, and the remote script needs access to network resources, in that case ‘SYSTEM‘ will not work because the SYSTEM account does not have access to network resources. So in that case you would need to use ‘Elevated token‘ + ‘Interactive‘.
BatchPatch April 2021
There will be another BatchPatch update published very soon (in early April), which will include a PsExec version check to notify users if their PsExec version is affected.