PsExec: The SysAdmin’s Swiss Army Knife

Over the years, Windows administrators have collected and used a wide range of tools that provide capabilities, features, and abilities not natively found in the Windows operating system. Remote administration has always been a vast space for third-party tools and other utilities to provide capabilities for administering remote Windows systems.

Many of these are pay for products. However, free tools provide extremely robust remote management of Windows systems, allowing IT administrators to execute commands and other activities remotely. One such tool that has been extremely popular among Windows administrators is PsExec. What is PsExec? How is PsExec used? Is it installed in Windows by default? How does it work with Windows 10? This guide will look at PsExec, the sysadmin’s Swiss Army knife, and see how and why this tool is so valuable.

What is PsExec?

Windows administrators have long needed programs to execute remote processes on other systems. Unlike Linux, with remote SSH connectivity and other native tools built-in, Windows is limited in its ability to remotely run commands aside from interacting with remote systems using Windows Remote Desktop. This means of “remotely” administering Windows environments is cumbersome, challenging, and anything but efficient at scale.

PsExec is a “telnet-like” application that allows executing processes and interacting with console applications without using an entire desktop session. It provides remote access to tools that you would not otherwise be able to interact with generally in Windows, such as the IPconfig command. It will enable the launching of interactive command-prompts on remote Windows systems. An additional benefit of PsExec remote cmd is that it does not require installing client software for remote connectivity on either the host or target client.

The PsExec tool is a member of the very well-known Sysinternal’s PsTools suite of tools. Windows Sysinternals is a suite of tools that contains over 70 free utilities that allow Windows administrators to monitor, manage, and troubleshoot Windows. The SysInternals tools were the brainchild of Mark Russinovich and Bryce Cogswell. The tools are still currently developed and maintained.

The compelling characteristics, ease of use, and functionality makes PsExec extremely versatile, capable and has grown into a tool of choice among Windows administrators for remote command execution. Now that we have a better understanding of what PsExec is and a few of its characteristics, let’s get into how to use PsExec effectively and a few use cases.

Run as privileged users

PsExec offers the ability for IT admins to easily run certain commands and troubleshooting tools as specially privileged users, such as the Local System account. So, if you receive a PsExec access denied error, you can easily change the context of running PsExec commands. Note the following example of running commands as the Local System account:

• psexec -i -s cmd.exe

This PsExec run as system ability allows administrators to perform tasks under special contexts that are not easily achieved using other means. We will take a look at further examples of running as different users with PsExec a bit later.

Why not just use PowerShell?

At this time, can administrators not use new tools and capabilities such as PowerShell remoting in the environment instead of leveraging PsExec? In some environments, organizations may pivot to natively using PowerShell remoting and other newer remote capabilities. However, there may still be legacy operating systems found as part of the infrastructure due to certain business or software requirements in some current business environments.

PsExec supports Windows versions back to Windows XP and can be effectively used in all operating systems from XP to the current Windows 10 release. There may be challenges with using PowerShell remoting with legacy operating systems such as Windows XP. Also, this has to be enabled and can potentially be problematic. PsExec is a more traditional and straightforward process to connect, start a service, and start issuing commands.

In this case, using PowerShell may not be possible. Additionally, PsExec can also work with PowerShell scripts and cmdlets. Using PsExec PowerShell commands can provide the best of both worlds, in terms of interoperability and functionality.

Requirements for Using PsExec

The requirements for using and running PsExec are relatively simple since there isn’t an installation of the utility itself. However, there are a few things to keep in mind when using the PsExec utility. These include:

• PsExec is a Windows-only solution that works between Windows computers
• You will need a Windows host computer to use to connect to the target Windows hosts you want to manage
• The admin$ share must be available on the target Windows system
• You will need to ensure you have connectivity between the host you are running PsExec, and the target computer you want to manage. It includes:
  • Ensuring a firewall is not filtering traffic between your host and target
  • Enabling the File and Printer Sharing Windows Defender Firewall exception on the target Windows computer

Allowing File and Printer Sharing in the Windows Defender Firewall

Downloading and Installing PsExec

