By now, word is out among admins that if you stand up a Virtual Machine in Azure or AWS and open up port 3389 to allow RDP access for administrative or app/desktop hosting purposes, you will receive relentless RDP brute force attacks. Hell, even if you change your endpoint / inbound port mappings in Azure to something other than 3389, the hackers are still probably going to find you! Public cloud providers like Microsoft and Amazon are just too juicy of a target for attackers to not scan every single port they can with NMAP, leveraging banner grabbing techniques with custom tweaked Python scripts on Kali Linux, etc, etc.
As part of my work on an upcoming book about Remote Desktop Security, I’ve set up a few honeypots in Azure to track hacking attempts and research hacking behaviors. Today’s blog post will highlight some of what I’ve learned about brute force attacks when system usernames are not known to the hacker. This presumes that you have at least made sure that Network Level Authentication (NLA) is enforced on your server with exposed RDP on the Internet. If you have DISABLED NLA on your server, then you’re in for a world of hurt. Not only is your server subject to DOS and DDOS attacks via RDP authentication attempts, but hackers can leverage RDP login screen banner scraping to deduce many of the usernames already present on your server. I discuss this more in my book but, suffice it to say, disabling NLA on a server with exposed RDP on the Internet is a really, really bad idea.
What usernames did the bad guys try to brute force on my RDP server?
Here’s a cross-section of some of the most-attempted brute force attack usernames. I was able to aggregate these by using the login failure collection feature of our commercial Remote Desktop Commander Suite tool.
| ADMINISTRATOR | 76780 |
| ADMIN | 4067 |
| USER | 2775 |
| TEST | 2139 |
| USER1 | 1349 |
| TEST1 | 1273 |
| AZUREUSER | 994 |
| MICHAEL | 376 |
| ADMINISTRATÖR | 360 |
| DANIEL | 355 |
| SCANNER | 343 |
| CRMADMIN | 333 |
| JOHN | 327 |
| DAVID | 305 |
| SYSADMIN | 287 |
| ADMIN1 | 286 |
| SPADMIN | 284 |
| SERVER | 273 |
| SCAN | 270 |
| JAMES | 270 |
| SP_ADMIN | 256 |
| MARK | 256 |
| SP_FARM | 254 |
| BRIAN | 251 |
| MIKE | 245 |
| ALEX | 237 |
| KEVIN | 235 |
I only included the top 25 or so usernames in terms of frequency. At the top of the list is ADMINISTRATOR, which is no surprise. Unlike other usernames, the Builtin Administrator account on Windows cannot be locked out, so hackers are free to wail upon that username without mercy. Admittedly this is Security 101, but:
TIP 1 – Rename the Builtin Administrator Account On Your Servers.
Preferably, rename it to something like jmer92331X, that is not your first name, your last name, or anything remotely approaching it! Because, as you can see from the other login failures, the next most frequently targeted usernames during brute force attacks are some of the most common first names in the Western world.
TIP 2 – Whenever Possible: Do Not Use Simple First Names as Remote Desktop Services Usernames, Don’t Use the Same Naming Convention as Your Organizational Email Addresses, and Decorate Your Usernames With Prefixes/Suffixes.
Hackers employing brute force attack strategies will certainly try common first names, as we can see in the frequency sample collected from my RDP honeypot server above. Likewise, if they have been able to determine your organization name through various server fingerprinting techniques (more on this in an upcoming blog post), they can then use any number of websites online to look up specific employees AND your default naming conventions to guess usernames on your RDP server. If you are synchronizing credentials across multiple services like Office 365 and Remote Desktop access, then employing some type of multifactor/two factor authentication mechanism for better security becomes essential.
If your RemoteApp/RDS environment is not integrated with your organization’s primary Active Directory, consider decorating usernames with suffixes or prefixes (e.g. jsmith_dept_hr, hr_dept_kjones) to make them harder to guess.
TIP 3 – If Possible, Rename Well Known Service Account Names On RDP Servers, and/or Deny Them From Being Able To Login Over RDP.
Looking at the cross-section of brute forced usernames, you will see well-known service account usernames like SP_ADMIN and SP_FARM. Consider renaming these accounts or, if you cannot rename them, make sure that they cannot logon via RDP to the server. You can do this by adjusting group memberships but, a more definitive way, is to load the Local Security Policy editor (secpol.msc), navigate to Local Policy, User Rights Assignment, and then add those accounts to the “Deny Log On Through Remote Desktop Services” user right.
Stay tuned for more from my RDS Honeypot series. And, please sign up to be notified when my book on Remote Desktop Security is ready.
Leave a Reply