Early October of 2020, a botnet started attacking my server over SSH, the one running this website. I run some automation that detected their attack and notified me of it after blocking their IPs. At first, I thought it was just the usual scans of ports and various non-comittal hack attempts I see every day or so, but the number of IPs increased with the same attempt methods without slowing down.
Since the attack began, my automation has blocked over 10,100 IPs and counting. They are rotating through a little over 100 IPs per day.
Unfortunately, I recently upgraded my server and got a new IP address with it, so the fun had to come to an end. With any luck though, they'll realize it and come back. It should be interesting to see if they do, which should tell me if they were attacking IP addresses they found running ssh, or if they were attacking domains (since my domain now points to the new IP).
Regardless, there are a few things that make this attack interesting.
They are attempting to guess passwords on my SSH server. The primary user being attacked is root (no surprise there), but they are also iterrating over a very large list of presumably common usernames, such as guest, admin, ubuntu, postgres, ftpuser, oracle, user, test, bot, common, jenkins, colord, django, dummy, foobar, john, news, webmaster, etc. So far they have tried just under 28,000 unique usernames (it took me a few days to notice a certain signature of the attack and update my automation to catch that as well) and appear to keep trying new ones alongside trying to break into root.
I'm guessing somewhere a list of common service account usernames was published and that is what they're iterrating over to try what I assume is common or even default passwords often used for the respective common account name.
The SSH server on my server does not listen on the standard port 22, which means they first scanned my server looking for listening services.
Further, the port on which SSH does reside is very obscure and outside of the standard 1000 port nmap scan, which means they took the time to do a full 65535 port scan, unless of course they just got lucky.
But what's extra interesting here is they aren't attacking the other services listening on my server which are listening on standard ports, like smtp and http. If they had done a full scan of my server, they certainly would have found all the other services. Granted, I know the toolkit to attack those protocols is different than a simple SSH brute force, but still, this gives us a better idea of which botnet might be doing this.
The countries of origin are from around the planet. Not in any particular order (in fact, sent through sort -R), the password attempts have come from China, Columbia, Netherlands, United States, France, Italy, Spain, Argentina, Singapore, North Korea, Lybia, Brazil, Chile, Hong Kong, Thailand, South Africa, Bulgaria, Germany, the United Kingdom, India, Japan, Georgia, Australia, Poland, Ukraine, Vietnam, Turkey, Mexico, Peru, Bangladesh, Malaysia, and Indonesia.
I'm sure there are more, but I didn't want to get rate-limited on lookups after the first few hundred. So far though, that makes 32 countries.
Given the signature of attack here, only attempting to brute force ssh passwords primarily for the root account and no other services, I think it is likely to be the Kaiji botnet. However, the attacks also include other usernames, though root is the primary, so it is possible another botnet is the culprit, or perhaps one based on Kaiji, or perhaps there are two different botnets.
Other possible candidates are the FritzFrog and Lemon_Duck botnets, as they both use a similar ssh brute force method.
Blocking these IPs is a bit annoying, as I keep getting notifications from my service when it does so. Since I don't have a full list of the IPs they might use, I can't preemptively block them all. But to be honest it's a bit gratifying to get a notification from my server saying it has blocked yet another IP address. It's almost become part of my morning routine now: wake up and check the IPs blocked while I was sleeping
That said, I think I am going to implement block digest functionality in my automation so I get fewer emails.
I could also move my SSH listening port to a different one, which would stop the attack immediately. They would have to do another full scan, which could yield some interesting logs. But more than likely I think, the botnet would just move on. But where's the fun in that?
This is always a fun option, especially because I have moved to a new server. However, I lack the time to watch what they're doing, so I just went ahead and shut the server down.
Well I'm glad you suggested that! Since I moved to my new server, thus ending the attack, the list of IPs I have for this botnet is incomplete, though it does contain a little over 10,300 IPs. You can find this list here. Note that that list almost certainly contains additional IPs not part of that botnet, as my server is routinely, uh, "tested", a few times a day by outside servers.
Additionally, if you are interested, I posted the top 200 or so passwords I sniffed from their attacks. You can also find those over here.
In short folks, DO NOT USE PASSWORDS FOR SSH ACCOUNTS. I know a lot of people just say outright, do not expose SSH to the internet. They would be mostly right. Publicly available SSH presents an incredible attack surface. But if you're going to do it, don't be dumb about it. If you use passwords, make them massive and complex, but better yet, just don't allow passwords. Use keys only, or even better, add OTP on top of the keys.
Last edited: 2021-07-16 00:22:07 UTC
This work is licensed under a
Creative Commons Attribution-ShareAlike 4.0 International License
by Aaron Ball