Curious about a conversation of some weeks ago regarding noise on the
default telnet port (port 23), I downloaded the latest BBS list from the
Telnet BBS Guide and did a count of the most popular ports bulletin board systems were listening on.
Over 70% of BBSes on this list use the standard port 23. The next most
popular ports are 32, and 2323 (variants of "23"). A surprising number of systems (54 of them) run on the cheeky FTP data port [20].
Anyway, I took the top bunch and set up listeners on these ports for about 6 days using netcat (traditional) on a system which shouldn't have any inbound connections. Netcat hands inbound connections to a script which prints fake Login: and Password: prompts, and then, regardless of what is entered here, displays a fake # or $ shell prompt, depending on whether they're using root as the login or not.
My purpose was to get a sense of what the cost is of running on port 23, and also to see what these systems were doing when they did connect.
Port 23 is almost exclusively scripts, but these scripts are intended to log
in via telnet to deliver their payload. If this seems like an obvious statement, I make it because most of the other ports logged http GET
requests, which I take to mean they're trying to log into compromised
devices with web interfaces (or are simply spiders). I didn't detect inbound connections intending to establish a shell session on the other ports.
In six days, then, these are the unique number of IP addresses attempting to connect on these popular BBS ports:
23 - 1886 unique hosts
8888 - 2 unique hosts
1337 - 1 unique host
20 - 1 unique host
2002 - 1 unique host
2323 - 1 unique host
24 - 1 unique host
800 - 1 unique host
2300 - 1 unique host
28 - 0 unique hosts
30 - 0 unique hosts
32 - 0 unique hosts
513 - 0 unique hosts
6400 - 0 unique hosts
64128 - 0 unique hosts
6502 - 0 unique hosts
Unsurprisingly (but perhaps dramatically), port 23 is nearly constantly
pounded by what appear to be botnets.
A typical payload of a port 23 connection, and I didn't detect this on any of the other ports I was listening on, looks like this:
==================================================
LISTENING AT: 2023-01-28_11:37:12_UTC
TOTAL HOSTS: [ 252 ] since 1.14 days (27.53 hours) ===================================================
TIME/DATE.....2023-01-28_11:52:20_UTC
IP............89.22.39.162
HOSTNAME......auto.89-22-39-162.matrix-net.pl
CITY..........Suwalki
SUBDIV........Woiwodschaft Podlachien, Podlasie
COUNTRY.......Poland
ASN...........MATRIX Cezary Taraszkiewicz
CREDENTIALS...root / 666666
# enable
# system
# shell
# sh
# cat /proc/mounts; /bin/busybox YUYHC
Note that nearly every system which connects through and runs commands at the shell prompt is remarkably consistent in what it attempts to do. My script doesn't actually print responses to those commands (mocking some up is the next step) so I am unsure if there if there is IF-THEN logic which will trigger other things if those commands return something interesting to the script.
They all end with an attempt to run a compromised busybox executable, but the "YUYHC" string is different for every login. It is unclear what a compromised busybox executable would do, although a fair guess is, among other things, it would begin to try to log into other systems similarly. Perhaps the compromised busybox downloads a remote payload and installs it.
Anyway if you wondered what all of that was on your port 23, it is almost certainly a lot of this sort of thing.
I also captured all of the credential pairs these scripts think will get them in. I assume the scripts are intended to find known compromised appliances like security cameras, routers, switches, and so forth.
Most of these hits come from China. It is unclear whether these are coordinated attacks from a central authority or whether there are just a lot of compromised machines in China (it's a huge country) reaching out.
It does make me wish that when BBSes went online, they standardized on a different service port than 23. 23 is a cesspool.
My router at home monitors all ports from /etc/services - none of which have ever allowed ingress - just to see what's knocking on my residential internet connection's door (don't judge, we all have hobbies. Some dudes surf. Some work on classic cars. I monitor my ports. Chicks. Dig me. For this. Like surfers. I...I'm cool.)
For the month of January 2002, these are the top ports in /etc/services that machines on the Internet are trying to connect to:
Port 23 - 13116 hits [telnet]
Port 22 - 5067 hits [ssh]
Port 8080 - 4378 hits [http-alt]
Port 80 - 2864 hits [http]
Port 443 - 2032 hits [https]
Port 1433 - 1426 hits [ms-sql-s]
Port 123 - 815 hits [ntp]
Port 8081 - 800 hits [tproxy]
Port 53 - 686 hits [dns]
Port 3306 - 465 hits [mysql]
Port 21 - 453 hits [ftp cmd]
It's interesting to me that in 2023, telnet is the most thwacked of all ports, when it is largely considered deprecated. Not only that, it is the top port by a very large margin.
If you ever read a tech forum in which anyone even mentions 23, there's a pile-on from forum participants immediately attempting to discourage the poster from running anything on that port; the disdain for it is almost pathological, and the assumption is that whatever the poster is attempting to do with telnet should almost certainly be done with ssh instead.
Yet for all that, here we are, port 23, the trashy reigning king of all ports. The most popular person in school. Somehow.
If anyone is interested in more details about this, I put the logs online. They include some nice credential pairs, if you want to blacklist them or at least audit your system for them (it is unlikely anyone here has these login/password pairs since they appear to be limited to known compromised devices, rather than normal system account defaults on PC-based operating systems). However, a blacklist on the login names themselves should blunt nearly all of this traffic since presumably no one here allows "root" or "admin" as a username on their system:
http://shibboleths.org/ibr/
When I have time, I am going to punch up these scripts so they look like more convincing honeypots, returning bogus but plausible data for each of the commands.
--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: Shipwrecks & Shibboleths [San Francisco, CA - USA] (21:1/227)