Most of the tools we use to administer networks tend to be a double-edged sword. These tools provide a great deal of flexibility and allow for eased management of devices, services, and software alike. In the right hands we have nothing to worry about, but in the wrong hands our remote administration tools become powerful weapons that can be used by attackers to perform a wide array of malicious activities. In this article I am going to talk about a tool that fits this description. This tool is the Microsoft Sysinternals PsExec tool. In this article I’m going to give an overview of what PsExec is and what its capabilities are from an administrative standpoint. Following this, I am going to take the role of an adversary and demonstrate some of the nasty things it can be used for on a network.
This article aims to serve two audiences. The first audience consists of the system administrators who is responsible for protecting their networks from the use of tools like PsExec for malicious purposes. The other intended audience consists of ethical hackers and professional penetration testers who may gain some benefit from knowing a bit more about some of the things PsExec can be used for. Regardless of which audience you fall into its important that I provide the disclaimer that some of the commands and techniques I discuss here can be quite illegal depending on the circumstance in which they are used, so I urge to proceed with caution if any actions you are taking may be questionable.
What is PsExec?
The PsExec utility was designed as part of the PsTools suite, originally developed by Mark Russinovich of Sysinternals, now owned by Microsoft. The tool is coined as a command line based remote administration tool and allows for the remote execution of processes on other systems. It is very flexible in that it will allow for the use of alternate authentication credentials rather than those of the user executing it, meaning you can manage devices separated by domain and site boundaries. Not only can PsExec execute programs on a remote system, but it can also redirect console input and output between systems so that you can use interactive tools remotely.
Unlike most Microsoft associated software, the inner workings of PsExec are no secret and are fairly straightforward. PsExec allows redirects of the input and output of a remotely started executable through the use of SMB and the hidden $ADMIN share on the remote system. With this share, PsExec uses the Windows Service control Manager API to start the PsExecsvc service on the remote system which creates a named pipe that PsExec communicates with. This named pipe is what allows for input/output redirection back to the system that launched PsExec.
Playing Nice with PsExec
As per its original design, PsExec can be used to do a number of very useful things that can aide system administrators. One such scenario that I have found myself in a number of times is one in which I’ve known the DNS name of a computer but not the exact IP configuration settings (DNS server, default gateway, etc). Under normal circumstance I would use ipconfig on the local system to determine this information. In the vast majority of cases however, this might mean I would have to drive to another location or borrow a user’s computer, inherently reducing their productivity for the day. Since ipconfig has not capabilities for being run against a non-local machine, I can use PsExec to launch it successfully, as shown in Figure 1.
Figure 1: Using PsExec to launch ipconfig on a remote system
After PsExec is called, the remote computer is designated after the double slash (\\), followed by the ipconfig command. When you execute PsExec it defaults to the %SYSTEM% directory on the remote system you are attempting to run the command on, which is why I did not have to specify a full path here. Lastly, the /all switch for ipconfig is specified in order to output all available ipconfig information.
Another common implementation of PsExec is to use it for the deployment of updates, patches, and hotfixes. Although the typical preferred method of doing this is through Group Policy there may be instances in which that method is too slow. I’ve been in many situations where I’ve needed to deploy a high-priority security patch that can’t wait the duration of the standard group policy refresh time, so I’ve turned to PsExec to deploy the file in a more rapid fashion. An example of this is seen in Figure 2.
Figure 2: Launching an executable patch remotely
The command picture above utilizes some additional features. First, notice that there are two computer names separated by commas after the double slash (\\). PsExec allows you to specify multiple target devices here, or alternatively, a file containing a list of device names or addresses. The command also includes the /c switch, which is used when you want to specify a file on the local system to be executed on the remote system. In this case I’ve specified the file patch.exe. The file is located on my local system at the root of the C drive, so I’ve had to specify the full file path. The /c switch looks in the %SYSTEM% directory on the local system by default. As you can see, the file is executed successfully and the output is redirected back to the local console we are running PsExec from.
One last friendly usage of PsExec I’ve found to be very convenient is using it to remotely administer systems of a higher privilege level while using a system under a lower privileged account. I can’t count the number of times I’ve been on site working on a users computer and I’ve gotten a call that requires me to perform an administrative function such as a password change. Of course, in an Active Directory environment I could just RDP into a domain controller and perform this change, but I’ve had several clients who don’t use active directory or RDP for various reasons. When that is the case its fairly easy to pop in a USB flash drive and access the copy of PsExec I have installed on it. In the case of Figure 3, I’ve used PsExec to reset a users password on a system by elevating the privileges’ of the net tool as executed by PsExec.
Figure 3: Changing a user’s password by elevating PsExec’s privileges
Doing Nasty Things with PsExec
Now let’s take a walk on the dark side and look at some things that can be done with PsExec by those with potentially evil intentions. First off, let’s consider a scenario in which an attacker has obtained credentials for a system but doesn’t have any direct access to it. In this case, the attacker is aiming to gain GUI or command line control of the system but the avenues available for the use of these credentials may be limited. One method that can be useful in this situation is to use PsExec to run a backdoor executable on the system, like what is shown in Figure 4.
Figure 4: A malicious executable being launched remotely
In the case of this screenshot a remote attacker is using the PsExec with the /c switch to run the local file nc.exe on the remote system. Along with this, the -u and -p switches are used to specify the compromised username and password so that the file can be executed with root level privileges. Unbeknownst to the victim, the file that is being silently executed in actually a backdoor that will allow the attacker to connect to the system and receive an administrative command prompt.
An interesting thing about the attack we just looked at is that you actually don’t even need a user’s password in order to execute it. In all reality, all you need is the username and password hash of the user. In Windows, mathematical calculations are applied to user supplied passwords in order to make those passwords into an encrypted fixed-length string, called a hash. These hashes are a security feature designed to keep clear text passwords from being transmitted across a network. When authentication occurs, these password hashes are sent from one host to another. Using PsExec this can be taken advantage of by simply supplying the password hash instead of the password, shown in Figure 5.
Figure 5: Using a password hash to execute a file remotely
This example is the same as the one seen in Figure 4, the only difference is that a password hash is used in the place of the password. The receiving system has no problem accepting this hash for authentication purposes. There are a variety of methods for obtaining password hashes that are a bit beyond the scope of this article. I’ve written another article on this topic that be viewed here.
Another neat trick that PsExec makes possible is the ability to access files and spawn processes with the SYSTEM built-in account. The SYSTEM account on a Windows machine is the most powerful account and allows for access to pretty much anything, including some items that aren’t accessible by the administrator account and user created accounts.. Figure 6 provides an example for accessing the regedit application.
Figure 6: Accessing the registry of the victim
The command above is run directly on a local system but specifies the -s switch in order to use the local SYSTEM account. This is combined with the -I (interactive) option which runs regedit in interactive mode. Running this command will launch regedit with SYSTEM access which provides additional access to some interesting files. One such example of this is the SAM file that contains user password hashes. Given the right motivation, an attacker with access to a system and PsExec could easily extract all of the password hashes from the system using this technique, potentially providing him with information that may allow for the compromise of other systems or accounts.
A Few Caveats
Credentials in the clear – If you are concerned about who might be listening in on your network activity then PsExec is probably not the best tool to use. PsExec transmits all user credentials supplied to it in the clear, meaning that if you supply a username and password to access a system remotely, anybody with a copy of Wireshark or Tcpdump running can intercept the credentials.
Antivirus Detection – This used to not be as much of an issue, but now that most virus scanning applications do some level of system and memory monitoring most of them will catch PsExec being used on the system they are monitoring. If you are doing a penetration test on a Windows system and PsExec isn’t working as it should be then chances are you are getting blocked by antivirus, and worse yet, you may be letting the end user know you are toying with their system.
PsExec and Metasploit – When possible I never use PsExec by itself anymore. A modified version of PsExec is now included in the Metasploit Framework. Metasploit is a penetration testing framework that provides quite a bit of functionality. If you want to use PsExec for some form of security assessment then considering looking into the added functionality Metasploit provides with it. I actually used this version of PsExec in an article I wrote earlier on Passing the Hash techniques.
The PsExec tool has a lot of uses for a variety of intentions of the user. Hopefully, this article has helped to educate you on some of its features and how they can be used for wrong-doing. PsExec is the kind of tool that allows an attacker to be creative. Although I have only covered a few unique uses of the tool here I would dare to say that dozens or even hundreds of interesting attack vectors are available using its feature set. At some point I will plan on writing a follow up article containing more interesting and advanced uses for PsExec. In the meantime, if you have any interesting PsExec tricks then feel free to write to me directly for inclusion in the next article.