Hello again everyone! I’m releasing a book on how to secure your Remote Desktop Services infrastructure this year, and I’ll be posting some excerpts/topics from the book here on my PureRDS.org blog prior to its release. Please sign up here if you’d like to be notified when my book is released.
Recapping RDP Login Failure Correlation on RDS Session Hosts
In my first article on auditing remote desktop services login failures, I talked about how different authentication methods (e.g. NLA versus no-NLA) and operating system levels (Server 2008, Server 2012 R2, Server 2016) affect the ability to successfully audit RDP brute force attacks on RDS session hosts that are directly connected to the Internet. Because it’s so tedious to do this sort of log parsing manually, I elected to write and release a free tool called the RDS Log Viewer that would do this sort of correlation for you automatically. I updated that tool last year to do some Remote Desktop Gateway login failure tracking too. Later, I leveraged those RDP login and login failure correlation techniques to add some amazing IP geolocation tracking, interactive maps, and automated RDP login reporting to our commercial Remote Desktop Commander Tool.
“I Don’t Worry About RDP Hacking Attempts Any More, Because I Placed My RDS Deployment Behind a Remote Desktop Gateway.”
However, its becoming increasingly important to start auditing login failures through your Remote Desktop Gateway servers as well. For a while, there was a perception among admins running a Remote Desktop Services deployment that as long as you had your Remote Desktop session hosts placed behind a Remote Desktop Gateway, you were relatively impervious to brute force hack attacks. Now, in 2019, that idea cannot be farther from the truth.
As recently as late last year, brute force hacking tools and Python scripts, all easily downloadable from public GitHub repositories, have been updated to include modules that now attempt to brute force RDP gateway servers in addition to the session hosts themselves. At its core, the Remote Desktop Gateway is designed to receive authentication attempts over HTTPS – all it takes is a single, specially formed request to the gateway over 443 to make a login attempt. If you’d like to know more of the gory details about how this works – sign up here to be notified when my book is released.
So how do you know if your Remote Desktop Gateway servers are getting peppered with Brute Force attacks? It’s as simple as scanning for Event ID 4625 in the event log. Since Windows Server 2008, authentication failures to the Remote Desktop Gateway are recorded just like any other login failure, with the external IP address of the attacker logged in the event. Here’s an example:
Log Name: Security
Date: 2/6/2019 7:24:46 AM
Event ID: 4625
Task Category: Logon
Keywords: Audit Failure
An account failed to log on.
Security ID: NULL SID
Account Name: –
Account Domain: –
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: hax0r
Failure Reason: Unknown user name or bad password.
Sub Status: 0xc0000064
Caller Process ID: 0x0
Caller Process Name: –
Source Network Address: XXX.XXX.XXX.XX
Source Port: 6690
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: –
Package Name (NTLM only): –
Key Length: 0
As you can see, the username the attacker is using to bruteforce is in the Account Name subfield of the “Account For Which Logon Failed” section. Like most login attempts over the network (Login Type 3), the primary username will be displayed as NULL, but unlike direct RDP logins to terminal servers on certain Windows OS levels, we can actually get both the username and the IP address from a single 4625 event.
Note that if you have multiple services that users authenticate against over the Internet on the same VM/server as your RD Gateway Server, there may be authentication failures that originate from those services interspersed with the RD Gateway login failures. Unfortunately, since network login attempts can be treated the same way across the board by the Windows auditing subsystem, there may not be a way to attribute those login failures to one particular service over the other. Therefore, consider having only the RD Gateway service on a specific VM/server exposed to the Internet via specific firewall rules, so you know that all recorded login failures (Event ID 4625, Login Type 3) with a non-internal IP address logged are attributable to that service.