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:
Account Name: AZUREUSER

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

Windows Event ID 4625

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.

Brute Force Attacks Against Windows RDP

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: 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:

Attribute Description
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: the IP address used by the attacker.

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:

Logon Type Description
2 Interactive - A user failed to login locally on to the computer - physical access.
3: Remote - A user failed to login remotely to the computer - remote access.
4 Batch - A batch program (process) failed to login.
5 Service - A service failed to login.
7 Unlock - The user failed the password trying to unlock the computer.
8 NetworkCleartext - A remote login failed and tried via clear text.
9 NewCredentials - A user failed to clone its login token for a new credential.
10 NewCredentials - A user failed to clone its login token for a new credential.
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).

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
  9. 487 guest
  10. 442 Administrateur
  11. 413 AZUREUSER
  12. 386 administrator
  13. 353 TESTUSER
  14. 349 AZUREADMIN
  15. 286 USER
  17. 230 Windows-Trunc
  18. 212 TEST
  19. 200 VMADMIN
  20. 199 SYSADMIN
  21. 196 DEMOUSER
  22. 182 SUPERADMIN
  23. 180 ADMINUSER
  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
  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:

Top countries used in brute force attacks against RDP

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 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
64 bytes from 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:

Top IPS used in brute force attacks against RDP

With many IPs from the range in there - covering almost 40% of all the attacks. The second most popular range 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: and, 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

Posted in   security-research   log-analysis   windows-logs     by Daniel Cid (@dcid)

Simple, affordable, log management and analysis.