To begin using PsExec, you need to download the SysInternals PsExec tool and install this on your administrative workstation, from which you will be running it. You can download PsExec as part of the PsTools suite that is readily (and freely) available from Microsoft. Download PsTools from the following link:

• PsTools – Windows Sysinternals | Microsoft Docs

The tools are downloaded as a .zip file containing the executables for the PS Tools suite. After extracting the PS Tools suite, you will see the list of available tools as part of the PS Tools suite. Below is a look at the directory after extracting the .zip file. You will see you have PsExec.exe and PsExec64.exe.

After extracting the PS Tools suite of tools to a directory

Installing PsExec

As mentioned earlier, there is no need to install the PS Tools suite tools individually, including the process to install PsExec. These are self-executing files that have everything they need as part of the executable itself. However, there are a few things you probably want to do after you download the PS Tools suite to your administrative workstation. These include the following:

• Add the PS Tools directory to your Windows PATH configuration
• Security implications and Antivirus exceptions

Let’s take these one-by-one and see why the above steps are essential.

Add PsExec to your Windows PATH configuration

To allow PsExec to have native built-in Windows utility behavior, you will want to add your PS Tools directory to your Windows PATH statement. What does this do? Adding the PS Tools directory to the PATH statement will make the tools easy to use and allow launching them without your focus in the directory containing the PS Tools suite executables. To do this, you will want to copy the PS Tools directory to a centralized, intuitive location, then add this location to your Windows PATH configuration.

Below is the PSTools folder containing the PS Tools utilities after being copied to the root of the C drive.

Copying the PSTools directory to the root of the C drive

After copying the PSTools directory to the location you want to house them, you need to edit the System PATH variable under the Advanced System properties in either the Windows client or Windows Server operating system. You can get to the Advanced System properties by typing sysdm.cpl > Advanced > Environment Variables. Then edit the PATH variable under the System variables.

Editing the Windows System PATH variable to add the path to the PSTools directory

As you can see below, after adding the PATH variable configuration for the PSTools directory, we can now type psexec. Windows finds the executable without executing the command in the parent PSTools directory.

Testing the PATH variable by executing the PsExec command outside the parent directory

Security implications and antivirus exceptions

It is essential to consider the security around using the PsExec utility. While it is a powerful, useful, and helpful utility, it can be used for malicious means, as we will discuss. Any tool that is misused can lead to tremendous damage to a production system or environment. Only those who have experience running command-line tools in a cautious and well-tested manner should be allowed to interact with production systems using PsExec.

An important consideration to make with the PSTool suite of utilities, including PsExec is that many antivirus solutions flag PsExec and other PSTools utilities as malicious. Are the PSTools utilities malicious? PsExec and the other PSTools are not malicious tools. These have been developed under the purview of Microsoft and are legitimate tools under the SysInternals division. Why are these flagged?

A file flagged in the PSTools suite folder by a well-known antivirus vendor

Malware creators and malicious attackers are getting better and more sophisticated in using native or legitimate tools to compromise systems. If an attacker can use a built-in, legitimate, or known tool, these are most likely not going to be flagged as suspicious, even if used for malicious activity. Even with newer allow listing cybersecurity solutions, built-in or legitimate tools such as those found in the PSTools may be whitelisted by organizations. Attackers know this. They often use these tools not to be flagged as suspicious. It may take much longer for an activity involving legitimate tools to be seen as suspicious.

For example, the NotPetya ransomware uses the PsExec utility to copy and spread via PsExec to admin$ shares using remote WMI. The BitPaymer ransomware also uses the PsExec utility to copy and run malicious commands in environments to spread ransomware quickly and effectively.

A note from the tool’s creator, Mark Russinovich, describes the security implications of the tool this way:

“The last security note relates to viruses. Several viruses use PsExec to propagate within a network, and as a result, several major antivirus products flag PsExec as a Trojan horse program or a worm. Remember that PsExec works on remote systems only if it runs within an account that has administrator group membership on the remote system. In other words, unless the account from which you run it has administrative access to a remote system, PsExec won’t be able to execute a process on the remote system. In addition, PsExec’s functionality can be achieved in other ways; thus, PsExec is only a convenience for virus writers, who could otherwise easily implement the functionality that PsExec provides.”

