Detecting Impacket: Why Your Lateral Movement Is Noisy

TLDR: Impacket is the Swiss Army knife of lateral movement, but its default scripts leave distinct, high-fidelity artifacts in Windows Event Logs. By analyzing the specific service creation, file system, and registry modifications generated by psexec.py, smbexec.py, wmiexec.py, and dcomexec.py, defenders can easily identify and triage these activities. This post breaks down the detection logic for each script to help you distinguish between legitimate administrative tasks and active exploitation.

Lateral movement is where most red team engagements are won or lost. When you land on a box, the goal is to pivot, escalate, and dump credentials without triggering a SOC alert. For years, the Impacket library has been the go-to toolkit for this, providing a collection of Python classes that interact directly with Windows network protocols. Because these tools are so effective, they are also heavily used by adversaries, making them a primary target for detection engineering.

If you are a pentester, you likely use these scripts daily. If you are a researcher, you need to understand the footprint they leave behind to avoid burning your infrastructure. The reality is that while these tools are powerful, they are not stealthy by default. They interact with the operating system in predictable ways that, if you know where to look, make them stand out like a sore thumb in a SIEM.

The Mechanics of Noise

Each Impacket script handles remote execution differently, and those differences dictate the artifacts they generate. Understanding these mechanics is the difference between a successful engagement and getting kicked off the network in ten minutes.

psexec.py and the Service Binary

The psexec.py script functions by creating a service on the remote host. It writes a randomly named binary to the ADMIN$ share, registers it as a service, and communicates over a named pipe. From a detection standpoint, this is loud. You are looking for:

• Event ID 7045: A new service was installed.
• Event ID 4624: A logon type 3 (network) event associated with the service account.
• File Creation: The binary written to the ADMIN$ share.

The process hierarchy is also a dead giveaway. You will see the service binary spawning cmd.exe, which then executes your commands. If you are monitoring for services.exe spawning unexpected child processes, you are already halfway to catching this.

smbexec.py: The Fileless Approach

Unlike psexec.py, smbexec.py attempts to be more "fileless" by using a batch file for execution and a temporary file for output. It still creates a service, but it doesn't drop a persistent binary. The detection logic here shifts toward the command line. You will see cmd.exe executing a batch file in C:\Windows\Temp\ that redirects output to a file in the root of C:. If you see cmd.exe spawning from services.exe with a command line containing echo cd ^> \\127.0.0.1\ADMIN$, you are looking at smbexec.py.

wmiexec.py and dcomexec.py: The Stealthier Alternatives

These scripts are often preferred because they do not create a service. wmiexec.py uses the Windows Management Instrumentation (WMI) service, while dcomexec.py leverages DCOM objects like MMC20.Application.

wmiexec.py is particularly interesting because it spawns WmiPrvSE.exe, which then executes cmd.exe. Because it uses RPC for communication, you will see network connections over dynamic ports. The key artifact here is the process lineage: WmiPrvSE.exe -> cmd.exe. If you see this pattern, especially when it involves whoami or hostname commands, it is almost certainly a lateral movement attempt.

Practical Triage for Pentesters

When you are on an engagement, you need to know what you are leaving behind. The most effective way to test your own activity is to use Atomic Red Team tests. These tests allow you to execute specific techniques and immediately check your logs to see what was generated.

For example, the T1047 test for WMI execution is a perfect way to baseline your environment. If you run these tests against your own lab, you can use Sysmon to capture the process creation and network events. Tools like Sysmon View are invaluable for visualizing the process hierarchy and identifying the exact moment your script triggers an alert.

Defensive Considerations

Defenders should focus on baselining administrative activity. If your sysadmins are not using WMI or DCOM to manage workstations, any instance of WmiPrvSE.exe spawning cmd.exe on a workstation should be an immediate, high-severity alert.

Furthermore, disabling administrative shares like ADMIN$ and C$ on workstations is a massive hurdle for these tools. While it might break some legacy management scripts, it forces an attacker to find more complex, and likely noisier, ways to move laterally.

Ultimately, the goal is to force the adversary to work harder. Every time you force them to move away from a standard, "easy" tool like Impacket, you increase the likelihood that they will make a mistake and get caught. Keep testing your detection logic, keep baselining your environment, and never assume that a tool is "stealthy" just because it is popular.