How Hackers Move Between Windows Computers: PsExec, WinRM, and Lateral Movement Explained

In many cases, getting into one machine is only the beginning. If an attacker obtains valid credentials and those credentials have access to other computers, they may be able to move through the network without exploiting a new vulnerability on every system.

This is called lateral movement.

Windows has several built-in technologies that administrators use to manage computers remotely. Tools such as PsExec and Evil-WinRM use these technologies to run commands on another machine. In the wrong hands, stolen credentials and legitimate administration tools can be used to move between systems.

I wanted to break down how these methods work in plain English, because understanding the commands is only part of it. It's just as important to know which account is running the commands, what permissions it has, and what evidence the activity might leave behind.

What is lateral movement?

Imagine an attacker gains access to an employee's workstation using a compromised account.

That account might also have permission to connect to a file server or another workstation. If the attacker can authenticate to that second machine and has the required permissions, they may be able to run commands there, access files, or look for additional credentials.

They've moved from one system to another without necessarily exploiting a separate vulnerability.

The key ingredients are usually:

• Valid credentials, such as a username and password or an NTLM hash.
• Network connectivity to the target computer.
• A remote management service or protocol that can be reached.
• Sufficient permissions to perform the intended action.

Not every account can run commands remotely on every computer. Having a working password doesn't automatically make someone an administrator. The account's permissions and the target's configuration determine what is possible.

PsExec: Running commands as a Windows service

PsExec is a popular way to execute commands on a remote Windows computer. Impacket provides a Python implementation called psexec.py.

Let's look at what happens behind the scenes and why these steps can leave clues that security teams can detect:

1. Authenticate to the target over SMB (port 445) and open the IPC$ share.
2. Connect to ADMIN$ (which maps to C:\Windows) and upload a randomly named service executable.
3. Open a handle to the Service Control Manager (SCM) via the \PIPE\svcctl named pipe and call CreateServiceW. This generates Event ID 7045 (new service installed) in the System event log.
4. Call StartServiceW which is a binary that executes as LocalSystem. Input and output are redirected through named pipes.
5. On exit, the service is stopped, deleted, and the binary is removed from ADMIN$.

This is why PsExec gives you a SYSTEM shell rather than a shell as the authenticated user. Your commands run in the context of the Windows service, which executes as LocalSystem. It's also why PsExec is considered noisy: it writes a file to disk, creates a service, and generates multiple detectable event log entries.

Does Evil-WinRM leave evidence?

WinRM avoids some of the steps associated with PsExec. It doesn't need to use the same service-executable workflow, so it doesn't automatically create the same service-installation evidence.

However, it isn't invisible. Successful remote logons, WinRM operational logs, PowerShell logging, and endpoint monitoring may record the activity, depending on how the system is configured.

It's better to think of PsExec and Evil-WinRM as methods with different behaviors and evidence, rather than assuming one is always noisy and the other is undetectable.

PsExec vs. Evil-WinRM:

Which method works depends on the target, available permissions, network restrictions, and security configuration. A successful login with one protocol doesn't mean every other remote execution method will work.

Other Windows remote execution methods:

PsExec and Evil-WinRM aren't the only ways to execute commands remotely. Other tools use different Windows components, which means they have different requirements and may leave different traces.

WMI: wmiexec.py

Windows Management Instrumentation (WMI) is a Windows technology for managing and querying system information. Impacket's wmiexec.py can use WMI and DCOM to execute commands remotely.

It doesn't follow the same service-executable workflow as PsExec, making it useful to understand when investigating other forms of remote command execution.

DCOM: dcomexec.py

Distributed Component Object Model (DCOM) allows software components to communicate across computers. Impacket's dcomexec.py uses remote COM objects to execute commands. Whether it works depends on permissions, network access, and the target's configuration.

SMBExec: smbexec.py

SMBExec uses SMB and service-related functionality to run commands. It handles command output differently from PsExec and does not rely on uploading the same kind of service executable, but service creation can still leave detectable evidence.

AtExec: atexec.py

AtExec uses Windows Task Scheduler functionality to run a command remotely. When the relevant auditing is enabled, scheduled-task creation can generate Event ID 4698.

RDP: xfreerdp

Remote Desktop Protocol provides a full graphical desktop session instead of a command-line shell. It is useful when remote interaction with a graphical application is needed. Remote interactive logons may appear as Event ID 4624, Logon Type 10.

NetExec

NetExec is useful for checking credentials, enumerating SMB shares, and running commands remotely without opening a full interactive shell.

For example:

nxc smb 192.168.13.61 -u jdoe -p 'Summer2020!' -d thr.loc -x 'whoami'

The lowercase -x runs a command through cmd.exe. The uppercase -X is used for PowerShell commands.

These tools rely on different protocols and Windows features, so they aren't interchangeable in every environment.

The main thing to remember:

The biggest lesson with Windows lateral movement is that being able to connect to a computer is not the same as having full control of it.

PsExec and Evil-WinRM demonstrate this in different ways. PsExec can use a Windows service to provide a shell running as SYSTEM, provided the necessary access is available. Evil-WinRM gives you a remote PowerShell session under the authenticated user's security context, so that user's permissions still matter.

The same principle applies to the other methods. Each depends on particular protocols, services, and permissions. Understanding those requirements helps explain why a command succeeds on one computer and fails on another.

For defenders, the goal isn't just to recognize the name of a tool. It's to understand what the tool does, what normal administrative use looks like, and what evidence might indicate someone is using it in an unexpected way.

Once you understand the account context, the permissions required, and the traces left behind, Windows lateral movement becomes much easier to follow.

Disclaimer:

The content of this article is intended for educational purposes only.

The author does not condone or encourage illegal activities, and all methods discussed should only be used in legal environments, such as authorized penetration testing engagements or controlled environments for research. Unauthorized access to systems, networks, or data is illegal and unethical.

Always ensure you have proper authorization before conducting any form of security testing.