How to Run Command Prompt on a Remote Computer

To run a command prompt on a remote Windows computer, use PsExec (psexec \\PC01 cmd) or PowerShell remoting (Enter-PSSession -ComputerName PC01). PsExec needs admin rights and access to the remote admin share. PowerShell remoting needs WinRM turned on. Both give you a prompt on the other machine, and both are tools attackers use too, so restrict and log them.

Three ways to run commands on a remote PC

Method 1: PsExec

PsExec is part of Microsoft's Sysinternals PsTools. It runs a process on another computer without you installing client software first. The current page for it is PsExec on Microsoft Learn. It runs on Windows 8.1 and later, and Windows Server 2012 and later.

1. Download PSTools from Microsoft and copy psexec.exe to a folder on your path.
2. Open Command Prompt as administrator on your PC.
3. Run: psexec \\PC01 -accepteula cmd. Add -u DOMAIN\admin if your current account is not an admin on PC01. PsExec asks for the password.
4. You are now at a command prompt on PC01. Type exit to leave. The temporary service is removed afterwards.

Useful switches from the documentation:

• -s runs the process as the SYSTEM account.
• -i runs the process interactively on the session's desktop.
• -h uses the account's admin token on Vista and later.
• -c copies a program to the remote PC and runs it there.
• -d does not wait for the process to finish.
• @file runs the command on every computer listed in a text file.

One command, no shell: psexec \\PC01 ipconfig /all prints the output on your screen.

Common PsExec examples

These assume you run them from an administrator prompt with admin rights on the target. Replace PC01 with your computer name.

• Run a command as SYSTEM: psexec \\PC01 -s cmd opens a prompt as the SYSTEM account. Use it for tasks a normal admin token cannot do, such as reading protected registry keys.
• Run one command and read the output: psexec \\PC01 ipconfig /all
• Copy a program and run it: psexec \\PC01 -c C:\Tools\cleanup.bat copies the file to the target and runs it there. Add -f to overwrite a copy that is already there.
• Run a script already on the target: psexec \\PC01 -s powershell -ExecutionPolicy Bypass -File C:\Scripts\check.ps1. The path is on the remote PC, not yours.
• Several PCs at once: psexec \\PC01,PC02,PC03 -s ipconfig /flushdns, or put one name per line in pcs.txt and run psexec @pcs.txt -s ipconfig /flushdns.
• Start something and walk away: psexec \\PC01 -d notepad.exe does not wait for the process to finish.

Run a small test on one PC before you point a command at a list. PsExec does what you tell it, on every machine you name.

Method 2: PowerShell remoting with Enter-PSSession

PowerShell remoting uses WinRM, which listens on port 5985 for HTTP and 5986 for HTTPS. On Windows Server it is on by default. On Windows 10 and 11 you turn it on once, on the target.

1. On the target, open PowerShell as administrator and run Enable-PSRemoting -Force. It starts the WinRM service, sets it to start automatically, creates a listener and opens the firewall exception.
2. On your PC, run Enter-PSSession -ComputerName PC01 -Credential DOMAIN\admin.
3. The prompt changes to [PC01]: PS>. Type cmd if you want a Command Prompt, or run commands directly. Exit-PSSession ends it.

By default only members of the Administrators group can connect. In a domain, connecting by computer name uses Kerberos. Connecting by IP address, or to a PC in a workgroup, falls back to NTLM, which is blocked until you configure HTTPS on the target or add it to the TrustedHosts list on your PC. On a public network profile, Windows 10 and 11 only allow connections from the same subnet, and Enable-PSRemoting refuses to run unless you add -SkipNetworkProfileCheck. Details are in Microsoft's WinRM security guidance.

Set up PowerShell remoting over HTTPS

Outside a domain, WinRM over HTTP on port 5985 has no Kerberos to authenticate the PC. HTTPS on port 5986 fixes that with a certificate. You need a certificate on the target whose name matches the name you connect with.

1. Get a certificate on the target. In production, issue one from your internal certificate authority. For a lab, a self-signed one works: $cert = New-SelfSignedCertificate -DnsName "pc01.corp.example.com" -CertStoreLocation Cert:\LocalMachine\My
2. Create the HTTPS listener in a PowerShell window run as administrator on the target: New-Item -Path WSMan:\localhost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $cert.Thumbprint -Force
3. Open the firewall: New-NetFirewallRule -DisplayName "WinRM HTTPS" -Direction Inbound -Protocol TCP -LocalPort 5986 -Action Allow. Limit the remote address to your admin subnet.
4. Connect with SSL from your PC, using the name on the certificate: Enter-PSSession -ComputerName pc01.corp.example.com -UseSSL -Credential DOMAIN\admin
5. Check it with Test-WSMan pc01.corp.example.com -UseSSL.

With a self-signed certificate your PC does not trust the issuer, and the connection fails until you import the certificate into Trusted Root Certification Authorities. The shortcut, -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck), turns off the checks that make HTTPS worth having, so keep it to a lab. Once HTTPS works you can remove the HTTP listener and close port 5985.

Method 3: Invoke-Command for many computers

Invoke-Command runs a script block on one or many machines at once and returns the results.

• One PC: Invoke-Command -ComputerName PC01 -ScriptBlock { hostname; ipconfig /all }
• Several: Invoke-Command -ComputerName PC01,PC02,PC03 -ScriptBlock { Get-Service wuauserv }
• A script file: Invoke-Command -ComputerName PC01,PC02 -FilePath .\check.ps1

Remote commands run in the user's context, and by default the remote PC cannot pass your credentials on to a third machine. That is the second hop problem. For more on running one script across many PCs, see how to run a PowerShell script on multiple computers and remote script execution.

Troubleshooting remote command errors

For PowerShell, Test-WSMan PC01 from your PC shows quickly whether the listener answers.

Security: restrict and log remote command tools

PsExec is a common attacker tool. MITRE lists malware such as LockBit 3.0 ransomware and NotPetya that uses it to run commands and spread across networks, and antivirus products often flag it for that reason. Remote admin tools should be a short, known list.

• Allow remote execution only from named admin workstations or a jump host, and only for admin accounts.
• Block inbound SMB (port 445) and WinRM between ordinary workstations. Admin traffic should come from one place.
• Log service creation (event 7045) and logons, and alert on a new service named PSEXESVC.
• Turn on PowerShell script block logging and keep the logs off the machine.
• Do not leave Enable-PSRemoting on for PCs that never need it.

MITRE describes how PsExec is abused and what to detect in Service Execution (T1569.002).

Managing this across many devices

PsExec and PowerShell remoting work well for a handful of PCs on one network. They are harder when devices are remote, off the domain or behind home routers, because each PC needs open ports and an admin account. trio.so runs scripts and gives a remote terminal on enrolled Windows, macOS and Linux devices from the console. See remote terminal.

Related reading: PowerShell execution policies, preventing remote code execution attacks and trio.so remote operations update.