tekkie wrote:I received alerts from my data center (OVH) that an IP on a virtual machine belonging to a client had been blocked for attacking numerous IPs. I confronted him and he had no idea what I was talking about. I looked into it further to see that the server was trying to connect back to 115.231.17.13:36665 and that top showed a process called nhgbhhj using a lot of CPU. I found that it was running out of /etc/nhgbhhj, but opening it with nano just showed random symbols...
That machine was infected these campaign of Billgates:
https://twitter.com/unixfreaxjp/status/ ... 3494391808 < only this campaign has that callback, and the callback in every bins is specific.
It's good to know which "process name" the malware is. Your lsof & netstat/sockstat is your friend for this. Aim the thread PID, which can be only one parent, ignore the child. Seek file of /tmp/gates* < this contains PID of the parent thread of the malware, you can kill that PID and all process of DDoS/backdoor will be stoped. Check again in the lsof|netstat to make sure no active process running. This is a howto kill the malware running process smoothly. DDoS process and multiple thread runs by the malware is exhausting the CPU.
Linux/BillGates will be auto-started since it is installed in xinetd. Check in which UID "/etc/nhgbhhj" runs, since "/etc was mentioned I think it gets the root already, anyway, pls check. If suid=0 was taken then you will have a lot to clean up, like: check every entry used in /etc/init.d/, check the /etc/rc.local, check the /etc/crontab for suspicious entries < not so much area to check and this is all they are using. Don't delete that file without seeing the contents, which will tell which basedir of the malware payload, use the data to clean the infected directory/unix user.
Lucky that in this case you have specific data of callback which lead to specific known malware. I always crite the CNC info in each ELF malware I found for this purpose to help sysadmins know which ELF hits them.
About root privilege. In my country, if suid 0 of a NIX server taken by malware/backdoor. I can not trust that machine anymore. It's not about the malware itself, but it is about "what else" the hacker did after getting suid 0, so I strongly suggest you audit the system, or restore it from image backup, or rebuild it. I saw many cases that the attacker implement special crafted user access for the "second visit" after the malware part was cleaned.
Very important point: BillGates in all cases I see, was installed AFTER the attacker gained the shell environment. The malware can run with or without root privilege. It depends on the attacker to gain the root or not gaining the root, not the malware. And in your case "it looks like" (noted: I did not see your system info well) there is a strong probability they got the root.
