What is Impacket – Bitdefender TechZone

atexec executes commands by creating a scheduled task on the target system using the Task Scheduler RPC interface (ATSVC). The task runs immediately and is then deleted. Output is redirected to a temporary file in C:\Windows\Temp\ named after the task (task name + .tmp extension), which the attacker reads back over the ADMIN$ share.

Forensic artifacts include Event ID 4698 (scheduled task created), Event ID 4699 (scheduled task deleted), Event ID 106 (TaskScheduler operational log, task registered), and Event ID 141 (task registration deleted). The scheduled task appears in the root task folder with a randomly generated ASCII name. Process creation events (Event ID 4688) show the command execution, and detailed file share access logs (Event ID 5145) capture the SMB read operations when the attacker retrieves the output file.

Windows allows remote task creation via the ATSVC RPC interface, a legitimate capability used by administrators to schedule maintenance jobs across multiple systems – Impacket reimplements this protocol from a non-Windows host.

smbexec creates a temporary Windows service for each command executed. The service runs the command via cmd.exe /Q /c, captures output to a temporary file (__output) written to C:\ via the C$ share, and writes the file to an SMB share that the attacker reads. The output file and service are both deleted immediately after execution.

Forensic artifacts include Event ID 7045 (service installed) and Event ID 4697 (service installation in Security log if auditing is enabled). The service name follows a recognizable pattern – typically a short random string. SMB share access logs (Event ID 5145) capture the output file read operation. Windows allows remote service creation and execution via the SVCCTL RPC interface, used by administrators to deploy and manage services across domain-joined systems. smbexec creates ephemeral services that execute and self-destruct within seconds.

wmiexec executes commands using the Windows Management Instrumentation (WMI) subsystem via DCOM. DCERPC (Distributed Computing Environment / Remote Procedure Call) is the underlying protocol Windows uses to enable services like DCOM and WMI to communicate between hosts. wmiexec leverages this protocol to issue remote commands. WMI allows remote process creation through the Win32_Process class. The command runs under WmiPrvSE.exe (the WMI Provider Host), and output is redirected to a file in the ADMIN$ share that the attacker reads back.

The command-line fingerprint is distinctive: cmd.exe /Q /c <command> \\127.0.0.1\ADMIN$\__<timestamp> 2>&1. This pattern – redirecting both stdout and stderr to a file in the ADMIN$ share using a loopback address – is a reliable behavioral indicator visible in process command-line logging (Event ID 4688). The output file is written to C:\Windows\ on the target (ADMIN$ maps to C:\Windows\) and is deleted by the tool after retrieval, but may persist on disk if execution is interrupted.

Forensic artifacts include process creation events showing WmiPrvSE.exe as the parent process of cmd.exe, and DCOM/DCERPC network traffic. wmiexec leaves no service and drops no persistent binary – detection relies on process ancestry, command-line patterns, and the transient output file rather than persistent file or registry artifacts.

psexec (Impacket’s implementation, not Sysinternals PsExec) drops a helper binary to the ADMIN$ share, creates a Windows service to execute it, and uses a named pipe for command output. The service persists until explicitly stopped. This is the noisiest of the four tools – it leaves a persistent binary, a service creation event, and SMB file write operations in the logs.

Forensic artifacts include Event ID 7045 (service installed) with a recognizable service name pattern (often “RemCom” or a variant), SMB file write logs (Event ID 5145) showing the binary being copied to ADMIN$, and the service binary itself, which remains on disk unless manually deleted.

The Sysinternals PsExec tool (a legitimate Microsoft utility) uses a similar mechanism but is signed by Microsoft and widely used for legitimate remote administration. Impacket’s psexec.py is unsigned, runs from a Python script on a non-Windows host, and supports pass-the-hash authentication – capabilities that distinguish it from the Microsoft version in a forensic context.

Impacket is not malware – it is a legitimate open-source Python library used by security researchers, penetration testers, and system administrators for protocol testing, auditing, and research. The malicious behavior is the way attackers use the toolkit against targets they do not own, not the code itself. Forensic analysts typically find Impacket execution traces on attacker-controlled hosts rather than binaries on victim endpoints. The toolkit does not spread autonomously, does not contain exploit code, and does not execute on the target system in most cases – the attacker runs it from their own machine.

This misconception applies to none of the four tools in default configuration. atexec writes a temporary .tmp output file to C:\Windows\Temp\, named after the task. smbexec writes a temporary output file (__output) to C:\ via the C$ share. wmiexec writes a temporary output file named __<epoch_timestamp> to C:\Windows\ via ADMIN$. All three delete the file after retrieval under normal operation, but interruption leaves it on disk -- and these files are recoverable from the MFT or USN journal even after deletion. psexec is the one tool that does not use a disk file for output -- it uses named pipes ("RemCom_communication", "RemCom_stdin", "RemCom_stdout", "RemCom_stderr") for command I/O -- but it drops a persistent helper binary to ADMIN$ that remains on disk until the session ends.

The more accurate framing is that three of the four tools write transient output files that are cleaned up under normal operation, while psexec drops a persistent binary but uses named pipes for command I/O. Advanced customizations exist – some actors route output through the registry via RemoteRegistry rather than writing to an SMB share file, a technique observed in the RedCurl operation – but these are not default Impacket behavior. The shorthand “Impacket is fileless” is wrong for every tool in its default configuration.

Not in the classical sense. Living-off-the-land (LOTL) techniques use binaries and scripts that are already present on the target system – tools like PowerShell, WMI, Certutil, or BITSAdmin that ship with Windows and serve legitimate administrative purposes. Impacket is attacker-owned Python code running on the attacker’s machine, usually Linux. It never touches the target as a binary. What it does instead is speak the same SMB, RPC, DCOM, and Kerberos protocols that legitimate Windows administration produces – so the network traffic blends in even though the tool itself does not live on the host. Call this “LOTL-adjacent” or “LOTL-style protocol abuse,” not LOTL. The distinction matters for detection – LOTL defenses focus on restricting or monitoring built-in Windows utilities, while Impacket defenses focus on behavioral anomalies in protocol usage.

Most Impacket execution tools require only valid credentials (password, NTLM hash, or Kerberos ticket) and network reachability to the target’s administrative protocols (SMB, RPC, DCOM). psexec and smbexec create a service on the target as part of their execution mechanism, but neither persists malware beyond the command execution itself. wmiexec and atexec execute commands using native Windows subsystems without installing anything persistent. An attacker who has compromised one system and harvested credentials can pivot to other systems using Impacket without dropping a single malicious file on the targets.

The protocols Impacket speaks – SMB (port 445), MSRPC (port 135 + dynamic high ports), DCOM/WMI (port 135 + dynamic high ports), Kerberos (port 88) – are the same protocols that domain administrators use for remote management, Group Policy deployment, software installation, and troubleshooting. Blocking these protocols at the network perimeter is feasible for external traffic, but blocking them internally would break legitimate Windows administration. Detection must happen at the behavioral layer rather than the network layer: flag anomalous service creation, scheduled task creation over remote RPC, WMI process creation from non-admin workstations, SMB traffic from endpoints to ADMIN$ shares, and authentication from systems that should not be authenticating to other systems. Network policies that limit which hosts can initiate administrative protocols to other hosts (lateral movement restrictions) reduce an attacker’s ability to pivot from a compromised workstation, but they require careful scoping to avoid breaking legitimate workflows.