Lateral Movement – RDP

fortean (25)in #penetration • 7 years ago

The Remote Desktop Protocol (RDP) is widely used across internal networks by Administrators. This allows systems owners and admins to manage Windows environments remotely. However RDP can give various opportunities to an attacker to conduct attacks that can be used for lateral movement in red team scenarios. The attacks below can allow the red team to obtain credentials, to hijack RDP sessions of other users and to execute arbitrary code to remote systems that will use RDP as authentication mechanism to infected workstations.
RDP Man-in-the-Middle

Implementing a Man-in-the-middle attack can often lead to credential capturing. It is Performing this attack against RDP sessions will allow an attacker to trivially obtain the plain-text password of a domain account for lateral movement purposes. Seth is a tool which can automate RDP Man-in-the-middle attacks regardless if Network Level Authentication (NLA) is enabled. Implementation of this attack requires four parameters:

The Ethernet Interface
The IP of the Attacker
The IP of the victim Workstation (client)
The IP of the target RDP host (server)

1 | ./seth.sh eth0 10.0.0.2 10.0.0.3 10.0.0.1

Upon execution the tool will perform on the background a series of steps to ensure that the attack will be implemented successfully. These steps are:

Spoofing ARP replies
Enable forwarding of IPv4 traffic to redirect traffic from the victim host to the attacker machine and then to the target RDP server.
Configure an iptable rule to reject SYN packet to prevent direct RDP authentication.
Capture SYN packet of the destination host.
Clone of the SSL certificate.
Reconfigure iptables rules to route traffic from the victim workstation to the target RDP host.
Block traffic to port 88 to downgrade Kerberos authentication to NTLM.

Steps 1-3 will be performed prior to victim authentication. The user that will attempt to authenticate via RDP to the target server will be presented with the following message:

When the user will establish connection the credentials will appear in plain-text to the attacker.

RDP Inception

MDSec discovered a technique which allows an attacker to perform lateral movement inside a network by executing arbitrary code upon start up and propagates via RDP connections. To facilitate this attack MDSec developed a batch script to implement a proof of concept and a cobalt strike script. Executing the batch script on a workstation that an attacker has already gained access will result of a shell.

If an elevated user (Administrator or Domain Admin) attempt to authenticate via RDP with the host that has been already infected the batch script will be copied and on the system of the other user.

The batch script will be executed every time that the workstation starts in order to achieve persistence.

When the elevated user that has authenticated via RDP to the infected host restarts his machine the code will executed.

A new Meterpreter session will open however this time on the host of the administrator by abusing the RDP service and without the need to attack this system directly.

The list of active Meterpreter sessions will verify that the attacker has access on both systems.

RDP Session Hijacking

In the event that local administrator access has been obtained on a target system an attacker it is possible to hijack the RDP session of another user. This eliminates the need for the attacker to discover credentials of that user. This technique was initially discovered by Alexander Korznikov and it has been described in his blog.

The list of available sessions that can be used can be retrieved from the Windows Task Manager in the tab “Users“.

The same information can be obtained from the command prompt.

1 query user

Creating a service that will execute tscon with system level privileges will hijack the session that has 3 as ID.

1 | sc create sesshijack binpath= "cmd.exe /k tscon 3 /dest:rdp-tcp#0"
2 | net start sesshijack

When the service start the user “test” can use the session of netbiosX without knowing his password.

Mimikatz also supports this technique. The first step is to retrieve the list of Terminal Services sessions.

1 | ts::sessions

Attempts to use the session 1 directly will fail since Mimikatz has not been executed as SYSTEM. Therefore the following commands will elevate the token from Local Administrator to SYSTEM in order to use another session without the need to know the password of the user.

1 | ts::remote /id:1
2 | privilege::debug
3 | token::elevate