In addition to carefully considering the credentials used, administrators should consider allow listing PsExec with application allow listing cybersecurity solutions or GPO app-locker settings so it can run from a specific workstation or set of workstations. In this way, if a malicious actor has compromised a particular set of credentials, there is only a specific workstation or environment where the credentials will allow running PsExec or any other administrative tool.

Other PsExec security to note

There are other security features and behaviors to make a note of with PsExec. The PsExec service uses Windows security and impersonates the account from which you run the PsExec utility on the local system. It is essential to understand the restrictions and caveats of impersonation from a PsExec standpoint.

By design, impersonation is somewhat restricted. Remote processes don’t have access to network resources, even if the account typically has access to those resources. Suppose the account being impersonated for connectivity does not have local administrative privileges on the remote system. In that case, PsExec allows specifying a different account to provide alternate user context for commands. To use alternate credentials with PsExec, there are a couple of switches for you to note:

• -u specify the username – REMOTEMACHINEadministrator
• -p specify the password for the alternate credentials – -p administrator_pass ipconfig
• PsExec remote cmd as administrator – psexec -u REMOTEMACHINEadministrator -p mypassword ipconfig

To prevent an “over the shoulder” attack by typing in the password in plain sight, you can omit the -p switch, and PsExe will prompt for the password. When typing the password, the characters are not echoed to the screen output. It provides some flexibility in how passwords are entered for alternate credentials.

Running under the LOCAL SYSTEM account

Another option regarding user credentials is the ability to use the LOCAL SYSTEM account. The LOCAL SYSTEM account is an extremely powerful account that has permissions to interact with core Windows services and processes. Examples include Winlogon and the Local Security Authority Subsystem Service (LSASS) service. The Windows System Account is the only account that has the ability to access certain resources such as the HKEY_LOCAL_MACHINESAM registry values as well as the special-purpose System Volume Information directory on recent Windows systems. To run PsExec as the LOCAL SYSTEM account you pass the -s switch:

• psexec -s \REMOTEHOST <command>

The LOCAL SYSTEM functionality is also useful when needing to run a process or console application in the context of the LOCAL SYSTEM account on a local computer. Another beneficial use case of the PsExec utility is it is an easy way to run a program under the LOCAL SYSTEM user. On your local Windows system, you can use the following to run a program under the LOCAL SYSTEM account:

• psexec -s -i <program>

As you decide to use PsExec in your environment, you must consider cybersecurity carefully. PsExec is a robust and powerful tool that depends on administrator credentials when making connections to target machines. It is essential that administrator credentials are adequately protected and safeguards are put in place so that PsExec is run only from a particular location or workstation.

How does PsExec work?

You may wonder how PsExec works under the hood and how it provides the functionality it does to execute remote commands on target Windows computers. The workflow of PsExec looks like the following:

1. PsExec begins by extracting from its executable image an embedded Windows service called Psexesvc
2. The service is copied to the Admin$ share of the remote system
3. Windows Service Control Manager API is then used to have a remote interface with the target computer
4. The Psexesvc service is started on the remote system
5. A named pipe called psexecsvc is created to which the PsExec utility connects to and sends commands to the remote target
6. The remote executable you specify is launched along with the options you specify

Controlling the Psexesvc service

As mentioned, the Psexesvc service is installed on the remote computer. You can control the behaviour of the service on the remote target. The default behaviour of the Psexesvc looks like this:

• The service waits for the executable to terminate then sends the exit code back to PsExec for printing out to the local console
• Using the -d parameter (don’t wait), the service will exit after starting the executable

Understanding the workflow and how PsExec interacts with remote systems will help from a troubleshooting perspective and keep security in mind.

Exploring PsExec functionality

One of the first things you will want to do is explore the functionality of the PsExec utility. You can easily see the capabilities provided by the tool when you issue the psexec command without switches. As shown, PsExec has a healthy number of command-line switches to interact with the remote target and control the behaviour.

Usage: psexec [\computer[,computer2[,…] | @file]][-u user [-p psswd]][-n s][-r servicename][-h][-l][-s|-e][-x][-i [session]][-c [-f|-v]][-w directory][-d][-<priority>][-a n,n,…] cmd [arguments]

