This write up has a disclaimer at the bottom that you agree to prior to reading any other content on this post.
Today I asked myself, what is my attack surface, and how can I lower it. One function that computer admins love is remote desktop. It is amazing. It makes life so easy we would be willing to make security exceptions just to have it such as forwarding a port to be able to use it.
The problem with remote desktop is that it opens a very real security risk to our network, assume you are an admin on your box and someone was able to gain access to your RDP without you knowing. That box is connected to you home network where photos and excel sheets of budgets and CC info lay. Priceless videos of kids and important PDFs of job applications, let alone backups of those items. Drobo’s , media centers, installed apps with remember my password checked and whatnot. These are all things that a would be bruteforcer might want.
So in here lies the problem… I will split this into two problems but they have a single solution.
Problem: I want remote desktop access, but I want to mitigate as many risks as possible when I expose myself to the WAN. If you don’t care about the bruteforce guide you can skip to the solution below.
Problem: I would like to see how a bruteforce attack would work against a RDP connection so I can better defend against it.
First of all you will need a few pieces of software to get started.
-A Linux Box (Windoze can be substituted but this is beyond the scope of this guide)
-THC Hydra that can be download here.
-A word list (You can make one when we get to that point for the example)
-A target windows host that is able to accept RDP connections
Once you have your Linux box up and running you need to install THC Hydra, download and extract it. The application requires assembly via make so change directory to the extracted files.
This may need to be sudo make install depending on you level of access / where you are working
Once completed if you put in ls you should see a green hydra file. This what we will be using from now on.
Next we need to make a word list. This is the list that hydra will use against the remote host, it will contain passwords only. To save on room I have made the simplified list below, your list will be custom to you testing as it needs to contain at least one correct password.
Open up nano by typing: nano wordlist.txt
Enter in the following lines:
The password that my test box has for it is the word password I have placed it in the middle since I don’t want to make this too easy. Press Ctl+X to save the file.
Now we want to execute the attack, you will need the victims *ahem* test boxes IP address as well ass the assumed username, generally there is a administrator account, however if you are testing a domain / specific target you may want to change this.
Enter in the command:
hydra -t 1 -V -f -l administrator -P wordlist.txt rdp://192.168.0.100
Ok les break this down nice and quick:
hydra – The program assembled we via make.
-t 1 – Tasks set to 1, good enough for a VM but you can up it if you have a physical pc dedicated to this, too many threads will yield false results. Play with it.
-V – verbose, give me all output while you work
-f – quit once you found a positive user:pass match
-l administrator – use the username admin to attempt to login
-P wordlist.txt – This is the word list that we will be pulling passwords from.
rdp://192.168.0.100 – This is the target IP, customize to your liking attacks can be carried out over the WAN.
But my client is using port 3390, or 3391 or some other arbitrary port that they should not be using in the predefined port range! …No problem simply use the -s option followed by the port number to specify.
Your output will say something along the lines of:
[ATTEMPT] target 192.168.0.100 – login “administrator” – pass “123456” …
[ATTEMPT] target 192.168.0.100 – login “administrator” – pass “654321” …
[ATTEMPT] target 192.168.0.100 – login “administrator” – pass “admin” …
[rdp] host 192.168.0.100 login: administrator password: admin
[STATUS] attack was finished…
*Note: The user will be kicked to the lock screen if you get a successful user:pass while they are using the computer.
If your attack did not work, then its probably due to windows firewall being enabled or Network Level Authentication being set to on. I cover this in the solutions section below.
Solution: Enable Network Level Authentications, don’t use basic authentication.
This can be overlooked due to the fact when most users set up RDP they just want it to work, this is the problem with RDP. Scrubs spend so much time just trying to get it to work and think about security after so they choose (more compatible) when they set it up not (more secure). So by changing this setting you force the client to authenticate before making the RDP connection so that THC Hydra will fail. Interesting side not is it does not fail, it just sees all passwords as wrong. This setting will cause issues with services in a win/linux environment that use services like xrdp.
Another solution is to move the RDP port to something more obscure like 50001, this maybe not be obscure but most of the utilities i looked at automatically try ports 3389 (RDPs default) 3390 and 3391.
The final and more annoying but secure option is to look into 2FA or two factor authentication. This provides two kinds of protection, one that only the user with the device can log in, and notification when a user attempts to log in but is unsuccessful. This will help you gauge the amount of RDP attempts without having to look at the event viewer. Duo Security is not too bad I have used them in the past and they offer free accounts to non corporate users.
How ever implementing 2FA in you organization may be difficult so you may have to rely on event log. To do this I highly recommend Overseer Network Monitor, this is not an ad, or a scare and but tactic. I love this product, we used it in my previous environment and I would love it where I am working now. It allows event monitoring and email notifications.
There you have it! 4 ways to protect yourself from exploitation via RDP!
*2016-09-16 Update: I have been playing around with various 2FA solutions and I feel the Yubikey is a exellent solution for protecting RDP if properly implemented.
The instructions below should only be used on a local network against your own equipment unless granted explicit permission to do so from the owner of said equipment. This guide is not to be used to attack users over the WAN or people you don’t like / want to hack. The guide is provided for informational purposes only.
Be smart. Stay Safe.