If it was possible to nominate a command-line utility for an award, PsExec would definitively win the most useful category. This tool allows administrators to run remote commands as if they were on the local computer. But unfortunately, not only network administrators love this tool, so do hackers.

Sysinternals 101

Windows Sysinternals is a suite of tools which supplies users with numerous free utilities and resources to manage, diagnose, troubleshoot, and monitor a Microsoft Windows environment. One of these tools is a command-line utility for Windows called PsExec, which was built to replace tools like telnet, that forced you to open up ports and introduce security vulnerabilities. PsExec allows full interactivity for console applications without any setup or installation of a client software, which makes it very easy to use. It can launch interactive command prompts, run as a local system on remote computers, run commands on multiple computers at once and more.

How does it work? 

Before we dive in, let’s talk for a minute about Remote Procedure Calls. RPC is a protocol that provides high-level communication with the operating system. It relies on the existence of a transport protocol, such as TCP or SMB for carrying the messages between communicating programs. RPC implements a lot of functions that can help a user to create, manage and execute services on the operating system. 

PsExec usually uses the SMB protocol to run, and most often runs on port 445 for its common uses. It requires SMB to enumerate the writable shares, so it can use one of the writable shares  to upload an executable to it. The tool also uses SMB to supply the user with output of the commands. 

PsExec requires three parameters in order to run – a computer name, credentials, and a command. As we said, it does not require any installations; all that’s necessary for PsExec to work are: 

• File and Printer Sharing to be enabled on the remote machine
• An available shared folder 

Let’s give it a try

Usually, PsExec will require the share folder $Admin, which is an administrative share. Luckily, this is a very common configuration on most Windows computers, so we can get started with running PsExec Using SMB file sharing, the tool will upload an executable called PSEXESVC.exe, then it will use RPC to create and start a Windows service on the remote computer, which in turn will run the program with the relevant arguments. 

In the above screenshot, you can see that we are running cmd on a remote computer using PsExec, by supplying a username and password. This is just the tip of the iceberg, and there is much more that can be achieved using this tool. 

Can you make it easier? 

Since PsExec is such a useful tool, there is another implementation of it in the Impacket Library. Impacket is a collection of Python classes used for working with network protocols, built by SecureAuth Labs. The library provides a set of tools as examples of what can be done within its context, one of which is a python implementation of the PsExec tool. 

This implementation also uses an SMB connection and is based on port 445. It uses DCE/RPC methods such as the SVCCTL named pipe, which is used to manage Windows services via the SCM (Service Control Manager). 

The basics of this implementation work much the same as the PsExec Windows tool, with just a few tweaks. The Impacket Library implementation of PsExec has the option to:  

• Supply a file to run. If we do not provide a binary file, then the default binary that the program runs is taken from RemCom, another open source project. 
• Provide a service name. If not provided, a random 4 letter word is used. 

Once the user exits the console or the command has finished, SCM is called to close the service, the exe file is deleted and the SMB connection is disconnected.

Oops I did it again

So up until now, we talked about two implementations, which operate in the same basic way and use port 445. But what if port 445 is blocked? What can we do then?

Using the Impacket infrastructure, we were able to build an implementation of PsExec based solely on port 135. We found that the SMB protocol is used to upload the binary and to forward the input and output, but as we explained, the commands are executed using DCE/RPC calls, and the processes will run without consideration of the output. 

By using RPC calls we can create a service that will run a command of our choice, and start the service, without the use of port 445. This implementation does not offer a running output, but there are ways to overcome this. 

Here you can see an example code from the implementation, that will create a DCERPC connection without the use of SMB as transport or output. 

Conclusions

As protectors, we mostly focus on port 445 as the “source of all evil” and monitor it everywhere. Yet sometimes we forget that port 135 can also run SMB, and not only port 445. 

Now, SMB is not the only exploitable protocol. DCE/RPC, as discussed above, is a far more valuable protocol for hackers as compared with SMB, yet is many times overlooked and not monitored correctly. DCE/RPC is a primary target used for lateral movement in the network, as is often demonstrated by Pentera’s validations – many times without even being noticed by the Blue Team. Don’t let this blindspot undermine your own security posture. It is clearly necessary to implement mitigations for port 135 and closely monitor DCE/RPC.

For any questions, feel free to reach out at yuval.lazar@pentera.io or read more research from Pentera Labs.