-a Separate processors on which the application can run with

commas where 1 is the lowest numbered CPU. For example,

to run the application on CPU 2 and CPU 4, enter:

“-a 2,4”

-c Copy the specified program to the remote system for

execution. If you omit this option the application

must be in the system path on the remote system.

-d Don’t wait for process to terminate (non-interactive).

-e Does not load the specified account’s profile.

-f Copy the specified program even if the file already

exists on the remote system.

-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.

-h If the target system is Vista or higher, has the process

run with the account’s elevated token, if available.

-l Run process as limited user (strips the Administrators group

and allows only privileges assigned to the Users group).

On Windows Vista the process runs with Low Integrity.

-n Specifies timeout in seconds connecting to remote computers.

-p Specifies optional password for user name. If you omit this

you will be prompted to enter a hidden password.

-r Specifies the name of the remote service to create or interact.

with.

-s Run the remote process in the System account.

-u Specifies optional user name for login to remote

computer.

-v Copy the specified file only if it has a higher version number

or is newer on than the one on the remote system.

-w Set the working directory of the process (relative to

remote computer).

-x Display the UI on the Winlogon secure desktop (local system

only).

-arm Specifies the remote computer is of ARM architecture.

-priority Specifies -low, -belownormal, -abovenormal, -high or

-realtime to run the process at a different priority. Use

-background to run at low memory and I/O priority on Vista.

computer Direct PsExec to run the application on the remote

computer or computers specified. If you omit the computer

name PsExec runs the application on the local system,

and if you specify a wildcard (\*), PsExec runs the

command on all computers in the current domain.

@file PsExec will execute the command on each of the computers listed

in the file.

cmd Name of application to execute.

arguments Arguments to pass (note that file paths must be

absolute paths on the target system).

-accepteula This flag suppresses the display of the license dialog.

-nobanner Do not display the startup banner and copyright message.

You can enclose applications that have spaces in their name with

quotation marks e.g. psexec \marklap “c:long name app.exe”.

Input is only passed to the remote system when you press the enter

key, and typing Ctrl-C terminates the remote process.

If you omit a user name the process will run in the context of your

account on the remote system, but will not have access to network

resources (because it is impersonating). Specify a valid user name

in the DomainUser syntax if the remote process requires access

to network resources or to run in a different account. Note that

the password and command is encrypted in transit to the remote system.

Error codes returned by PsExec are specific to the applications you

execute, not PsExec.

How is PsExec Used?

How is PsExec Used – PsExec Examples ?

There are many ways that the PsExec command can be used. These include:

• Running a specific remote command on a single computer
• Running a generic command prompt or PowerShell prompt on a remote computer
• Running a remote command against multiple computers
• Reading computers from a file
• Launching programs for remote end-users interactively

Running a remote command on a single computer

Now that we have a basic understanding of PsExec, what it is, and have explored the command line switches, let’s start looking at using PsExec with a few basic connectivity and functionality examples. In its most basic form, PsExec requires the following:

1. PsExec commands and any PsExec options to be passed
2. A target computer
3. A command to run on the target

We are using PsExec to connect to a remote computer called win10remote and invoke the remote computer’s ipconfig command. The PsExec Windows 10 output to the console is the ipconfig output of the remote Windows 10 workstation.

Running the ipconfig command on a remote computer using PsExec

Running a generic command prompt or PowerShell prompt on a remote computer

Initially, you probably first think about running a specific command on a remote Windows computer. However, one of the compelling use cases with PsExec is the ability to run a generic command prompt or PowerShell session on a remote computer. In this way, if you are needed to perform remote troubleshooting on a remote computer without knowing which specific command you may need, you can start with the generic command prompt or PowerShell session.

As you can see below, we are launching a PowerShell session on a remote host, then issuing commands on the target Windows host to begin troubleshooting. After starting the PowerShell prompt, we can launch commands such as Ipconfig, route print, etc. In this way, you do not have to begin a new PsExec session on the remote Windows host for each command you want to run.

Using a generic PowerShell prompt launched with PsExec for troubleshooting

