[ad_1]

Security researchers have developed an implementation of the Sysinternals PsExec utility that allows roaming laterally in a network using a single, less guarded port, Windows TCP port 135.

PsExec is designed to help administrators run processes remotely on network machines without the need to install a client.

Threat actors have also embraced the tool and frequently use it in the post-exploitation stages of an attack to spread across the network, run commands across multiple systems, or deploy malware.

Impacket is a collection of Python classes for working with network protocols

PsExec and the TCP ports it needs

Although the original PsExec is available in the Suite of Sysinternals utilitiesthere is also an implementation in the Impacket collection of Python classes for working with network protocols, which supports SMB and other protocols like IP, UDP, TCP which allow connections for HTTP, Lightweight Directory Access Protocol (LDAP) and Microsoft SQL Server (MSSQL).

The original version and the Impacket variant work the same way. They use an SMB connection and are based on port 445, which must be open to communicate over the SMB network file sharing protocol.

They also manage Windows services (create, run, start, stop) through remote procedure calls (RPC), a protocol that allows high-level communication with the operating system.

For extended functionality, however, port 135 is required. However, blocking this port does not prevent a malicious actor from carrying out an attack, which is why port 445 is essential for PsExec to work.

For this reason, defenders mainly focus on blocking port 445, which is essential for PsExec to execute commands or files. This works in most cases but is not sufficient.

New implementation of PsExec

Based on the Impacket library, researchers from Pentea company that provides an automated security validation solution, has created an implementation of the PsExec tool that runs only on port 135.

This achievement brings changes to the defense game since only blocking port 445 to restrict malicious PsExec activity is no longer a reliable option for most attacks.

“We found that the SMB protocol is used to download the binary and to transmit input and output,” says Yuval Lazar, senior security researcher at Pentera.

Lazar adds in a report shared with BleepingComputer that the commands are executed via distributed computing environment/remote procedure calls (DCE/RPC) and that the processes “run regardless of output.”

PsExec commands executed using DCE/RPC calls
Run PsExec commands on port 135
source: Pentera Labs

Pentera’s PsExec variant uses an RPC connection that allowed researchers to create a service that executes an arbitrary command without communicating through SMB port 445 for transport or output.

PsExec implementation uses DCE/RPC connection without SMB
Pentera’s PsExec implementation creates a DCE/RPC connection without SMB
source: Pentera Labs

Full monitoring is required

Unlike the original PsExec from the Sysinternals suite, Pentera’s variant is more likely to go undetected in a network, Lazar told BleepingComputer, because many organizations monitor port 445 and SMB.

“What we have noticed is that while many organizations implement a lot of mitigations based on SMB and port 445, they neglect other important ports such as 135” – Yuval Lazar, Principal Researcher in safety at Pentera

Another point made by Lazar is that other PsExec implementations must use SMB because they are file-based. The Pentera variant is fileless, the researcher said, which would make it harder to detect.

Lazar’s research on PsExec highlights that if security vulnerabilities like PetitPotam [12] and DFSCoerce have drawn attention to the risk posed by RPC, the mitigations do not focus on DCE/RPC monitoring but on preventing NTLM relays.

According to Pentera’s observations, blocking or monitoring RPC traffic is not a common practice in enterprise environments. The reason in many cases is that defenders are unaware that RPC can introduce a security risk to the network if left unchecked.

“Security teams need to understand how different ports can be used by hackers so they know what to watch them for” – Yuval Lazar

Will Dormanvulnerability analyst at CERT/CC, agrees that blocking TCP port 445 alone is insufficient to block malicious activity relying on the tool.

“If people think blocking 445 is enough to prevent PsExec (and other RPC-related things), then they’re wrong,” the researcher told BleepingComputer.

PsExec is based on SMB and RPC connections, which require ports 445, 139, and 135. However, Lazar added that there is an RPC implementation in addition to HTTP, which means PsExec could also work on port 80.

PsExec popular with ransomware actors

Hackers have been using PsExec in their attacks for a long time. Ransomware gangs, in particular, have adopted it to deploy file-encrypting malware.

In an attack that only lasted an hour, NetWalker ransomware used PsExec to run their payload on all systems in a domain.

In a more recent example, the Quantum ransomware gang relied on PsExec and WMI to encrypt systems in an attack that only lasted two hours after gaining access via IcedID malware.

A Microsoft report in June details a BlackCat ransomware attackwhich also used PsExec to distribute its ransomware payload.

Another example is taken from the recent disclosure Cisco Violationwhere the Yanluowang ransomware gang used PsExec to add registry values ​​remotely, allowing the threat actor to take advantage of accessibility features available on the Windows login screen.

Update [September 13, 10:10 EST]: Article updated with commentary from Will Dormann, Vulnerability Analyst at the US CERT Coordination Center.



[ad_2]

Source link