Threat actors conducting Remote Desktop Protocol (RDP) attacks are increasingly using network tunneling and host-based port forwarding to bypass network protections, FireEye reports.
A Microsoft Windows component, RDP was designed to provide administrators, engineers and users with remote access to systems. However, threat actors have been using the technology for nefarious purposes, and the trend continues, especially since an RDP compromise is usually more difficult to detect than a backdoor.
“Threat actors continue to prefer RDP for the stability and functionality advantages over non-graphical backdoors, which can leave unwanted artifacts on a system. As a result, FireEye has observed threat actors using native Windows RDP utilities to connect laterally across systems in compromised environments,” the security firm notes.
RDP access to a system allows threat actors to achieve persistence, but it requires a different attack vector for the initial compromise (such as phishing). Furthermore, to gain access to non-exposed systems protected by a firewall and NAT rules, actors are increasingly using network tunneling and host-based port forwarding.
These allow attackers to establish a connection with a remote server blocked by a firewall and abuse that connection as a transport mechanism to “tunnel” local listening services through the firewall, thus rendering them accessible to the remote server.
One utility used to tunnel RDP sessions is PuTTY Link, or Plink, which allows attackers to establish secure shell (SSH) network connections to other systems. With many IT environments either not inspecting protocols or not blocking SSH communications outbound from their network, attackers can use the tool to create encrypted tunnels and establish RDP connections with the command and control (C&C) server.
RDP sessions also allow attackers to move laterally through an environment, and FireEye has observed actors using the native Windows Network Shell (netsh) command to use RDP port forwarding for network discovery on “segmented networks reachable only through an administrative jump box.”
“For example, a threat actor could configure the jump box to listen on an arbitrary port for traffic being sent from a previously compromised system. The traffic would then be forwarded directly through the jump box to any system on the segmented network using any designated port, including the default RDP port TCP 3389,” FireEye explains.
Thus, the threat actors abuse a jump box’s allowed network routes but don’t disrupt legitimate administrators who are also using the jump box.
Host-based and network-based prevention and detection mechanisms should provide organizations with the means necessary for mitigating this type of RDP attacks, FireEye says.
Disabling the remote desktop service when not in use, enabling host-based firewall rules to deny inbound RDP connections, and preventing the use of RDP with local accounts on workstations should help with the mitigation efforts. Reviewing registry keys, event logs, and other artifacts helps detecting such attacks.
At the network level, admins should enforce RDP connections to be initiated from a designated jump box or centralized management server, prevent privileged accounts from being used for RDP, review firewall rules to identify port forwarding vulnerabilities, inspect the content of network traffic, and set Snort rules to identify RDP tunneling in their network traffic.
“RDP enables IT environments to offer freedom and interoperability to users. But with more and more threat actors using RDP to move laterally across networks with limited segmentation, security teams are being challenged to decipher between legitimate and malicious RDP traffic. Therefore, adequate host-based and network-based prevention and detection methods should be taken to actively monitor for and be able to identify malicious RDP usage,” FireEye concludes.
Related: RDP Increasingly Abused in Attacks: FBI
Related: Hacker Offers Access to Machine at International Airport for $10
Ionut Arghire is an international correspondent for SecurityWeek.
Tags: 