0

A VPS running Ubuntu 14.04.5 LTS is consuming nearly 300% of CPU capacity. It is identified running top as cER6XH.

Is there any way to track down what this process is and why it may be going rogue?

Jerome
  • 175
  • 7
  • If you really want to do forensic analysis, take a snapshot of the VPS storage and work on it offline from another system. You should be most concerned about getting rid of the crypto mining, spamming, malware you have as quickly as possible, and the only way to do that is to nuke it from orbit. Then keep the newly installed OS properly secured. – Michael Hampton Nov 01 '18 at 14:56

3 Answers3

0

When you say VPS, do you mean a virtual server, running in a virtualisation solution, like KVM?

300% CPU simply means its running on 3 cores at any one time. If its a virtual server, and been allocated 3 cores - if its doing something, all allocated CPUs should be busy, to find out what its doing, youll need to connect to the server, and run top, or ps there.

Sirch
  • 5,697
  • 4
  • 19
  • 36
0

You can find out what the process is running by listing the exe link in the process directory: if the PID you see in top is 666, then execute ls -l /proc/666/exe.

That will (or at least should) show a -> arrow towards a file that you can analyze.

However, the name of the file is random, and that indicates with some confidence that your server has been compromised, and that you need to take immediate corrective actions which are out of the scope of this short answer. The best is to make sure that everything is backed up, and replace the VPS with an up-to-date OS. You want to determine how the intruder got in and make sure the new server does not have the same problem (change password, make sure any services offered to the Internet are secure, etc.)

Law29
  • 3,507
  • 1
  • 15
  • 28
  • since I could not even ssh into the VPS, I took no chance and rebooted as the service provider was understandably complaining. I will try to keep track of this in coming hours to see if something similar pops up its ugly head anew. – Jerome Nov 01 '18 at 13:49
  • Just rebooting will correct the symptom, but only for a time, because it will not correct the vulnerability that caused the problem. You need to audit the server -- you probably do not need a top-notch professional to do it, but you do need someone competent in Linux server security. – Law29 Nov 01 '18 at 14:21
  • @Law29 any suggested utilities for an audit? `rkhunter`, `lynis`, other ? – Server Fault Nov 01 '18 at 14:28
  • @ServerFault This is more `rkhunter` than `lynis`. I was thinking of a more manual high-level audit: what are the open ports, what are they running, are there any obvious config errors (redis without password exposed to the Internet, for example), are there any files named cER6XH or any other files that should obviously not be there. If nothing is found that that way, then an automated tool would be helpful. @Jerome may want to take a snapshot of the server if the VPS service permits that. – Law29 Nov 01 '18 at 14:55
0

I would issue ps -ef and grep for the process. The columns in the ps output are UID, PID, PPID, C, STIME, TTY, TIME and CMD. look at the PPID column to determine which parent process launched cER6XH. Re-issue the ps command and grep for the parent process PID. Eventually, you should find out which binaries are involved and possibly track down which application should be investigated further.

An easier method (depending on how busy your system is) may be the pstree command, but pipe the output to less so you can view the pages of info in a sane way.

edit: reading the comment from @Law29: although the process name is a non-standard *nix utility and does look fishy, it's possible that another process you are running created a temporary shell script and forked something. The process name alone isn't a tell-tale sign of a compromise.

Server Fault
  • 3,454
  • 7
  • 48
  • 88