2

I just noticed a high CPU usage on my server in the last few days and checked the processes. It appears that these 2 process below is consuming my CPU usage:

30741 www-data  20   0   89556  10264      4 S 213.6  0.1  26636:45 /tmp/sshm -c /tmp/.u
18575 www-data  20   0  725948  10244     56 S 212.3  0.1   6608:57 /tmp/.FILE/stak/ld-linux-x86-64.so.2 --library-path /tmp/.FILE/stak /tmp/.FILE/stak/xmrig -o 195.22.126.117:443 -u 45ENzNUptUrV8nLM2Cwwwb1r98M7ZPocmdsmg1SKWAL6b8DJQcU3+

Is my server hacked or,as I read on some other places, being used for crypto-currency mining? What should I do in this situation?

I would really appreciate any help/support. Thank you!

8
  • 4
    If it isn't your miner process running as www-data (httpd) from /tmp, then your server is quite possibly hacked.
    – sebasth
    Commented Apr 24, 2018 at 22:02
  • I read in other articles about the Jenkins servers (which mine is) issue that turn them into XMRIG mining slaves - which can be seen in "/tmp/.FILE/stak/xmrig -o". Does anyone know how to stop & remove this from the server?
    – Vu Hoang
    Commented Apr 24, 2018 at 22:06
  • Put the server into single user runlevel. Block the IP in your log on the FW. Kill processes. Remove their files. Patch the vulnerability and return to normal op. This way you may be able to avoid rebuilding.
    – ajeh
    Commented Apr 24, 2018 at 22:27
  • 1
    Your server is hacked and being used for crypto-currency mining. Commented Apr 24, 2018 at 22:48
  • 3
    The intruder has probably done something to make the system give you false information about either the system's firewall configuration, or about the source IP of the intruder. This is why dsstorefile said you'll have to restore from backup: you don't know for sure the full scope of the intruders' actions without a very labor-intensive investigation. Restoring from backup and/or rebuilding is usually easier, and gives you a strong guarantee that no intruder's tools are left hidden in the system.
    – telcoM
    Commented Apr 25, 2018 at 5:55

1 Answer 1

3

Just by looking at your posted output, I can see a cryptocurrency miner xmrig running. If you did not intend to launch that process, someone with sufficient access was able to.

You posted two processes, each of them look very suspicious:

30741 www-data  20   0   89556  10264      4 S 213.6  0.1  26636:45 /tmp/sshm -c /tmp/.u

This is a process owned by www-data running an executable, /tmp/sshm, with the argument /tmp/.u. You should be able to inspect those two files to determine if they are malicious or not.

18575 www-data  20   0  725948  10244     56 S 212.3  0.1   6608:57 /tmp/.FILE/stak/ld-linux-x86-64.so.2 --library-path /tmp/.FILE/stak /tmp/.FILE/stak/xmrig -o 195.22.126.117:443 -u 45ENzNUptUrV8nLM2Cwwwb1r98M7ZPocmdsmg1SKWAL6b8DJQcU3+

This is another process owned by www-data, and this is the cryptocurrency miner. It has installed itself into /tmp/.FILE. If you did not install and run this, then you are most certainly exploited somewhere.

If those processes are malicious, you want to kill them so they stop running. You would then want to look for the entry point of these malicious files. Since they are owned by www-data, you most likely have a legitimate process on this server running as that user, possibly a web server or application, that is allowing the creation and execution of these files.

You need to find that entry point as soon as you can and fix it, or the malicious files will probably just come back again. Looking at your log files should help. Make sure to check anything that the www-data user is able to do. Double check your web server and/or web applications to make sure they are not allowing the installing and execution of these files.

One server hardening step I have seen to mitigate these kind of issues is to not allow exec from /tmp at all: mount -o noexec,remount /tmp.

2
  • 1
    I understand the hedging, but I'm confident in saying that nobody has ever installed a cryptocurrency miner in a hidden directory in /tmp and then run it under their web server's account Commented Apr 25, 2018 at 4:43
  • Whilst noexec in /tmp and /var/tmp would be pretty a good idea, many installers, including Debian APT, depend on having exec there. You will break things. Commented Apr 25, 2018 at 8:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .