Using PsExec to Run Commands on Remote Windows Computers

7.4K

Sysinternals PsExec remains a useful legacy and troubleshooting tool for Windows admins, particularly for remote administration cases where SMB-based execution is required.

PsExec allows you to run commands and launch apps on remote Windows machines from your local command prompt, making them appear to be running locally and returning the output to your local computer’s console. While many PsExec use cases can now be handled with PowerShell Remoting or centralized management tools, PsExec remains useful for cases that require SMB-based remote execution/direct access to a Windows system.

In this tutorial, we’ll examine how to use the PsExec utility to execute commands on remote computers, gather information about remote systems. This includes interactive command execution, scripts, installing software, running commands as the Local System account or a different user, and performing remote control and administration tasks on multiple machines. Our article was tested with PsExec v2.43.

How to Download and Use PsExec on Windows

The PsExec utility is part of a family of command-line toolkit called PsTools, which were a part of Microsoft Sysinternals project. You can download it from the Microsoft website.

No installation is required. Download the PsTools package from Microsoft Sysinternals and extract PsExec.exe/PsExec64.exe to a dedicated tools directory (for example C:\Tools\Sysinternals\).

For modern 64-bit versions of Windows, use psexec64.exe.

PsExec can also be used without copying binary files to the local computer. To live run utilities from the PsTools kit, you can use the public share \\live.sysinternals.com\tools. For example, you can use this command call to run PsExec without copying:

\\live.sysinternals.com\tools\psexec64.exe

You can verify that PsExec runs locally using the command:

psexec -?

In order to test remote PsExec connectivity and execution, use the command below:

psexec -accepteula \\RemotePC hostname

Accepting the PsExec License Agreement Automatically

When PsExec is run for the first time under a user context where the Sysinternals EULA has not yet been accepted, it displays an interactive license agreement. You should use -accepteula in scripts and unattended automation to suppress the prompt.

In order to automatically accept the PsExec license agreement, you should use the -accepteula parameter:

psexec -accepteula \\RemotePC hostname

This suppresses the interactive prompt and is commonly used in enterprise automation scripts, scheduled tasks, and deployment solutions.

PsExec Basic Syntax and Parameters

The basic syntax for PsExec is as follows:

psexec \\RemotePCName [-u username] [-p password] command [arguments]

List the available PsExec command options by running the psexec in the command prompt.

Information about all available PsExec parameters can be found in the built-in help. Here, we will highlight the tool’s most frequently used parameters.

Most important PsExec parameters

Parameter	Description
\\computer	The name or IP address of the remote computer
-i [session]	Run the process interactively in the specified session. If no session is specified, PsExec uses the console session
-d	Don’t wait for process to terminate (non-interactive)
-u	Specify optional username for logon
-p	Specifies the optional password for the user account. You should avoid using -p in scripts or commands because the password can be exposed in command history, process arguments, or logs. Also, prefer interactive password prompts or other secure credential mechanisms.
-c	Copy the specified local program to the remote computer before execution
-h	Run the remote with the account’s elevated token
-s	Run the remote process under the LOCAL SYSTEM account
-e	Don’t load the user profile if interaction with the user profile environment is not necessary
-w	Set the working directory for the process on the remote computer
-n	Specify a timeout in seconds for connecting to the remote machine
-r	Specify a different name for the remote PsExec service
-accepteula	Suppress the Sysinternals license agreement prompt
-nobanner	Do not display the PsExec startup banner

For example, to view the interactive and disconnected sessions on the remote machine named wks11, run the command:

psexec.exe \\wks11 qwinsta

PsExec connects to a remote machine, executes the command given as an argument, and redirects the output to the caller console.

How PsExec Works Internally

PsExec offers a key benefit in remote control scenarios: it doesn’t need to be preinstalled on managed computers. When using PsExec against a remote computer, all required components are installed automatically.

The workflow of PsExec looks like the following:

1. PsExec copies the psexesvc.exe executable to the Admin$ share of the remote computer (C:\Windows\System32\psexesvc.exe), creates and starts the PSEXESVC service via the Windows Service Control (WSC) Manager API;
2. The local PsExec connects to the remote PSEXESVC via a named pipe, sends the command, and waits for result.

   