Running a remote command against multiple computers

You may have thought earlier that you may need to create a batch script of some sort to loop through multiple remote computers if you have several on which you need to perform a remote command. However, this functionality is built into PsExec. To launch a remote command against multiple computers, use the following syntax:

• psexec \computername1,computername2,computername3,computername4

PsExec will launch the remote command on all of the computer names listed in the UNC string separated by a comma.

Reading computers from a file

In case you were wondering if you can use PowerShell in conjunction with PsExec, yes, you can. One of the easy ways to demonstrate how you can feed information into PsExec from PowerShell is by enumerating computers from Active Directory to provide PsExec the list of computers for running remote commands. An easy example of this is using the Active Directory PowerShell Module to pipe out computers from Active Directory into a text file. Once you have the text file, you can then have PsExec read the text file to enumerate computers that have been exported from Active Directory.

The Active Directory PowerShell module is installed by installing the AD DS and AD LDS Tools under the Role Administration Tools on a Windows Server host.

Installing AD DS and AD LDS Tools to install the Active Directory PowerShell module

Once you have the Active Directory PowerShell module installed, you can use it to create your input file for PsExec. What if you wanted to flush the DNS cache on all computer contained in a specific Active Directory OU? You could do something like the following:

• psexec “\$((Get-AdComputer -Filter * -SearchBase “OU=TestOU, DC=cloud, DC=local”).Name -join ‘,’)” ipconfig /flushdns

The command above searches a particular Active Directory OU, joins the resulting computers into the comma-separated string format the PsExec command needs to connect to multiple remote computers, and then runs the Ipconfig /flushdns command.

Launching programs for remote end-users interactively

Another interesting switch with the PsExec utility allows launching programs on the remote Windows host interactively. In other words, the output will be seen on the remote computer and not on your local output. Suppose a user is having difficulty launching a remote program on their end-user client. In that case, you can connect using PsExec and launching the program session interactively on the remote Windows host.

To do that, you can use the following command:

• psexec -i \remotewindows winword.exe

The command above will launch Microsoft Word interactively for the end-user to see the program launch on their Windows workstation. It is a great tool for helping remote end-users launch a particular program if unable to use their normal shortcuts.

To properly protect your Hyper-V virtual machines, use Altaro VM Backup to securely backup and replicate your virtual machines. We work hard perpetually to give our customers confidence in their Hyper-V backup strategy. 

To keep up to date with the latest Hyper-V best practices, become a member of the Hyper-V DOJO now (it’s free).

Concluding Thoughts

No matter how few or many Windows hosts you may need to administer remotely, there is always the need to connect to remote Windows systems to issue commands, perform troubleshooting, install software, and assist end-users. With this in mind, most organizations need to use tools to establish a connection to remote Windows clients and issue commands. Using Remote Desktop connections to remote Windows computers is cumbersome, time-consuming, and not very efficient.

PsExec is a powerful tool that is part of the PSTools suite of tools from SysInternals. It is a powerful utility that allows IT admins to connect to Windows hosts remotely and issue commands on the remote system. The requirements for connecting to remote Windows systems are minimal. These include credentials that allow connecting to the Admin$ share of the remote computer, File and Printer sharing enabled, and local administrator permissions if needed for configuration on the remote Windows host.

PsExec provides many different capabilities that allow you to interact with a single remote Windows host, multiple Windows computers, launching programs interactively, and even working in tandem with Windows PowerShell to pull a list of computers from Active Directory. Due to the nature of what PsExec can do, organizations need to be careful about who has access to run the utility and which locations it can be run. Malware, including many ransomware variants, can use PsExec to propagate malicious files and run specific commands on the network for compromising environments.

Organizations may want to hesitate to whitelist PsExec and other command-line tools globally since these can be used for malicious purposes. A better approach is to use a minimal scope of allowed workstations allowed to use PsExec to connect to remote Windows clients. In this way, the attack surface is much smaller if malicious software attempts to use known, common, or built-in command-line tools. All-in-all, PsExec is the sysadmin’s Swiss Army knife of functionality for performing remote administration from the command line and provides quick and easy access for troubleshooting, configuration, and assisting end-users.