Analysis of a large brute force attack campaign against Windows Remote Desktop

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 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, that's how it looks like:

And these attacks have continued for the past ~week since we booted 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 ever hosted a website, like WordPress, you will see a lot of password guessing attempts against wp-login.php (or /xmlrpc).

And Windows is not immune to that. For the past 4 days that we have been tracking, that's how many password guessing attempts that happened per 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

And the number is growing each day. That's a lot more than the hundreds (some times low thousands) brute force attempts we see on our SSH logs from our 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.

Which you can ignore a big part of it. The pieces that matter are:

• AUDIT_FAILURE(4625): That's an audit failure with the event ID 4625.
• Logon Type: 3: The logon type 3 means it was a remote login attempt.
• Account Name: AZUREUSER That's the user tried (AZUREUSER).
• Source Network Address: 164.92.82.228 And finally, the IP address used by the attacker.

And if you ever see this Event ID (4625) on Windows, 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:

• Logon Type: 2     Interactive - A user failed to login locally on to the computer - physical access.
• Logon Type: 3     Remote - A user failed to login remotely to the computer - remote access.
• Logon Type: 4     Batch - A batch program (process) failed to login.
• Logon Type: 5     Service - A service failed to login.
• Logon Type: 7     Unlock - The user failed the password trying to unlock the computer.
• Logon Type: 8     NetworkCleartext - A remote login failed and tried via clear text.
• Logon Type: 9     NewCredentials - A user failed to clone its login token for a new credential.
• Logon Type: 10     RemoteInteractive - A user failed to login remotely via terminal services.
• Logon Type: 11     CachedInteractive - A user failed to login using network credentials that were stored locally on the computer.

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).

Analysing Remote Desktop brute force attacks.

No more wasting time, let's look at that data. The first piece we are interested in looking 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. Those are the top 40 user names we saw in our 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 largest 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 do 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 [email protected].

Posted in   windows   brute_force     by Daniel Cid (dcid)