3. If the command has been successfully executed, you will see an exit code of 0.
4. PsExec stops the service and automatically removes it.

PsExec Connectivity and Prerequisites

In order for PsExec to connect to a remote computer, the following conditions must be met:

• An account that is a member of the Administrators group on the remote computer is used to run PsExec (otherwise you will get the error:
  Couldn’t install/start PSEXESVC service)
• TCP port 445 is open (File and Printer Sharing service and Windows Defender rule are enabled) and default Admin$ share is available (if not, an error occurs: Couldn’t access computername. The network path was not found);
• The LanmanServer and LanmanWorkstation services are running;
• Remote UAC restricts remote administrative access when local admin accounts are used over the network. You need to use a properly delegated domain administrative account instead of disabling Remote UAC. You should not disable Remote UAC merely in order to make PsExec work.

Modern Windows security controls

Modern Windows security features and enterprise app-control policies can affect PsExec behavior. On supported Windows 11 and Windows Server systems, Credential Guard can protect NTLM and Kerberos-derived credentials from credential-theft attacks, including Pass-the-Hash cases. Credential Guard is enabled by default on eligible domain-joined, non-domain-controller systems starting with Windows 11 22H2 and Windows Server 2025.

In addition, Windows 11 24H2 and Windows Server 2025 support configuring SMB to block NTLM authentication. Because PsExec relies on SMB, an environment that blocks NTLM for SMB can affect PsExec connections that depend on NTLM authentication.

App-control policies (such as Windows Defender Application Control (WDAC) and AppLocker) may also restrict execution of PsExec/related binaries according to the organization’s app-control policy. WDAC can restrict which apps and code are allowed to run.

Note. Some antivirus software may mistakenly detect PsExec as malware, PUA (Potentially Unwanted Application) hacking tool, or a remote administration tool.

This happens because PsExec uses techniques commonly associated with lateral movement and remote admin tools:

• remote service creation
• SMB administrative shares
• remote process execution
• credential-based remote access

Keep in mind that modern EDR/XDR security products may generate alerts/block PsExec activity entirely.

Note that in enterprise environments, PsExec usage is often restricted, monitored, or audited by security teams.

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint includes an Attack Surface Reduction (ASR) rule named Block process creations originating from PSExec and WMI commands. The rule is designed to block processes created through PsExec and WMI because these mechanisms can be abused for remote code execution and lateral movement.

The rule GUID is d1e49aac-8f56-4280-b9ba-993a6d77406c. In Microsoft Defender advanced hunting, related actions include AsrPsexecWmiChildProcessAudited and AsrPsexecWmiChildProcessBlocked.

Testing SMB Connectivity Before Using PsExec

Network connectivity problems are one of the most common causes of PsExec failures (this is because PsExec relies on SMB and the Admin$ administrative share). Before troubleshooting PsExec itself, you should verify the following:

• TCP port 445 connectivity
• Admin$ share accessibility
• DNS name resolution
• Windows Defender Firewall rules

To test TCP port 445 connectivity, use the following command:

Test-NetConnection computername -Port 445

In order to check Admin$ share access, run the command:

dir \\computername\Admin$

To verify DNS resolution:

Resolve-DnsName computername

Note that common connectivity-related PsExec errors include:

• The network path was not found
• Access is denied
• Could not start PSEXESVC service
• The handle is invalid

Keep in mind that in enterprise environments, firewall policies and endpoint protection software commonly block PsExec traffic by default.

Using PsExec to Execute Remote Commands with Examples

Let’s look at some useful examples of using PsExec to execute commands on remote computers.

Reboot a remote computer:

psexec \\computername shutdown /r /t 60

Run a GUI app in an interactive user session

Before starting a GUI application, identify the interactive session on the remote computer:

query user /server:computername

Then specify the required session ID with the `-i` parameter:

psexec -i <sessionID> -d \\computername notepad.exe

This is particularly important on Remote Desktop Session Host servers and machines with multiple/disconnected user sessions.

