Are you used to getting inundated with invalid certificate prompts when connecting to a remote machine? Way more often than not do I see self-signed certificates in play when establishing RDP connections. This always left me wondering… Surely this opens the door to a Man in the Middle Attack?
Insert Seth! Which is described by its authors as “A tool written in Python and Bash to MitM RDP connections by attempting to downgrade the connection in order to extract clear text credentials.”
Table of Contents:
- Installing the Tool
- Setting the Stage
- Performing the Attack
- Mitigation Strategies
Installing the Tool
You can download the tool from GitHub by using the following command.
sudo git clone https://github.com/SySS-Research/Seth.git
We have a couple prerequisites to install.
sudo apt install dsniff -y
Setting the Stage
In my demo, we have three virtual machines in play.
- Attacker VM running Kali Linux at IP address 10.0.0.139
- Victim VM running Windows 10 at 10.0.0.20
- Server/Destination VM running Windows 10 at 10.0.0.250.
The victim is going to sign into his computer, and then attempt to perform a RDP connection to the Destination VM at 10.0.0.250 using his domain credentials, NBA\dLillard. When he attempts the connection, he is prompted to enter a password.
Because IT admins are usually lazy, all machines are just using their self-signed certificates which generate certificate errors when users connect. Many users in the real world are actually numb to these errors because this is such a common misconfiguration left far too often. Because of this, majority of users will just ignore the certificate error that gets generated during the Man in The Middle attack.
Performing the Attack
The tool is actually very simple to use.
sudo ./seth.sh <INTERFACE> <ATTACKER IP> <VICTIM IP> <GATEWAY IP|HOST IP>
Using the above syntax, our command will look like this.
sudo ./seth.sh eth0 10.0.0.139 10.0.0.20 10.0.0.250
When we execute the above command, we just need to wait for the victim to attempt their RDP connection. Once they do, they’ll be treated with their normal credential and certificate error prompts, which should return their cleartext credentials to us.
The above example is showing output from Seth when the destination machine does not require NLA authentication. However, domain joined Windows 10 machines will enforce NLA by default, which means we will not be able to forward the connection request off to the server in order to establish the connection.
However, even with NLA enabled, Seth will spin up a fake server in order to attack the client and receive the cleartext credential. The end user’s connection attempt to the server will fail, but we’re still able to utilize the tool to grab what we need.
Warning When Using Against Local User Accounts
Be careful when using this tool against machine that are not domain joined, or against machines that authenticate over RDP using local user accounts.
I found that when I attempted to perform the attack to non-domain joined machines, the invalid hostname was passed to the destination server. The login was attempted using the local user account to the hostname of the victim, and not the local user account on the hostname of the destination. The attack still “worked” because I was able to extract cleartext credentials, but the end user was unable to authenticate to their destined computer and would know something was wrong.
Mitigation Strategies
Configure clients so they do not establish connections to a RDP host if they cannot verify its identity. This will require Public Key Infrastructure, either by purchasing public certification or rolling out your own infrastructure.
Windows machines can be configured in this way using the following GPO:
Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client\Configure server authentication for client
TAKE CERTIFICATE WARNINGS SERIOUSLY.. mm.kay?
Infinite Logins 