Brute force attacks against Windows Remote Desktop

We come from the Linux world and we don't use Windows very often. However, we have been "forced" to use it more here at Trunc lately as we work to properly support Windows logs. Because of that, we installed a Windows 11 Pro server on Azure as one of our testing servers for our Windows logging agent.

And I have to say - unrelated to this content - that the Windows experience has improved a lot. So much easier to use and cleaner than what it was back in the old Windows 2000/Vista days - yes, that's how long we have avoided Windows.

That being said, the other thing we noticed besides the better experience, is that just a few hours after installing the server, brute force attacks started to happen.

By looking at the Windows event log, we would see this type of log over and over from different IPs:

2022/05/31 17:32:29 WinEvtLog: Security: AUDIT_FAILURE(4625)
An account failed to log on.
Source Network Address: 20.197.4.216
Account Name: AZUREUSER


Or if you prefer to use the Event Viewer on Windows, this is what it looks like:



These attacks have continued for the past ~week, since starting the server.

How bad are those attacks against Remote Desktop?

Coming from the Linux world, we see and deal with SSHD brute forces all the time. Running my own mail server, I see Dovecot and Postfix as common targets as well. And if you have ever hosted a website, like WordPress, you will see a lot of password guessing attempts against wp-login.php (or /xmlrpc).

Windows is not immune to that. We've bee tracking this for 4 days, and here is a snapshot of the number of the number of guessing attempts this one, random, windows machine has been hit with each day:

• 2022/05/31: 910 (first day, only up for ~10 hours)
• 2022/06/01: 5,335
• 2022/06/02: 13,161
• 2022/06/03: 36,396

As you can see, the number is growing daily. That's exponentially more than the hundreds (some times low thousands) brute force attempts we see via SSH logs from vanilla Linux servers. This lead us to believe that Windows servers are more desirable targets than their Linux counterparts.

Understanding the Windows logging format for authentication failures (event id 4625)

Before we dive into the data, let's look at the Windows log to understand what is going on. If you are not familiar with the Windows logging format, every authentication success and failure is logged to the Windows event log. On newer Windows versions, it is logged as the Event ID 4625 for failures and as the Event ID 4624 for success.

The full log is pretty verbose and looks like this:

2022/06/04 02:53:09 WinEvtLog: Security: AUDIT_FAILURE(4625): Microsoft-Windows-Security-Auditing: no_user: no_domain: Windows-Test1: An account failed to log on. Subject: Security ID: S-1-0-0 Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Account For Which Logon Failed: Security ID: S-1-0-0 Account Name: AZUREUSER Account Domain: ? Failure Information: Failure Reason: %%2313 Status: 0xc000006d Sub Status: 0xc0000064 Process Information: Caller Process ID: 0x0 Caller Process Name: - Network Information: Workstation Name: - Source Network Address: 164.92.82.228 Source Port: 0 Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon request fails. It is generated on the computer where access was attempted.

You can ignore most of the stuff in that log. The pieces that matter are:

If you ever see this Event ID (4625) in your Windows logs, pay special attention to the Logon Type. Some services and internal applications can log failure with the Logon type 4 or 5, which are common and not a part of a remote attack. Logon type 2, on the other hand, means someone logged in physically on the computer. This is a quick cheat sheet with every Logon type:

Pay special attention to type 3, which is used for remote logins. Also note that when you login remotely via RDP (or fail the login), it uses the Logon Type 3, not logon type 10 (even though the documentation says it would be type 10).

Analyzing Remote Desktop brute force attacks.

Let's look at that data.

The first piece we are interested in looking at are the user names used in this attack. Attackers often like to use common user names that are going to be available on as many servers as possible. And on the remote desktop brute force, is not different. These are the top 40 user names we saw via the logs:

1. 41535 Administrator (~70%)
2. 2021 Administrador (~3%)
3. 1590 ADMINISTRATOR (~2%)
4. 1009 admin
5. 925 ADMIN
6. 687 user
7. 684 test
8. 683 WINDOWS-TRUNC
9. 487 guest
10. 442 Administrateur
11. 413 AZUREUSER
12. 386 administrator
13. 353 TESTUSER
14. 349 AZUREADMIN
15. 286 USER
16. 235 ADMINISTRADOR
17. 230 Windows-Trunc
18. 212 TEST
19. 200 VMADMIN
20. 199 SYSADMIN
21. 196 DEMOUSER
22. 182 SUPERADMIN
23. 180 ADMINUSER
24. 176 SERVERADMIN
25. 175 LOCALADMIN
26. 175 AZADMIN
27. 174 NETADMIN
28. 173 JOE
29. 173 ADMIN123
30. 173 ADADMIN
31. 153 DB2ADMIN
32. 131 GUEST
33. 102 SUPPORT
34. 95 LOGIN
35. 94 SYSTEM
36. 94 DIRECTOR
37. 42 STUDENT
38. 42 manager
39. 35 ADMINISTRAT?R
40. 34 SERVER

The vast majority (41,535 - close to 70%) used the Administrator username, which is often used by default on many Windows server. After that, they tried different variations of Administrator, including the translation to other languages (Administrateur: french. ADMINISTRADOR: portuguese) and other common names that could be available in the server. Windows does not log the passwords they tried, so we can't know which ones were used.

After that, we were interested in the countries (based on the geoip) where the attacks were coming from. We pushed these logs to Trunc and it gave us a nice breakdown:



To our suprise, PA (Panama) and MC (Monaco) accounted for almost 65% of all the attacks. The following countries (Poland, US, Russia) made more sense as they are bigger and we see them more often into attacks.

But Panama and Monaco didn't seem right. We dug more into the data and found that almost all requests from Panama came from this IP range 45.227.254.0/24 which is registered to Flyservers S.A, in Panama. The GeoIP shows Panama, but after doing traceroutes from a few locations, we found that it seems to be hosted in Poland as the ping from one of our Poland servers was very close to it:

ping -c 1 45.227.254.1
64 bytes from 45.227.254.1: icmp_seq=1 ttl=58 time=6.73 ms


It seems the GeoIP mapping to it was just wrong. Another interesting thing is that the whole range was already blacklisted for web brute force attacks on the noc reputation checker.

And those are the top 10 IP addresses:



With many IPs from the 45.227.254.0/24 range in there - covering almost 40% of all the attacks. The second most popular range 194.165.16.0/24 accounted for almost 30% of the attacks, was also hosted at Flyserver, but this time GeoIP mapped to Monaco.

We are not blaming this hosting company (Flyserver) for the attacks, maybe they just have many compromised servers in those locations. But we would recommend blocking both: 45.227.254.0/24 and 194.165.16.0/24, even if just to reduce the noise on your logs.

We will keep the server up and be monitoring these attacks to see how much they change over time. We will update this post with more details as it progress. If you have any questions or additional data that you want us to get from it, ping me at dcid@noc.org.