Run a remote program with arguments under a specified user account (if -p is omitted, PsExec prompts for the password interactively instead of requiring it on the command line). The following example assumes that 7-Zip and the specified archive already exist on the remote machine:

psexec -u username \\computername "C:\Program Files\7-Zip\7z.exe" t "C:\Temp\archive.zip"

Open an interactive PowerShell prompt with a remote computer:

psexec -i \\computername powershell.exe

Running Multiple Commands with PsExec

If you need to run multiple commands on a remote computer one after the other, run them as arguments to the cmd.exe command, separating them with && characters. For example:

psexec -nobanner \\wks11 cmd /c "net localgroup administrators user1 /add && net localgroup administrators"

This command adds a new user to the Local Administrators group and lists the current membership.

The -nobanner option allows you to hide the PsExec startup banner and copyright message.

Using PsExec Interactive Mode

PsExec allows to create an interactive session with a remote computer and execute commands in real time:

psexec \\lon-srv01 cmd

This will open up an interactive command prompt. Any command that you type in the console will be executed on the remote lon-srv01 computer.

To stop an interactive PsExec session, run:

Exit

Running Commands as LOCAL SYSTEM

One of the most common PsExec cases is running a process under the LOCAL SYSTEM account. Note that this account has extensive privileges on the local machine, it is frequently used for troubleshooting, software deployment testing, and permission validation.

For example, in case you need to open an interactive command prompt running as SYSTEM, use the following command (the example runs a SYSTEM shell on the local computer):

psexec -i -s cmd.exe

In case you need to verify the security context, run the following command:

whoami

The command above should return:

nt authority\system

Notes.

• -s parameter starts the process under the LOCAL SYSTEM account
• -i parameter allows interaction with the currently logged-on user’s desktop session

Run PowerShell as LOCAL SYSTEM

The following command opens an interactive PowerShell console running under the NT AUTHORITY\SYSTEM security context:

psexec -i -s powershell.exe

You can verify it with the command:

whoami

As expected result, you should see nt authority\system.

Understanding Session 0 Isolation

When running apps under the LOCAL SYSTEM account, admins often expect graphical windows to appear on the desktop. However, modern Windows versions isolate services in Session 0.

Here is an example:

psexec -s notepad.exe

The app may start successfully, but you won’t notice any visible window.

To launch an app in an interactive user session, you should use the -i parameter. If the target machine has multiple interactive sessions, you need to specify the required session ID explicitly:

psexec -i 3 -s notepad.exe

Here, 3 is the ID of the target interactive session. If no session ID is specified, PsExec uses the console session.

Using PsExec with Alternative User Credentials

By default, PsExec uses the current user to connect to the remote machine, which works great in a domain environment. If you need to run a command on a computer in a workgroup or under a different user account, you can set alternative remote user credentials in PsExec:

psexec.exe -u user \\lon-srv01 cmd.exe

If -p is omitted, PsExec prompts for the password interactively instead of exposing it in the command line. Keep in mind that you should prefer Kerberos/domain authentication and dedicated, least-privileged admin accounts. You should avoid using highly privileged accounts such as Domain Admin for routine PsExec operations.

For local admin accounts, you should consider using Windows LAPS to manage and automatically rotate unique local admin passwords. You need to avoid using the same local admin password across multiple machines, as compromise of one endpoint could enable lateral movement to other systems.

Running PowerShell Command in PsExec

You can even use PsExec to run PowerShell commands remotely. For example, the following command will return you the size of the C:\PS directory on the remote computer:

psexec \\lon-srv01 powershell.exe -NoProfile -Command "(Get-ChildItem 'C:\PS' -File | Measure-Object -Property Length -Sum).Sum / 1MB"

Note. You can use the Invoke-Command cmdlet instead of PsExec to run commands remotely with PowerShell.

Copy and Run Files on a Remote Computer with PsExec

The -c parameter copies the specified executable to the remote computer before execution:

psexec -c \\lon-srv01 C:\Tools\myprogram.exe

To copy and run a script on a remote computer, use the following command:

