The process seemed to be receiving instructions from an external server as highlighted here.
This is the usual behavior of bots, where malware contacts an external control server to receive commands from a botmaster.
Rescue action – Killing the bot, Blocking the IP and Neutralizing the malware
Our immediate concern is to rescue the server from high load and possible IP blacklisting.
So, once we identified the malware and its source, we:
- Killed the bot process (masquerading as apache2).
- Blocked the IPs to which the bots communicated (most possibly bot controller IPs).
- Made the malware files non-executable and non-readable (which prevents the process from starting again).
Now reload and check, if the bot process came back and if the server load went down.
What’s the extent of the damage? Finding all locations of malware
Now, we know that when an attacker gains access to a server, they don’t leave malware only in one location.
They’ll spread it as wide and deep as possible.
So, we then looked in these areas:
- Newly inserted code within legitimate web files.
- Malware hidden as images, or other such innocuous files.
- Crontab, which is used to re-trigger bot process if one is killed.
How did the malware get here?
Our next priority is to find out which vulnerability in the website or server allowed the attacker to get in.
For this, we looked at the file creation time of each malware file and correlated that with server access logs in HTTP, FTP and Plesk file manager.
Killing the malware & Cleaning the server
Now that we had all the information we needed, we cleaned all malware off the account and restored any needed file from backup archives.
Securing the account
Reset all passwords to prevent attacks using stolen credentials.If you are still facing the same issue then hire our experts.
