We have placed 5 honeypots, hereinafter simply "servers", to collect statistics on RDP brute-force in our networks.
One server was in London, the other in Zurich, one in a secure network in M9, two others in the Rucloud data center in a secure and unsecured network. The IP addresses of each of the servers are in different subnets, each IP address is distinguished by the first octet. If you try to measure the scan "distance" between IP addresses using the formula:
((First octet of subnet # 1) - (First octet of subnet # 2)) * (2 ^ 24),
If you scan for 0.0.0.0/0, an attacker will have to leaf through at least 771751936 IP addresses to find the two closest servers to each other. In addition, none of the servers responded to ICMP and each IP address was not used by anyone for 3 months, all 5 servers opened ports at the same time. All servers were connected to AD.
Multicolored graphics
We start with the interesting and end with the significant.
The start was good. The first bruteforcer got on the server in Rucloud in the first hour after the port was opened. On all other data centers, the server was discovered only in the second hour.
As you can see in the graphs, the brute force did not change much from day to day. And if you look at the time of day? Here are the graphs. Different colors are different days.
Time of day schedule dc ZUR1.
Time-of-day graph in secured M9 subnet.
Time of day graph in dc LD8.
Time-of-day graph in the protected Rucloud subnet.
Time of day graph in Rucloud.
A rather boring picture, we can say that the picture does not change depending on the time of day.
Let's look at the same charts by time of day, but in total for all data centers.
Stacked time-of-day graph.
Time of day graph.
The brute-force pattern does not change depending on the time of day. That is, the devices that participated in the brute-force attack are most likely always on.
Statistics of unsuccessful login attempts for each address on one unprotected Rucloud subnet.
In total, 89 IP addresses took part in the search for a whole week on one of the unprotected Rucloud subnets. 10 IP addresses filled 50% of 114809 attempts.
Statistics of unsuccessful login attempts for each address for all data centers.
The same damn thing, but only with statistics for all data centers. 50% of all statistics filled 15 IP addresses. There were more than half a million attempts on all five servers. How different were the attackers?
143 IP addresses were seen across all networks and only 29 IP addresses were seen on all 5 servers. Less than half of all attackers were attacking 2 or more servers. This means the scan distance between IP addresses matters. This means that the attackers obtained information about open ports using nmap, scanning IP addresses one by one.
Counting botnets
Looking at the reports and usernames that were used for the search, I was struck by the dictionaries that used different IP addresses, the number of logins in the dictionaries.
Suppose they are all different botnets with different vocabularies, then I counted N botnets. Here are the dictionaries for each of them:
admin, administrator, administrador, administrateur, admin, administrator, administrador, administrateur, ADMIN, USER, USER1, TEST, TEST1, ADMINISTRATOR, USER1, USER2, USER3, USER4, USER5, USER6, USER7, USER8, USER9, HP, ADMIN, USER, PC, DENTAL
This botnet was the largest and used the largest dictionary. There were many logins in different languages, incl. Russian, French and English:
1, 12, 123, 1234, 12345, 13, 14, 15, 19, 1C, CAMERA, CAMERA, ADMIN, USERL8, GVC, ADMINISTRATEUR, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADM, ALYSSA, ADMINISTRATOR, CAMERA, AT CAMERA, ADMIN, USERL8, GVC, ADMINISTRATEUR, USR_TERMINAL, JEREMY, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADMIN, ADM, SERGEY, OLEG, IRINA, NATASHA, SYSTEM, SERVICE, GVC, USTRATER ADMIN, ADM, SERGEY, OLEG, IRINA, NATASHA and so on, including even Chinese logins.
There were dictionaries that only used Chinese and English words. I was unable to extract Chinese characters from the database using Powershell. Here are just a part of the vocabulary of Chinese comrades:
SHENZHEN, TIANJIN, MANDARIN, CHONGQING, SHENYANG, XIAN, CONS, CHINA, TECHNOLOGY, ISPADMIN, BEIJING, SHANGHAI
There were also single IP addresses trying to iterate over these logins. Probably, just kids are playing:
USR1CV8, ADMINISTRATOR
ADMI, NIMDA, ADMS, ADMINS
There is just a stupid brute-force attack on passwords, a dictionary search, but there is a more or less interesting search. Attackers have the ability to get usernames, SMB shares, sometimes even password hashes, computer names, AD or WorkGroup domain names.
Security specialists know about BloodHound, and hackers know about it. If we leave AD in its default state, then we can steal the domain name, computer name, even hashes of user passwords. Habré has already written about attack vectors on AD and this tool. I recommend reading this brilliant material .
By the way, the first attack using the server name and domain started 13 hours after the ports were opened, but the attacker quickly fell behind, trying to break in only 138 times. The second such attack with the same dictionary was repeated 3 days later, but also did not last long.
A total of 5 botnets with different dictionaries. It will be necessary to collect more detailed statistics on the logins used in order to understand which ones are most often used and in what proportions. It is very likely that the first glance is blurred by not very accurate collection of all statistics and the real picture is a little more interesting.
Is this a problem?
From the beginning of self-isolation, we began to record a very strange server unavailability. At first, we chalked it all up to overloading the network of home Internet providers, Netflix and torrents, sometimes the infrastructure was not ready.
Suspicions about the infrastructure quickly disappeared when our few clients on Windows Server 2008, they could not go to RDP in principle. Having looked at the security log, we recorded record rates of attacks, more than 36 thousand attempts in 24 hours.
As it turned out, brute-force of sufficient intensity is capable of either completely killing RDP, or causing permanent breaks.
The genesis of the problem is not fully understood. Either RDP is put by the whole pack, or by some one attacker. The script and mstsc.exe failed to reproduce disconnects and picture freezes.
Either brute-force turns into DDoS, or some of the attackers have a brute-force implementation somehow in a special way, which also causes problems. The only thing that is clear is that the time to disconnect the connection coincides with the failed login attempts.
The most brutal attacks took place this summer in June, when our support recorded the largest number of RDP lags and breaks. Unfortunately, we did not collect statistics yet.
Source: Kaspersky
Decision?
Yes.
All you need to do to protect yourself is to cover yourself with a firewall. But I feel the same laziness as you, so I made these modules.
The modules work on Windows Powershell 5.1 and Powershell Core 7. The link to the project github is here . Now let's take a look at the functions.
Protect-Bruteforce
So far, the module is called that. Modifies the firewall rule by adding all successfully logged in IP addresses to the rule. Convenient for use in conjunction with a static IP address, simplifies deployment of remote desktop servers in conjunction with a VPN gateway.
Unprotect-Bruteforce
Resets RemoteAddress for default firewall rules.
Stop-Bruteforce
Scans the event log for failed logins and blocks IP addresses from the list with a separate "Stop-Bruteforce" rule.
Get-Bruteforce
Returns an array of statistics objects for each IP address. This function was used to collect statistics for the charts above.
Interview
We at RUVDS believe that the operating system should be delivered to the user in an extremely unaltered state. We think that in an ideal world, the operating system should be presented as it was in its stock state when it was first launched. But after all, functions, such as generating passwords from the personal account, not only simplify life, they are simply necessary for many of our clients. We want to know your opinion about this kind of quality of life pieces. Vote and comment.
