Brobot Malware Troubleshooting and Guidelines

Description of Issue

Brobot or PHP Brobot is a trojan infection that may affect Windows and Linux web servers that provide PHP scripting.  Most of the infections are caused by weak CMS applications (such as out of date or insecure Joomla or Wordpress installations).  The Brobot trojan provides attackers with access to include your server in DDoS attacks as well as a backdoor to your server to execute other commands or retrieve confidential information stored on your server.  The trojan infection is usually specific to just an affected website hosting the files included in the infection and are not an indication of a system-wide compromise or administrative/root level compromise.

Platforms Affected

  • Web servers with a PHP script interpreter

Requirements for Resolution

  • A system-wide search for infected files must be performed since multiple sites may be infected but not detected yet
  • The infected files must be un-modified or restored from a backup.  Since infected websites probably contain other similar malicious content, injected into legitimate webpages you must not simply delete infected files because they might be valid web pages that have been modified by a third party without your knowledge.
  • Steps must be taken to avoid re-infection

Recommendation for Resolution

If you don't already have a backup of your site please create one in case something goes wrong while you are correcting this issue.

Remove the Infected Material

You can use the following command to help identify infected webpages for the reported website (modify /home/*/public_html if needed):

find /home/*/public_html/ -type f -regex ".*php" | xargs egrep -rl '(php.*eval\(gzinflate|base64_decode\(\$_REQUEST\[|eval\(base64_decode *\(|*md5\(md5 *\()'

Please also look for the file php.class.php in /tmp, /var/tmp and /dev/shm. This script allows re-infection via uploading of files to the server. 

Remove the Vector Used to Infect the Material

It’s important to not only remove the content involved in the malware attack, but to also identify and fix the vulnerability that allowed such content to be placed on your site. Once you've cleaned the offending content from the site please correct the vulnerabilities that may have allowed this to happen.

  • Vulnerable Software or Content Management System

We ask that you verify all software versions and web applications running on the server and confirm they are current or patched with the latest security updates. Examples of these types of applications are apache, control panels (Plesk, cPanel) or website CMS (joomla!, wordpress, drupal) including plugins, modules and/or themes.

  • Insecure Files/Folders Permissions

Files and/or folders in your website's content should not have full read-write execution permissions for everybody. Most files only require permissions of 644 (-rw-r--r--) and directories usually only require permissions of 755 (-rwxr-xr-x). Please be sure to check the ownership of those files and directories as well.

  • Weak/Stolen Passwords (including FTP and SSH accounts)

Please ensure you are enforcing a secure password policy and change all passwords of the compromised account. Do not use default passwords. At a bare minimum a password should contain both uppercase and lowercase letters as well as at least one number and not be based on a dictionary word. We recommend you to install an intrusion detection software (like ConfigServer Security & firewall or Fail2Ban) to protect your accounts against bruteforce attacks.

  • Modified .htaccess Files or Other Malicious Files

Quite often files are uploaded on the website such as php backdoor, php mailers, or php files containing a malicious javascript or iframe code. These must be removed.

  • Please also check any recently modified files in the involved website content, and any other files in the same involved folders or other vulnerable folders.
  • Another recommendation is to install Maldet (LMD) and Clamav, and run the scans regularly across all your websites and your /var and /dev/shm directories.
  • Investigating your access_log file can sometimes provide useful information about the attack.


Article is closed for comments.
Powered by Zendesk