copy "C:\ps\myscript.bat" "\\lon-srv01\C$\Temp\myscript.bat"

psexec \\lon-srv01 cmd.exe /c "C:\Temp\myscript.bat"

To install an MSI package stored on the local computer, copy it to the remote computer first and then run msiexec.exe remotely:

copy "C:\install\setup.msi" "\\lon-srv01\C$\Temp\setup.msi"

psexec.exe \\lon-srv01 msiexec.exe /i "C:\Temp\setup.msi" /qn /norestart

Note. You must enclose the path in double quotation marks if it contains spaces. For example:

psexec \\lon-srv01 "c:\Program Files (x86)\app1\app.exe"

How to Use PsExec to Run Commands on Multiple Remote Computers

PsExec allows to run the command on multiple remote computers simultaneously. You can specify the list of remote computers separated by commas:

psexec \\PC1,PC2,PC3,PC33 "ipconfig /all"

Or save a list of computers to a text file (one hostname on each line), and then specify the path to that file:

psexec @c:\ps\computer_list.txt ipconfig

To redirect the results of running commands on remote computers to a text log file:

psexec @C:\Tools\computer_list.txt CMD /C "hostname & ipconfig" >> C:\Tools\log2.txt

How to Use PsExec to Run a Command on All Domain Computers

PsExec can target all machines in the current domain by using the \\* wildcard. Note that you should use this only when domain-wide execution is explicitly authorized and the scope is fully understood. The command may attempt execution against a large number of endpoints and servers and can generate significant SMB traffic, process/service-creation events, and EDR/SOC alerts. 

psexec \\* hostname

This runs the specified command on all machines in the current domain that PsExec can access. For your routine admin tasks, you should prefer an explicitly generated target list filtered by Active Directory OU, group, OS, or another controlled scope.

If you need more control over the target scope, create an explicit computer list using your organization’s preferred inventory or management tools, with one computer name per line, and pass it to PsExec:

psexec @C:\Tools\computers.txt hostname

Note that large-scale execution may trigger endpoint security monitoring and you should only perform it when authorized.

PsExec Logging and Security Auditing

Keep in mind that PsExec activity may generate various Windows security and operational logs on both local and remote machines.

Security context

PsExec is frequently used as a lateral movement technique in enterprise environments and is also commonly observed in post-exploitation tasks (including ransomware and credential-based attack chains).

From a security perspective, you should consider PsExec activity as a high-risk because it enables remote execution over SMB using admin credentials and can facilitate:

• lateral movement between hosts
• remote service creation (PSEXESVC)
• credential-based execution without WinRM requirements

Because of this, PsExec is actively monitored and often detected by modern EDR/XDR solutions and security teams as part of MITRE ATT&CK techniques (e.g., Remote Services/Service Execution patterns).

In enterprise environments, the usage of PsExec should be:

• explicitly authorized
• logged and audited centrally
• correlated with authentication and SMB activity logs

PsExec activity can generate multiple types of security telemetry, depending on the Windows auditing, Defender, and EDR config:

• Service creation events — for example, Windows Security/Service Control Manager Event ID 7045 when a new service is installed.
• Process creation events — for example, Security Event ID 4688 when process creation auditing is enabled.
• Authentication events — such as successful logon events associated with the account used for remote access.
• SMB/network telemetry — PsExec relies on SMB connectivity to the remote computer, typically over TCP port 445.
• Microsoft Defender for Endpoint telemetry — MDE can provide behavioral telemetry and detections associated with PsExec activity.
• Attack Surface Reduction (ASR) events — Microsoft Defender includes an ASR rule named Block process creations originating from PSExec and WMI commands, which can audit/block processes created through PsExec and WMI.
• EDR alerts and incidents — endpoint security products may detect or block PsExec based on process, service, network, and behavioral activity.

Note. Keep in mind that in many security monitoring systems, PsExec activity is treated as a high-confidence indicator of lateral movement when combined with remote authentication events and service creation logs.

Note that PsExec is a dual-use tool: it is widely used for legitimate system administration, but its execution pattern is identical to techniques used in lateral movement during security incidents.

Common PsExec Errors and Troubleshooting

