Source: Unsplash
By: Yuval Lazar
If asked what is the most useful tool for both hackers and information security professionals, PSExec would probably win. The tool’s ability to run commands on remote machines makes it a particularly useful tool for both parties.
So what is this tool?
PSExec is part of a suite of Microsoft tools known as Windows Sysinternals, which aim to help manage and monitor Windows environments. The purpose of PSExec is to provide full interactivity to an end user with a remote system, without the need to install any software. Tools with similar functionality existed even before, like Telnet for example, which has many known weaknesses, and PSExec was built to be a better alternative. In addition, the tool allows you to run commands as System as well as to run commands on several computers at once.
Here you can see running the Whoami command on a remote computer and getting the output using Microsoft’s PSExec tool
The capabilities of the tool derive from the use of the RPC (Remote Procedure Calls) protocol, which enables communication with the operating system. As a result, the user can create, manage and initiate services on the operating system. The protocol uses some kind of traffic layer, the most common of which is SMB. Also the above tool – PSEexec , uses the SMB protocol as its transport layer, which allows it to scan open shares and upload files to the remote system. As a rule, it is not possible to run the tool without using the SMB protocol, as it is required in order to display the output of the operations performed remotely.
There are different implementations of the tool in a wide variety – both as a defensive tool, such as Cobalt Strike, and as an offensive tool. In the past it was even announced that PsExec was used in attacks by malicious groups such as Fin5.
Another implementation is by a library called Impacket, which allows access to Microsoft protocols such as RPC and SMB, through Python. This library offers a set of tools and examples for exploiting the protocols, including a Python implementation of PSExec that is very similar to Microsoft’s implementation. This implementation also uses the SMB protocol on port 445, in order to upload files so that it can transmit the output of the operations performed on the remote computer.
The use of the SMB protocol on port 445 turned on for us Red light. The research team, led by Alex Spivkowski, aims to investigate new avenues of attack and cyber weaknesses as well as monitor known weaknesses and the effects and dangers inherent in them. Port 445 is notorious in the information security community as a dangerous port that is a point of weakness and needs to be monitored. From this, he often encounters situations where the port is blocked or massively monitored, which supposedly prevents attackers from running attack tools that rely on this port, but at the same time also limits the IT team in the daily operations it needs to perform remotely. The PSExec tool also uses the capabilities of the SMB protocol, and cannot run if port 445 is not open, so we looked for a way to run the tool – without using port 445.
In the implementations we’ve discussed so far, the RPC protocol uses SMB as its transport layer, but we’ve seen that it can use other ways as well. In the same way it can, for example, run on port 139 – SMB on top of NetBIOS, without any change in the protocol itself.
Another way is that the RPC protocol can implement its own transport layer on port 135. We researched the issue, and set out to implement PSExec on port 135. Thanks to Impacket’s library, we used Python to build our tool. The tool we created does not rely on port 445 at all, and can run even if the port is blocked.
Moreover, it seems that not only the above tool can run on port 135 instead of 445, but other tools can be converted to use only port 135, which raises the need for massive monitoring of port 135 as well.
The next step in the research was to understand what the monitoring policy on port 135 is among information security professionals. In a quick research, we discovered that many information security agencies are not aware of the security risks inherent in port 135 or the set of capabilities that can be run on it and therefore do not monitor it at all and do not emphasize RPC traffic on this port.
Recently there have been several famous attacks that used RPC such as PetitPotam and DFSCoerce, so awareness of the risks that RPC presents is on the rise. The problem is that even with these types of attacks, Microsoft’s policy focuses on preventing NTLM Relay or privilege theft and rarely covers the dangers inherent in the RPC protocol. Since the mitigation strategy is focused on specific patches, the information security people do not internalize the need to monitor the RPC protocol and that is exactly what we are interested in changing.