Brute Force RDP Hacking Is a Lot More Sophisticated Than You Think

In my last article, I showed you some of the most frequently targeted usernames for brute force RDP attacks on one of my RDP honeypot servers in Azure. Not surprisingly, hackers loved to target the built-in Administrator account, followed by common first names, and then common, built-in service accounts.

The purpose of this article will be to show you how SOPHISTICATED brute force hacking attempts against RDP have gotten in recent years. I’ll share real samples from the login failure tables that my Remote Desktop Commander Suite software maintains to prove my point.

Account Lockout Policies – No Longer a Panacea… and Often a Liability!

Back in the late 90s, when I was a young whippersnapper of a college network admin (this was in the wild west days of Windows NT 4.0), defining and setting account lockout policies at the domain level was a commonly accepted best practice. Nowadays, with the proliferation of single sign-on authentication and unified account directories like Azure Active Directory, defining aggressive account lockout policies as a prophylactic security measure no longer makes sense in many circumstances.

In fact, in a Remote Desktop Services environment, aggressively defining account lockout policies can have several serious consequences, and is largely ineffective.

Let’s examine why:

1. It sets the stage for an eventual DDOS (Distributed Denial-Of-Service) attack that can lockout wide swaths of your user base, creating a huge headache for your admins and service desk help techs if/when that occurs.
2. It also increases workload for your admins in general, as a certain percentage of your user base (gotta love the ID10T users) will always fat finger their passwords and lock themselves out. If your RDS environment is linked to your domain, an RDP-originated lockout can effectively prevent them from accessing any other services. Yikes!
3. Modern RDP brute force attacks, as I will now demonstrate to you, skirt around all but the most draconian of account lockout policies, rendering them hopelessly ineffective.

What About Intrusion Detection Systems? Will They Help?

It’s truly an arms race right now between black hat hackers and IDS vendors, in terms of attack techniques versus IDS countermeasures and detection algorithms. I’m sure there are some IDS vendors out there that have developed better detection algorithms for RDP brute force attacks, but the most sophisticated modern brute force attacks are designed to blend in with normal background login failures from users. By that very nature it makes it harder for an IDS system to detect. That’s why month after month we read about one company after another getting PWNED by ransomware and/or their sensitive data getting exfiltrated, where the initial attack vector was RDP.

How are hackers / nation state actors / cybercriminals getting around account lockout policies? They do several things:

• They leverage botnets or similar to make RDP login attempts originate from many different machines. When you look at these login trials and geolocate their origin, you see bunches of different IP addresses from across the world.
• They rotate through username password combinations, trying the same username a few times over an extended period of time (30 minutes, 1 hour, 3 hours). In many cases, different usernames are interleaved with one another. By spreading out the attempts and rotating the usernames, the login failures look more organic and benign to an IDS. Also, the lengthy duration in between those attempts prevents lockout of the account.

In a coming article, and in my upcoming book, I’ll talk more about the tools and Python scripts they use to accomplish these brute force techniques. I’ll also speak on how you can block these sorts of attacks using the Remote Desktop Commander Suite solution I built. For now, I’ll conclude this article with a sample of logon failures I obtained from my RDP Honeypot in Azure.

Time Logged	Username	Attacker IP
12:00:09 AM	COLUMBIANA	xxx.209.0.46
12:00:17 AM	SAUL	xxx.209.0.30
12:00:20 AM	LAW	xxx.238.46.140
12:00:21 AM	AAFDEV	xxx.209.0.45
12:00:27 AM	NETADMIN	xxx.238.46.121
12:00:29 AM	WSP1	xxx.238.46.140
12:00:36 AM	SBSADMIN	xxx.238.46.140
12:00:46 AM	VISITOR	xxx.242.228.45
12:00:51 AM	ADMINISTRATOR	xxx.71.243.115
12:00:59 AM	ADMINISTRATOR	xxx.43.157.98

Above, you can see exactly what I mentioned. Multiple usernames are being tried, with only ADMINISTRATOR being repeated, and only one IP address was used more than once.

Time Logged	Username	Attacker IP
12:32:54 PM	WALTER	xxx.156.177.193
5:38:28 PM	WALTER	xxx.156.177.192
7:41:56 PM	WALTER	xxx.156.177.192
7:42:29 PM	WALTER	xxx.156.177.192
7:53:30 PM	WALTER	xxx.156.177.192
10:22:44 PM	WALTER	xxx.156.177.193

Yet looking at the above, if we filter out login attempts for a specific user, we’ll see that the login failures for “WALTER” are all coming from the same two IPs in the same subnet. As you will also notice, “WALTER” only managed 6 login failures in a 12 hour period, none of them too close to one another. Is “WALTER” a real user who is klutzy with his passwords, or part of a huge RDP brute forcing botnet?

When we as humans look at all of the data holistically, we know “WALTER” is part of a larger distributed RDP bruteforce attack. But will your IDS be able to make that judgment call? Till next time…