Windows RDP: Attack targeting real account names

Question

We have a Windows 2012 R2 server hosted in a datacenter, and we are using RDP for its administration. Automatic updates are enabled.

RDP login is not allowed for the Administrator account, and there are several user accounts with RDP enabled.

I recently found in the logs that there was a brute force attack ongoing that was targeting one of the accounts that actually exists on the server. Looking deeper in the logs, I found that at least 3 accounts have been targeted recently. And this cannot be a coïncidence since the account's names are complex.

I have now restricted the connection to the IPs of my company, and the problem is solved (I know that this should have been done before but we had reasons not to do it).

However, I am still wondering how the attacker(s) managed to get the names of the accounts. Is it a known security flaw of RDP?

EDIT: There are a few elements that I did not mention: This server is a virtual machine, and both this VM and the hypervisor (Windows 2012 R2 also) are behind a router and share the same public IP. RDP is NATed with a public port that is not the default one, and this is the only NATed port. This machine hosts an HTTP server (kestrel) that can only be accessed through a reverse proxy (nginx) installed on another machine.

Given that RDP was open, perhaps file sharing was open too? If [this setting](https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares) isn't turned on, account enumeration may be possible - I'm not sure of the details. — Harry Johnston, Oct 22 '19 at 23:27
@Harry Johnston: RDP was the only Windows service opened, actually the machine is behind a router and RDP is NATed. — Olivier Leneveu, Oct 23 '19 at 07:03
RDP [does allow you to see the login screen](https://digi.ninja/blog/rdp_show_login_page.php) if NLA isn't enabled, and depending on how Windows is configured this may expose usernames. Might this have been the problem? — Harry Johnston, Oct 23 '19 at 09:36
@HarryJohnston: This is interesting, because I'm using NLA but with the option you suggested I can bypass NLA and reach the login screen. Some default setting that I should check I believe... Anyway, the login screen does not seem to expose any user name: There are only two inputs, one for the user name and one for the password. The user name is pre-filled with the account I'm using on my own computer. — Olivier Leneveu, Oct 23 '19 at 16:05
If I open the virtual console on the hypervisor, I can see the login screen with a list of all the accounts that are available on this server. Do you mean that this list could also be available through RDP if it is visible on the console? — Olivier Leneveu, Oct 24 '19 at 08:23
Possibly? I thought that was only true if NLA wasn't enforced, but I'm not entirely certain. There's a site our security team pointed me at recently that might have information about this stuff, I'll see if I can have a look tomorrow and get back to you. — Harry Johnston, Oct 24 '19 at 11:19
OK, the site is https://www.shodan.io/ (free account needed) and if you put an IP address into the search box then if RDP was available at that address (when the address was last scanned, I guess) it shows a screenshot. Unfortunately I can't find any information on that site about what exactly it is doing to *get* these screenshots but perhaps that will be helpful anyway. — Harry Johnston, Oct 24 '19 at 22:03
The server does not seem to be referenced. However I have tried with another server that has RDP opened and it was referenced but the screen capture was black. Anyway, I will keep that address in my bookmarks as there are some valuable informations here. And thank you very much Harry for the time you have spent helping me. — Olivier Leneveu, Oct 25 '19 at 10:29
How certain are you that the usernames were not intentionally or unintentionally exposed. What avenues for such exposure might there be? Are they so cryptic that a person would be motivated to store them (regardless of policy) somewhere for reference that then might have been compromised? Were they stored or communicated in a form that might have been backed up to a less secure location? Does anyone who knows them have a potential grudge against your employer or someone else there? — HumanJHawkins, Apr 02 '20 at 06:16
@HumanJHawkins This is the point. If there was a flaw in the RDP protocol allowing someone to get the account names, I could assume that it was a random attack. Otherwise, the problem is not the same... There are only 4 people who have an account on this system, for maintenance and administration. They are aware of the security rules, so I can expect that they did not wrote down their identifiers on a blog page as a reminder. — Olivier Leneveu, Apr 03 '20 at 08:51
I suggest limit Access IP for RDP , Best way is using vpn to connect user to your local network and then access RDP to them , whitout limitation security don't have any meaning — MohammadReza moeini, Oct 03 '20 at 12:14

score 0 · Answer 1 · answered Oct 08 '20 at 15:48

Overview

We cannot know for sure how they got the account names without knowing more details. From my personal experience, I will give you the most common ways bad guys get this info.

Assume Breach

There is a saying in the advanced cyber security field;

There are two types of organizations: those that are breached, and those that don't know that they are breached.

Since you are running an Active Directory Domain Services environment, it is easy for an attacker to dump a list of all account and use an application like BloodHound to chart a course to domain admin.

Easy Access

The bad guy can compromise a single domain joined workstation (may be through phishing or something else) then dump a list of all users and computers from the AD DS instance. You can't easily defend against something like this as this behavior is core to how AD DS works. You can easily dump everything as a standard user, no special or priv permissions are needed to do this.

Identity Perimeter

Security Through Obscurity is no longer an option, back in the early 2000s and 90s, it may have been but with automation and tools like BloodHound, you get the picture.

Security needs to be at the network and identity layer. A network only security perimeter is just a foolish as a Security Through Obscurity. Wired Magazine ran an article on this back in 2013.

An example of a security control that can help breaches at an identity level is multi-factor authentication. There are many more but that is an answer for a different question.

RDP/SMB Account Dumping

To the best of my knowledge, I am not aware of any attacks via RDP or SMB that would dump usernames from a computer as a direct result of the attack. I am aware of attacks that can gain access to the computer as an admin then with those rights they could dump, but not a direct attack that could dump.