Below you will find some common PsExec errors and their typical causes:

Error	Possible Cause
Access is denied	Insufficient admin permissions/UAC restrictions
The network path was not found	SMB connectivity/firewall problem
Could not start PSEXESVC service	Admin$ unavailable/antivirus blocked service creation
The handle is invalid	Interactive session/UAC problem
Logon failure: unknown user name or bad password	Invalid credentials

In case you are facing errors mentioned above, you need to make sure that:

• TCP 445 is reachable
• Admin$ share exists
• the account has local admin permissions
• endpoint protection and app-control policies (such as Microsoft Defender for Endpoint, WDAC, or AppLocker) are not blocking PsExec or the remote service/process it creates.

PsExec vs PowerShell Remoting

In a modern environment, the preferred means of remotely managing computers is PowerShell Remoting (Invoke-Command and Enter-PSSession cmdlets). PowerShell Remoting uses WinRM/WS-Man. On Windows client systems (such as Windows 10 and Windows 11), WinRM is not configured for remote management by default and PowerShell Remoting must be enabled and configured. On Windows Server, PowerShell Remoting is enabled by default unless it has been disabled/reconfigured.

PsExec’s key benefit is that it doesn’t require any prior configuration on the remote computer. Moreover, PsExec can be used to remotely enable WinRM and PowerShell Remoting on a machine:

$computerName = 'computername1'

psexec "\\$computerName" -s c:\windows\system32\winrm.cmd quickconfig -quiet *>&1 | Out-Null

Keep in mind that PowerShell remoting sessions (Enter-PSSession/Invoke-Command over WinRM) typically run under user context and do not natively provide an interactive SYSTEM-level session.

However, PowerShell code itself can be executed under SYSTEM context when launched through mechanisms such as:

• PsExec (-s)
• Windows Services
• Scheduled Tasks
• WMI/CIM remote execution

Note that the limitation is not PowerShell execution itself, but the identity and session model used by WinRM-based interactive remoting.

Keep in mind that PsExec primarily relies on SMB connectivity over TCP port 445, while PowerShell Remoting uses WinRM over ports 5985 (HTTP) and 5986 (HTTPS). Because of this, PowerShell Remoting is often easier to secure and audit in enterprise environments.

Modern Alternatives to PsExec

OpenSSH is another option for remote command execution on Windows. Microsoft provides OpenSSH Client and OpenSSH Server for supported Windows versions, including Windows 10/11 and Windows Server. OpenSSH uses the SSH protocol and normally listens on TCP port 22. You can read more about it here.

Unlike PsExec, SSH does not rely on SMB administrative shares/PSEXESVC service. However, OpenSSH Server must be installed, configured, and running on the target machine, and access must be controlled through the organization’s authentication and authorization policies.

Windows Admin Center provides a browser-based management interface for Windows Server and clusters. Unlike PsExec, it is designed for ongoing server administration and troubleshooting rather than ad-hoc remote command execution. Windows Admin Center uses a gateway architecture and manages target servers through PowerShell and WMI over WinRM.

A few examples of using PsExec to run PowerShell workflows

Run a PowerShell command on a remote computer via PsExec:

psexec \\computername Powershell -command Get-Service spooler

To run a local PowerShell script on a remote computer, you should copy the script to the remote machine first and then invoke powershell.exe with -File:

copy "C:\Tools\Get-UserInfo.ps1" "\\computer\C$\Windows\Temp\Get-UserInfo.ps1"

psexec \\computer powershell.exe -NoProfile -File "C:\Windows\Temp\Get-UserInfo.ps1"

Windows admins still use PsExec actively to execute commands and run programs on remote machines, including those in PowerShell cases.

Wrapping up

Although PsExec remains useful for troubleshooting, break-glass administration, and environments where SMB-based remote execution is specifically required, modern Windows environments have several alternatives. These include PowerShell Remoting, OpenSSH, Microsoft Intune, Configuration Manager, and other centralized management platforms. You need to choose the mechanism based on authentication, encryption, application-control policy, auditability, endpoint-management requirements, and the organization’s security baseline.