edit-icon download-icon

System CPU exhaustion caused by minerd, tplink and other mining processes in ECS Linux

Last Updated: May 08, 2018

Note: The mining programs mentioned in this article only serves to provide technical staff with troubleshooting ideas and may not be precisely consistent with the actual scenarios. See examples of actual scenarios for more information.


The CPU usage rate of the ECS Linux server exceeds 70% and even reaches 100% in severe cases. Or the server response is slow.


Run the top command in the server. The result is as follows.


From the result, an abnormal minerd or tplink process takes up a lot of CPU resources. This process comes from a Bitcoin mining program that was maliciously installed after the server was broken into. In general, the program is located at /tmp/.

If you cannot see such processes by using the top command, you can use the ps command instead to check relevant processes. For example,


This process exists in the server. If the process was not enabled by you or other users, then your server most probably have been compromised and become someone else’s bitcoin miner.

Hidden malicious processes

A hacker may use the rootkit to break into the host and deploy a hidden mining program. As a result, the CPU usage can reach 90-100 %. In this case, you cannot check the running processes by using the top and ps commands.


  • Run the following command to get the file path of the minerd or tplink program through PID. Then, locate and delete the corresponding file.

    1. ls -l /proc/$PID/exe

    Where, $PID is the corresponding PID of the process. You can get the PID through running the ps or top command.

  • Use the kill command to close the process.

  • We recommend that you enhance security maintenance for the server and optimize the code to avoid program vulnerabilities that may allow intrusion into the server.

Hidden malicious processes

Hidden malicious modules include raid.ko, iptable_mac.ko, snd_pcs.ko, usb_pcs.ko, and ipv6_kac.ko. You can use the file /lib/udev/usb_control/... command to separately check whether the preceding modules exist in your server.

For example, you can use the following command to check whether the iptable_mac.ko module exists.

  1. file /lib/udev/usb_control/iptable_mac.ko

The result is as follows. From the result, a hidden iptable_mac.ko module exists.


Thank you! We've received your feedback.