Last week we described the hack that randomly redirected site visitors either to a parked test0 .com domain or to malicious sites via the default7 .com domain. This week the default7 .com domain went down but the attackers returned with a new wave of site infections and the new redirecting domain – test5 .xyz (registered just a few days ago on May 7th, 2016).
This new domain points to the same dedicated server as default7 .com – 199 .48 .227 .25 (United States Carlsbad Plankton Tech Inc) and it still redirects eligible visitors to malicious sites and the rest to a parked test0 .com domain.
Malware + Ads Combo
Here’s an example of a redirect chain that leads to a fake Flash update download with a very poor detection rate of 2/56 on VirusTotal.
In the final redirect, the visitor is delivered an executable file:
Interestingly enough, the fake Flash update site also loaded ad scripts (adk2x is well known for malvertising). These scripts tried to open a scam site in a popup window:
adsrvmedia .adk2x .com/imp?p=71630944&ct=html&ap=1303&iss=0&f=0
Most likely they use this hybrid technique to maximize the conversion rate.
New Injected Code
The malicious code is still being injected at the top of the active theme’s header.php file but it looks and works differently.
This code resembles the older version of the same attack where it infected the footer.php file. While the code is not obfuscated, it is more complex to understand and uses client-side redirects instead of the server-side redirects from the previous version of the attack.
To get redirected, a visitor has to pass several levels of this malware, each of which requires a separate HTTP request. This is supposed to hinder detection by scanners that do not see the whole picture.
Step 1 – Set IP Parameter
Where nnn_nnn_nnn_nnn is the server’s IP address. The dots are replaced with underscores (e.g. 10_123_123_123 instead of 10.123.123.123)
This script doesn’t reveal much about its malicious nature – just another script from the same site. The only suspicious thing about it is it requests a home page instead of a real .JS file.
Step 2 – Check Cookies
The goal of this code is to hide the malware from returning visitors and load the real malware from a third-party site. It checks for the same Jf8y6S2aifZVynJb6hEZ cookie to identify returning visitors.
Step 3 – Return Gateways
To get the URLs of the third-party sites, the script makes one more request to the same infected page. This time with this parameter: /?sXnj0DSOvuqJQ7SnZkS6=1
When the injected code detects this parameter, it returns the list of URLs:
hxxp://22degrees .co.nz/wp/wp-content/themes/lightweight/main .php
hxxp://alf-mutschelbach .de/wp-content/themes/lightweight/track .php
hxxp://newsweetpix .com/assets/track .php
hxxp://morrow-technologies .com/wp-content/themes/lightweight/inc .php
The script from step 2 uses these URLs to dynamically load external scripts from them. Since the URLs reside on hacked sites, the redundancy helps keep the attack alive, even if some of the gateways scripts get removed. If all the scripts are live, usually only the first one returns malware. Most likely, behind the scenes, they all communicate with the same C&C server. This ensures the malware only returns the payload once for each visitor’s IP address.
Using this scheme – where gateways communicate with a common central server – adds flexibility to the attack, as it can change the redirect URL and the malicious payload anytime without making changes on the infected sites.
Step 4 – Final Redirect
The gateway returns the BetterJsPop script. This either creates a popup, or redirects to test5 .xyz. It also sets the Jf8y6S2aifZVynJb6hEZ cookie for one year to recognize returning visitors (which it checks for in step 2).
Cleanup and Prevention
As we showed last week, this attack commonly uses stolen WordPress credentials to log into admin interface and use the theme editor to inject malware into theme files. That’s why we suggest the following steps to clean and harden your site.
- Remove the malicious code from your theme files. This attack injects the malicious code at the very top of header.php (and footer.php in some older versions, or administrator/includes/help.php in the case of Joomla) so it’s easy to find and remove it. If in doubt, replace the whole theme with a clean backup version (or get a new copy from WordPress theme repository or the theme’s developer).
- Make sure there are no new WordPress users.
- Change passwords of all WordPress admin users.
- Most likely you don’t edit theme files every day, so it’s a good idea to prevent them being edited in WordPress admin interface. To do this, you can either revoke write permissions from theme files (change their permissions to 444) and/or disable file editing using this setting in your wp-config.php file:
define( ‘DISALLOW_FILE_EDIT’, true);
- Hinder brute force attacks against your blog. You can use plugins that limit login attempts, and/or change the login form URL. Consider disabling XML RPC if none of your plugins use it.
- Restrict access to the WordPress admin interface, so that only trusted IPs can use it. Our WAF offers this option by default.
- Although this attack doesn’t directly use software vulnerabilities, make sure that everything is up to date and all the core files are intact.
Overall, it’s a good idea to employ a website firewall that not only will protect your site from attacks that exploit vulnerable code but also stop brute force attacks and prevent access to restricted areas of your site.