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: 126.96.36.199
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.
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:
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.
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: 188.8.131.52 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:
|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: 184.108.40.206||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:
|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).
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:
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 220.127.116.11/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 18.104.22.168
64 bytes from 22.214.171.124: 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 126.96.36.199/24 range in there - covering almost 40% of all the attacks. The second most popular range 188.8.131.52/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: 184.108.40.206/24 and 220.127.116.11/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 firstname.lastname@example.org.