Menu

My RDS Honeypot in Azure – Usernames Susceptible to RDP Brute Force Attacks

March 5, 2019 - Remote Desktop Security

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.

Changing RDP Port in Azure

Remapping your RDP port in Azure still doesn’t keep the bad guys out

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.

The Bad Idea Bears Hate NLA

The Bad Idea Bears Always Want You To Disable NLA On Your Servers

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.

Andy Milford is the CEO and Founder of RDPSoft, and is a Microsoft MVP in the Enterprise Mobility / Remote Desktop Services area. Prior to starting RDPSoft, Andy was the CEO and Founder of Dorian Software, a log management company acquired by Ipswitch in late 2009. He loves creating easy-to-use yet powerful software solutions for SMBs and emerging enterprise companies.

Leave a Reply

Your email address will not be published. Required fields are marked *